| === chihchun_afk is now known as chihchun | ||
| === Stskeepz is now known as Stskeeps | ||
| === dandrader is now known as dandrader|afk | ||
| 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:09 |
| alf_ | alan_g: actually, with gtest_repeat I get that assertion failure fairly consistently | 10:10 |
| alan_g | alf_: I assume my changes have no effect on that? | 10:11 |
| alf_ | alan_g: No, I don't think so, it also happens in the CI for ~afrantzis/mir/lgpl-gbm-android. | 10:12 |
| alan_g | OK. Do you want help? Or can I leave you to investigate for now? | 10:13 |
| alf_ | alan_g: I am OK for now, I will let you know if I hit a dead-end, thanks | 10:15 |
| === dandrader|afk is now known as dandrader | ||
| === Prf_Jako1 is now known as Prf_Jakob | ||
| alf_ | alan_g: ok, found the issue with the test and I am experimenting with a solution | 11:24 |
| alf_ | (well tentative solution) | 11:24 |
| alan_g | alf_: well done | 11:27 |
| alan_g | Guesses it was a race condition | 11:27 |
| alf_ | alan_g: well done to you too :) | 11:28 |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| alf_ | alan_g: https://code.launchpad.net/~afrantzis/mir/fix-gbm-udev-events-test/+merge/197182 | 12:31 |
| alan_g | alf_: ta | 12:31 |
| pete-woods1 | tvoss_: good afternoon / ping ! | 13:02 |
| === pete-woods1 is now known as pete-woods | ||
| tvoss_ | pete-woods, hello :) | 13:02 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| 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:43 |
| * alan_g thinks that a surface pointer in the notification would be useful for other use cases too | 14:44 | |
| 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:45 |
| alf_ | greyback: very useful, thanks | 14:46 |
| alan_g | I'd also like to factor in the display on notification we were discussing re the GNexus problems | 14:47 |
| 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:49 |
| 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 | 14:50 |
| dandrader | should libmirserver and libmirclient be mutually exclusive (ie. a binary shouldn't link to both) or they're complementary? | 15:05 |
| alan_g | dandrader: the nested server uses both | 15:06 |
| dandrader | alan_g, ok | 15:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| alan_g | dandrader: I think we need to police our exports. But there's too much in movement ATM | 15:11 |
| 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:12 |
| 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:14 |
| alf_ | alan_g: The listener would make sense to have in our new model | 15:15 |
| 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:16 |
| alan_g | alf_: I think that outputs *should* be part of the model | 15:17 |
| alan_g | But they're not yet. (Nor is some of the input model - which I've yet to get my head around) | 15:18 |
| alan_g | alf_: I was thinking of changing out existing functor to an interface and then adding events over time. | 15:19 |
| alf_ | alan_g: sounds good | 15:34 |
| alf_ | alan_g: and +1 for a comprehensive model | 15:35 |
| === chihchun is now known as chihchun_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!