[00:40] <racarr> RAOF: The second changes are necessary or it only makes one instance of the dri2_drv and the function pointers get overridden between the drivers
[00:41] <racarr> RAOF: You can test the changes with enable-inprocess-egl and the new example (bin/mir_demo_inprocess_egl)
[00:42] <RAOF> racarr: Aaah, thanks. Right, yeah, now I can see why the second change.
[00:45] <RAOF> I think the second change is still wrong, or rather needs additional changes to make it not-wrong :)
[00:45] <RAOF> But I'll start poking at them now.
[00:50] <racarr> RAOF: Thanks :)
[02:01] <thomi> Hey guys - the newer mir packages link to libandroid-input.so, which I don't have. Is this intentional? If so, where do I get that library from, and can we update the mir package to depend on that library please?
[02:07] <thomi> RAOF: any ideas? ^
[02:14] <RAOF> thomi: Mir builds that library.
[02:14] <RAOF> thomi: Oh, but we probably don't install it properly.
[02:14] <thomi> ahhh, that would explain it.
[02:14] <robert_ancell> duflu, yay, -zdefs works a treat. Thansk
[02:15] <duflu> robert_ancell: Cool np
[02:15] <robert_ancell> thomi, oh, I'm tracking that down right now
[02:15] <robert_ancell> thomi, it also doesn't link against glog
[02:15] <duflu> thomi: Yeah barely half the dev team knows how to and does test package builds :/
[02:16] <duflu> thomi: Bug against mir project please!
[02:16] <thomi> duflu: sure
[02:16] <RAOF> GRARGH!
[02:17] <RAOF> What the hell is causing the tests to abort part-way through with exit status 0?
[02:20] <RAOF> RUN_ALL_TESTS() is returning prematurely, but successfully.
[02:21] <thomi> duflu: https://bugs.launchpad.net/mir/+bug/1164253
[02:21] <duflu> RAOF: grep exit ;)
[02:21] <duflu> RAOF: Or maybe we're handling _too_many_ exceptions
[02:22] <RAOF> duflu: I broke in exit(); it's getting called at the end of main, after RUN_ALL_TESTS() has returned 0.
[02:22] <duflu> RAOF: Maybe we just need fflush(stdout)
[02:22] <duflu> Hmm, no that will be done at exit
[02:23] <duflu> Bisect!
[02:37] <robert_ancell> racarr, ping
[02:39] <duflu> robert_ancell: Forgot to mention I have an appointment after lunch in a few hours. Should not take too long
[02:39] <robert_ancell> duflu, np
[02:40] <duflu> robert_ancell: I am also eager to see and approve -zdefs
[02:40] <robert_ancell> duflu, yeah, will propose once I get it linking to glog correctly
[03:16] <racarr> robert_ancell: Pong
[03:16] <robert_ancell> racarr, hey, was wondering why libandroid-input is a shared library?
[03:16] <racarr> robert_ancell: client and server both use it
[03:16] <robert_ancell> racarr, but why not just statically link it to both?
[03:18] <racarr> besides potential difficulties with two copies in the test binaries
[03:18] <racarr> No reason
[03:19] <racarr> it feels like it should be a shared library though the way its used between the client and server
[03:20] <robert_ancell> racarr, it's opened up a number of problems having it installed shared - it doesn't have a unique name, it doesn't have a library version. We'd have to package it separately to the other library packages. We'd have to manage different versions being used potentially by the client and the server
[03:20] <RAOF> Hm. Something's playing silly buggers with file descriptors.
[03:21] <RAOF> #4  0x00007ffff6466cab in android::InputChannel::InputChannel (this=0x15580a0, name="TODO: Name", fd=2)
[03:21] <RAOF> Is unlikely to do anything sensible.
[03:21] <RAOF> duflu: Do you know offhand what happens when someone close()es stdout under gtest?
[03:22] <RAOF> :)
[03:22] <robert_ancell> racarr, what's the two copies in test binaries that you're referring to?
[03:48] <RAOF> Ah. So, TEST(AndroidInputWindowHandle, update_info_uses_geometry_and_channel_from_surface) first sets stderr to non-blocking mode, then closes it. With, apparently, hilarious consequences!
[04:07] <duflu> Wow, stupid mistake and also not a test failure
[04:07] <duflu> Cool
[04:18] <RAOF> Now I curse C++ for not having a mkstemp-alike.
[05:11] <duflu> I suspect it does but you really don't want to see it
[05:11]  * duflu --> doctor
[06:41] <tvoss> RAOF, ping
[06:41] <RAOF> tvoss: Pong.
[06:41] <tvoss> RAOF, good morning :) did you have a chance to have a look at: https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368
[06:41] <tvoss> RAOF, you are the remaining "needs fixing" :)
[06:41] <RAOF> I'll do so now.
[06:42]  * RAOF was working through the mesa changes needed for in-process EGL, but I guess input can preempt that.
[06:43] <tvoss> RAOF, sorry for pulling you out of something else, but I think we should land the mp, it has been up for so long and Robert has been addressing almost all reviewer comments :)
[06:43] <RAOF> This is a fair call.
[06:44] <RAOF> I know how that is :)
[06:44] <duflu> "almost all" is probably sufficient. We will make better progress if we don't try to reach 100% perfection on every proposal. Just iterate
[06:45] <tvoss> agreed, the important part of the mp is the end-end test of input
[06:46] <tvoss> which allows us to pick up pace on integrating input
[06:47] <duflu> It would be cool to be able to finally write clients that use the mouse ;)
[07:10] <tvoss> duflu, it works with a mouse :) however, no cursor is rendered ;)
[07:10] <duflu> Hah. Yeah forgot that part
[07:11] <duflu> See also https://bugs.launchpad.net/mir/+bug/1109921
[07:11] <tvoss> duflu, any input device that does not require a screen setup to be present is working :)
[07:11] <ubot5`> Launchpad bug 1109921 in Mir "Mouse pointer flickers in xmir. Looks like "HW cursor" is not in HW." [Medium,New]
[07:11] <duflu> tvoss: So we can write the first Mir game :)
[07:12] <tvoss> duflu, of course, or better: integrate with sdl 2.0 to unblock all the fancy game engines
[07:12] <duflu> What game engines depend on SDL?
[07:12] <duflu> Aside from amateur ones?
[07:13] <duflu> Never mind. SDL is pretty widely used. I might have overstepped the mark there
[07:14] <tvoss> duflu, :)
[07:14] <duflu> I know that QEMU used SDL exclusively for a long time
[07:15] <tvoss> duflu, I wasn't aware of that
[07:15] <duflu> And QEMU is one of the many definitions of "awesome"
[07:15] <tvoss> yup
[07:16] <duflu> Another definition is "Fabrice Bellard"
[08:21] <tvoss> alan_g, can I get you to do another review of https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368
[08:21] <tvoss> ?
[08:22] <alan_g> tvoss: OK when I get off call
[08:22] <tvoss> alan_g, ack :)
[08:44]  * RAOF wonders whether eglGetProcAddress makes in-process-egl any harder.
[08:44] <RAOF> Then decides that it's 7:45pm, and that can wait for tomorrow.
[09:01] <alan_g> tvoss: approved
[09:01] <tvoss> alan_g, thx
[10:14] <tvoss> alf_, can you have a look at https://bugs.launchpad.net/mir/+bug/1116452
[10:14] <ubot5`> Launchpad bug 1116452 in Mir "gbm returns byte unit stride, android returns pixel unit stride" [Medium,New]
[10:14] <tvoss> alf_, I remember some discussion around it, is it fixed?
[10:15] <alf_> tvoss: no, the decision was to change Android to return byte unit stride too, but I don't think anything has been done. I will ping kdub, though. He may have started working on it.
[10:16] <tvoss> alf_, ack, fine with you if I assign the bug to you and you change to kdub if appropriate?
[10:16] <tvoss> ah, already assigned :)
[10:16] <tvoss> alf_, setting the status to confirmed, though
[10:49]  * duflu falls off chair
[10:50] <alan_g> "* duflu falls off chair" - what was that about?
[10:55] <ogra_> cheap chairs ?
[11:40] <smspillaz> it happens
[12:36] <kgunn> tvoss: thank you for pushing the mp on client input...
[12:36] <tvoss> kgunn, yw
[14:00] <thiagoandrade> I'm try
[14:01] <thiagoandrade> I'm trying to compile Mir but I'm getting the error "/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libEGL.so: undefined reference for `mir_egl_native_display_is_valid'". Anyone knows how to solve that?
[14:18] <thiagoandrade> Anyone here who can help me?
[14:18] <smspillaz> thiagoandrade: you probably need to compile mesa with the mir patches. Ask racarr when he's around
[14:20] <thiagoandrade> smspillaz, isn't there a way of using their repositories to install Mesa?
[14:20] <alan_g> smspillaz: thiagoandrade the PPA should have a mesa that supports compiling
[14:20] <smspillaz> yeah, that :)
[14:21] <thiagoandrade> I've added the PPA to my system but waht shoul I do after adding the PPA?
[14:21] <smspillaz> thiagoandrade: sudo apt-get update && sudo apt-get dist upgrade
[14:21] <smspillaz> you'll just need to make sure you don't have a locally installed mesa in your PKG_CONFIG_PATH or LD_LIBRARY_PATH
[14:21] <smspillaz> (eg, through compiling)
[14:22] <thiagoandrade> smspillaz, Let me try that. Thanks
[14:24] <alan_g> thiagoandrade: http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
[15:06] <kdub> good morning, status reworked some sizing for hwc devices in the process of getting the fb native window out of 3rd_party
[15:11] <alan_g> good afternoon, status: reviewing and chasing down memory leaks in use of glog/gflags
[15:26] <alf_> status: more main loop work and discussion, reviewing
[16:31] <alf_> kdub: @display-sizing, l289, is the first expectation targeted for the HW11Device constructor, and the second for the display_size() call?
[16:33] <alf_> kdub: or is the first one just to set up the environment, not actually part of the test?
[16:34] <kdub> alf_, yes
[16:34] <kdub> alf_, i guess that expectation could be removed
[16:36] <alf_> kdub: it's ok, I was just wondering if it makes sense to put a Mock::VerifyAndClearExpectations() before the second expectation
[16:37] <alf_> kdub: to ensure that getDisplayConfigs_interface is called in the constructor, but since it's more of an environment setup it doesn't matter
[17:05] <kdub> kgunn, tvoss https://www.youtube.com/watch?v=iZ_iIZg4Xbw
[17:06] <thiagoandrade> I followed this http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html and then thishttp://unity.ubuntu.com/mir/using_mir_on_pc.html. But When I try to run Mir on VT1 I get an error "mir: error while loading shared libraries: libandroid-input.so: cannot open shared object file: No such file or directory"
[17:06] <kgunn> kdub: freaking awesome!!!
[17:07] <thiagoandrade> The problem is that I can't find such package in the repositories.
[17:07] <kdub> kgunn, :) sorry for the shaky camera, bad lighting and narration :P
[17:07] <tvoss> kdub, epic :)
[17:08] <kdub> thiagoandrade, build system bug, let me try to find the number
[17:08] <tvoss> kdub, is this using the hwc :)
[17:08] <kdub> thiagoandrade, https://bugs.launchpad.net/mir/+bug/1164253
[17:08] <racarr> morning
[17:08] <ubot5`> Launchpad bug 1164253 in Mir "mir links to libandroid-input.so, but does not package it or Depend on a package that provides it" [High,In progress]
[17:08] <kdub> tvoss, hwc 1.1 with gpu composition
[17:09] <tvoss> kdub, so the composition is accelerated?
[17:09] <kdub> well, its always been accelerated, now it just doesn't flicker and tear and look bad
[17:09] <tvoss> kdub, cool :)
[17:09] <tvoss> kdub, let me share on google+ :)
[17:12] <kgunn> kdub: dude...you realize everyone's gonna want play with that config...like, now :)
[17:14] <kdub> they can play with our egltriangle demo much more easily :)
[17:15] <kgunn> kdub: i just shared with unity ui guys...everyones pumped!
[17:16] <kgunn> kdub: look so nice...like buttah!...no jank or tears...nice work man
[17:17] <thiagoandrade> kdub, Sorry had to do something. Let me check that bug.
[17:18] <kdub> kgunn, thanks!
[17:19] <thiagoandrade> kdub, Basically that means I can't build Mir?
[17:19] <kdub> thiagoandrade, its built, it just doesn't install one of the .so's in the right place
[17:27] <thiagoandrade> kdub, I don't know if I'm gonna be of any help, but I was hoping I could help in the development of Mir. The problem is that until now I've not been able to build and run Mir.
[17:28] <kdub> thiagoandrade, well, hopefully its easier when there aren't bugs. if you're using our guides, and something doesn't make sense, a good way to help would be to submit a patch (once you've figured it out) to the doc/ folder in lp:mir
[17:30] <racarr> It should work fine it built from source yes?
[17:32] <kdub> yes, i think so... but there's gotchas that I'd guess aren't documented
[17:34] <thiagoandrade> So building from source I should not get that error, right?
[17:34] <racarr> Right :)
[17:35] <thiagoandrade> So I'm trying that. Let you know if I got any problem ;)
[17:39] <racarr> Great.
[17:49] <thiagoandrade> racarr, I got this error on 51% of the build: "Built target mir_demo_client_unaccelerated /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libEGL.so: undefined reference of `mir_egl_native_display_is_valid'"
[17:50] <racarr> thiagoandrade: Hrm maybe something landed that wasn't supposed to
[17:50] <racarr> looking
[17:52] <racarr> thiagoandrade: I don't know whats going on. my guess is we need to remove the mesa in the ppa
[17:52] <racarr> rebuild*
[17:52] <racarr> though I'm not sure how it could be broken like that...
[17:53] <thiagoandrade> racarr, Is there a manual or guide to compile the custom mesa I need?
[17:53] <racarr> thiagoandrade: https://github.com/RAOF/mesa
[17:53] <racarr>  ./configure --disable-gallium-egl --enable-gles2 --with-egl-platforms=x11,drm,mir,wayland --enable-gbm --enable-shared-glapi --with-gallium-drivers=r300,r600
[17:54] <racarr> perhaps change --with-gallium-drivers
[17:54] <racarr> thiagoandrade: In this case...you might need to install
[17:54] <racarr> libmirclient from your partial build (so you can build mesa)
[17:54] <racarr> i.e. go to build/src/client. make install
[17:54] <racarr> then will be enough to build and install mesa
[17:54] <racarr> then I bet mir build will finish
[17:54] <racarr> will try and make sure the ppas are updated this afternoon :)
[17:55] <thiagoandrade> Ok, I'll try. Let you know. ;)
[19:13] <racarr> Got a qml terminal emulator (https://github.com/jorgen/yat) running with input
[19:13] <racarr> was able to type and initiate tab completion (and modifiers and stuff work!)
[19:13] <racarr> somehow enter doesn't work though
[19:13] <racarr> not sure where the problem is
[19:16] <kgunn> racarr: weird....like the button(ui) depresses...but nothing handles it?...or you literally don't even see the event?
[19:20] <racarr> kgunn: Like the terminal emulator relied on an old Qt behavior
[19:20] <racarr> where translating Key_Enter to string would produce \n
[19:20] <racarr> now it seems it doesnt
[19:20] <racarr> thats my best guess :) I got it working
[19:21] <kgunn> cool
[19:21] <kgunn> nice to see stuff falling together
[19:24] <racarr> hmm
[19:24] <racarr> not enough keys work for emacs to work
[19:25] <racarr> Im going to try and get enough key mapping to work to make emacs work
[19:25] <racarr> then write a demo shell that can alt tab then I can uninstall X11
[19:26] <tvoss> racarr, that needs to go to the quotes wall :)
[19:27] <racarr> :D
[19:29] <thomi> morning folks
[19:29] <racarr> Morrrnin!
[19:34] <thomi> racarr: are you able to comment on this please? https://code.launchpad.net/~robert-ancell/mir/shared-android-input/+merge/157017
[19:35] <thomi> I need the mir packages to work before I can complete my glmark work :-/
[20:29] <thomi> robert_ancell: are you around?
[20:29] <robert_ancell> thomi, yes, otp at the moment
[20:30] <robert_ancell> thomi, free now
[20:30] <thomi> robert_ancell: OK, when you get a minute, do you mind if I approve this MP of yours to fix the packaging? https://code.launchpad.net/~robert-ancell/mir/shared-android-input/+merge/157017
[20:30] <racarr> There was a reason it was shared originally but maybe it has mysteriously resolved itself
[20:30] <robert_ancell> thomi, sure, I'm not sure what Jenkins is complaining about
[20:31] <robert_ancell> thomi, I just merged to see if that would help but it has now
[20:31] <robert_ancell> not
[20:31]  * thomi pushes the big red button
[20:31] <robert_ancell> :)
[20:31] <thomi> done
[20:32] <racarr> We merged it with failing jenkins?
[20:32] <racarr> I dont think that was a good idea -.- the merge fail is probably like
[20:32] <racarr> jenkins fail*
[20:32] <racarr> well how is anything else going to pass jenkins now?
[20:32] <thomi> racarr: jenkins will do a proper merge, build, test before merging it into trunk
[20:32] <thomi> autolanding != CI
[20:32] <racarr> oh
[20:33] <racarr> I thought when you said the big red button
[20:33] <racarr> you meant you were just like
[20:33] <robert_ancell> big red override :)
[20:33] <racarr> pushing ;)
[20:33] <thomi> sorry, I meant "I'm approving the MP"
[20:33] <thomi> words 'n stuff
[21:46] <thomi> robert_ancell: So your branch didn't land, and I think the problem is that g++ segfaults :-/
[21:47] <robert_ancell> thomi, ech!
[21:47] <thomi> at least, on my machine, I'm unable to build your branch due to g++ segfaulting
[21:49] <RAOF> thomi: Segfaulting, or suffering an Internal Compiler Error?
[21:49] <robert_ancell> thomi, is it a memory issue?
[21:49] <thomi> robert_ancell: segfaulting
[21:49] <robert_ancell> thomi, yeah but due to running out of memory?
[21:49] <thomi> robert_ancell: I have 16GB or memory, so I sure hope not ;)
[21:49] <robert_ancell> I don't think so then :)
[21:50]  * robert_ancell rebuilds again to check here
[21:50] <thomi> will go make coffee while this build chruns through
[21:50] <thomi> *churns
[21:53] <kgunn> thomi: it might chrun...you never know
[21:54] <RAOF> kgunn: Oh, StevenK (A launchpad guy) told me that the issue that was preventing you from deleting a bunch of milestones has been resolved now, so you can go ahead and do whatever deletion takes your fancy.
[21:55] <kgunn> sweet...now duflu will be less annoyed
[21:56] <kgunn> hmmm....it remembered....already deleted
[21:56] <robert_ancell> thomi, hmm, it fails here now
[21:57] <robert_ancell> kgunn, oh, I worked around the LP issue by moving the milestone then disabling it
[22:01] <racarr> hmm
[22:01] <racarr> I can't figure out how Shift+4 is becoming $ on the phablet.
[22:03] <robert_ancell> racarr, thomi, does this segfault mean anything to you? http://paste.ubuntu.com/5678081/
[22:07] <thomi> robert_ancell: ahhh, I just noticed that it is indeed the acceptance tests failing. Not sure how I missed that before
[22:12] <thomi> robert_ancell: so we're trying to destroy an android::KeyCharacterMap at program exit, and that fails for some reason
[22:14] <thomi> robert_ancell: maybe we can try without the global data..?
[22:14]  * thomi looks through the source code
[22:36] <thomi> robert_ancell: this is really odd - trunk works fine, something about building the input library as a static lib is causing the acceptance tests to fail, and then segfault.
[22:36] <thomi> I think I'll leave this in your more capable hands :)
[22:36] <robert_ancell> thomi, lucky me! :)
[22:36] <thomi> heh
[22:40] <racarr> thomi: I think it has to do with the binary linking against both libmirserver
[22:40] <racarr> and libmirclient
[22:40] <racarr> and libandroidinputtransport
[22:40] <racarr> and some sort of
[22:40] <racarr> static initializer double something scenario
[22:40] <racarr> I dunno I saw it and was like "Oh this needs to be a shared library"
[22:40] <racarr> and thats why its a shared library ;)
[22:40] <racarr> thats as deep as I went
[22:41] <racarr> im tired of fiddling with the (due to be replaced)
[22:42] <racarr> android keymapping system
[22:42] <racarr> so I am going to go ahead and just replace it with libxkb-common
[22:42] <racarr> eta ~1 day
[22:43] <RAOF> racarr: Woo!
[22:43] <RAOF> racarr: Remember to badger daniels (in #xorg-devel or elsewhere on freenode) about any limitations/problems in libxkbcommon you find. :)
[22:47] <racarr> RAOF: It seems really easy
[22:47] <racarr> the only question is where exactly to do it
[22:47] <racarr> oh
[22:48] <RAOF> We do it client-side, right?
[22:48] <racarr> I think just qtubuntu is fine for now.
[22:48] <racarr> yeah
[22:48] <racarr> The thing is
[22:48] <racarr> is it part of MirEvent
[22:48] <RAOF> (Possibly with an optimisation to build the mapping-table server-side and share it with clients)
[22:48] <racarr> or is it double client side
[22:49] <RAOF> Do you mean - do we make clients manually apply the keymap?
[22:50] <racarr> I guess right, is it part of the toolkits job
[22:50] <RAOF> Or do we show them shiny pre-processed, gleamingly mapped keys?
[22:50] <racarr> or does MirKeyEvent include like
[22:50] <racarr> uint32_t unicode or whatever
[22:50] <racarr> yeah
[22:51] <racarr> I guess
[22:51] <RAOF> My feeling is that MirKeyEvent should emit fully-processed unicode.
[22:51] <racarr> why be a jerk and make every toolkit do it
[22:51] <racarr> yeah
[22:51] <RAOF> Anything that wants to preprocess the stream (input methods, etc) has to go through the shell.
[22:51] <RAOF> Because the *shell* gets to see raw scancodes, right?
[22:52] <racarr> well
[22:52] <racarr> presumably KeyEvent has like
[22:52] <racarr> uint32_t keycode, uint32_t unicode
[22:52] <racarr> in the case of
[22:52] <racarr> evdev->xkb
[22:53] <racarr> the distinction between the scan and key code is kind of weird/unclear
[22:53] <racarr> and mostly involves adding 8
[22:53] <RAOF> Heh.
[22:54] <RAOF> So, question - composing characters. I've got <menu> set as the compose key, so when I hit <menu>e" I get ë.
[22:54] <RAOF> Here we have three key events turning into a single uint32_t unicode.
[22:54] <RAOF> What does Mir send?
[22:54] <racarr> a KeyEvent but instead of action
[22:54] <racarr> down or up
[22:54] <racarr> EVENT_ACTION_MULTIPLE
[22:54] <racarr> keycode is 0
[22:54] <racarr> and unicode is the only useful field
[22:55] <racarr> it's the same sort of thing as when
[22:55] <racarr> hey wait
[22:55] <racarr> eh nvm
[22:55] <racarr> thinking about weird onscreen keyboard things :)
[22:56] <RAOF> evdev is sending you three complete down+up pairs, plus modifiers - <menu>down/up, <e>down/up, <shift>down, <'>down/up, <shift>up.
[22:56] <RAOF> The client probably only wants to see ë.
[22:57] <RAOF> (*Most* clients; games and maybe other things want to see the full event stream)
[23:00] <RAOF> Or, I guess more accurately - most clients do *not* want to act on the <e>down/up and shift+<'>down/up.
[23:01] <RAOF> racarr: We should probably ask desrt about what he thinks would be maximally awesome.
[23:02] <racarr> Mm
[23:02] <racarr> Why isn't he here
[23:22] <racarr> difficult to write test this xkbcommon stuff...
[23:22] <racarr> the tests for*
[23:23] <racarr> code is pretty straightforward I think
[23:28] <RAOF> Would a change to xkbcommon make the tests easier?
[23:30] <racarr> If it were all mockable XD I dunno
[23:30] <racarr> ill think about it
[23:39] <racarr> there are so many options rather than take 2 days and try and figure it all out myself
[23:39] <racarr> I am going to take 2 hours and make a prototype branch
[23:39] <racarr> and ask for comment :)
[23:39] <RAOF> racarr: I mention this because Daniel has explicitly asked me to be notified of any annoyances we have with using xkbcommon; if there's something that would make our lives easier...
[23:40] <racarr> Good to know :)
[23:47] <RAOF> So, I think my solution for mesa's in-process-egl changes is to have a EGLPlatformType→Drv map in EGLModule, and construct a new driver iff there's not currently a driver for that platform.
[23:48] <RAOF> I don't believe that violates any spec, won't leak drivers, and we should even be able to have it transparently unload drivers if the last-using display gets closed.
[23:50] <racarr> RAOF: Seems like the right thing to do
[23:51] <racarr> RAOF: Do you have some time to work on it or do you want me to plan on it?
[23:51] <RAOF> I should be able to do it today.
[23:51] <racarr> oh great :)
[23:51] <RAOF> We can land that and use-dma-buf at the same time :)
[23:52] <RAOF> (Incidentally, feel like reviewing that? You're the last "needs fixing")
[23:55] <racarr> RAOF: Will in 15-20 minutes
[23:55] <racarr> feel like I am close to unwinding my thought and getting a solid plan on key-mapping
[23:55] <RAOF> Woot!
[23:55] <RAOF> No huge rush, unless you plan to land changes that conflict again :P