| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik | ||
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 | |
| 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 :) | 08:32 |
| === francisco is now known as Guest2384 | ||
| kdub | morning folks, status, working on internal client/inprocess-egl for android | 15:07 |
| kdub | specifically, expanding the platform abstraction to accomodate android | 15:07 |
| kdub | also mp-ed a unification of our types around native buffer handles | 15:08 |
| kdub | are we having mir sessions at v-uds next week? | 15:29 |
| tvoss | kgunn, ping | 15:46 |
| kgunn | tvoss: pong | 15:46 |
| tvoss | kgunn, do you have any mir sessions planned next week? | 15:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| kgunn | racarr_: would you be cool with that? (since you'd likely get stuck driving :) | 15:50 |
| === mmrazik is now known as mmrazik|afk | ||
| kdub | i kinda wish the c++ steering committee had just used 'sp' for 'shared_ptr' | 17:39 |
| kdub | racarr_, ping | 17:47 |
| racarr_ | kdub: Hi :) What's up | 18:10 |
| racarr_ | kgunn: Ok sounds fun :) | 18:10 |
| racarr_ | <--Can't stay away from IRC | 18:11 |
| 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:13 |
| 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) | 18:19 |
| 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:37 |
| racarr_ | kdub: yay | 20:48 |
| RAOF | racarr_: Please don't be breaking the EGL spec :) | 23:17 |
| kdub | hello RAOF | 23:19 |
| 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:20 |
| kdub | why do we check for valid_displays in mir_egl_mesa_display_is_valid() ? | 23:21 |
| RAOF | Because mesa's EGL implementation checks what gets passed in to eglCreateDisplay to determine what platform is being used. | 23:24 |
| 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:26 |
| RAOF | Probably? | 23:27 |
| 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:28 |
| kdub | yeah... we'll see how the abstraction looks once I iterate on the gbm platform code a bit more | 23:34 |
| 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:50 |
| RAOF | That would seem to be reasonable. | 23:51 |
| 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. | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!