=== chihchun_afk is now known as chihchun === Stskeepz is now known as Stskeeps === dandrader is now known as dandrader|afk [10:09] alan_g: Have you been able to reproduce a GBMDisplayTest.drm_device_change_event_triggers_handler failure locally? [10:09] alf_: not tried very hard (yet) [10:09] 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] alan_g: actually, with gtest_repeat I get that assertion failure fairly consistently [10:11] alf_: I assume my changes have no effect on that? [10:12] alan_g: No, I don't think so, it also happens in the CI for ~afrantzis/mir/lgpl-gbm-android. [10:13] OK. Do you want help? Or can I leave you to investigate for now? [10:15] alan_g: I am OK for now, I will let you know if I hit a dead-end, thanks === dandrader|afk is now known as dandrader === Prf_Jako1 is now known as Prf_Jakob [11:24] alan_g: ok, found the issue with the test and I am experimenting with a solution [11:24] (well tentative solution) [11:27] alf_: well done [11:27] Guesses it was a race condition [11:28] alan_g: well done to you too :) === dandrader is now known as dandrader|lunch === dandrader|lunch is now known as dandrader [12:31] alan_g: https://code.launchpad.net/~afrantzis/mir/fix-gbm-udev-events-test/+merge/197182 [12:31] alf_: ta [13:02] tvoss_: good afternoon / ping ! === pete-woods1 is now known as pete-woods [13:02] pete-woods, hello :) === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [14:43] 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] 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] alan_g: greyback: sure [14:45] 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] They're rough, but I'd say they're of interest [14:46] greyback: very useful, thanks [14:47] I'd also like to factor in the display on notification we were discussing re the GNexus problems [14:49] greyback: useful notes. I think there are some alternative solutions but knowing the problems is good. [14:49] greyback: @generic way to call eglGetProcAddress(), can you please elaborate, it's not clear what's blocking us from using eglGetProcAddress() [14:49] alan_g: oh of course, I just hacked in what I needed [14:50] alf_: I suppose nothing stops me calling eglGetProcAddress. Just didn't know if Mir should wrap it or not. Probably not.. [14:50] sure, experimenting is how we learn the right approach [15:05] should libmirserver and libmirclient be mutually exclusive (ie. a binary shouldn't link to both) or they're complementary? [15:06] dandrader: the nested server uses both [15:06] alan_g, ok [15:07] 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] 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] not saying it's right or wrong. just noticed it [15:08] Does this suggest a listener interface interface? [15:08] dandrader: It could be wrong, but the server does use the client library [15:09] 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] dandrader: I think we need to police our exports. But there's too much in movement ATM [15:12] alan_g, agreed [15:12] dandrader: I've also been saying that we should rename the "android" namespace in the input stack fork [15:14] 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] alan_g: The listener would make sense to have in our new model [15:16] 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] alan_g: or whether we provide some kind of facade [15:17] alf_: I think that outputs *should* be part of the model [15:18] But they're not yet. (Nor is some of the input model - which I've yet to get my head around) [15:19] alf_: I was thinking of changing out existing functor to an interface and then adding events over time. [15:34] alan_g: sounds good [15:35] alan_g: and +1 for a comprehensive model === chihchun is now known as chihchun_afk