ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
paulk has joined #wayland
paulk-bis has quit [Read error: Connection reset by peer]
tanty has quit [Remote host closed the connection]
tanty has joined #wayland
kts has joined #wayland
tzimmermann has joined #wayland
kts has quit [Quit: Konversation terminated!]
tanty has quit [Quit: Ciao!]
pochu has joined #wayland
kts has joined #wayland
tanty has joined #wayland
nnm has quit []
nnm has joined #wayland
parazyd3 has left #wayland [#wayland]
parazyd has joined #wayland
kts has quit [Quit: Konversation terminated!]
iomari891 has joined #wayland
simplymaster has joined #wayland
simplymaster has quit [Remote host closed the connection]
dcz has joined #wayland
kts has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
kts has quit []
<WhyNotHugo>
If I want my client to draw a "hand" cursor, I need to load the cursor and put it into a surface/buffer myself, right? Like, the compositor won't do that for me, will it?
<WhyNotHugo>
I'm looking at wl_pointer::set_cursor specifically, but I'm wondering if clients need to handle the "load the cursor file and decode it" themselves.
<emersion>
there is a WIP cursor-shape protocol to address this
<emersion>
but yeah otherwise you need libwayland-cursor
<WhyNotHugo>
And the "theme" string is usually the value of "XCURSOR_THEME", right?
<emersion>
and the size is usually XCURSOR_SIZE
<emersion>
short of anything better
<WhyNotHugo>
Now I understand why I had to set xcursor_theme in sway AND install adwaita: there's no "default" theme.
<emersion>
there should be a default theme
<emersion>
you can poass a NULL theme
<emersion>
pass*
<emersion>
then it'll use /usr/share/icons/default
<emersion>
(but that may not be what the user wants, maybe the user wants another theme)
<WhyNotHugo>
I don't seem to have any /usr/share/icons/default, nor do I see any package providing that.
<WhyNotHugo>
My question is answered though, I think it's up to the user to have XCURSOR_THEME properly set and a matching theme installed.
<WhyNotHugo>
What package provides /usr/share/icons/default for you?
<JoshuaAshton>
fwiw I really don't like the use of h.273 code points for any of the color protocol stuff
<JoshuaAshton>
It doesn't provide any advantage over us just enumerating them ourselves in the protocol
<JoshuaAshton>
and just produces lock-in
floof58 is now known as Guest494
floof58 has joined #wayland
<emersion>
yeah, same here
<pq>
I don't understand why you say that. It's not a lock-in, and the more I think about using these in Weston, the less it seems likely I'd use them.
<JoshuaAshton>
How is it not a lock-in?
<JoshuaAshton>
You're linking some external specification meant for video containers to a generic color protocol forever
<pq>
because CICP only takes values 0-255, and we have values 256 - 4 billion to use ourselves.
<pq>
I guess I don't understand what you mean by "lock-in".
<JoshuaAshton>
Using values outside of the range for ourselves seems even more of a hack
<JoshuaAshton>
Them being conveniently the same, I completely understand, but not enumerating them in specification is a different story right
<pq>
the whole reason why H.273 was written is so that we don't have to invent our own enumerations from scratch.
<JoshuaAshton>
We are not a video container
<pq>
yes, we are
Guest494 has quit [Ping timeout: 480 seconds]
<JoshuaAshton>
???
<pq>
we carry the exact same information for the exact same use and purpose
<JoshuaAshton>
What I am saying is, I am completely okay if you want 0-255 to be the same as H.273, that's fine right, but not enumerating them in the specification and referring to externally is the complete wrong approach
<pq>
I have already promised I will type the enums for you to look at, but I think you will be gravely disappointed since it won't help anything.
<JoshuaAshton>
That is what I am referring to, yes
<JoshuaAshton>
If you are going to enumerate in the xml then I am fine
<pq>
in XML, yes
<JoshuaAshton>
I just want us to be on the same page here that we aren't doing a Vulkan external data sheet thing (those suck!)
<JoshuaAshton>
:p
<pq>
you cannot avoid having to dig up and read each and ever spec it refers to
<pq>
*every
<JoshuaAshton>
> the only thing that makes PQ special is that people keep saying PQ is special and that's what gets us displays where you can't control the brightness in HDR modes...
<JoshuaAshton>
swick[m]: Yeah... We have digital gain brightness slider in SteamOS for this reason
<emersion>
JoshuaAshton: is that what the "HDR multiplier" hw block is for? or completely unrelated?
<JoshuaAshton>
Unrelated
<emersion>
okok
<JoshuaAshton>
the HDR multiplier is mostly if you aren't using the Shaper + 3D LUT
<JoshuaAshton>
but we use shaper + 3D LUT per-plane so we roll digital gain and also SDR brightness etc etc into the shaper + 3D LUT
<JoshuaAshton>
I imagine it's probably needed for the cursor plane
<JoshuaAshton>
but we don't even attempt to use that in SteamOS given it's clipped to the overlay plane which means it doesn't work for us.
<JoshuaAshton>
also rotatey schenanigans :(
<emersion>
yeah…
<emersion>
i think we do attempt to use it though?
<emersion>
i still have some patches for that which are in steamos but not upstream :(
<pq>
IEC 61966-2-2:2003 is the spec, but since it's IEC, it's unfortunately behind a paywall
<JoshuaAshton>
This was listed on Wikipedia so /shrug
<pq>
yes, it is
<pq>
Windows API does not define this, the IEC spec does
<JoshuaAshton>
What the IEC spec does compared to what Microsoft, Windows, every application in existence, actually does is kind of irrelevant though.
<JoshuaAshton>
If this distinction is upsetting, just call it what Vulkan does: `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT` :P
<JoshuaAshton>
like that's the best way to avoid confusion
<pq>
The point of scRGB is that it is fully compatible with sRGB values (encoded with the same TF, obviously), so you can feed sRGB optical through an scRGB pipeline without any modifications and get the right results.
<JoshuaAshton>
Pretty sure that is "scRGB-nl"
<JoshuaAshton>
but
<JoshuaAshton>
We have had a decent amount of back and forth about "what scRGB" actually is, when it doesn't actually matter or achieve anything. So let's just agree on calling it something less confusing like "ExtendedSRGB_Linear" and "ExtendedSRGB_NonLinear" or something.
<swick[m]>
not sure what you're trying to achieve here. you can pick a fp format, a linear TF, the sRGB primaries and define the content color volume
<JoshuaAshton>
The issue is what you define 1.0 as in the FP format
<swick[m]>
the same as with sRGB
<swick[m]>
and if you have 1.0, 1.0, 1.0 that has relative luminance 1.0
<swick[m]>
what exactly that maps to in absolute luminance terms depends on the reference display
<JoshuaAshton>
I am more referring to mapping it to an absolute value in nits. scRGB is used by some Windows games for HDR content and has 1.0 = 80 nits.
<JoshuaAshton>
it is absolute luminence
<swick[m]>
on some hypothetical monitor, yes
<pq>
..and that means that whatever luminance you choose as the SDR maximum white, then scRGB optical (1.0, 1.0, 1.0) needs to have that same luminance.
<pq>
in a hypothetical reference viewing environment, yes.
<pq>
What I'm saying is that *if* you have adjustable SDR max white luminance, then scRGB optical (1.0, 1.0, 1.0) luminance must match.
<pq>
or if you fix the scRGB diffuse white to 80 nits, then you fixed your SDR max white to that too.
<JoshuaAshton>
Are you stating that if the user changes the brightness of typical SDR content away from 80 nits, that you think scRGB brightness should change too?
<pq>
Yes.
<swick[m]>
this question doesn't really make sense
<pq>
because the [0.0, 1.0] range on scRGB *is* sRGB.
<pq>
optical values
<JoshuaAshton>
pq: No, then. That is not what I want, and that is not how apps use it or expect.
<pq>
That's really interesting.
<JoshuaAshton>
"For example, scRGB (1.0, 1.0, 1.0) and HDR10 (497, 497, 497) both encode exactly D65 white at 80 nits luminance."
<pq>
please do not confuse HDR10 here
<swick[m]>
again, 80 nits for the sRGB viewing environment
<swick[m]>
this is different from PQ and the actual viewing environment
<JoshuaAshton>
pq: This is from the Microsoft documentation, not my words :-)
<pq>
we're talking about sRGB and scRGB in the sRGB viewing environment, there is no PQ here
<swick[m]>
I don't know to be honest because JoshuaAshton is throwing in everything at the same time
<pq>
yes, I get the same feeling
<JEEB>
outside the theoretical, scRGB seems to be utilized as follows by MS: 1.0 is the graphics white, which is sRGB max when then handled as SDR output by the compositor, and gets mapped to HDR graphics white with HDR output in the compositor
<swick[m]>
you have to be absolute clear what you're talking about. scRGB and sRGB 1.0, 1.0, 1.0 encode 80 nits on the sRGB reference display in the sRGB viewing environment.
<JEEB>
yup
<swick[m]>
if you now throw in some PQ encoding, you also change the reference monitor and the reference viewing environment
<JoshuaAshton>
I am saying that scRGB 1.0 encodes 80 nits no matter what the scale for SDR/sRGB content is.
<swick[m]>
so the 80 nits from scRGB do not represent 80 nits in PQ
<swick[m]>
sure
<JoshuaAshton>
I am saying 80 nits in scRGB represent 80 nits in PQ
<JEEB>
no
<swick[m]>
that's just wrong
<JoshuaAshton>
The MS documentation literally says this.
<JEEB>
then if you need to interpret that value for output in HDR context, you need to remap graphics white to HDR graphics white, which is by various documents is documented at 203 nits
<JEEB>
ah yes, I was just looking in my browser for the URL in history for that thing
<JEEB>
> Windows allows the user to adjust the SDR reference white level to their preference; that's the luminance that Windows will render sRGB (1.0, 1.0, 1.0) at. On desktop HDR monitors, SDR reference white levels are typically set to around 200 nits.
<JEEB>
that's the graphics white
<JoshuaAshton>
Yes, and in your speak, Windows treats scRGB as scene-referred brightness and not display-referred brightness.
<JoshuaAshton>
The line before that says that
<pq>
I'm a lot more worried now what the Windows web page says: SDR is display-referred, and HDR is scene-referred.
<swick[m]>
it is not scene-referred
<swick[m]>
it cannot be
<pq>
yeah, it cannot be, but they say so
<swick[m]>
oh god ms
<JEEB>
I think that's just because of HDR monitors being monitors, and not every monitor being "white enough" at 203 nits input. they note that specifically because they let the user adjust the amount of boosting done to graphics white.
<swick[m]>
if I had to guess what they mean I'd say they mean linear?
<pq>
they probably mean something else, maybe HDR is display-referred on a refence display in reference viewing environment, which may be different from reality
<pq>
I could bet this choice of wording is to avoid implying that when using PQ system, one always displays nits 1:1
<swick[m]>
possible...
<JEEB>
in any case, looking at the compositor, by default without adjusting the graphics white for HDR output, they clip scRGB to [0,1] for SDR output, and map 1.0 to ~203 nits for HDR output (or according to user's preference)
<pq>
only because PQ is defined in nits, but those not the same nits that will actually be displayed
<JEEB>
yea
<pq>
so they cannot say it's display-referred
<swick[m]>
JoshuaAshton: don't use the microsoft docs to try to understand color management :s
<pq>
but it also is not scene-referred, it's something in between
<JEEB>
scene-referred is something like HLG :P
<swick[m]>
yeah
<JoshuaAshton>
pq: More like tonemapped scene-referred
<pq>
I think HLG makes the same mistake with terminology
<swick[m]>
not even that
<JoshuaAshton>
I guess not
<JoshuaAshton>
because of eye adaptation in games and stuff :-)
<JoshuaAshton>
I guess that is a 'tonemapping'
<swick[m]>
scene-referred means you need some image state transition to output-referred
<swick[m]>
that is not tone mapping or gamut mapping or anything like that
pochu has quit [Quit: leaving]
<JoshuaAshton>
swick[m]: I am just using them to try and explain to you what I see games do.
<swick[m]>
games do whatever to look well on windows
<JEEB>
while I use those docs + what MS compositor seems to do
<JEEB>
I did the d3d11 colorspace stuff for mpv and finished up the libplacebo patches
<JEEB>
so I kinda have a grasp on what the compositor seems to be doing
<pq>
It's useful to understand what Windows does, for compatiblity purposes, but that's all.
<JoshuaAshton>
I did not see scRGB content change from 1.0f = 80 nits, on Windows in my testing for DXVK
<JEEB>
JoshuaAshton: with SDR output you don't see a jump of course. since compositor just clamps
<JoshuaAshton>
No, I mean in HDR mode
<JEEB>
OK, that differs from my experience
<JoshuaAshton>
I see sRGB content change brightness with the slider, sure, but not scRGB
<JEEB>
I'll try to retest later
<JoshuaAshton>
> Windows defines the nominal, or default, reference white level at 80 nits. Therefore if you were to render a standard sRGB (1.0, 1.0, 1.0) white to an FP16 swap chain, then it would be reproduced at 80 nits luminance. In order to match the actual user-defined reference white level, you must adjust SDR content from 80 nits to the level specified via AdvancedColorInfo.SdrWhiteLevelInNits.
<pq>
from IEC 61966-2-2 draft: "This extended standard RGB colour space solution accomplishes these goals by extending the sRGB tonal range and bit precision and encoding the values linearly with respect to luminance. All other aspects of the sRGB64 solution are directly inherited from the IEC 61966-2-1 sRGB standard."
<JoshuaAshton>
Seems to match my experience and what I am saying
<JEEB>
JoshuaAshton: that is :weird: if true
<JoshuaAshton>
Why is that weird? Every scRGB app I have seen (games) treat scRGB output the same as PQ output?
<swick[m]>
because scRGB is not PQ
<swick[m]>
but hey, windows things
<JEEB>
it is weird because the whole idea would be to have similar SDR range. and graphics white gets mapped to another nit range in HDR output context
<JEEB>
but if they define it like that and you need to do the boosting yourself, then sure...
<swick[m]>
but it's not scRGB anymore
<swick[m]>
it has the primaries and white point of scRGB but the reference viewing environment and reference display of PQ
<pq>
maybe JEEB and JoshuaAshton are looking at different "formats"? JEEB is looking at the actual scRGB format while JoshuaAshton happens to be using an FP16 optical color space derived from BT.2020/PQ which is not scRGB. Do you have two different code points in Windows for those?
<JEEB>
nah, there is a single one
<pq>
hmm... some other API toggle for it elsewhere? or heaven forbid, a user setting? or a difference between Windows versions?
<JEEB>
and the weird thing is that it does indeed get clipped in SDR output mode, which probably would lead to the same values possibly being shown with less perceived brightness in HDR mode
<JoshuaAshton>
There is only one "DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709"
<JEEB>
yea
<pq>
ok
<JoshuaAshton>
"This is the standard definition for scRGB, and is usually used with 16 bit integer, 16 bit floating point, or 32 bit floating point color channels."
<JEEB>
I mean, if they actually document it like that then most likely I misremembered my testing results with the compositor
<JEEB>
although I'll still attempt to retest at some point
<JEEB>
but it's *weird* if that's how it gets handled with HDR output in compositor
<pq>
yeah, it doesn't make sense to me
<JEEB>
since you can easily get white -> grey with screens without the remapping
<pq>
maybe we'll understand why once we try it ourselves
<pq>
in a Wayland compositor where we know what it does and can see the alternative result ourselves
<JEEB>
at least I should be able to test what the compositor does easily. open the same wide gamut image either signaled as normal sRGB or scRGB next to each other with the compositor output being in HDR mode
<pq>
cool
<pq>
maybe they have an assumption that when you start viewing HDR content, you turn off the room lights? :-)
<JEEB>
if that was the case, they wouldn't boost sRGB to HDR graphics white :)
<pq>
but that's for regular apps with lights on, still in HDR mode
<JEEB>
lol
<pq>
..because otherwise the monitor has much less headroom for HDR highlights
<pq>
it's wild but I can almost buy that argument
<pq>
if people do turn lights off for entertainment, then we would have the same problem: users would need to re-adjust the SDR levels manually. That's not cool.
<pq>
and who'd play games or watch movies with lights on at office brightness levels
kts has joined #wayland
<zamundaaa[m]>
pq: I do that. I guess we'll need a brightness slider for HDR content too
MrCooper has joined #wayland
<haasn>
absolute luminance was a mistake
<haasn>
HLG could have prevented this, but industry decided to follow dolby's crap standards
<haasn>
can we just pretend PQ doesn't exist in wayland
<haasn>
can we also pretend HLG doesn't exist
<haasn>
can we use something like S-Log or V-Log
tzimmermann has quit [Quit: Leaving]
fmuellner has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
dopiosu has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
Company has joined #wayland
floof58 is now known as Guest508
floof58 has joined #wayland
Guest508 has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
cmichael has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
dcz has joined #wayland
kts has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
nerdopolis has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
dopiosu has quit [Quit: dopiosu]
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
kts has joined #wayland
kts has quit []
kts has joined #wayland
mvlad has quit [Remote host closed the connection]
dcz has quit [Ping timeout: 480 seconds]
rv1sr has quit []
DodoGTA is now known as Guest523
Guest523 has quit [Read error: Connection reset by peer]