| racarr | kgunn: Wait so whattimeisitnow? Not sure ifitupdated in my calendar | 01:12 |
|---|---|---|
| racarr | i.e. dont remember when it was last week | 01:12 |
| kgunn | racarr: hey...so...i forgot to make it a repeat anyway...so i had to just send a new invite | 01:13 |
| kgunn | racarr: so its, 3hr 15 min from now | 01:13 |
| racarr | kgunn: Ok | 01:17 |
| racarr | depending on how my soon to start bus bound adventure goes I may be a little late. | 01:17 |
| kgunn | racarr: np | 01:17 |
| duflu | kgunn: Make it earlier perhaps? As in 90 minutes? | 01:29 |
| === chihchun_afk is now known as chihchun | ||
| kdub | duflu, good job on the resizing work :) all my devices seem to work with it | 03:10 |
| duflu | kdub: Thanks, but it's still laggy without events | 03:13 |
| duflu | kdub: BTW, even Nexus7? I've found Mir on N7 hasn't responded to touch properly (if at all) for some time | 03:14 |
| duflu | --> bug 1239501 | 03:15 |
| ubot5 | bug 1239501 in Mir "Nexus 7 does not respond to touch" [High,Triaged] https://launchpad.net/bugs/1239501 | 03:15 |
| duflu | Hmm, hanging the server with a broken client is bad, right? | 09:35 |
| alan_g | yep | 09:39 |
| duflu | Argh. So. Many. Deadlocks | 09:41 |
| duflu | . | 09:41 |
| alan_g | Want to talk about it? | 09:41 |
| duflu | alan_g: If I had the words to describe them I would have logged bugs. But for now it's easy to blame myself, since they only happen on my branch | 09:43 |
| duflu | Although me finding deadlocks is different to me causing deadlocks :/ | 09:44 |
| alan_g | so true | 09:44 |
| duflu | One of the major problems I have encountered is our client event callbacks coming in on their own thread. That's quite a problem for simple single-threaded clients. | 09:45 |
| alan_g | Hmm. We don't have control of the single tread to execute callbacks on it - so what would you do instead? | 09:47 |
| duflu | alan_g: I presently have to use pthreads in the single threaded client to signal the primary rendering thread from the event thread. That's not ideal | 09:49 |
| alan_g | Why does the simple single-threaded client need to use callbacks? Doesn't the ..._sync API cover it? | 09:50 |
| duflu | alan_g: How else do you get immediate notification of resizing? | 09:51 |
| duflu | ... or input etc | 09:51 |
| duflu | Or do you mean we need a mir_wait_for(mir_next_event(&e)) ? :) | 09:52 |
| alan_g | So, you'd want to poll an event queue? | 09:52 |
| * alan_g bad memories of the Windows event loop | 09:52 | |
| duflu | alan_g: Not poll. I'm happy to have everything event driven and sleeping nicely. But whatever it takes to get clients back to one thread would be excellent | 09:53 |
| duflu | or perhaps: what = mir_wait_for_either(mir_sleep(n), mir_next_event(&e)) | 09:54 |
| alan_g | mir_get_event_sync(...)? | 09:55 |
| duflu | alan_g: You really need support for waiting on multiple handles simultaneously to do it properly. Like Win32's WaitForMultipleObjects | 09:56 |
| duflu | mir_wait_for_any(a, b, c, NULL) | 09:57 |
| alan_g | Perhaps - but doesn't that go further than the "simple" single-threaded client case needs? | 09:59 |
| alan_g | BTW How does this hang the server? | 10:00 |
| duflu | alan_g: I have the server hung in send() sending a trivial resize notification, while the client is somehow deadlocked. | 10:03 |
| duflu | I'll just avoid that path for now and if I can describe the problem in terms of existing logic, then log a bug | 10:03 |
| alan_g | duflu: that's clearly a server side bug - I can look at that later | 10:04 |
| alan_g | duflu: if the default event callback were to push events into a queue and we provided an optionally blocking call to pull off the queue doesn't that cover the simple case? | 10:13 |
| duflu | alan_g: Essentially yes. I would want to fuss over the client-side API we expose though. In the least you need to be able to wait for any-and-all Mir things that could be happening, including a timeout/sleep to animate the client | 10:15 |
| duflu | Even more weird... it's safe for an event callback to swap_buffers on motion events, but not on resize events which originated from motion events | 10:18 |
| alan_g | Does "safe" mean guaranteed by a standard? Or just "doesn't break on my machine"? | 10:20 |
| mlankhorst | What if the standard is doesn't break on my machine? ;) | 10:20 |
| duflu | alan_g: Doesn't *seem* to break and has worked for most of the year | 10:20 |
| duflu | (as in fingerpaint) | 10:21 |
| alan_g | Ah | 10:21 |
| duflu | alan_g: It appears my hanging send() contains a TODO :) [mfd::SocketMessenger::send()] | 10:27 |
| alan_g | That TODO is a typical comment - it disagrees with the code | 10:30 |
| alan_g | the send_fds it refers to is now part of that function | 10:31 |
| duflu | alan_g: I mean that I need it to be async. It's not. | 10:31 |
| duflu | What are the "fds" we're passing around all the time?? | 10:32 |
| alan_g | duflu: It shouldn't block anyway - so being async would be at best an optimization | 10:32 |
| duflu | alan_g: It seems a broken client can block it :) | 10:33 |
| alan_g | the fds are handles from gbm or android | 10:33 |
| duflu | alan_g: Why do we use them on every message? That's weird | 10:33 |
| alan_g | They're optional on all messages. Only a few send them | 10:33 |
| alan_g | The wire protocol is blob+optional fds | 10:34 |
| duflu | alan_g: Oh, I see. Empty if not provided | 10:34 |
| alan_g | ack | 10:34 |
| alan_g | So you think we're writing bytes to a socket and get throttled because the client isn't reading the other end? | 10:37 |
| === chihchun is now known as chihchun_afk | ||
| duflu | alan_g: Yes, I think so. Another (probably different) problem I have now is that the surface events come in on a different thread to input events. Yet they share the same callback so it's very confusing | 10:51 |
| duflu | I suspect we'll need to solve this before resize events can be usefully demonstrated. Unless I instrument all the examples with pthread magic, but that's bad | 10:52 |
| alan_g | @"on a different thread" - that's weird. I though there was just the comms thread (and any threads the client code has) | 10:55 |
| duflu | alan_g: Weird, but I just remembered I documented that when I discovered it -- http://unity.ubuntu.com/mir/group__mir__toolkit.html#ga171267b0c507a17b2d76a8e927f2d959 | 10:56 |
| duflu | "and locking" should say "any locking" | 10:57 |
| * duflu closes the can of worms and wanders off | 11:04 | |
| alan_g | alf_: How strong is your preference for references? gmock is throwing up a bunch of errors when I set expectations on a mock of fill_ipc_package(BufferIPCPacker& packer, Buffer const& buffer) - it can't check anything for equality and doesn't like incomplete types. | 11:41 |
| * alan_g thinks pointers are fine anyway | 11:41 | |
| alf_ | alan_g: My preference is strong, but if references are causing problems I am OK with pointers. | 11:46 |
| alan_g | pointers it is then. | 11:57 |
| alan_g | tvoss_: when you have a moment: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/dont-use-ApplicationSession/+merge/193070 | 11:59 |
| tvoss_ | alan_g, looking | 12:08 |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| didrocks | kgunn: Mir in -proposed! (thanks to the restless Mirv) | 13:32 |
| didrocks | let me cry of joy for a minute :) | 13:32 |
| Mirv | :) | 13:36 |
| tvoss_ | didrocks, :) | 13:37 |
| greyback | could someone please check that Mir in daily-proposed works on the Nexus10? It's failing for me with http://pastebin.ubuntu.com/6448151/ | 13:38 |
| Mirv | addition to above, Mir almost in -release pocket as well (visible in LP that it's already accepted, waiting for publisher run) | 13:46 |
| alan_g | Must be time to try landing another batch of updates. ;) | 13:48 |
| Mirv | :) rmadison now tells it's in archives for real | 13:57 |
| fginther | kgunn, are https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1252933 and https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1252857 duplicates? | 13:58 |
| ubot5 | Ubuntu bug 1252933 in Ubuntu CI Services "Mir performance testing as a merge requirement" [Undecided,New] | 13:58 |
| ubot5 | Ubuntu bug 1252857 in Ubuntu CI Services "mir performance baseline, tracking, & blocking" [Undecided,New] | 13:58 |
| fginther | kgunn, I received 1252933 from thomi | 13:58 |
| === dandrader is now known as dandrader|afk | ||
| kgunn | Mirv: didrocks ...thanks both! | 14:03 |
| * kgunn will be laughing all day imagining didrocks crying tears of joy | 14:03 | |
| kgunn | fginther: lemme look | 14:03 |
| didrocks | kgunn: rohhhh! you have no idea about the pain we endure ;) | 14:04 |
| kgunn | fginther: yes...those seem to be duplicates, i guess thomi thot mine sucked :) | 14:05 |
| fginther | kgunn, I filed the second bug, didn't think to look for one first :-) | 14:05 |
| kgunn | fginther: np | 14:05 |
| === dandrader|afk is now known as dandradee | ||
| === dandradee is now known as dandrader | ||
| alan_g | greyback: I don't have one to test - but I think you need -r 1228 of dev branch for N10. trunk is based on r1192 | 14:28 |
| greyback | alan_g: okay | 14:32 |
| alan_g | greyback: and to use dev-branch we need to land https://code.launchpad.net/~alan-griffiths/unity-mir/dont-use-ApplicationSession/+merge/195242 (hint hint) | 14:33 |
| greyback | alan_g: sure. I'm trying to test it as I type, just bad luck I chose nexus10 to test it on | 14:34 |
| greyback | alan_g: I've added 2 little comments to that MR just now | 14:34 |
| alan_g | greyback: fixing... | 14:36 |
| alan_g | tvoss_: when you have a moment: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/dont-use-ApplicationSession/+merge/193070 | 14:37 |
| tvoss_ | alan_g, yup, still looking | 14:39 |
| Mirv | kgunn: you're welcome | 14:39 |
| alan_g | greyback: ...pushd | 14:40 |
| greyback | alan_g: thanks | 14:40 |
| === alex-abreu|afk is now known as alex-abreu | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|tea | ||
| greyback | alan_g|tea: https://code.launchpad.net/~alan-griffiths/unity-mir/dont-use-ApplicationSession/+merge/195242? approved, top approve at your desire | 15:45 |
| === alan_g|tea is now known as alan_g | ||
| alan_g | greyback: top-approved. Thanks | 15:46 |
| tvoss_ | alan_g, can I just use your branch of usc, latest Mir and whatever X drivers we have and give it a spin? | 16:18 |
| alan_g | tvoss_: I would hope so. | 16:20 |
| === dandrader is now known as dandrader|lunch | ||
| tvoss_ | alan_g, building right now, just wanted to check before I kill my local setup :) | 16:20 |
| * alan_g assumes that the trunk usc is working (hasn't tried it yet) | 16:21 | |
| tvoss_ | alan_g, can you give it a spin, too? | 16:26 |
| alan_g | tvoss_: I'm not really set up for it right now. Too many versions in flight | 16:28 |
| tvoss_ | alan_g, ack, I will give it a spin on two machines then. I'm hesitant to approve as usc has no no tests in place | 16:29 |
| alan_g | that's something I'd like to get fixed. But only one set of hands | 16:29 |
| tvoss_ | alan_g, sure, not saying it's your fault :) just explaining high latency for the review here | 16:35 |
| alan_g | tvoss_: I know. | 16:36 |
| === dandrader|lunch is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === RoddieKieley1 is now known as RoddieKieley | ||
| === dandrader|afk is now known as dandrader | ||
| mterry | Heyo! Can someone help me with a nested-mir issue? "Nested Mir failed to find an opaque surface format" | 19:37 |
| mterry | I can reproduce with just mir-demos | 19:37 |
| racarr | mterry: Oh this is the transparentstuff | 19:38 |
| racarr | mterry: https://code.launchpad.net/~robertcarr/mir/alpha-for-nested-servers/+merge/193162 will unblock you for nowbut it wont land | 19:39 |
| mterry | racarr, yeah. I realized today I've been testing all this time with that branch in place | 19:39 |
| mterry | racarr, assumed it would have landed by now. But I see that feedback is needed on that branch | 19:39 |
| mterry | racarr, what can I do to move that branch (or something like it) along? | 19:40 |
| mterry | racarr, at this point, it's not even what the greeter needs. This error is just preventing nested Mir at all | 19:40 |
| racarr | I guess I need to redo it to expose an option or something | 19:41 |
| racarr | oratleast pick a transparent format if there is an opaque one in plac | 19:41 |
| racarr | eerr | 19:41 |
| racarr | if there is no opaque one | 19:41 |
| mterry | racarr, also... is there not an automated test involving nested Mir? I would have expected such a test to hit this, although maybe this is android specific | 19:44 |
| racarr | no automated testing on actual android devices | 19:44 |
| mterry | racarr, well, once we land nested, I guess it will get tested all the time | 19:46 |
| mterry | racarr, well, if this could get highish priority, I'd give you a hug | 19:47 |
| mterry | racarr, I'm *so* close to landing nested mode | 19:47 |
| mterry | racarr, so why can't a nested Mir find an opaque surface format anyway? Why would that change in nested mode? | 19:51 |
| racarr | mterry: Oh it's just that nothing else insists on having an opaque surface. | 19:51 |
| mterry | racarr, oh | 19:52 |
| mterry | racarr, and android can't provide one? | 19:52 |
| racarr | mterry: Apparently not that seems like it must be abug though | 19:58 |
| mterry | racarr, OK, well if there's anything I can do to help, let me know | 19:59 |
| racarr | mterry: Ok thanks. I will get on it in like | 20:01 |
| racarr | 30mins | 20:01 |
| racarr | I forgot about the underlying bug when the branch was abandoned because we dont need alpha anymore | 20:02 |
| * kdub wades into composition options | 20:09 | |
| mterry | racarr, me too :) | 20:11 |
| mterry | racarr, and we do need alpha... just not immediately | 20:11 |
| mterry | racarr, greeter will still want to be semi-transparent | 20:11 |
| kdub | i don't really know why we even have that error | 20:29 |
| kdub | maybe gbm can't bypass buffers with alpha? | 20:30 |
| racarr | kdub: Ithink it was | 20:48 |
| racarr | "optimization" | 20:48 |
| racarr | and a weird strategy ;) | 20:48 |
| rsalveti | kdub: so, one more device, the emulator :-) | 21:26 |
| rsalveti | 5 "android"-based devices | 21:26 |
| kdub | rsalveti, yeah | 21:27 |
| kdub | is that working with mir? | 21:27 |
| rsalveti | kdub: yup | 21:27 |
| kdub | oh :) thats good news | 21:28 |
| racarr | Just had a fun idea...trying to figure out how to make the focus mechanism make sense,the idea of customizing behavior doesn't make so much sense anymore, but it's nice for testing the default shell/system compositor, i.e. EXPECT(focus_setter, set_focus), v. EXPECT(surface_controller,raise) EXPECT(input_targeter, target) | 21:53 |
| racarr | so I had the idea that maybe there is a 'FocusTracker' which handles the bit of defocusing the focused surface (i.e. updating the attribute) when we focus a new surface | 21:56 |
| racarr | but rather than a 'FocusTracker' it could just be a callback | 21:56 |
| racarr | i.e. mf::Shell::create_surface(Session, SurfaceParameters, std::function<void(FocusState)> track_focus) | 21:57 |
| racarr | the more I type the less im sure :p | 21:57 |
| racarr | You can test instead with an integration test by acting on the event sink... | 21:59 |
| racarr | and thats probably more clear | 21:59 |
| racarr | mterry: https://code.launchpad.net/~robertcarr/mir/nested-dont-require-opaque-surface/+merge/196026 | 22:04 |
| racarr | should have just dont that right away :p its tiny | 22:04 |
| racarr | sorry | 22:04 |
| mterry | racarr, heh. why does nested mode want an opaque surface anyway? | 22:04 |
| mterry | racarr, the performance aspect? | 22:05 |
| mterry | racarr, oh, just noticed that you want me to review that branch. I can test on my device, sure. But should probably have an actual mir dev actually review | 22:15 |
| * mterry goes to test | 22:15 | |
| mterry | racarr, btw, I'm a little confused by the issues of performance around the alpha branch. If the background is alpha, but opaque things cover that background (like would happen in unity8), why would there be a performance hit? I figured that alpha bg would be optimized out | 22:37 |
| kdub | rsalveti, how does the emulator work? | 23:00 |
| kdub | kinda a vague question | 23:00 |
| kdub | but is it using a software egl for the android platform? | 23:01 |
| xnox | kdub: emulator is the same one as for android. there are egl libraries in android-container, which do pass-through to hypervisor, where a traslation from egl -> host gl is done, host's drivers are used to process gl, and it gets fed back into the emulator. | 23:26 |
| kdub | hmm, interesting | 23:28 |
| kdub | and the host is X... | 23:29 |
| kdub | xnox, how about the display? | 23:29 |
| xnox | kdub: there is no host X involved at all. | 23:30 |
| xnox | kdub: it's a virtual machine, based on goldfish kernel. so there is goldfish framebuffer which is what mir paints on. | 23:30 |
| xnox | to the user it is magically projected over vnc. | 23:30 |
| xnox | and that's how humans look at it =) | 23:31 |
| xnox | the egl -> gl -> egl translator is very cunning. | 23:31 |
| xnox | you can run emulator head-less, as in without projecting the vnc window anywhere. | 23:32 |
| kdub | so the emulator does the translation from android platform egl to the host platform's egl? | 23:32 |
| kdub | and the other curiosity is that mir only paints the fb via the android HAL surrounding the fb.... so there must be some goldfish friendly hwc somewhere | 23:33 |
| kdub | neat... | 23:39 |
| * kdub pokes around android code in this area | 23:39 | |
| kdub | okay, i see how this all works from a high level then.. very cool | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!