[10:09] <alf_> alan_g: Have you been able to reproduce a GBMDisplayTest.drm_device_change_event_triggers_handler failure locally?
[10:09] <alan_g> alf_: not tried very hard (yet)
[10:09] <alf_> alan_g: ok, I am looking into it, and the best I could to is cause it to "mir_unit_tests: src/uevent_sender.c:213: uevent_sender_send: Assertion `subsystem != ((void *)0)' failed"
[10:10] <alf_> alan_g: actually, with gtest_repeat I get that assertion failure fairly consistently
[10:11] <alan_g> alf_: I assume my changes have no effect on that?
[10:12] <alf_> alan_g: No, I don't think so, it also happens in the CI for ~afrantzis/mir/lgpl-gbm-android.
[10:13] <alan_g> OK. Do you want help? Or can I leave you to investigate for now?
[10:15] <alf_> alan_g: I am OK for now, I will let you know if I hit a dead-end, thanks
[11:24] <alf_> alan_g: ok, found the issue with the test and I am experimenting with a solution
[11:24] <alf_> (well tentative solution)
[11:27] <alan_g> alf_: well done
[11:27] <alan_g> Guesses it was a race condition
[11:28] <alf_> alan_g: well done to you too :)
[12:31] <alf_> alan_g: https://code.launchpad.net/~afrantzis/mir/fix-gbm-udev-events-test/+merge/197182
[12:31] <alan_g> alf_: ta
[13:02] <pete-woods1> tvoss_: good afternoon / ping !
[13:02] <tvoss_> pete-woods, hello :)
[14:43] <alan_g> alf_: looking at greyback's hacks for qt composition reminds me that the lack of information about what changed when calling the notify_change is something we need to address. (In this case he's created a second callback so that he knows which surface has posted a buffer)
[14:43] <greyback> alan_g: yep, I did that :)
[14:44]  * alan_g thinks that a surface pointer in the notification would be useful for other use cases too
[14:45] <alf_> alan_g: greyback: sure
[14:45] <greyback> alan_g: alf_ these are misc notes I took in my work: https://docs.google.com/a/canonical.com/document/d/12aVPbX5qzr2GqF8yBcc17ZWsD9Z1kQfoSaYi2yMm1rE/edit
[14:45] <greyback> They're rough, but I'd say they're of interest
[14:46] <alf_> greyback: very useful, thanks
[14:47] <alan_g> I'd also like to factor in the display on notification we were discussing re the GNexus problems
[14:49] <alan_g> greyback: useful notes. I think there are some alternative solutions but knowing the problems is good.
[14:49] <alf_> greyback: @generic way to call eglGetProcAddress(), can you please elaborate, it's not clear what's blocking us from using  eglGetProcAddress()
[14:49] <greyback> alan_g: oh of course, I just hacked in what I needed
[14:50] <greyback> alf_: I suppose nothing stops me calling eglGetProcAddress. Just didn't know if Mir should wrap it or not. Probably not..
[14:50] <alan_g> sure, experimenting is how we learn the right approach
[15:05] <dandrader> should libmirserver and libmirclient be mutually exclusive (ie. a binary shouldn't link to both) or they're complementary?
[15:06] <alan_g> dandrader: the nested server uses both
[15:06] <dandrader> alan_g, ok
[15:07] <dandrader> alan_g, because I was looking at the android-input symbols exported by then. mirserver needs "android::InputChannel::openInputFdPair(int&, int&)" but mirclient is the one providing it
[15:07] <alan_g> alf_: I can think of several changes to notify: buffer_posted_on_surface, surface_created/translated/resized/raised, output_off/on/resize/translated
[15:08] <dandrader> not saying it's right or wrong. just noticed it
[15:08] <alan_g> Does this suggest a listener interface interface?
[15:08] <alan_g> dandrader: It could be wrong, but the server does use the client library
[15:09] <dandrader> alan_g, theoretically I suppose mir libs shouldn't let any android symbol out. but in practice it's very useful for the qt-scene-graph-as-compositor prototype work :)
[15:11] <alan_g> dandrader: I think we need to police our exports. But there's too much in movement ATM
[15:12] <dandrader> alan_g, agreed
[15:12] <alan_g> dandrader: I've also been saying that we should rename the "android" namespace in  the input stack fork
[15:14] <dandrader> I suppose RAOFs refactoring work of android-input will effectively pull that code out of 3rd_party and reshape them to fit mir's style and naming. ie. make mir absorb android-input
[15:15] <alf_> alan_g: The listener would make sense to have in our new model
[15:16] <alf_> alan_g: I am not sure about whether output_off/on/resize/translated belongs in the same listener. Depends on what the model contains etc
[15:16] <alf_> alan_g: or whether we provide some kind of facade
[15:17] <alan_g> alf_: I think that outputs *should* be part of the model
[15:18] <alan_g> But they're not yet. (Nor is some of the input model - which I've yet to get my head around)
[15:19] <alan_g> alf_: I was thinking of changing out existing functor to an interface and then adding events over time.
[15:34] <alf_> alan_g: sounds good
[15:35] <alf_> alan_g: and +1 for a comprehensive model