[08:27] <mlankhorst> RAOF: oh btw, http://people.canonical.com/~mlankhorst/plymouth-mir.patch
[08:27] <RAOF> mlankhorst: Oh, cool. Did you work out how input works?
[08:27] <mlankhorst> not yet
[08:28] <RAOF> You get a callback for your input events (you need to pass that callback to the server)
[08:28] <mlankhorst> RAOF: in what thread does the callback run?
[08:28] <RAOF> In surface creation.
[08:28] <RAOF> It runs in a random thread.
[08:28] <RAOF> I hope you're threadsafe! :)
[08:28] <mlankhorst> RAOF: but what if I want a fd + poll + call a function to run in the main thread
[08:29] <RAOF> ¹: Not actually random, but not under your control.
[08:29] <mlankhorst> that WILL be a common way of doing things..
[08:29] <RAOF> mlankhorst: Then you get to do something like hw/xfree86/xmir/xmir-thread-proxy.c at the moment
[08:29] <mlankhorst> if xserver does it, plymouth does it, gtk supports it
[08:29] <tvoss> RAOF, the callback will always only run on one thread, the client side is not using a threadpool
[08:30] <mlankhorst> tvoss: missing the point, it's not under the client's control :-)
[08:30] <RAOF> tvoss: Right, but the thread is not under the caller's control.
[08:30] <tvoss> mlankhorst, RAOF fair enough
[08:31] <mlankhorst> I think for now I'll wait then until there's proper threadless support
[08:31] <mlankhorst> even pulseaudio allows you to override it :P
[08:31] <RAOF> *Internally* input is on a fd, which the client library polls, so there's no particular reason why we can't expose a pollable fd, and I expect we shall.
[08:31]  * RAOF goes to settle Zoë
[08:32] <mlankhorst> RAOF: yeah this is why I won't mind waiting a bit longer, I can do it sooner but it relies on nasty hacks :)
[15:07] <kdub> morning folks, status, working on internal client/inprocess-egl for android
[15:07] <kdub> specifically, expanding the platform abstraction to accomodate android
[15:08] <kdub> also mp-ed a unification of our types around native buffer handles
[15:29] <kdub> are we having mir sessions at v-uds next week?
[15:46] <tvoss> kgunn, ping
[15:46] <kgunn> tvoss: pong
[15:46] <tvoss> kgunn, do you have any mir sessions planned next week?
[15:47] <kgunn> tvoss: kdub its on my todo....was thinking about breaking out the thrash testing stuff we added recently
[15:47] <kgunn> its a decent size topic
[15:47] <kgunn> and fairly unplanned
[15:47] <kgunn> but with semi-firm ideas
[15:47] <kgunn> about what we need
[15:48] <kgunn> so the todo part is just the bp wrangling
[15:48] <kgunn> getting on the agenda etc
[15:48] <tvoss> kgunn, cool, let me know if I can help
[15:48] <kgunn> tvoss: kdub racarr_ open to suggestions too....lemme know if you have a topic you;d like to add
[15:49] <tvoss> kgunn, input stack might be interesting, but other than knowledge transfer, I cannot think of topics
[15:49] <kgunn> tvoss: that might be good....just couch it as an info sharing session rather than work planning
[15:50] <kgunn> racarr_: would you be cool with that? (since you'd likely get stuck driving :)
[17:39] <kdub> i kinda wish the c++ steering committee had just used 'sp' for 'shared_ptr'
[17:47] <kdub> racarr_, ping
[18:10] <racarr_> kdub: Hi :) What's up
[18:10] <racarr_> kgunn: Ok sounds fun :)
[18:11] <racarr_> <--Can't stay away from IRC
[18:13] <kdub> racarr_, seems the mesa inprocess egl platform always returns the same EGLNativeDisplayType, it wouldn't break anything if it returns a new one each time mg::Platform::shell_egl_display() is called, would it?
[18:19] <racarr_> No I don't think so
[18:19] <racarr_> maybe it breaks share lists between contexts? (not that we use it or have plans to)
[20:37] <kdub> yay, got in-process/internal-client on android to work
[20:37] <kdub> now i just have to unbreak what i did to mesa ;-)
[20:48] <racarr_> kdub: yay
[23:17] <RAOF> racarr_: Please don't be breaking the EGL spec :)
[23:19] <kdub> hello RAOF
[23:20] <kdub> i'm trying to sort out the ownership story for mesa internal clients (as part of getting our platform abstraction to work for android clients)
[23:21] <kdub> why do we check for valid_displays in mir_egl_mesa_display_is_valid() ?
[23:24] <RAOF> Because mesa's EGL implementation checks what gets passed in to eglCreateDisplay to determine what platform is being used.
[23:26] <RAOF> So we need to be able to check if a random pointer is a valid Mir EGL display, so we can correctly initialise.
[23:26] <kdub> but, really, we just need one EGLDisplay for all internal clients
[23:26] <kdub> right?
[23:27] <RAOF> Probably?
[23:28] <RAOF> I mean, there's nothing stopping Mir servers from using more than one EGLDisplay, but I don't see any particular value to them to do that.
[23:28] <RAOF> It's unlikely to be a big deal if we say “shells get exactly one EGLDisplay”
[23:34] <kdub> yeah... we'll see how the abstraction looks once I iterate on the gbm platform code a bit more
[23:50] <kdub> seems though that an internal client can only establish one EGLDisplay connection though, that is
[23:50] <kdub> the connection to the process in which it exists
[23:51] <RAOF> That would seem to be reasonable.
[23:52] <RAOF> I'm not totally familiar with our in-process code. There doesn't seem to be any reason for an in-process shell to make more than one connection, though.