[01:05] 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] bregma: NEW processing isn't a core-dev power. [01:06] bregma: You're thinking of Archive Admin, which I'm not. [01:06] Oh and an Xmir patch please :) [01:06] it's all a black box to me [01:07] Actually might need robert_ancell's help [01:07] duflu, Xmir appears to have stopped working on Xenial, is that what you're talking about? [01:07] bregma: No, but let me check that... [01:07] I can totally upload an XMir patch... [01:08] bregma: It must just be your machine. Xmir has not changed since 27 November: https://launchpad.net/ubuntu/+source/xorg-server [01:08] Xenial? [01:08] Yep [01:08] well, entirely possible it's my machine [01:09] The last distro change was 27 Nov anyway [01:09] Although I have been compiling and running the latest Xmir on the latest xenial and it works [01:10] ...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] 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] 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] But in terms of risk, maybe not a great idea [01:24] We're still pre-feature freeze. [01:24] It's a perfectly sensible time to get new features in :) [01:25] 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] Confidence is a good thing to keep [01:26] That said, this is xenial. And on desktop Xmir still defaults to less stable dri2 renderer [01:27] Less correct, not less stable [01:29] Speaking of maturity, despite our Unity8 issues Weston logins are more broken than Unity8 :) [02:05] Eh. Weston isn't really pretending to be a DE :) [02:16] RAOF: No, but a VT with just a flashing cursor is worse than expected [02:17] Probably. No-one really cares for it in Ubuntu :) [02:18] 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] It's actually more trouble to *not* provide it as a login option. [02:20] (Probably?) [02:23] 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] I'm assuming a fresh install would be less broken [11:04] 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] zzarr: it isn't interesting (yet). Assuming there are userspace drivers I'd expect Mir to use them. [11:11] 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] I know it's a longways away, but I find it interesting [11:12] just donate one of those to a team member :) [11:12] at the moment we cannot because the kms platform figures that out during startup [11:13] hehe, okey [11:13] well there's another thing holding it back.... there are no cabinets for sale yet [11:14] so, I guess I should have asked, how would you like the application that just lost the GPU to behave? [11:14] 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] I would like it to resume on the internal GPU [11:15] okey [11:17] 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] 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] okey, alan_g so the question was basically not related to Mir [11:19] Well, if you can come up with patches for Mir that would help we'll be happy to review them. [11:20] I just wonder, if I succeed porting, how will Mir handle more then 1 monitor? [11:20] Perfectly? [11:21] :-) [11:22] even if I use the Android (user space) driver or is that irrelevant [11:25] 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] alan_g, that's exactly what I wanted to hear :-D === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|lunch === dandrader|lunch is now known as dandrader === chihchun_afk is now known as chihchun === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|EOD [22:58] zzarr: In the best case, pulling the thunderbolt cable will result in applications seamlessly transferring to the integrated chip. [22:58] zzarr: In the common case, pulling the thunderbolt cable will result in applications crashing :) [22:59] 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.