07:39wlb: weston Issue #759 opened by ye-huang (ye-huang) weston: not available drm_plane to use after hotplug multiple times https://gitlab.freedesktop.org/wayland/weston/-/issues/759
08:13pq: swick[m], I read about MHC ICC, and my knee-jerk reaction was "yuck". They are not ICC spec'd, and I'm not sure they are standard enough. Didn't the doc say that apps need to craft those profiles themselves, too?
08:14pq: the backlight thing sounded like a sane compromize, given that backlight control is mostly an unknown what it does when it works.
08:14wlb: weston/main: Leandro Ribeiro * drm: drop disable_planes being false as a condition to support writeback https://gitlab.freedesktop.org/wayland/weston/commit/6d8e3c569cf7 libweston/backend-drm/drm.c
08:14wlb: weston/main: Leandro Ribeiro * drm: do not pull writeback task if KMS atomic API is not supported https://gitlab.freedesktop.org/wayland/weston/commit/3226417573ac libweston/backend-drm/drm.c
08:14wlb: weston/main: Leandro Ribeiro * tests: assert that capture info was received before trying screenshot https://gitlab.freedesktop.org/wayland/weston/commit/cf64fbe78478 tests/weston-test-client-helper.c
08:14wlb: weston Issue #757 closed \o/ (cannot start up when upgrade weston to 12.0 https://gitlab.freedesktop.org/wayland/weston/-/issues/757)
08:14wlb: weston Merge request !1257 merged \o/ (Fixes DRM-backend for devices without support for the KMS atomic API https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1257)
08:16pq: mjt, by "intercept" do you mean have an application prevent idle-timer from triggering when it is about to trigger?
09:11wlb: weston Merge request !1258 opened by Chao Guo (ChaoGuo) Support the display of the image on underlay planes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258
09:21abdur: Hi, I am running weston 10.0.1 on arm64 and see that XWAYLAND_NO_GLAMOR is set in the environment of weston's child processes. I haven't set this in environment files or shell source files. If this is unset, xwayland runs fine with glamor support.
09:36MrCooper: abdur: the string XWAYLAND_NO_GLAMOR does not appear in the upstream weston Git history; is it maybe set in /etc/environment or some other file under /etc ?
09:52daniels: are you perhaps running NXP's vendor tree?
10:00wlb: wayland Merge request !321 opened by Simon Ser (emersion) server: document wl_display_add_socket_fd() ownership https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/321 [IPC library]
10:05wlb: wayland Merge request !322 opened by Simon Ser (emersion) server: add wl_display_remove_socket_fd() https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/322 [IPC library]
10:05abdur: MrCooper: XWAYLAND_NO_GLAMOR is not there in /etc/environment or in other files under /etc/.
10:05abdur: daniels: yes, it is NXP's vendor tree for weston, but I cannot find XWAYLAND_NO_GLAMOR in downstream weston's history either.
10:08pq: It must be somewhere in your system, fgrep -R should be able to find it.
10:26pq: swick[m], btw. your the points that Vegdahl raised, do you have plans on those?
10:42swick[m]: pq: you'd think that ms would maybe try to find a way to make backlight controls more predictable but they alos just gave up apparently
10:43swick[m]: the vcgt tag is (was?) not standard either yet it turned out very useful
10:44pq: yeah, but the VCGT tag is quite old, right? Has MHC proven itself yet?
10:44swick[m]: and the new tag basically replaces vcgt with a lut, matrix, lut pipeline instead
10:44swick[m]: well, no, but it seems sensible
10:46swick[m]: and they want manufactures to provide that stuff so we might get better calibrated monitors... maybe
10:47pq: wait, really? That... err... I didn't really read how MHC works. I got the feeling it is a band-aid for letting ICC files work in HDR systems, so I wasn't interested.
10:48pq: it's also very much orthogonal to what we have in the protocol, so I think we can just wait and see.
10:49pq: Did it offer any answers to the reference white and viewing environment problems?
10:50pq: Wonder if ICC's people have made any comments about MHC.
10:51swick[m]: pq: Vegdahl? missing context here
10:51pq: the Blender person
10:52swick[m]: oh, our different color volumes being a bit confusing?
10:52swick[m]: not really sure what to do there tbh
10:52pq: yes, that was the most tangible question I think
10:54pq: I think a page in color-and-hdr with pics of volumes or CIE xy plane might be nice to explain what the different volumes are. Glossary is a reminder/definition.
10:55swick[m]: wrt reference white on windows: they assume that a certain PQ signal produces a specific real-world luminance level and then just have a variable reference white level
10:56pq: How to link from XML to docs is a technical problem, and the most I can think of that is to use ad hoc footnotes for links.
10:56swick[m]: if you have PQ mastered content you would have to remap that to the configurable reference white
10:56swick[m]: but I don't think apps do that, hence too dark HDR
10:57pq: swick[m], right, but all the problems we are having with reference white, like how to define it for all kinds on content that may or may not use PQ luminance units.
10:57swick[m]: true. they just let you use PQ, scRGB and everything else is SDR
10:57pq: oh, Windows requires apps to fetch the reference white level and apply it themselves?
10:58swick[m]: yes, for PQ and scRGB. everything else is considered SDR and is handled transparently
10:58pq: right
10:59swick[m]: and I got what they mean with scene-referred: the scene in which a user sees the content
10:59swick[m]: absolutely terrible misuse imo but then it all starts to make some sense
10:59pq: ...
11:00pq: umm, how is that different from display-referred then?
11:02pq: Did you find out where does the scRGB 1.0 = 80 PQ-cd/m² come from? Or is that 80 just a default number and Windows compositor actually makes 1.0 to the set reference white?
11:02swick[m]: well, PQ content is usually mastered for the reference display. the PQ mode in windows is supposed to be values encoded for the specific output that it will end up on.
11:03swick[m]: so the reference monitor vs the real monitor
11:04swick[m]: https://learn.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range
11:04swick[m]: > Match your app's reference white to the OS SDR reference white level
11:04pq: I'm staring at https://learn.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range#system-composition-using-a-high-bit-depth-canonical-color-space-1 ...
11:04swick[m]: oh, it's linkable...
11:07pq: in *that* table, I think "display-referred" means "relative to reference white" and "scene-referred" means "absolute luminance", because that's what it seems to be saying.
11:10pq: In the end, Windows HDR apps need to render for whatever Windows tells them to, right? Apps targeting a standard ... err, image description just don't work right unless by accident. That main design difference to Wayland.
11:11pq: *That is the main design difference to Wayland.
11:12pq: How the use of MHC ICC changes things, I didn't get yet.
11:34swick[m]: the only image description like thing they have is sRGB but that's most things on windows
11:34swick[m]: but yeah, it is different indeed
11:35swick[m]: MHC is something to think about when it pops up in the real world and the calibration bits should be easy to support
11:35pq: ok
11:38pq: Was the current Windows ICC workflow the same as X11? Display server takes care of VCGT but nothing else, apps need to use both display and content profiles themselves?
11:38swick[m]: yup
11:38pq: And MHC does not change that?
11:38swick[m]: don't think so
11:38pq: alright, that makes it simple to think about
11:53zamundaaa[m]: afaiu they do change that a bit, as apps don't get the ICC profile anymore
11:53zamundaaa[m]: Instead, Windows tells them to target primaries+whitepoint+sdr brightness + whatever, and deals with the rest itself
11:55pq: ok, so the job of the display ICC profile is to make the monitor look like a simple display describable with a matrix-shaper profile which what those parameters essentially are.
11:55pq: err, "look like" I mean "appear API wise"
11:58mjt: pq: re intercept idle status changes in weston: not to prevent entering idle status but to know when this happens (back n forth)
11:59pq: mjt, right, no such implementation in Weston yet AFAIK - if there was, wayland-info would list it. I suppose an implementation would be welcome.
11:59mjt: ah.. So it's just a missing feature
12:00pq: yup, the protocol has already been accepted in wayland-protocols, right? I haven't really looked.
12:01mjt: weston handles idle state internally, unlike, say, sway: it needs swayidle which keeps status and run swaymsg dpms on/off. But at the same time, weston does not integrate with logind for example, so weston-running machine wont suspend when not in use
12:02pq: that's another feature missing from weston
12:11zamundaaa[m]: hwentlan_: is there a way for us to get lower level documentation on FreeSync Premium Pro and/or use it on Linux?
12:12zamundaaa[m]: Afaict it would be fantastic to use that in compositors - both for knowing a monitor is certified (-> enable features by default) and for disabling the gamut mapper of the display, which seems to often mess things up
12:13pq: ... I'm curious about that messing up
12:23daniels: mjt: we could definitely add the logind idle stuff pretty easily!
12:23zamundaaa[m]: the common bits are that the gamut mapper adds latency, and potentially does gamut mapping in a different way from what you'd want or expect
12:24swick[m]: I asked Harry and he said it's probably not happening
12:24swick[m]: so, SBTM is your best bet
12:25zamundaaa[m]: swick: well that's annoying. Not that "free" after all then I guess :/
12:26swick[m]: and when that's not available you might get the same behavior of PQ with "native" display hdr metadata
12:27swick[m]: the freesync premium pro stuff is a lot of different things such as certified vrr (freesync) working in hdr mode and other certification
12:27mjt: daniels: yes, this (logind idle notifications) is about 5 lines of code if using glib
12:27zamundaaa[m]: pq: the bigger problem is that some displays mess it up real bad. My FreeSync Premium Pro HDR certified display looks the same with Colorspace = Default and Colorspace = BT2020_RGB with normal HDR metadata... while I'm sending BT709 content in both cases
12:29zamundaaa[m]: If I send content encoded as BT2020 with BT2020_RGB, everything looks really heavily desaturated in comparison to both its sRGB mode and to other displays I have here. Which I suspect might be the case on more gaming monitors out there
12:30pq: zamundaaa[m], which colors do you actually see? BT709 color, or BT709 values reinterpreted as if it was already BT2020?
12:31pq: zamundaaa[m], for comparison, do you have any decent SDR monitor where you can choose sRGB mode in the OSD?
12:32daniels: mjt: hmm, we're using libseat for most everything, so it would need to be added there first; that does at least use sd-bus rather than raw libdbus, so it would be way less painful to type out there
12:33pq: zamundaaa[m], I am wondering if what you call heavily de-saturated is actually what sRGB is supposed to look like.
12:34zamundaaa[m]: pq: I have a laptop where HP at least claims it's 100% sRGB. The comparison looks like this: https://media.discordapp.net/attachments/1092950047487959210/1102034368060469368/20230430_025007.jpg?width=981&height=736
12:34pq: zamundaaa[m], I'm also guessing that sending "normal HDR metadata" might make the monitor ignore your Colorspace=default, assuming BT2020 instead. Which actually is a reasonable default if any HDR metadata is present.
12:35zamundaaa[m]: pq: that's with the content also encoded in BT2020 though
12:35pq: zamundaaa[m], marketing "100% sRGB" says nothing to me. I wouldn't trust such claims.
12:35pq: and a laptop panel, even less trust
12:35swick[m]: I mean, the spec is pretty clear that the hdr tf metadata only overrides the transfer characteristics
12:36swick[m]: so per spec you really need to set both
12:36pq: swick[m], but did anyone actually test without? :-)
12:36pq: if works if one sets both...
12:36swick[m]: but it won't surprise me the least if a lot of monitors just claim to support bt2020 primaries without reacting to the infoframe at all
12:36zamundaaa[m]: pq: only sending HDR metadata works correctly on this monitor
12:37swick[m]: just to be HDR compliant
12:37zamundaaa[m]: Using the PQ EOTF and Colorspace = Default looks good
12:38pq: zamundaaa[m], in your photo, the bigger monitor looks more natural to me, but that's no indication of anything really.
12:40pq: zamundaaa[m], my guess is still: for all these modes you tested, that monitor takes everything as if it was a BT2020 signal, and maps that to the panel. Only when your compositor manually converts BT709 to BT2020, you see BT709 roughly correctly.
12:40zamundaaa[m]: pq: I am doing that in KWin...
12:40pq: yes?
12:43zamundaaa[m]: pq: so you mean to say that even in sRGB mode it assumes BT2020 signalling?
12:43pq: If my guess holds, then the usual case of displaying sRGB on that monitor (without the manual color conversion) is showing the image far too saturated. But people tend to like more saturation than less, so they just "ooh!" for ten seconds and then adapt.
12:43mjt: daniels: glib bindings are also quite good. But yeah, sd-bus is much easier
12:44kennylevinsen: hmm, it's a good question how that would best be done
12:45pq: zamundaaa[m], if by sRGB mode you mean a "defaults everything" mode, then I think any consumer monitor will attempt to use all of the gamut it has, because that makes people go "ooh!".
12:46zamundaaa[m]: pq: the sRGB mode isn't enabled by default
12:46pq: exactly
12:46kennylevinsen: note that most of the logind API can be called "blindly" by any process belonging to the session, so e.g. SetBrightness and inhibitors do not *need* to go through libseat
12:49zamundaaa[m]: pq: according to https://www.rtings.com/monitor/reviews/samsung/c49rg9-crg9, the sRGB mode does actual sRGB
12:49hwentlan_: zamundaaa, I agree it would be great. Unfortunately I can't share anything, though.
12:50pq: zamundaaa[m], did you set picture mode to sRGB in the monitor?
12:52kennylevinsen: there could be a libseat_set_hint thing if necessary, but I postponed thinking about this until someone twisted my arm
12:53emersion: i'm not sure i understand what set_hint would do…?
12:55kennylevinsen: logind's SetIdleHint and SetLockedHint just set a boolean about current compositor state, used for configured logind actions
12:55zamundaaa[m]: pq: yes. With Colorspace = Default it looks like the laptop
12:55pq: zamundaaa[m], no, I mean in the monitor's settings.
12:56emersion: kennylevinsen: maybe we can just add a logind-specific getter for the sd-bus stuff and let the compositor do that?
12:56pq: Is there no setting for that *in* the monitor?
12:56emersion: getter for the objects necessary to make a D-Bus call
12:56zamundaaa[m]: pq: I meant with the monitor "picture mode" to sRGB + `Colorspace = Default`
12:56pq: zamundaaa[m], Ah! Ok.
12:57pq: zamundaaa[m], does changing "picture mode" not change anything?
12:58zamundaaa[m]: It seems to change the brightness curve, and some modes also change the colors
12:59pq: mmhm
13:00kennylevinsen: strictly speaking, one can just use /org/freedesktop/login1/session/self - but at least knowing that logind was in use would probably be nice...
13:01zamundaaa[m]: pq: the meeting with Krita devs is now
13:01pq: zamundaaa[m], I wonder if in the de-saturated case stuff happens twice... first compositor converts BT.709 to BT.2020, then the monitor maps BT.2020 1:1 into its own gamut. What do you send as the HDR metadata?
13:02pq: yup, I'm watching
13:02zamundaaa[m]: I send what the monitor claims to have in the EDID
13:02pq: ok... wonder if it just ignores that
13:14pq: zamundaaa[m], what if you convert BT.709 to monitor-native and lie about it being BT.2020? Do you get a good image match that way?
13:46zamundaaa[m]: pq: yep, it looks good that way
13:50pq: zamundaaa[m], so I guess the monitor expects a BT.2020 signal to use the full gamut of BT.2020 and ignored the HDR static metadata telling it about a smaller actual gamut.
13:51zamundaaa[m]: yeah
13:51pq: then it gamut-maps the full BT.2020 to native in a fixed fashion, perhaps
13:51pq: where "maps" could even be "does nothing to the pixel values"
13:52pq: zamundaaa[m], I'm like 20 minutes behind in the discussion.