ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
kts has quit [Quit: Konversation terminated!]
kts has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
floof58 has quit [Quit: floof58]
floof58 has joined #wayland
kts has quit [Quit: Konversation terminated!]
cool110_ has quit [Remote host closed the connection]
cool110 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
kelnos has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
rasterman has joined #wayland
<pq>
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?
<pq>
the backlight thing sounded like a sane compromize, given that backlight control is mostly an unknown what it does when it works.
<abdur>
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.
<MrCooper>
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 ?
elinor has joined #wayland
<daniels>
are you perhaps running NXP's vendor tree?
<abdur>
MrCooper: XWAYLAND_NO_GLAMOR is not there in /etc/environment or in other files under /etc/.
<abdur>
daniels: yes, it is NXP's vendor tree for weston, but I cannot find XWAYLAND_NO_GLAMOR in downstream weston's history either.
<pq>
It must be somewhere in your system, fgrep -R should be able to find it.
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
kts has joined #wayland
<pq>
swick[m], btw. your the points that Vegdahl raised, do you have plans on those?
junaid has quit [Remote host closed the connection]
<swick[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
<swick[m]>
the vcgt tag is (was?) not standard either yet it turned out very useful
<pq>
yeah, but the VCGT tag is quite old, right? Has MHC proven itself yet?
<swick[m]>
and the new tag basically replaces vcgt with a lut, matrix, lut pipeline instead
<swick[m]>
well, no, but it seems sensible
<swick[m]>
and they want manufactures to provide that stuff so we might get better calibrated monitors... maybe
<pq>
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.
<pq>
it's also very much orthogonal to what we have in the protocol, so I think we can just wait and see.
<pq>
Did it offer any answers to the reference white and viewing environment problems?
<pq>
Wonder if ICC's people have made any comments about MHC.
<swick[m]>
pq: Vegdahl? missing context here
<pq>
the Blender person
<swick[m]>
oh, our different color volumes being a bit confusing?
<swick[m]>
not really sure what to do there tbh
<pq>
yes, that was the most tangible question I think
<pq>
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.
<swick[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
<pq>
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.
<swick[m]>
if you have PQ mastered content you would have to remap that to the configurable reference white
<swick[m]>
but I don't think apps do that, hence too dark HDR
<pq>
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.
<swick[m]>
true. they just let you use PQ, scRGB and everything else is SDR
<pq>
oh, Windows requires apps to fetch the reference white level and apply it themselves?
<swick[m]>
yes, for PQ and scRGB. everything else is considered SDR and is handled transparently
<pq>
right
<swick[m]>
and I got what they mean with scene-referred: the scene in which a user sees the content
<swick[m]>
absolutely terrible misuse imo but then it all starts to make some sense
<pq>
...
<pq>
umm, how is that different from display-referred then?
<pq>
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?
<swick[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.
<swick[m]>
so the reference monitor vs the real monitor
<pq>
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.
<pq>
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.
<pq>
*That is the main design difference to Wayland.
<pq>
How the use of MHC ICC changes things, I didn't get yet.
fmuellner has joined #wayland
kts has quit [Read error: Connection reset by peer]
<swick[m]>
the only image description like thing they have is sRGB but that's most things on windows
<swick[m]>
but yeah, it is different indeed
<swick[m]>
MHC is something to think about when it pops up in the real world and the calibration bits should be easy to support
<pq>
ok
nerdopolis has joined #wayland
<pq>
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?
<swick[m]>
yup
<pq>
And MHC does not change that?
<swick[m]>
don't think so
<pq>
alright, that makes it simple to think about
<zamundaaa[m]>
afaiu they do change that a bit, as apps don't get the ICC profile anymore
<zamundaaa[m]>
Instead, Windows tells them to target primaries+whitepoint+sdr brightness + whatever, and deals with the rest itself
<pq>
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.
<pq>
err, "look like" I mean "appear API wise"
<mjt>
pq: re intercept idle status changes in weston: not to prevent entering idle status but to know when this happens (back n forth)
<pq>
mjt, right, no such implementation in Weston yet AFAIK - if there was, wayland-info would list it. I suppose an implementation would be welcome.
<mjt>
ah.. So it's just a missing feature
<pq>
yup, the protocol has already been accepted in wayland-protocols, right? I haven't really looked.
<mjt>
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
<pq>
that's another feature missing from weston
kts has joined #wayland
bluepenquin has joined #wayland
<zamundaaa[m]>
hwentlan_: is there a way for us to get lower level documentation on FreeSync Premium Pro and/or use it on Linux?
<zamundaaa[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
<pq>
... I'm curious about that messing up
selckin has quit [Quit: selckin]
<daniels>
mjt: we could definitely add the logind idle stuff pretty easily!
<zamundaaa[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
<swick[m]>
I asked Harry and he said it's probably not happening
<swick[m]>
so, SBTM is your best bet
<zamundaaa[m]>
swick: well that's annoying. Not that "free" after all then I guess :/
tawonga has joined #wayland
<swick[m]>
and when that's not available you might get the same behavior of PQ with "native" display hdr metadata
<swick[m]>
the freesync premium pro stuff is a lot of different things such as certified vrr (freesync) working in hdr mode and other certification
<mjt>
daniels: yes, this (logind idle notifications) is about 5 lines of code if using glib
<zamundaaa[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
<zamundaaa[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
<pq>
zamundaaa[m], which colors do you actually see? BT709 color, or BT709 values reinterpreted as if it was already BT2020?
<pq>
zamundaaa[m], for comparison, do you have any decent SDR monitor where you can choose sRGB mode in the OSD?
Company has joined #wayland
<daniels>
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
<pq>
zamundaaa[m], I am wondering if what you call heavily de-saturated is actually what sRGB is supposed to look like.
<pq>
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.
<zamundaaa[m]>
pq: that's with the content also encoded in BT2020 though
<pq>
zamundaaa[m], marketing "100% sRGB" says nothing to me. I wouldn't trust such claims.
<pq>
and a laptop panel, even less trust
<swick[m]>
I mean, the spec is pretty clear that the hdr tf metadata only overrides the transfer characteristics
<swick[m]>
so per spec you really need to set both
<pq>
swick[m], but did anyone actually test without? :-)
<pq>
if works if one sets both...
<swick[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
<zamundaaa[m]>
pq: only sending HDR metadata works correctly on this monitor
<swick[m]>
just to be HDR compliant
<zamundaaa[m]>
Using the PQ EOTF and Colorspace = Default looks good
<pq>
zamundaaa[m], in your photo, the bigger monitor looks more natural to me, but that's no indication of anything really.
bluepenquin has quit [Quit: issued !quit command]
<pq>
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.
<zamundaaa[m]>
pq: I am doing that in KWin...
<pq>
yes?
<zamundaaa[m]>
pq: so you mean to say that even in sRGB mode it assumes BT2020 signalling?
<pq>
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.
<mjt>
daniels: glib bindings are also quite good. But yeah, sd-bus is much easier
<kennylevinsen>
hmm, it's a good question how that would best be done
<pq>
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!".
<zamundaaa[m]>
pq: the sRGB mode isn't enabled by default
<pq>
exactly
<kennylevinsen>
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
<hwentlan_>
zamundaaa, I agree it would be great. Unfortunately I can't share anything, though.
<pq>
zamundaaa[m], did you set picture mode to sRGB in the monitor?
<kennylevinsen>
there could be a libseat_set_hint thing if necessary, but I postponed thinking about this until someone twisted my arm
<emersion>
i'm not sure i understand what set_hint would do…?
<kennylevinsen>
logind's SetIdleHint and SetLockedHint just set a boolean about current compositor state, used for configured logind actions
selckin has joined #wayland
<zamundaaa[m]>
pq: yes. With Colorspace = Default it looks like the laptop
<pq>
zamundaaa[m], no, I mean in the monitor's settings.
<emersion>
kennylevinsen: maybe we can just add a logind-specific getter for the sd-bus stuff and let the compositor do that?
<pq>
Is there no setting for that *in* the monitor?
bbhtt has joined #wayland
<emersion>
getter for the objects necessary to make a D-Bus call
<zamundaaa[m]>
pq: I meant with the monitor "picture mode" to sRGB + `Colorspace = Default`
<pq>
zamundaaa[m], Ah! Ok.
<pq>
zamundaaa[m], does changing "picture mode" not change anything?
<zamundaaa[m]>
It seems to change the brightness curve, and some modes also change the colors
<pq>
mmhm
<kennylevinsen>
strictly speaking, one can just use /org/freedesktop/login1/session/self - but at least knowing that logind was in use would probably be nice...
<zamundaaa[m]>
pq: the meeting with Krita devs is now
<pq>
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?
<pq>
yup, I'm watching
<zamundaaa[m]>
I send what the monitor claims to have in the EDID
bbhtt has quit []
<pq>
ok... wonder if it just ignores that
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
kts has quit [Quit: Konversation terminated!]
<pq>
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?
spdy has joined #wayland
spdy has quit [Quit: Leaving]
agd5f has quit [Read error: Connection reset by peer]
rv1sr has joined #wayland
<zamundaaa[m]>
pq: yep, it looks good that way
agd5f has joined #wayland
<pq>
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.
<zamundaaa[m]>
yeah
<pq>
then it gamut-maps the full BT.2020 to native in a fixed fashion, perhaps
<pq>
where "maps" could even be "does nothing to the pixel values"
<pq>
zamundaaa[m], I'm like 20 minutes behind in the discussion.
flibitijibibo has joined #wayland
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #wayland
i509vcb has joined #wayland
kts has joined #wayland
tzimmermann has quit [Quit: Leaving]
rederick29 has joined #wayland
pochu has quit [Ping timeout: 480 seconds]
d_ed has joined #wayland
iomari891 has quit [Remote host closed the connection]
jmdaemon has quit [Ping timeout: 480 seconds]
d_ed has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
junaid has joined #wayland
cool110_ has joined #wayland
riverdc_ has joined #wayland
cool110 has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
riverdc has quit [Remote host closed the connection]
Leopold_ has joined #wayland
pochu has joined #wayland
pochu has quit []
junaid has quit [Remote host closed the connection]
rv1sr has quit []
iomari891 has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
agd5f_ has joined #wayland
agd5f has quit [Read error: Connection reset by peer]
qyliss has quit [Quit: bye]
qyliss has joined #wayland
agd5f has joined #wayland
agd5f_ has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
junaid has joined #wayland
junaid has quit []
junaid has joined #wayland
junaid has quit []
junaid has joined #wayland
junaid has quit []
junaid has joined #wayland
junaid_ has joined #wayland
junaid__ has joined #wayland
junaid___ has joined #wayland
junaid__1 has joined #wayland
junaid__ has quit []
junaid has quit [Quit: Lost terminal]
junaid___ has quit []
junaid__1 has quit []
junaid_ has quit []
junaid has joined #wayland
junaid has quit []
junaid has joined #wayland
junaid has quit []
rederick29 has quit [Quit: Leaving]
ahartmetz has quit [Quit: Konversation terminated!]
cool110 has joined #wayland
cool110_ has quit [Quit: ZNC 1.8.2+deb3build2 - https://znc.in]