[04:43] <hk> where's the XMir code hosted?
[05:30] <mlankhorst> mirning
[05:31] <mlankhorst> 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] <mlankhorst> racarr_:         AC_DEFINE(XMIR, 1, [Support wayland mode])
[09:02] <mlankhorst> er RAOF_*
[13:07] <mlankhorst> ohey plymouth sort of works
[13:08] <mlankhorst> Mesa 9.2.0 implementation error: unhandled format!
[13:08] <mlankhorst> Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
[13:14] <mlankhorst> http://testbot.winehq.org/~mlankhorst/plymouth-mir-wip-1.patch -- not complete yet, just a WIP
[15:51] <robert_ancell> thomi, is there a way to recompile unity-system-compositor every time mir changes?
[15:52] <robert_ancell> i.e. recompile the package in the PPA
[15:52] <thomi> robert_ancell: hmmmmm - you want to rebuild because of API/ABI changes?
[16:59] <robert_ancell> thomi, yes
[16:59] <robert_ancell> 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] <thomi> 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] <robert_ancell> thomi, ta
[17:12] <thomi> 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] <thomi> 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] <thomi> 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] <bschaefer> robert_ancell, https://launchpad.net/~brandontschaefer/+archive/sdl-mir-support
[17:32] <RAOF> Dear GLX: I hate you.
[18:00] <robert_ancell> 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] <mlankhorst> RAOF: oh btw could you peek at my plymouth mir wip patch?
[18:01] <robert_ancell> bschaefer, you should probably use version 2.0.0-0ubuntu1~mir1 so it's less than the official 2.0.0 release
[18:02] <robert_ancell> bschaefer, I mean 2.0.0-0ubuntu1+mir1
[18:02] <mlankhorst> I only tested on the mir demo server with input explicitly disabled, I still use raw console handling for input for now
[18:02] <robert_ancell> bschaefer, actually, disregard that. Now I understand
[18:03] <RAOF> mlankhorst: Sure. Where is it?
[18:04] <bschaefer> robert_ancell, alright, :)
[18:04] <mlankhorst> above^
[18:04] <mlankhorst> http://testbot.winehq.org/~mlankhorst/plymouth-mir-wip-1.patch
[18:04] <mlankhorst> it doesn't work correctly yet since it assumes that last buffer == current buffer
[18:05] <mlankhorst> so it doesn't do a full redraw, and mir_demo_server was complaining "Mesa 9.2.0 implementation error: unhandled format!"
[18:05] <robert_ancell> thomi, can we get u-s-c to rebuild now? Or shall I just do a trivial merge?
[18:05] <thomi> robert_ancell: sure, I'll trigger it manually
[18:06] <RAOF> mlankhorst: Got a patch that isn't full of automake droppingsz/
[18:06] <RAOF> ?
[18:06] <mlankhorst> RAOF: no sorry :(, plugins/renders/mir and configure.ac is the meat
[18:07] <robert_ancell> bschaefer, what branch are you working on libsdl?
[18:08] <thomi> robert_ancell: running now - http://10.97.2.10:8080/view/Generic%20jobs/job/generic-dput/1189/console
[18:08] <bschaefer> 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] <robert_ancell> bschaefer, just a local checkout?
[18:09] <bschaefer> yeah, I grabbed it changed it, made a patch, patched the libsdl2 from saucy then uploaded the ppa
[18:09] <bschaefer> soo I suppose Im using the libsdl in the ppa from saucy
[18:10] <bschaefer> robert_ancell, https://launchpad.net/ubuntu/saucy/+source/libsdl2
[18:11] <RAOF> mlankhorst: Is plymouth wedded to VTs? Because that would ideally go away.
[18:11] <mlankhorst> RAOF: no, I just didn't get around to fixing the input stack yet
[18:12] <RAOF> 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] <alan_g> robert_ancell: kdub is still testing android on https://code.launchpad.net/~afrantzis/mir/remove-in-tree-glm/+merge/162174
[18:12] <RAOF> mlankhorst: We're thinking of renaming it as mir_surface_swap_buffers to make it more obvious ☺
[18:12] <mlankhorst> RAOF: Yeah I thought so, but the unaccelerated demo did it like that
[18:12] <RAOF> mlankhorst: Hm, so it does. I'll fix that :)
[18:12] <mlankhorst> this is just the work of me poking half a day at the mir demos and plymouth
[18:13] <mlankhorst> how many buffers are there in the sw case?
[18:13] <RAOF> 2
[18:13] <RAOF> Well, or more.
[18:13] <RAOF> But 2 by default.
[18:13] <RAOF> And we don't currently expose any way to get anything but 2.
[18:14] <mlankhorst> 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] <RAOF> You get buffer age :)
[18:14] <mlankhorst> ok
[18:15] <mlankhorst> I'll look at it monday then :)
[18:15] <RAOF> 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] <mlankhorst> shrug buffer age is probably good enough
[18:16] <mlankhorst> if it's > 1 I'll just redraw the entire screen
[18:16] <RAOF> It'll always be > 1 (it'll almost always be 2).
[18:17] <mlankhorst> ok ok, I'll poke it a bit more before I shout random stuff again ;P
[18:17] <RAOF> 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] <thomi> robert_ancell: maybe you noticed already, but the u-s-c package is in the staging PPA now