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