| duflu | RAOF: Hmm X things as well as the console fail a lot in this DP 1.2 mode. Is that well known? | 01:30 |
|---|---|---|
| RAOF | What sort of things? Is that MST mode? | 01:30 |
| duflu | RAOF: Yeah MST (although only one monitor plugged in) | 01:30 |
| RAOF | Ah, yah. | 01:30 |
| RAOF | Yeah, that's in-progress-ish, from memory. | 01:31 |
| duflu | The console is never native resolution and X randomly fails to start. | 01:31 |
| duflu | Mir is fine though | 01:31 |
| RAOF | airlied has done a bunch of work on it, but I'm not sure if any of the X drivers do the fiddling required to make it appear as a single monitor. | 01:31 |
| duflu | That's fine. Mir works perfectly with it. Better hurry up and replace X | 01:38 |
| RAOF | I'm a bit surprised that Mir works. What do we do with the two distinct outputs? | 01:42 |
| duflu | RAOF: I only have one monitor on each physical output. And each monitor provides a second DP but I don't use those yet | 01:45 |
| duflu | Still one monitor per stream | 01:46 |
| duflu | RAOF: Mir just reports (when the two monitors are plugged in) that I now have 4 DPs and 2 are used | 01:47 |
| duflu | which sounds correct | 01:47 |
| duflu | Although there's still the old i915 bug of reporting my DVI converter as HDMI | 01:48 |
| duflu | Last I checked that was a kernel bug | 01:48 |
| RAOF | Ah, right. | 01:49 |
| RAOF | DP 1.2 has enough bandwidth to drive your 4K monitor as a single panel. | 01:49 |
| RAOF | 4K@60Hz | 01:49 |
| duflu | RAOF: Not 4K just FHD | 01:49 |
| duflu | or 1920x1200 | 01:49 |
| RAOF | Oh. I thought we were talking about monitors that need to appear as 2 distinct outputs in order to drive all the pixels. | 01:50 |
| RAOF | I've got no idea why that wouldn't work with X at the moment. | 01:50 |
| duflu | RAOF: No, just a standard monitor that provides a DisplayPort "hub" | 01:50 |
| duflu | 4K would be fun. But my choice of monitors was motivated by cost (and that they still provide deep colour) | 01:52 |
| duflu | Although I suspect deep colour just means true colour plus temporal dithering | 01:53 |
| duflu | That's an improvement for me anyway | 01:53 |
| duflu | Not that Linux can output deep colour to them right now. | 01:53 |
| duflu | RAOF: Actually you do need to store the scaling factor. Because during resizing you need to know if the client wants to stretch, or is just lagging (and so should be clamped instead). Accidentally scaling during resize would be an ugly regression. We've been there before | 03:58 |
| duflu | RAOF: Actually I posed an algorithm for that yesterday... https://code.launchpad.net/~vanvugt/qtmir/unstretch/+merge/268724 | 04:01 |
| RAOF | Our whole resizing logic is pretty bad, yeah. | 04:20 |
| RAOF | But that's actually pretty easy - when we resize, we proportionately resize the attached buffer stream. | 04:20 |
| duflu | RAOF: I mean we still need clamping logic, a hybrid with scaling as in the above branch | 04:23 |
| RAOF | Oh, right. Yeah, I see your point. | 04:24 |
| RAOF | That's an issue because we do resizing in roughly the worst possible way, though. | 04:24 |
| duflu | RAOF: Actually it's the best. And the same way all other desktop OS's do it | 04:26 |
| duflu | Just the event delivery needs work | 04:26 |
| RAOF | And the “when has the client actually resized” bit. | 04:26 |
| duflu | RAOF: Yeah that's a bug. It's well documented now | 04:27 |
| duflu | As of Friday | 04:27 |
| RAOF | So ignoring all the ways that resizing is terrible, it's the best possible :) | 04:27 |
| duflu | RAOF: There are two open bugs. But the theory of doing it asynchronously is ideal | 04:28 |
| duflu | Unity8 resizing was pretty terrible last I checked. But it's catching up | 04:29 |
| RAOF | I think synchronous resizing would be better in most cases, but that's a matter of tradeoffs. | 04:30 |
| duflu | RAOF: Definitely not. Even if it's working well, you'd have the window edge lagging behind the mouse. Which is much worse than the window contents lagging behind the edge | 04:32 |
| RAOF | That is a value judgement, not an objective truth. | 04:33 |
| RAOF | As I say, tradeoffs. | 04:34 |
| duflu | RAOF: Try it by all means. And you will find out why no OS does it that way. The user experience is better when the thing you're moving keeps up with the mouse pointer (moreso) | 04:40 |
| RAOF | By “no OS” you mean “no OS but Ubuntu”, right? | 04:41 |
| duflu | Also keep in mind most of our resize lag is triple buffers. The problem is halved with double. And eliminated with swap interval zero. | 04:41 |
| duflu | RAOF: Including Ubuntu they all do it the same | 04:41 |
| duflu | Although you can try to drop frames, that also looks ugly. Anything that animates on the swap interval will jump during resizing | 04:43 |
| duflu | Sadly I think that's where QtMir is right now. Haven't checked | 04:43 |
| duflu | No, QtMir can't drop. That's OK then | 04:57 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | step | 07:24 |
| duflu | bt | 07:30 |
| duflu | greyback: So when do you expect to start landing the large change to lp:qtmir? | 08:13 |
| greyback | duflu: next couple of days, this is the culprit: https://code.launchpad.net/~gerboland/qtmir/multimonitor-spike/+merge/263602 | 08:13 |
| duflu | greyback: OK. I expect flux but if you guys are using big hammers I'll avoid the project for a while. | 08:14 |
| duflu | Mir has similar problems... you can't just *fix* a bug because the code in question is always about to be rewritten by somebody | 08:15 |
| greyback | duflu: I'll let you know when it lands then | 08:17 |
| duflu | greyback: Still got a couple of trivial MPs to qtmir up in the mean time | 08:18 |
| greyback | go for it | 08:18 |
| * duflu wishes for mildly stable code that doesn't get rewritten so often | 08:20 | |
| duflu | stable meaning unchanging | 08:20 |
| alan_g | You mean hardware? | 08:31 |
| mcphail | RAOF: Is your "Mir-on-X" project the appropriate thing to use if I'm developing an app (for the phone, using libmirclient) but building and testing on a standard Unity7 Ubuntu desktop? | 08:41 |
| duflu | mcphail: Mir runs on the Ubuntu Phone Emulator so you could use that. | 08:46 |
| mcphail | duflu: I'll try it, but I've found graphics things very slow on the emulator (even non-arm emulators) | 08:47 |
| guest42315 | the emulator experience is really really really bad | 08:47 |
| duflu | mcphail: Yeah, although running phone code on a desktop you can't easily test touch, unless you have a touchscreen laptop | 08:47 |
| mcphail | duflu: True | 08:48 |
| * mcphail will have another look at the emulator later | 08:48 | |
| mcphail | Cheers | 08:48 |
| duflu | mcphail: You can install mir-demos, in which there are three demo servers. All of them understand "--vt 1" to run on a separate VT and you can switch back and forth with X using Ctrl+Alt+Fn | 08:48 |
| mcphail | duflu: I'm running proprietary drivers, though. Will they work? | 08:49 |
| duflu | mcphail: Oh, no it won't | 08:49 |
| mcphail | duflu: I'd tried Unity8 with open source drivers but just got a black screen/flashing cursor so went back to the dark side | 08:50 |
| duflu | mcphail: Yeah I'm not talking about Unity8. Just the mir_* demos in the mir-demos package | 08:50 |
| guest42315 | wily is currently broken on nvidia, i get a black screen | 08:50 |
| guest42315 | with nouveau | 08:50 |
| duflu | Hmm, I wonder if any of ~mir-team has tested the latest wily nouveau | 08:51 |
| mcphail | This is why "Mir-on-X" sounds like an exciting project! :) | 08:51 |
| guest42315 | nobody cares about nvidia :)) they all have intel | 08:51 |
| duflu | mcphail: It has some conditions still. Like only works with some X drivers (not intel yet). And also lag is higher | 08:51 |
| duflu | Hmm, I should check that too | 08:52 |
| duflu | mcphail: Correction it works with intel now | 08:55 |
| mcphail | duflu: does mir-on-x work with proprietary nvidia? | 08:56 |
| duflu | mcphail: Not sure, but you can try easily: sudo env DISPLAY=:0 bin/mir_proving_server | 08:56 |
| duflu | I mean: sudo env DISPLAY=:0 mir_proving_server | 08:56 |
| mcphail | duflu: OK, I'll try this when I get home | 08:57 |
| alan_g | duflu: you shouldn't need sudo to connect to X | 08:57 |
| duflu | True | 08:57 |
| duflu | It works inside X | 08:57 |
| duflu | alan_g: Actually you do. Otherwise no mouse access | 08:57 |
| alan_g | --platform-input-lib=lib/server-modules/server-mesa-x11.so.4 | 08:58 |
| duflu | It's so obvious | 08:59 |
| alan_g | camako: is working on automatically selecting the right input stack | 08:59 |
| mcphail | That gives me something to work with. Cheers guys | 09:01 |
| duflu | Oh dear. Even --vt doesn't work like it used to | 09:01 |
| duflu | I need to relearn the options | 09:01 |
| alan_g | Yep, there is either too much or too little intelligence in the platform selection - but not the right amount. | 09:07 |
| alan_g | yet. | 09:08 |
| alf_ | alan_g: ^^ Tue Sep 01 2015, the day mir platform selection turns into skynet :) | 09:17 |
| alan_g | /sigh I nearly missed it | 09:18 |
| alan_g | BTW alf_ thanks for sorting lp:1489806, I was looking it totally the wrong place. | 09:19 |
| alf_ | alan_g: yw | 09:20 |
| * duflu wonders what changed from intel not working at all to suddenly working without effort | 10:06 | |
| duflu | Must have been a kernel change they were waiting on | 10:07 |
| alan_g | duflu: Mir-on-X? | 10:11 |
| duflu | alan_g: Yeah | 10:11 |
| alan_g | an extension that camako was using landed in the driver | 10:11 |
| duflu | alan_g: Any ETA on the double cursor issue? | 10:12 |
| duflu | Or no discussion yet? | 10:12 |
| alan_g | I've not heard anything | 10:13 |
| duflu | Bah, it's a simple matter of X function calls | 10:15 |
| alan_g | Sure, there's a whole lot "X function calls" needed for it to work right and camako is MPing each thing he get working. But I don't know the order or timescale. | 10:20 |
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|lunch | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g|lunch is now known as alan_g | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === alan_g is now known as alan_g|EOD | ||
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!