=== RAOF_ is now known as RAOF === Wellark__ is now known as Wellark [09:31] alf_: is this right? https://code.launchpad.net/~alan-griffiths/mir/suppress-tests-for-armhf/+merge/204620 [09:32] alan_g: looks good [09:33] alf_: thanks [09:35] alan_g: perhaps, though, we should apply this to devel first and merge that? [09:35] alan_g: too late, doesn't matter :) [09:36] alf_: I'd rather do a reverse merge after the trunk gets tagged [09:36] alan_g: ok [09:37] * alan_g thinks we should not be landing two months changes in one lump (but who listens?) [09:42] didrocks: I trust your changelog concerns are addressed? https://code.launchpad.net/~mir-team/mir/trunk-0.1.4/+merge/201707 === ogra_` is now known as ogra_ [10:04] alan_g: swimming over the diff, it looks good to me [10:06] didrocks: surely a 32k diff is no cause for concern. ;^/ [10:07] alan_g: well, that's your process, if things can't land, we are going to revert your 32k of diff [10:07] you pick your risk [10:08] didrocks: kgunn already made that decision. [10:08] yeah, so no need to argue on that more :) [10:10] Is it ok to top-approve now? (Or are there other steps needed in the latest process?) [10:10] alan_g: kgunn is the lander, he will handle that, so no top-approve (well, top-approve won't do anything anyway) [10:11] * alan_g washes hands [12:11] alan_g: have you tried cross compiling recently? [12:11] alf_: can you suggest a cleaner approach to https://code.launchpad.net/~alan-griffiths/mir/refactoring-so-SwitchingBundle-can-control-completion-of-client_acquire/+merge/204244 [12:12] alf_: no - can to though [12:12] *do [12:12] (Was probably friday I did it last) [12:13] alan_g: I am getting http://paste.ubuntu.com/6872683/ [12:15] Tried zapping the "partial chroot"? [12:16] alan_g: no, just the build dir (while updating the chroot), will try from scratch [12:16] Hmm " #error This file was generated by an older version of protoc which is"... [12:18] alan_g: you need to update the host protobuf libraries and protobuf-compiler package [12:18] alf_: ack [12:21] alan_g: @switching bundle, I like the proposed approach, perhaps with the change that Kevin proposed to swap_client_buffers() [12:22] alan_g: i.e., returning the buffer in the callback [12:24] thanks. Was thinking along those lines - but not feeling convinced it was the best of all possible solutions === Trevinho_ is now known as Trevinho [12:26] * alan_g isn't convinced by the name "submit_produced_buffer_and_notify_on_available_buffer" though [12:28] alan_g: the other approach is to move to a push model for surface buffers, but that's more radical and needs further discussion [12:29] alf_: quite [12:29] BBL [12:29] alan_g: cross-build ok from scratch, thanks === alan_g is now known as alan_g|lunch === dandrader is now known as dandrader|afk === popey_ is now known as popey === dandrader|afk is now known as dandrader === alan_g|lunch is now known as alan_g [13:51] alan_g, trying to make unity8 do custom RPC over mir_socket, following test_protobuf.cpp example [13:52] dandrader: yes? [13:52] alan_g, I need to include mir/frontend/template_protobuf_message_processor.h [13:52] alan_g, but that header, on its part, includes mir_protobuf_wire.pb.h [13:52] alan_g, which is not exported by mir [13:54] dandrader: you're right. That needs to be fixed. [13:54] Want to log a bug? I'll get to it today [13:54] alan_g, sure [13:59] thanks [14:01] alan_g, https://bugs.launchpad.net/mir/+bug/1276162 [14:01] Launchpad bug 1276162 in Mir "libmirserver user is unable to #include " [Undecided,New] === mterry_ is now known as mterry === alan_g is now known as alan_g|tea === dandrader is now known as dandrader|lunch === alan_g|tea is now known as alan_g [15:46] mlankhorst: Hi! I think I have found a bug in Mesa, could you take a look? [15:46] I guess [15:49] mlankhorst: So, the problem is that when unbinding a context, the driver unbind function is not called when there are no bound surfaces, but this break when we have a surfaceless context [15:50] is this a bug in gallium only or is i915 affected? [15:51] mlankhorst: it's in dri_utils, a tentative fix is http://paste.ubuntu.com/6873664/ . Just that look plausible? [15:52] s/Just/Does/ [15:54] I really can't say [15:55] mlankhorst: np, thanks [15:55] it seems like it's not called on purpose there [15:57] so I don't know, put it on the mesa-dev list I guess [15:57] or write a test [15:58] mlankhorst: will do thanks [16:02] kdub, hey, could you maybe answer asac's question in "Landing team 31.01.2014" on ubuntu-phone ("How can we ensure that display is ready before trying to start?")? [16:02] Saviq, i'll take a look [16:02] kdub, thanks === dandrader|lunch is now known as dandrader [17:12] alan_g, so mir wire protocol has no concept of services. only functions, right? [17:12] dandrader: correct [17:12] alan_g, meaning that you can map a wire protocol function to any protobuf service you like, right? [17:12] dandrader: correct [17:13] ok [17:16] was there a problem with protobuf? [17:20] kdub: bug 1276162 [17:20] bug 1276162 in Mir "libmirserver user is unable to #include " [High,In progress] https://launchpad.net/bugs/1276162 [17:22] alan_g, what i'm seeing looks more like a version mismatch of protobuf on my setup [17:22] upgrading everything and hopefully that works [17:23] kdub: yeah, theny just pushed protobuf8 in [17:23] &they [17:24] Sorry, thought you were joining the conversation, not starting a new one [17:30] alan_g, np, upgrading things seemed to fix what i was seeing [17:36] kdub: is this to your liking now? https://code.launchpad.net/~alan-griffiths/mir/refactoring-so-SwitchingBundle-can-control-completion-of-client_acquire/+merge/204244 [17:37] looking [18:00] kdub: thanks === alan_g is now known as alan_g|EOD === dandrader is now known as dandrader|afk [23:17] i just read about SDL Mir backend [23:17] don't most 3D games use GLX? how does that work then? [23:20] ali1234, when it comes to a game that uses GLX, the mir video backend returns an opengl context (through egl) which allows most games to work [23:20] i'm a game developer... how will i know if my game can work this way? [23:20] i've tested this out in SDL 1.2 (which I have a branch for) [23:20] i use SDL2 and ogre3d [23:20] then things should just work :) [23:21] to test, you would have to set up the mir server [23:21] i compile my own version of ogre and sdl... [23:21] and run it on it directly [23:21] i've not tested ogre out but if it depends on X11 it will not work [23:22] depends on it directly [23:22] well it depends on it for building [23:22] but i use SDL to open a window and get a GL context [23:22] the GL context you get from SDL (if you are running it through mir) will be opengl [23:23] ali1234, ive gotten games such as extremetuxracer [23:23] working through mir [23:23] (only in sdl 1.2, which is not patched for mir, but my own branch) [23:23] which depends on |Depends: libgl1-mesa-glx [23:24] so I would assume any games written in SDL2, should work with the same dependencies [23:26] i literally just open a window with SDL2 and then tell ogre to render into it... there is zero X11 specific code in my stuff, which also runs on windows [23:26] the problem i see though, is ogre has a hard depend on : Depends: libx11-6 [23:26] yes [23:26] at lease im seeing that here: apt-cache depends libogre-1.8.0 [23:26] ogre has it's own window management functions, but i do not use them [23:26] which will not allow it to work :( [23:26] o [23:26] well [23:27] so it should work as long as the libraries are around and it just won't use them... i guess? [23:27] also i could patch the X11 stuff out of ogre, maybe [23:27] well if they are around, and there are functions calls that attempt to connect with the XServer it'll fail [23:27] wondering if it's worth it... [23:28] luckily all this stuff is BSD licensed :) [23:28] or was it MIT, i forget [23:29] well the lease you could do is run down where ogre calls any x11 functions [23:30] you would hope that if you are using SDL2 to get the context (and set up the native handling) that ogre would leave all that alone [23:30] and let SDL2 handle that [23:30] if thats the case it'll work just fine [23:30] CMake/Packages/FindOpenGLES.cmake: # On Unix OpenGL most certainly always requires X11. [23:30] :( [23:31] :(, thats one assumption that has caused a lot of pain [23:32] on a related note, the oculus rift devkit relies on X11 and Xinerama as well [23:32] to bad they just don't all build a layer ontop of SDL2 and leave all the native window handling to it... [23:33] well ogre is a lot older than SDL2... SDL1 has no windowing support [23:33] right [23:33] i forgot how new SDL2 really is :)