| 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:05 |
|---|---|---|
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:23 |
| RAOF | We're still pre-feature freeze. | 01:24 |
| RAOF | It's a perfectly sensible time to get new features in :) | 01:24 |
| 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:25 |
| duflu | That said, this is xenial. And on desktop Xmir still defaults to less stable dri2 renderer | 01:26 |
| duflu | Less correct, not less stable | 01:27 |
| duflu | Speaking of maturity, despite our Unity8 issues Weston logins are more broken than Unity8 :) | 01:29 |
| RAOF | Eh. Weston isn't really pretending to be a DE :) | 02:05 |
| duflu | RAOF: No, but a VT with just a flashing cursor is worse than expected | 02:16 |
| RAOF | Probably. No-one really cares for it in Ubuntu :) | 02:17 |
| 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:18 |
| RAOF | It's actually more trouble to *not* provide it as a login option. | 02:20 |
| RAOF | (Probably?) | 02:20 |
| 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 | 02:23 |
| 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:04 |
| alan_g | zzarr: it isn't interesting (yet). Assuming there are userspace drivers I'd expect Mir to use them. | 11:08 |
| 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:11 |
| 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:12 |
| zzarr | hehe, okey | 11:13 |
| zzarr | well there's another thing holding it back.... there are no cabinets for sale yet | 11:13 |
| 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:14 |
| zzarr | I would like it to resume on the internal GPU | 11:15 |
| zzarr | okey | 11:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| zzarr | I just wonder, if I succeed porting, how will Mir handle more then 1 monitor? | 11:20 |
| alan_g | Perfectly? | 11:20 |
| zzarr | :-) | 11:21 |
| zzarr | even if I use the Android (user space) driver or is that irrelevant | 11:22 |
| 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:25 |
| zzarr | alan_g, that's exactly what I wanted to hear :-D | 11:26 |
| === 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 | ||
| 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:58 |
| 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. | 22:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!