[04:43] where's the XMir code hosted? [05:30] mirning [05:31] support mir as a backend for plymouth is INPROGRESS, is there anyone actively working on it? sounds like a fun little item for me to get started in mir [09:02] racarr_: AC_DEFINE(XMIR, 1, [Support wayland mode]) [09:02] er RAOF_* [13:07] ohey plymouth sort of works [13:08] Mesa 9.2.0 implementation error: unhandled format! [13:08] Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa [13:14] http://testbot.winehq.org/~mlankhorst/plymouth-mir-wip-1.patch -- not complete yet, just a WIP === francisco is now known as Guest65033 === mmrazik is now known as mmrazik|afk [15:51] thomi, is there a way to recompile unity-system-compositor every time mir changes? [15:52] i.e. recompile the package in the PPA [15:52] robert_ancell: hmmmmm - you want to rebuild because of API/ABI changes? [16:59] thomi, yes [16:59] thomi, we just set the mirserver API to always require recompiling as it doesn't have any API/ABI stability at the moment [17:09] robert_ancell: I'll ask Francis, I don't think there's any easy way (although we could hack something up pretty easily). [17:09] thomi, ta [17:12] robert_ancell: so the full story is that this is what the MBS is designed to solve (we use it for unity). It needs to be integrated with the new autolanding stuff [17:12] robert_ancell: but we can hack a jenkins job to do that. However, there are a few edge cases to think about, like what to do when the dependant package fails to build [17:12] so right now we'll just do the best we can - if anything fails to build it just won't get dput'd [17:12] robert_ancell, https://launchpad.net/~brandontschaefer/+archive/sdl-mir-support [17:32] Dear GLX: I hate you. [18:00] RAOF: From GLX. I apologize if I have offended you but I'm old and I just don't understand what you crazy kids are doing [18:01] RAOF: oh btw could you peek at my plymouth mir wip patch? [18:01] bschaefer, you should probably use version 2.0.0-0ubuntu1~mir1 so it's less than the official 2.0.0 release [18:02] bschaefer, I mean 2.0.0-0ubuntu1+mir1 [18:02] I only tested on the mir demo server with input explicitly disabled, I still use raw console handling for input for now [18:02] bschaefer, actually, disregard that. Now I understand [18:03] mlankhorst: Sure. Where is it? [18:04] robert_ancell, alright, :) [18:04] above^ [18:04] http://testbot.winehq.org/~mlankhorst/plymouth-mir-wip-1.patch [18:04] it doesn't work correctly yet since it assumes that last buffer == current buffer [18:05] so it doesn't do a full redraw, and mir_demo_server was complaining "Mesa 9.2.0 implementation error: unhandled format!" [18:05] thomi, can we get u-s-c to rebuild now? Or shall I just do a trivial merge? [18:05] robert_ancell: sure, I'll trigger it manually [18:06] mlankhorst: Got a patch that isn't full of automake droppingsz/ [18:06] ? [18:06] RAOF: no sorry :(, plugins/renders/mir and configure.ac is the meat [18:07] bschaefer, what branch are you working on libsdl? [18:08] robert_ancell: running now - http://10.97.2.10:8080/view/Generic%20jobs/job/generic-dput/1189/console [18:08] robert_ancell, I don't have the actual source pushed up but i moved over to using this version: http://hg.libsdl.org/SDL/ [18:09] bschaefer, just a local checkout? [18:09] yeah, I grabbed it changed it, made a patch, patched the libsdl2 from saucy then uploaded the ppa [18:09] soo I suppose Im using the libsdl in the ppa from saucy [18:10] robert_ancell, https://launchpad.net/ubuntu/saucy/+source/libsdl2 [18:11] mlankhorst: Is plymouth wedded to VTs? Because that would ideally go away. [18:11] RAOF: no, I just didn't get around to fixing the input stack yet [18:12] mlankhorst: Also, I think you're calling mir_surface_next_buffer_sync in the wrong place - you should call it *after* doing your drawing. [18:12] robert_ancell: kdub is still testing android on https://code.launchpad.net/~afrantzis/mir/remove-in-tree-glm/+merge/162174 [18:12] mlankhorst: We're thinking of renaming it as mir_surface_swap_buffers to make it more obvious ☺ [18:12] RAOF: Yeah I thought so, but the unaccelerated demo did it like that === seb128_ is now known as seb128 [18:12] mlankhorst: Hm, so it does. I'll fix that :) [18:12] this is just the work of me poking half a day at the mir demos and plymouth [18:13] how many buffers are there in the sw case? [18:13] 2 [18:13] Well, or more. [18:13] But 2 by default. [18:13] And we don't currently expose any way to get anything but 2. [18:14] is there any guarantee? I was thinking of just keeping track of the damage to last buffer and merge it with damage to current buffer [18:14] You get buffer age :) [18:14] ok [18:15] I'll look at it monday then :) [18:15] I'm not sure if we'll guarantee that the number of buffers will never exceed n, for a client-sent value of n. [18:16] shrug buffer age is probably good enough [18:16] if it's > 1 I'll just redraw the entire screen [18:16] It'll always be > 1 (it'll almost always be 2). [18:17] ok ok, I'll poke it a bit more before I shout random stuff again ;P [18:17] Because the buffer you've just drawn to will have age = 1 right after you've called next_buffer (see the EGL_EXT_buffer_age spec for further details ☺) [19:14] robert_ancell: maybe you noticed already, but the u-s-c package is in the staging PPA now === francisco is now known as Guest56549