00:12 navi: one could write a compositor and run it under another compositor, i'd think
11:31 swick[m]: pq: did you know the Colorimetry InfoFrame also influences the default quantization range?
11:31 swick[m]: so much fun to be had
12:03 pq: swick[m], but that's hidden by the kernel driver anyway, right? ;-)
12:04 pq: no, I didn't
12:05 pq: or well, I did know that xvYCC can only exist with limited qunatization range
12:10 vsyrjala: xvycc is a paradox
12:10 pq: some would call it "engineering" :-)
12:15 ifreund: with regards to the tablet-v2 protocol, is it expected that the compositor draws a separate cursor for each tool?
12:22 emersion: it's compositor policy
12:22 emersion: mutter does it that way, Sway doesn't, for instance
12:26 ifreund: does the hardware allow using multiple tools at the same time on the same tablet?
12:26 ifreund: it seems like not having separate cursors would be very confusing if so
12:29 emersion: i believe it does (but not all hw supports it)
12:29 emersion: yeah, i agree that per-tool cursors are better
12:29 emersion: from UX perspective
12:30 emersion: a single cursor reminds me of X11 dragging the pointer cursor on touchscreen press…
12:34 ifreund: it also seems a bit cleaner from a code perspective to me, for example the interaction with pointer-constraints seems non-trivial
12:34 ifreund: (if they used the same cursor as the pointer)
12:38 davidre: it depends on the tool probably as well
12:39 davidre: There are physical pens that become a different tool when you press a button
12:39 davidre: I have one that switches tools when I rotate it. Like a phyical pencil it has the eraser on top of it
12:40 ifreund: davidre: maybe I'm missing something, but I don't see how having a separate cursor per tool would be an issue there?
12:40 ifreund: just hide the tool's cursor on proximity out
12:40 davidre: Right
12:41 davidre: I was thinking if I have the same physical thing in my hand I probably expect it to be the same cursor
12:41 ifreund: I assume a client with good UX wants a different cursor graphic for a pen vs an eraser tool as well
12:43 davidre: True
12:43 davidre: The question is what happens if you use the same tool with multiple pads
12:43 davidre: According to the docs such things are possible but very rare
12:45 ifreund: davidre: I'm not sure I understand what issue you're referring to when using the same tool with multiple tablets?
12:46 ifreund: I'd assume the cursor is tied to the tool, not the tablet
12:46 davidre: yeah
12:46 ifreund: that's also what the set_cursor request in the protocol suggests
12:47 davidre: I was confused and thought the tool is not independent in wl protocol
13:19 swick[m]: pq: heh, hidden in the sense that none of the drivers ever sets the colorimetry? suuure
13:19 swick[m]: this is all such a huge shitshow
13:22 JEEB: I think there were some that supported that DRM extension?
13:22 JEEB: AMD being one of those that didn't, alas :<
13:22 JEEB: unless you mean it got set in DRM but not underneath 8)
13:25 swick[m]: every time I look at this mess it seems even more impossible to fix it
13:25 pq: swick[m], I mean, userspace setting "Colorspace" would limit the choices of quantization range the driver can take.
13:25 swick[m]: hah, you expect them to take care of the quantization range when you set the Colorspace prop?
13:26 swick[m]: that's very optimistic
13:26 pq: it's just bugs if they don't, not a broken spec on that part
13:26 swick[m]: but hence the idea to say only a few of the Colorspace variants are well-defined and the rest is undefined
13:27 swick[m]: but I'm failing so hard to even come up with a proper definition for "Default"
13:27 pq: since userspace is expected to program CRTC to always produce full range, the quantization range is not a problem. Transfer characteristics are a problem.
13:27 zamundaaa[m]: What do drivers do right now with "Default", when YCbCr is used on the wire?
13:28 swick[m]: how knows
13:28 swick[m]: who*
13:28 zamundaaa[m]: While we won't get any well defined behavior for what the display does, I would hope that drivers at least do something consistent
13:28 swick[m]: probably a bunch of different things
13:28 swick[m]: they certainly don't
13:28 zamundaaa[m]: As an escape hatch, I'd just leave it undefined until we know more at least
13:28 swick[m]: and even then, what the actual display does is a different matter
13:29 swick[m]: all I want is that they follow the spec consistently
13:29 zamundaaa[m]: Yeah, what the display does can be different, but I want to be able to share ICC profiles between PCs
13:29 pq: what the actual display does is not our worry
13:29 zamundaaa[m]: That doesn't work if Intel and AMD have different ideas of what they send on the wire
13:29 swick[m]: exactly
13:29 swick[m]: yes
13:30 swick[m]: either way, what we have right now is everyone being broken in different ways
13:30 swick[m]: and it takes so much effort to even convince people writing the drivers that everything they are doing is broken
13:30 pq: it's kinda starting to make sense how old-school color management people said that ICC profiles are tied to the machine and the OS and the software.
13:31 swick[m]: at this point I'd just like to make "Default" undefined as well
13:31 pq: (and use case, but I'll ignore that for now)
13:31 swick[m]: give up on the current KMS API
13:31 pq: default as undefined is fine by me
13:32 JEEB: even if the current KMS API mirrors the CTA stuff?
13:32 swick[m]: introduce the colorop CAP and remove all of that crap
13:32 swick[m]: then give user space props for the output format and the infoframes
13:32 swick[m]: move all that shit to user space
13:33 any1: yes please. :)
13:33 swick[m]: we just can't expect driver developers to get all of that right
13:34 pq: careful now, "we cannot expect display server to get anything right" ;-)
13:34 JEEB: just having one central logic which is shared by drivers would prolly be enough
13:35 pq: JEEB, I think mripard is tring to make that happen in the kernel.
13:35 zamundaaa[m]: pq: true, but this split color management responsibility stuff is getting pretty annoying
13:35 JEEB: pq: noice
13:35 mripard: pq: indeed
13:35 pq: but of course, the no-regressions policy means that... defaults cannot be fixed
13:36 pq: or, well, anything?
13:36 JEEB: wat
13:36 zamundaaa[m]: You can't change the behavior of the Default enum value, but you could introduce a new one of course
13:36 zamundaaa[m]: SaneDefault or something :D
13:36 pq: indeed
13:37 swick[m]: it's nice that mripard is moving the stuff to core, but really, we're moving the color pipeline to user space, we should also move the color signalling to user space
13:37 pq: if you fix a driver to behave consistently with others, there is always the possibility that someone will scream "you broke my use case"
13:37 pq: and if someone screams, the kernel regression policy is to revert the change
13:37 zamundaaa[m]: In this case it's also not unreasonable - if you've profiled your screen, you would not expect a new kernel version to break it
13:38 pq: zamundaaa[m], to be honest, I suspect people who care about color have let go of that idea a long time ago :-p
13:39 pq: so... maybe there is a chance
13:39 any1: has anyone suggested creating a new "low level" uAPI?
13:40 mripard: swick[m]: most drivers are broken because there's no real documentation on what drivers are expected to do, no test suite either, they are usually done by small teams that might not have even a full-time person on it, and the ones that have the manpower to understand and get this right largely work in silo
13:40 swick[m]: right, I don't blame anyone for the situation
13:40 mripard: so it's about more than just the API
13:40 mripard: and yeah, getting most of this stuff into the core will at least make it somewhat consistent
13:40 swick[m]: moving the stuff to user space means the driver developers don't even have to understand all of it
13:41 pq: new DRM client cap: UAPI generation? :-)
13:41 mripard: but you'd still have the test that, say, rockchip only ever tested their driver with Android
13:41 mripard: s/test/problem/
13:41 emersion: pq, yeah, i've thought about that
13:41 swick[m]: sure, there definitely also needs to be better documentation and a test suite for the kernel side, even if we move most of the logic to user space
13:42 swick[m]: I very much want that as well
13:42 emersion: API_SANITY_LEVEL=1
13:42 emersion: increase for each sane breaking change :)
13:42 zamundaaa[m]: Aa long as all drivers support the latest sanity level at the same time
13:43 zamundaaa[m]: I still have to deal with legacy modesetting from time to time
13:43 zamundaaa[m]: Having three APIs to support in userspace wouldn't be fun
13:45 pq: FWIW, Weston configuration will have KMS "Colorspace", EOTF from "HDR_OUTPUT_METADATA" and actual color profile as completely orthogonal things to configure separately. Now I'm starting to question whether KMS HDR static metadata should be derived from the output's color profile (image description).
13:46 zamundaaa[m]: In KWin I just always use the values from the EDID
13:46 zamundaaa[m]: Seems to work well so far
13:46 pq: I'd use sRGB by default, and only give an option to use (parts of) EDID.
13:48 pq: for defining the output image description that is, when no special KMS settings are made
13:49 zamundaaa[m]: Oh I just meant for the hdr output metadata
13:49 pq: if KMS "Colorspace" picks BT2020, then that's different, HDR_OUTPUT_METADA picks another EOTF.
13:49 swick[m]: zamundaaa: I mean, all combinations of caps are basically separate versions you have to support
13:50 pq: zamundaaa[m], do you have reports of displays actually responding to the metadata more than just HDR yes/no?
13:51 zamundaaa[m]: I was very pessimistic about that and haven't exposed that functionality to users. HDR_OUTPUT_METADATA is either unset in SDR mode, or set with the values from the EDID in HDR mode
13:53 zamundaaa[m]: On my own screens, I haven't seen a single one react to the primaries. One of them reacts to the brightness values, but really only in ways that would make the user experience worse
13:53 JEEB: yea for MDCV I expect the gamut is mostly ignored
13:54 pq: right
13:54 JEEB: windows does pass the content light level for fullscreen applications
13:54 zamundaaa[m]: JEEB: I don't think Windows 11 does that anymore?
13:55 JEEB: I haven't upgraded yet so haven't tested. don't recall what the other people testing the libplacebo implementation noted and with which windows versions
13:55 JEEB: but I would be surprised if it wouldn't pass it if the application says "ohai this is the CLL"
13:56 zamundaaa[m]: Apps, more specifically games get it wrong, a lot
13:56 pq: perhaps because displays have been ignoring a lot
14:30 zamundaaa[m]: On a very different topic, I've been doing some frame scheduling stuff in KWin, and I've now had a closer look at the timestamps reported by the kernel... They don't make a lot of sense to me
14:30 zamundaaa[m]: On my 120Hz display, usually the difference between to pageflip timestamps is 8.33ms, as you'd expect
14:31 zamundaaa[m]: But sometimes, it's 9.35ms instead. Has anyone seen such a thing happen before, or could perhaps explain why it would happen?
14:31 MrCooper: no and no
14:32 JoshuaAshton: JEEB: When I tested, it seemed not to be sent to the display on Win11, and there is docs here that functionality is kiiinda deprecated: https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_5/nf-dxgi1_5-idxgiswapchain4-sethdrmetadata
14:32 JoshuaAshton: zamundaaa[m]: Have not seen that before
14:32 MrCooper: zamundaaa[m]: which driver is that, and what kind of display connection?
14:32 JEEB: JoshuaAshton: wow re: deprecated
14:33 zamundaaa[m]: This is with amdgpu, over DisplayPort. Adaptive sync is off ofc
14:33 zamundaaa[m]: But the issue that lead me to look at the timestamps also happens on Intel
14:33 JoshuaAshton: SteamOS has some hacks in the kernel for allowing you to commit during vfp, but that would cause you to miss a whole flip, not have the event be delayed by a few ms...
14:34 JoshuaAshton: How are you getting the time zamundaaa[m]?
14:34 JoshuaAshton: The timestamp from the handler or clock_gettime on the event
14:35 zamundaaa[m]: I'm looking at the usec number from the pageflip handler
14:36 JoshuaAshton: O_O
14:38 zamundaaa[m]: That was my reaction as well
14:39 zamundaaa[m]: What's more, there aren't any pageflips that happen "earlier than expected" later to compensate. It just goes back to 8.3ms diff to the previous timestamp
14:42 MrCooper: that sounds like there might actually be different timings in the GPU for some reason
14:43 pq: adjtime clock slweing, perhaps?
14:43 pq: *slewing
14:44 pq: CLOCK_MONOTONIC is not immune to adjtime
14:46 swick[m]: ST 2094 is quite interesting. defines transforms from the hdr version to different other display capabilities. the transforms are applied for a specific period on different parts of the content
14:47 swick[m]: however, I don't think we should ever support that in wayland
14:47 MrCooper: pq: interesting, I almost joked about it being a leap millisecond, maybe that's not so far from the truth then
14:48 JoshuaAshton: seems far too much and too common for clock slewing, no?
14:48 JoshuaAshton: i haven't seen such behaviour on Deck
14:48 MrCooper: depends how far off the system time might go, doesn't it?
14:49 pq: how common is it?
14:49 JoshuaAshton: off by >1ms is huge
14:50 zamundaaa[m]: pq: sometimes it happens multiple times a second
14:51 zamundaaa[m]: I've even seen a pageflip being 2ms later
14:51 JoshuaAshton: zamundaaa[m]: I am curious if you see the same issue with kwin on Deck, or Gamescope on your PC (VBLANK_DEBUG define) and also curious what your clock source is
14:51 JoshuaAshton: perhaps you accidentally got screwed over and defaulted to hpet and not tsc?
14:52 zamundaaa[m]: dmesg says "switched to clocksource tsc"
14:53 MrCooper: and you don't force that via the kernel command line or something?
14:53 MrCooper: some Ryzen CPUs have unreliable TSC
14:54 MrCooper: e.g. the one in this laptop, and when I tried forcing TSC anyway, Firefox kept crashing due to the system time apparently moving backward sometimes
14:55 zamundaaa[m]: Not that I know of, no
14:55 zamundaaa[m]: But if this is a thing that can happen, then I suppose my scheduling logic will have to deal with it somehow
14:55 zamundaaa[m]: As long as the pageflips only happen too late, and not too early, it should be doable
14:56 JoshuaAshton: my scheduling logic would shit the bed at that lolol =)
14:56 JoshuaAshton: but i also haven't seen it
14:56 MrCooper: right, just means slightly higher latency than intended
14:56 JoshuaAshton: 1.3ms is like the entire time we have for our redzone... heh
14:56 MrCooper: well, assuming the timestamps are accurate
14:57 zamundaaa[m]: With my triple buffering MR, KWin schedules up to two frames in advance, which caused this issue to be visible - as then sometimes two frames can accidentally target the same vblank
14:57 zamundaaa[m]: Which then resulted in glxgears getting more fps than the screen actually can show
14:58 MrCooper: ah, because the extrapolated presentation times don't match?
14:58 zamundaaa[m]: Yeah
14:58 MrCooper: will need to keep that in mind for mutter as well
15:34 YaLTeR[m]: wait so what's broken now?
16:49 MrCooper: YaLTeR[m]: zamundaaa[m] is seeing variable intervals between the timestamps in atomic commit completion events, with fixed refresh rate
16:53 YaLTeR[m]: exciting
16:55 pq: could that timestamp be correct but the hardware itself being sometimes late, all the way to the cable?
16:55 MrCooper: that's what I was thinking, before you pointed out adjtime
16:58 vsyrjala: is psr involved?
17:01 Vaughn: Hi,
17:01 Vaughn: I'm trying to compile xwayland with the explicit sync patches applied, and having some trouble tracking down all the necessary patches.
17:01 Vaughn: Does anyone know where xDRI3ImportSyncobjReq is supposed to be defined?
17:02 nielsdg: Vaughn: jfyi, the patches won't do anything before the NVIDIA driver has implemented the protocol as well
17:02 Vaughn: Are you sure? I keep hearing about people having success using them.
17:03 Vaughn: That said, KDE6 seems like it might trigger epileptic fits if we don't get this fixed. So I'd still like to figure out the patches, so that we can patch xwayland in the distro ASAP.
17:03 ofourdan: Vaughn: you'll need the xorgproto branch as well
17:04 Vaughn: Got that one.
17:04 Vaughn: I have- let me show you.
17:04 Vaughn: https://www.irccloud.com/pastebin/pv7p2TTg/
17:06 MrCooper: vsyrjala: not sure, it's DisplayPort to external monitor, though IIRC DP has something like PSR now?
17:06 MrCooper: nielsdg: the effect users are seeing is probably from the glamor_finish workaround buried in there
17:07 ofourdan: Vaughn: xDRI3ImportSyncobjReq is being defined in https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/59 so if you have it and still fails to build, I can only assume your build does not use the xprgproto version from that merge request somehow.
17:07 nielsdg: ah yes, I was looking for your remark about that in the MR
17:07 nielsdg: thanks MrCooper :-)
17:07 ofourdan: Vaughn: see https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/59/diffs#c6dc543117731d25f850f9871e58f25e2e3d2a9f_264_278
17:07 MrCooper: no worries :)
17:08 Vaughn: I see. The overlay must be failing somehow, then.
17:09 Vaughn: ...oh. I'm overriding pkgs.xorgproto instead of pkgs.xorg.xorgproto
17:10 vsyrjala: MrCooper: yeah, "panel replay" is the new hotness apparently
17:12 Vaughn: It's applying properly now. Ok, just one question...
17:12 Vaughn: How is the patch being tested if there are no drivers that support it?
17:17 zamundaaa[m]: vsyrjala: this is on a desktop monitor, and not brand new, so it shouldn't have panel replay or whatever
17:31 MrCooper: Vaughn: it "works", just has mostly no effect without the corresponding pieces in the nvidia driver and Wayland compositor, except for the glamor_finish workaround
17:32 Vaughn: That particular workaround already sounds like something I'd want.
17:33 MrCooper: I suggested multiple times landing that ahead of time, the Nvidia engineers don't seem interested though
17:34 Vaughn: I'm mostly interested in making sure we don't hurt anyone when plasma6 lands in stable.
17:35 MrCooper: it could have a performance impact, so it's a tricky call
17:35 Vaughn: I'm going to push back on that as hard as I can, but if I can't, then anything that might help is good.
17:35 Vaughn: Switching the default session back to X11 would also work, I suppose.
17:44 zamundaaa[m]: Regressing the experience for everyone because of this seems a bit bad
17:44 Vaughn: It's not a matter of performance regressions anymore. Shipping Plasma6 in its current state could cause legal liability.
17:45 zamundaaa[m]: MrCooper: how complicated would it be to extract the glamor_finish workaround?
17:45 MrCooper: not very
17:45 Vaughn: (That aspect would probably come to nothing, since there's no single company to point at. Speaking personally, however, I am not okay with shipping something that can trigger epileptic fits.)
17:46 zamundaaa[m]: Okay, then I'll look into that on Monday. Even if full explicit sync support lands in time, that would be something to backport to older versions imo
17:47 Vaughn: Much appreciated.
17:47 Vaughn: Do you want a video as evidence?
17:48 MrCooper: Vaughn: FWIW, the glitches happen because the nvidia driver doesn't implement implicit synchronization as required by the Wayland & X11 Present protocols and KMS
17:48 Vaughn: Oh, I know. That just doesn't really matter.
17:50 MrCooper: (and BTW the explicit sync support in the protocols won't fix the glitches due to lack of KMS implicit sync)
17:50 Vaughn: I hope you understand. By the point medical regulations get into play, there's no longer any room for finger-pointing. There are real people on the other side of the screen.
17:51 Vaughn: If the only solution ends up being "disable Wayland entirely on nvidia", then I guess that's what I'll push for.
17:51 MrCooper: the issue has been widely known for a long time with GNOME Wayland, so no clue what you're on about
17:51 Vaughn: Wayland has never been the default before
17:52 daniels: defaulting to X11 on NV is the most sensible course of action until it’s fixed, yes
17:52 Vaughn: ...and, uh, until recently if I tried to run wayland on nvidia it wasn't an issue, because I could never get far enough into the process to encounter this issue; things failed in a more flagrant manner prior to that.
17:52 MrCooper: AFAIR it was the default even with nvidia for a long time in Fedora Workstation
17:52 Vaughn: But it's really about the default, yeah. Sorry; that's not really a wayland issue. I might take that up with KDE.
17:54 zamundaaa[m]: MrCooper: KMS implicit sync missing is fixed in KWin
17:54 MrCooper: actually IIRC it is the default now in Fedora, unless there are also non-Nvidia GPUs in the system
17:54 zamundaaa[m]: It just waits for the egl fence before committing buffers
17:55 MrCooper: I see, mutter doesn't do that quite yet
17:55 MrCooper: and IN_FENCE_FD doesn't seem hooked up yet in the nvidia KMS driver
18:00 zamundaaa[m]: Indeed it's not. I've been told it's being worked on, but for now it just rejects the atomic commits
18:09 MrCooper: oh, it's that broken? :(
18:10 MrCooper: so it rejects the commit if IN_FENCE_FD has a non-signaled fence? Because mutter always sets a signaled fence for direct scanout
18:12 zamundaaa[m]: When I tested it, yes. That was with an implicit fence extracted from a dmabuf though, so it could've just been that
18:13 zamundaaa[m]: I should test it again with a fence from egl... But I just hardcoded KWin to not set it with NVidia, as there's no implicit sync it would disable anyways
18:16 swick[m]: so is the problem that the fence is not signaled or that it's not from GL/VK, or something else?
18:16 swick[m]: I mean, in the end it shouldn't matter and they should fix their driver, but still... would be interesting to know
18:44 zamundaaa[m]: I looked up some old conversations about this, apparently it was only implemented for Tegra GPUs, and when it was implemented, they chose to reject commits on unsupported GPUs, for reasons that aren't entirely clear
18:47 zamundaaa[m]: So you really just have to do if (!isNVidia), at least until an updated driver actually supports the property
21:20 JEEB: JoshuaAshton: posted that on libplacebo channel and one of the generally-windows-developing people noted regarding win11 > < nevcairiel> was fine last i checked with a hdmi checker
21:20 JEEB: so it seems to be still passed just fine with fullscreen applications
21:22 JoshuaAshton: interesting
21:23 JoshuaAshton: last time I spoke with NV about it they said it didn't do anything anymore
21:23 JoshuaAshton: maybe the guy was wrong :frog:
21:23 JEEB: are you talking about colorspace configuration?
21:23 JoshuaAshton: no, the SetHDRMetadata
21:23 JoshuaAshton: call
21:23 JEEB: right
21:23 JEEB: just wanted to make sure :D
21:24 JEEB: since MS did apparently tell all vendors to stop auto-switching modes
21:24 JEEB: so that the windows setting (and vendor driver specific interfaces) would be the only ways to switch modes