| === chihchun is now known as chihchun_afk | ||
| duflu | RAOF: I'm half tempted to land two of my mirvanity proposals without any reviews. No one else has an interest/stake in it really. Would you mind sanity checking occluded-vanity and interval-0-is-not-an-error? | 02:49 |
|---|---|---|
| RAOF | duflu: sure | 02:49 |
| RAOF | duflu: Seems like a more correct fix for interval-0-is-not-an-error would be to disallow interval 0? | 02:57 |
| RAOF | duflu: Since there's never any reason to use it, and your new code assumes that the display runs at a fixed rate? | 02:57 |
| duflu | RAOF: There are two reasons you might want it; (a) To report Mir's absolute best case lowest latency; and (b) to measure improvements to framedropping (e.g. predictive bypass presently only helps with interval 0) | 03:01 |
| duflu | It's not default, sure. | 03:02 |
| duflu | RAOF: Also fixed frame rate displays are a good assumption, but also variable ones don't break mirvanity. My FreeSync display gets much better numbers than my fixed one | 03:03 |
| duflu | RAOF: The display Hz is only used to calculated the estimated range, which gives an estimate of when the test is finished (has covered the full superposition range) | 03:03 |
| duflu | It's not used to produce any measurements | 03:04 |
| RAOF | The latency variable is never used to calculate latency? | 03:05 |
| duflu | RAOF: The monitor's refresh rate does not contribute to the measurements reported. Just contributes to "estimated range" which tells the user what to expect from the measured range | 03:06 |
| duflu | I mean the display_hz does not contribute. The physical performance of the monitor does contribute of course | 03:07 |
| duflu | RAOF: Oh, sorry, I see the bit you mean. Yes latency -= state->last_change_time_error is a necessary evil, to avoid having to make every frame completely unique and having to write a vision algorithm that could distinguish tens of thousands of different images | 03:09 |
| duflu | Our "refresh rate" is always the maximum refresh rate of a monitor, so that tweak is minimal for a variable framerate display | 03:11 |
| RAOF | As long as we always report the maximum refresh that doesn't seem to be broken, yes. | 03:11 |
| duflu | RAOF: Indeed from the kernel up I believe we're always, only, told the maximum rate. | 03:12 |
| RAOF | For now :) | 03:12 |
| duflu | I don't mind. If we get more data later we can adjust | 03:12 |
| duflu | I read that Nvidia were drilling Google on the same kind of issue -- why optimize for fixed frame rate displays? The answer is because that's what most people have, and because variable frame rate displays don't really suffer if you're careful. | 03:14 |
| RAOF | If you use them as fixed framerate displays variable rate displays are simply a frame-times->16ms-optimisation. | 03:16 |
| duflu | RAOF: I intentionally drive mirvanity at the max frame rate the hardware will accept. So the max refresh rate is indeed the refresh rate it runs at | 03:17 |
| RAOF | Unless there's contention, but that's not very helpful for benchmarking anyway. | 03:18 |
| RAOF | ...at least for the moment. | 03:18 |
| duflu | I'm content that the benchmark is occasionally finding bugs we would never have found otherwise. So despite the theoretical limitations, it is immensely useful | 03:20 |
| === chihchun_afk is now known as chihchun | ||
| duflu | RAOF: In case you were curious my reasoning for wanting EDIDs was just to get at some sane identifying string for each monitor. | 06:28 |
| duflu | I don't think DRM provides that abstraction...? | 06:28 |
| RAOF | duflu: Yeah, we should totally expose something like that. | 06:28 |
| RAOF | Correct; you want to parse the edid. | 06:28 |
| duflu | Which is unfortunate if DRM is doing parsing already | 06:28 |
| RAOF | Yeah. | 06:29 |
| RAOF | Hm. | 06:30 |
| RAOF | I don't *think* there's a DRM API for extracting the vendor strings, but it might make sense. | 06:30 |
| RAOF | On the other hand, importing an edid parser into Mir might also make sense. | 06:30 |
| duflu | RAOF: What else are we missing from the EDID? | 06:31 |
| duflu | What is is *DRM* missing from the EDID? | 06:31 |
| RAOF | Nothing it cares about, AFAIK :) | 06:32 |
| RAOF | The monitor manufacturer and year/week of production are two things that aren't exposed by DRM. | 06:33 |
| duflu | I'm just thinking about things a user might want to see in a config GUI. The vendor/product strings are helpful | 06:34 |
| RAOF | Serial number, manufacturer product number. | 06:35 |
| RAOF | Yeah, these are useful things to expose. | 06:35 |
| duflu | And firmware uploads! Let's port Mir to the panel itself | 06:36 |
| RAOF | I'm about +0 for parsing the EDID in Mir, -0 for just throwing the EDID to a client. ☺ | 06:39 |
| duflu | RAOF: Sounds sufficient. And probably is the status quo (only the GUI app has to link to an EDID decoding library) | 06:44 |
| RAOF | I actually don't know; X parses the EDID itself, but I'm uncertain whether those properties are exported over XRANDR. | 06:45 |
| RAOF | Or, rather, I've forgotten whether those properties are exported :) | 06:46 |
| RAOF | Aaah, merge conflicts! | 06:58 |
| RAOF | A perfect time to EOD! | 06:59 |
| duflu | Ok, later. | 07:11 |
| === marcusto_ is now known as marcustomlinson | ||
| alan_g | sil2100: is it you I need to ask to get miral into X+O? https://bileto.ubuntu.com/#/ticket/21105 | 09:17 |
| sil2100 | alan_g: hey! Let me take a look | 09:53 |
| sil2100 | alan_g: ah, ok, so the destination probably confused people | 09:54 |
| sil2100 | alan_g: so this silo is only for xenial-overlay? | 09:54 |
| alan_g | sil2100: I got confused by belito UI and couldn't figure out how to target XO only. (I do know now.) But it's harmless landing in zesty too. Just wanted to know "the right way" before fiddling further as its new to xenial | 09:56 |
| sil2100 | alan_g: ok, publishing | 09:58 |
| alan_g | sil2100: thanks | 09:58 |
| alan_g | sil2100: does "xenial/miral: Failed to update local..." mean that didn't work? | 10:01 |
| sil2100 | Interesting error | 10:02 |
| sil2100 | Ah, I know what happened | 10:03 |
| sil2100 | Ok, publishing manually | 10:03 |
| sil2100 | Bileto got confused if I wanted to publish it as a xenial-overlay-only landing, as the cached primary branches were meant for zesty | 10:05 |
| alan_g | sil2100: I guess I got bileto back for confusing me. ;) | 10:08 |
| === JanC_ is now known as JanC | ||
| === marcusto_ is now known as marcustomlinson_ | ||
| === hikiko is now known as hikiko|ln | ||
| === hikiko|ln is now known as hikiko | ||
| alan_g | dandrader: I don't know how to go about checking this (as no-one knew it was missing). Can you take a look? https://code.launchpad.net/~alan-griffiths/miral/rewire-SurfaceObserver-notifySurfaceModifications/+merge/309668 | 12:16 |
| dandrader | alan_g, sure | 12:31 |
| dandrader | alan_g, btw, are you able to build miral-qt without issues? | 12:31 |
| dandrader | alan_g, gerry and I were getting some "missing tracepoints.h" errors | 12:32 |
| alan_g | dandrader: yes, I think that got fixed Friday | 12:32 |
| dandrader | didn't stop to investigate it. so far I I've been just commenting out all trace calls and #includes... | 12:32 |
| dandrader | alan_g, ah, great | 12:33 |
| alan_g | FWIW it actually worked on a second attempt - which is how it got missed | 12:33 |
| kdub | did any of the euro-vogons hear if raof had started poking at the platform extension mechanisms for the client api? | 13:42 |
| alf | kdub: I didn't hear anything | 13:44 |
| anpok_ | hm not yet .. his last complaint were branch conflicts.. | 13:44 |
| anpok_ | I assume he still was working on something else.. | 13:44 |
| anpok_ | as in .. not on something new.. | 13:44 |
| anpok_ | +about.. | 13:44 |
| anpok_ | before he left this morning | 13:44 |
| kdub | thanks alf and anpok_ (reaching the point in the hybris work where it would come in handy to stack on the intended final api instead of deprecations) | 13:45 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| alan_g | dandrader: I assume won't be stepping on anyone's if I rework MirSurface so that the property values get updated correctly? | 16:37 |
| dandrader | alan_g, right, you shouldn't be conflicting with anyone else's work | 16:39 |
| === JanC_ is now known as JanC | ||
| dandrader | alan_g, FYI: we plan to have a ppa with miral-qt as a big fat patch for qtmir this week. so your latest changes will come in handy. | 16:48 |
| dandrader | alan_g, I think gerry has been preparing it in https://code.launchpad.net/~unity-team/qtmir/miral-qt-integration | 16:49 |
| dandrader | I suppose you already know about all that. anyway, just in case :) | 16:50 |
| alan_g | dandrader: I knew he planned it | 16:53 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!