[04:46]  * Guest42341 What a fine day for science! 
[05:28] <RAOF> *Man* we don't care about object ownership at all.
[05:29] <RAOF> Want to receive events when a new surface is created? Congratulation! You're now a part-owner in all surfaces.
[05:31] <RAOF> Oh, for the love of god. Of *course* the_session_listener is a a singleton usable only by a consumer *outside* Mir.
[05:37] <RAOF> Raaaargh. Hulk SMASH!
[05:47] <Guest42341> :))
[09:14] <duflu> anpok_: It appears in my bucket-of-cheap-spare-mice that I have a choice between too-fast or smooth-but-sometimes-missing-kernel-events. Any hints for making mice smoother or more reliable?
[09:14] <duflu> Hmm, maybe "don't use cheap spare mice"
[09:45] <alf> vogons: Please take a look at the Display configuration API proposals in https://docs.google.com/document/d/1wpoHVYdPZGthN2WS8oDvhRlpyuUqrizK1C4quE4XwMk/edit# so we can have more meaningful discussions during upcoming meetings (standup, eu/aus/us syncs)
[10:04] <sturmflut2> I finally rebuilt glmark2 against the stable phone overlay PPA so it works on OTA-7 again, but it looks like at least on krillin sometimes the OpenGL ES context freezes until I trigger an event in Unity8, e.g. swipe in the launcher or the app switcher.
[10:05] <sturmflut2> I can post a link to the new click package for testing purposes
[10:09] <sturmflut2> Also happens on mako
[10:18] <alan_g> sturmflut2: thanks for trying the rebuild. I'm not sure who's best placed to investigate, but the link will help.
[10:21] <sturmflut2> http://hogsmeade.lieberbiber.de/~sturmflut/glmark2.sturmflut_0.5.0_armhf.click
[10:22] <sturmflut2> alan_g: At least the binary continues to write to stdout and switches between the benchmark scenes, so it's not completely frozen I think, it keeps trying to output something that maybe then isn't handed to the display in the end?
[10:24] <sturmflut2> I'll build it against X11 on the desktop too to make sure it's not a problem with the glmark2 code itself
[10:27] <Guest42341> sturmflut2, glmark2
[10:27] <Guest42341> Segmentation fault (core dumped)
[10:27] <Guest42341>  (on wily)
[10:27] <sturmflut2> Works fine on a 15.10 desktop with an Intel Ivybridge CPU/GPU (i915 driver)
[10:30] <alan_g> alf: any thoughts on the above?
[10:32] <duflu> sturmflut2: Not your fault. We know about it... https://bugs.launchpad.net/qtmir/+bug/1497828
[10:34] <duflu> alan_g: That freeze is a known issue ^
[10:34] <duflu> And then it was EOD
[10:35] <alan_g> duflu: ack, have a good evening
[11:08] <alan_g> anpok_: what's the state of https://code.launchpad.net/~andreas-pokorny/mir/load-all-supported-input-platforms/+merge/274421? Your last comment links it to https://code.launchpad.net/~andreas-pokorny/mir/move-cookie-test-to-acceptance-tests/+merge/275502 which got rejected.
[11:12] <anpok_> alan_g: bschaefer made a better version of the same
[11:12] <anpok_> so I removed my mp
[11:13] <anpok_> and that one landed this morning
[11:13] <alan_g> So load-all-supported-input-platforms is good to go?
[11:13] <anpok_> yes..
[11:14] <anpok_> evertything is currently waiting on the input abi bump
[11:14] <anpok_> which I reworked after a discussin with raof hmm on friday
[11:15] <alan_g> Great.
[11:15] <alan_g>  alf: could you look over https://code.launchpad.net/~alan-griffiths/mir/nested-server-applies-display-config-policy/+merge/275542 - I think it is orthogonal to your proposal (modulo stuff that still needs fixing) but I'd like your thoughts.
[11:16] <alf> alan_g: doing that right now (I also linked a bug report about this I had file some time ago)
[11:17] <alan_g> :)
[11:29] <alf> anpok_: When you get the time could you please take a look at https://code.launchpad.net/~alan-griffiths/mir/nested-server-applies-display-config-policy/+merge/275542 (see my last comment)
[12:00] <alan_g> anpok_: Looks like the merged pre-req confuses LP - https://code.launchpad.net/~andreas-pokorny/mir/input-configuration-api/+merge/273975
[12:13] <tjaalton> I'm about to push mesa 11.0.4 with ftbfs fix (1509005) to xenial, FYI
[12:23] <anpok_> alan_g: aye
[12:23] <anpok_> alf: I believe that is close to the reverse of the bandaid we had
[12:26] <anpok_> alf, alan_g: I believe the problem back then with the split-out greeter was that the screen is turned off usc switched to a newly craeated greeter session that turned the displays back on again.. because the nested server applied the display configuration on startup..
[12:26] <anpok_> *when the screen..
[12:27] <anpok_> but a lot changed since then... maybe usc would catch that..
[12:29] <anpok_> adding that to the review
[12:29] <anpok_> (i really didnt like the 'solution' back then)
[12:29] <alan_g> anpok_: that sounds like it would be caught by the check I added for "!= current config"?
[12:32] <anpok_> alan_g: hm what if the nested session sees the screen turned off on startup?
[12:34] <alan_g> anpok_: rather than speculate, there ought to  be a test case (even if we decide to land these changes first).
[12:34] <anpok_> i mean then the configs would/might be != .. and it would apply them - still this is the wrong place to make that decision
[12:34] <anpok_> yes.. imo the nested server should do that..
[12:35] <alan_g> Hmm. The greeter doesn't go through the nested server, so these changes shouldn't affect it.
[12:36]  * alan_g wonders if he understood the scenario correctly
[12:39] <anpok_> alan_g: hm oh i dont know how the greeter is done currently. That split greeter back then never landed..
[12:40] <anpok_> so for that scenario you need to have a nested session, turn the screen off, start a second nested session, focus the second nested session..
[12:40]  * alan_g was thinking of the spinner
[12:41] <anpok_> hm spinner is not submitting a config, is it?
[12:41] <alan_g> no
[12:43] <alan_g> Sounds like this isn't a scenario that currently matters. (And with the other bugs in this area I suspect it has problems anyway.)
[12:45] <alan_g> And at least a part of it is about USC policy.
[12:49] <anpok_> hm i think I wrote something similar to the review
[13:04] <kdub> should we be sending an initial visibility event? (I think we should be)
[14:04] <alan_g> kdub: what do you mean by "an initial visibility event"?
[14:05] <kdub> https://code.launchpad.net/~kdub/mir/initial-visibility-event/+merge/275704
[14:05] <kdub> :)
[14:06] <alan_g> alf: NI answered? https://code.launchpad.net/~alan-griffiths/mir/nested-server-applies-display-config-policy/+merge/275542
[14:06] <alf> alan_g: yes