[01:05] <bregma> hey RAOF do you have magic core dev powers?  I'm trying to squeeze my libertine-scope package through the NEW queue for Xenial and it's been sitting there ignored for a week and could use a little push....
[01:06] <RAOF> bregma: NEW processing isn't a core-dev power.
[01:06] <RAOF> bregma: You're thinking of Archive Admin, which I'm not.
[01:06] <duflu> Oh and an Xmir patch please :)
[01:06] <bregma> it's all a black box to me
[01:07] <duflu> Actually might need robert_ancell's help
[01:07] <bregma> duflu, Xmir appears to have stopped working on Xenial, is that what you're talking about?
[01:07] <duflu> bregma: No, but let me check that...
[01:07] <RAOF> I can totally upload an XMir patch...
[01:08] <duflu> bregma: It must just be your machine. Xmir has not changed since 27 November: https://launchpad.net/ubuntu/+source/xorg-server
[01:08] <bregma> Xenial?
[01:08] <duflu> Yep
[01:08] <bregma> well, entirely possible it's my machine
[01:09] <duflu> The last distro change was 27 Nov anyway
[01:09] <duflu> Although I have been compiling and running the latest Xmir on the latest xenial and it works
[01:10] <bregma> ...and Olli's machine, but in a totally different way...  there's a zillion places something could go wrong in the chain of events
[01:10] <bregma> I know a new x.org went in in Xenial a while back, I'm just paranoid about changes not getting synched somewhere
[01:23] <duflu> bregma: On that note, it's probably bad form to do a xorg update this late. I was only requesting it for kgunn's titlebar enhancement
[01:23] <duflu> But in terms of risk, maybe not a great idea
[01:24] <RAOF> We're still pre-feature freeze.
[01:24] <RAOF> It's a perfectly sensible time to get new features in :)
[01:25] <duflu> I know, but there's a huge maturity win in "It's unmodified since November" vs "it's unmodified for a couple of days"
[01:25] <duflu> Confidence is a good thing to keep
[01:26] <duflu> That said, this is xenial. And on desktop Xmir still defaults to less stable dri2 renderer
[01:27] <duflu> Less correct, not less stable
[01:29] <duflu> Speaking of maturity, despite our Unity8 issues Weston logins are more broken than Unity8 :)
[02:05] <RAOF> Eh. Weston isn't really pretending to be a DE :)
[02:16] <duflu> RAOF: No, but a VT with just a flashing cursor is worse than expected
[02:17] <RAOF> Probably. No-one really cares for it in Ubuntu :)
[02:18] <duflu> RAOF: True, but if you're going to the trouble of providing it as a login option in Ubuntu, it should do /something/ :)
[02:20] <RAOF> It's actually more trouble to *not* provide it as a login option.
[02:20] <RAOF> (Probably?)
[02:23] <duflu> Possibly. Although my xenial system makes me suspicious that continuous daily updates have broken some things (like Unity8 is missing most apps, and those I do have exit immediately)
[02:23] <duflu> I'm assuming a fresh install would be less broken
[11:04] <zzarr> hello! this is a question that might not have an answer yet, but I find it interesting: how will Mir handle external GPU's? (in external cabinets like ASUS ROG XG2 and Razer Core)
[11:08] <alan_g> zzarr: it isn't interesting (yet). Assuming there are userspace drivers I'd expect Mir to use them.
[11:11] <zzarr> alan_g, okey, I thought more about, what if I use a GPU heavy application an it's running on an external GPU and I unplug the Thunderbolt 3 cable, will the application die or can it "jump" to the internal GPU? (or maybe it's suspended and resumes when I plugin the cable again)
[11:12] <zzarr> I know it's a longways away, but I find it interesting
[11:12] <anpok> just donate one of those to a team member :)
[11:12] <anpok> at the moment we cannot because the kms platform figures that out during startup
[11:13] <zzarr> hehe, okey
[11:13] <zzarr> well there's another thing holding it back.... there are no cabinets for sale yet
[11:14] <zzarr> so, I guess I should have asked, how would you like the application that just lost the GPU to behave?
[11:14] <anpok> but later it might listen to udev.. from there on we have to deal with having several dri devies nodes for rendering/buffer allocation, and separate ones for outputs..
[11:15] <zzarr> I would like it to resume on the internal GPU
[11:15] <zzarr> okey
[11:17] <zzarr> I'm still trying to port Ubuntu Touch/Mir to my chromebook (as long as I have a viable plan I'll proceed till success or failure)
[11:18] <alan_g> In this hypothetical world of yours either the driver(s) migrates context across GPUs (implausible) or the application needs to rebuild it. Either way I don't think Mir has a big role.
[11:19] <zzarr> okey, alan_g so the question was basically not related to Mir
[11:19] <alan_g> Well, if you can come up with patches for Mir that would help we'll be happy to review them.
[11:20] <zzarr> I just wonder, if I succeed porting, how will Mir handle more then 1 monitor?
[11:20] <alan_g> Perfectly?
[11:21] <zzarr> :-)
[11:22] <zzarr> even if I use the Android (user space) driver or is that irrelevant
[11:25] <alan_g> Mir currently handles multi-monitor based on abstractions implemented on both mesa-kms and android driver stacks. No reason your port would stop it working,
[11:26] <zzarr> alan_g, that's exactly what I wanted to hear :-D
[22:58] <RAOF> zzarr: In the best case, pulling the thunderbolt cable will result in applications seamlessly transferring to the integrated chip.
[22:58] <RAOF> zzarr: In the common case, pulling the thunderbolt cable will result in applications crashing :)
[22:59] <RAOF> In order to handle the loss of a GPU the application will need to either: (a) be using software rendering, or (b) create an EGL context with KHR_ROBUSTNESS support and handle the EGL_CONTEXT_LOST case by destroying its EGL state and rebuilding it on a different GPU.