00:04 wlb: wayland-protocols Issue #141 opened by i509VCB (i509VCB) xdg-shell: restrict or clarify behavior with negative width and height in configure. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/141
09:47 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?
09:48 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.
09:48 emersion: there is a WIP cursor-shape protocol to address this
09:48 emersion: but yeah otherwise you need libwayland-cursor
09:55 WhyNotHugo: And the "theme" string is usually the value of "XCURSOR_THEME", right?
09:55 emersion: and the size is usually XCURSOR_SIZE
09:56 emersion: short of anything better
09:56 WhyNotHugo: Now I understand why I had to set xcursor_theme in sway AND install adwaita: there's no "default" theme.
09:57 emersion: there should be a default theme
09:57 emersion: you can poass a NULL theme
09:57 emersion: pass*
09:57 emersion: then it'll use /usr/share/icons/default
09:58 emersion: (but that may not be what the user wants, maybe the user wants another theme)
09:59 WhyNotHugo: I don't seem to have any /usr/share/icons/default, nor do I see any package providing that.
09:59 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.
10:00 WhyNotHugo: What package provides /usr/share/icons/default for you?
10:00 emersion: default-cursors
10:00 emersion: https://archlinux.org/packages/extra/any/default-cursors/
10:01 WhyNotHugo: lol https://github.com/archlinux/svntogit-packages/blob/packages/default-cursors/trunk/PKGBUILD#L13-L19
10:02 WhyNotHugo: That explains the differences in behaviour on arch/alpine I guess XD
10:04 WhyNotHugo: Re cursor-shape-v1: Why use "north-east corner" instead of "top-right corner" like other protocols?
10:04 emersion: CSS names
10:04 emersion: and also that's what cursor names look like
10:06 WhyNotHugo: Ah, now it all makes sense.
10:17 WhyNotHugo: cursor-shape-v1 looks great BTW, it's pretty much the missing piece here :)
12:18 pq: https://lists.w3.org/Archives/Public/public-colorweb/2023May/0001.html - maybe we'll get a couple more little docs public
12:47 wlb: weston Merge request !1233 opened by Philipp Zabel (pH5) libweston: consolidate 'Using GL/Pixman renderer' log message https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1233
13:08 JoshuaAshton: fwiw I really don't like the use of h.273 code points for any of the color protocol stuff
13:09 JoshuaAshton: It doesn't provide any advantage over us just enumerating them ourselves in the protocol
13:09 JoshuaAshton: and just produces lock-in
13:10 emersion: yeah, same here
13:10 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.
13:10 JoshuaAshton: How is it not a lock-in?
13:11 JoshuaAshton: You're linking some external specification meant for video containers to a generic color protocol forever
13:11 pq: because CICP only takes values 0-255, and we have values 256 - 4 billion to use ourselves.
13:11 pq: I guess I don't understand what you mean by "lock-in".
13:11 JoshuaAshton: Using values outside of the range for ourselves seems even more of a hack
13:12 JoshuaAshton: Them being conveniently the same, I completely understand, but not enumerating them in specification is a different story right
13:12 pq: the whole reason why H.273 was written is so that we don't have to invent our own enumerations from scratch.
13:12 JoshuaAshton: We are not a video container
13:12 pq: yes, we are
13:13 JoshuaAshton: ???
13:14 pq: we carry the exact same information for the exact same use and purpose
13:14 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
13:14 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.
13:15 JoshuaAshton: That is what I am referring to, yes
13:15 JoshuaAshton: If you are going to enumerate in the xml then I am fine
13:15 pq: in XML, yes
13:15 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!)
13:15 JoshuaAshton: :p
13:16 pq: you cannot avoid having to dig up and read each and ever spec it refers to
13:16 pq: *every
13:17 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...
13:17 JoshuaAshton: swick[m]: Yeah... We have digital gain brightness slider in SteamOS for this reason
13:18 emersion: JoshuaAshton: is that what the "HDR multiplier" hw block is for? or completely unrelated?
13:18 JoshuaAshton: Unrelated
13:18 emersion: okok
13:18 JoshuaAshton: the HDR multiplier is mostly if you aren't using the Shaper + 3D LUT
13:19 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
13:19 JoshuaAshton: I imagine it's probably needed for the cursor plane
13:19 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.
13:19 JoshuaAshton: also rotatey schenanigans :(
13:19 emersion: yeah…
13:20 emersion: i think we do attempt to use it though?
13:20 emersion: i still have some patches for that which are in steamos but not upstream :(
13:20 JoshuaAshton: No: `bNeedsComposite |= bDrewCursor;`
13:20 emersion: so we force composite?
13:20 JoshuaAshton: We did try once upon a time
13:20 JoshuaAshton: yeah
13:20 pq: I'm surprised the HDR multiplier thing exists, because it seems that any brightness/contrast control must have a non-linear effect to work well.
13:21 JoshuaAshton: the HDR multiplier is there for SDR content scaling really
13:21 emersion: ah right
13:21 pq: oh, just to set the SDR white level wrt. everything else?
13:21 JoshuaAshton: when you use sRGB TF in AMDGPU, it goes to [0 - 1] where 1.0 = 80 nits (like scRGB range)
13:21 JoshuaAshton: yeah
13:21 pq: ok
13:22 JoshuaAshton: so when you do a re-pq op its as if 1.0 = 80 nits
13:23 pq: isn't the main defining thing about scRGB that the per-channel range [0.0, 1.0] matches sRGB?
13:23 JoshuaAshton: What about it matches sRGB are you referring to?
13:23 JoshuaAshton: As in 1.0 = 80 nits or something else?
13:24 pq: I mean literally the same as sRGB when values are in [0,0, 1.0], on all aspects.
13:24 JoshuaAshton: No
13:24 pq: do tell me more
13:24 JoshuaAshton: On Windows, scRGB is entirely linear. There isn't even an extended sRGB option to at all in DXGI
13:24 pq: not, I'm not talking about Windows, but scRGB as defined
13:25 pq: that Windows thing is just one API among many, and not even a spec in the sense where scRGB is defined
13:25 JoshuaAshton: I mean... it is a colorspace defined by Microsoft
13:25 pq: yeah, but the Window API is not the spec of scRGB, let me dig that up
13:26 JoshuaAshton: https://web.archive.org/web/20110725185444/http://www.colour.org/tc8-05/Docs/colorspace/61966-2-2NPa.pdf
13:26 pq: IEC 61966-2-2:2003 is the spec, but since it's IEC, it's unfortunately behind a paywall
13:26 JoshuaAshton: This was listed on Wikipedia so /shrug
13:27 pq: yes, it is
13:27 pq: Windows API does not define this, the IEC spec does
13:29 JoshuaAshton: What the IEC spec does compared to what Microsoft, Windows, every application in existence, actually does is kind of irrelevant though.
13:29 JoshuaAshton: If this distinction is upsetting, just call it what Vulkan does: `VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT` :P
13:31 JoshuaAshton: like that's the best way to avoid confusion
13:31 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.
13:32 JoshuaAshton: Pretty sure that is "scRGB-nl"
13:32 JoshuaAshton: but
13:32 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.
13:39 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
13:39 JoshuaAshton: The issue is what you define 1.0 as in the FP format
13:40 swick[m]: the same as with sRGB
13:41 swick[m]: and if you have 1.0, 1.0, 1.0 that has relative luminance 1.0
13:41 swick[m]: what exactly that maps to in absolute luminance terms depends on the reference display
13:43 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.
13:43 JoshuaAshton: it is absolute luminence
13:43 swick[m]: on some hypothetical monitor, yes
13:44 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.
13:46 pq: in a hypothetical reference viewing environment, yes.
13:47 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.
13:47 pq: or if you fix the scRGB diffuse white to 80 nits, then you fixed your SDR max white to that too.
13:49 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?
13:49 pq: Yes.
13:49 swick[m]: this question doesn't really make sense
13:49 pq: because the [0.0, 1.0] range on scRGB *is* sRGB.
13:50 pq: optical values
13:50 JoshuaAshton: pq: No, then. That is not what I want, and that is not how apps use it or expect.
13:51 pq: That's really interesting.
13:51 JoshuaAshton: "For example, scRGB (1.0, 1.0, 1.0) and HDR10 (497, 497, 497) both encode exactly D65 white at 80 nits luminance."
13:51 pq: please do not confuse HDR10 here
13:51 swick[m]: again, 80 nits for the sRGB viewing environment
13:51 swick[m]: this is different from PQ and the actual viewing environment
13:52 JoshuaAshton: pq: This is from the Microsoft documentation, not my words :-)
13:52 pq: we're talking about sRGB and scRGB in the sRGB viewing environment, there is no PQ here
13:52 swick[m]: I don't know to be honest because JoshuaAshton is throwing in everything at the same time
13:53 pq: yes, I get the same feeling
13:53 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
13:54 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.
13:54 JEEB: yup
13:55 swick[m]: if you now throw in some PQ encoding, you also change the reference monitor and the reference viewing environment
13:55 JoshuaAshton: I am saying that scRGB 1.0 encodes 80 nits no matter what the scale for SDR/sRGB content is.
13:55 swick[m]: so the 80 nits from scRGB do not represent 80 nits in PQ
13:55 swick[m]: sure
13:55 JoshuaAshton: I am saying 80 nits in scRGB represent 80 nits in PQ
13:55 JEEB: no
13:55 swick[m]: that's just wrong
13:56 JoshuaAshton: The MS documentation literally says this.
13:56 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
13:56 JEEB: even MS documents note this IIRC
13:57 JoshuaAshton: https://learn.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range
13:57 JoshuaAshton: > See: How is 1.0f interpreted
13:57 JEEB: ah yes, I was just looking in my browser for the URL in history for that thing
13:57 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.
13:58 JEEB: that's the graphics white
13:58 JoshuaAshton: Yes, and in your speak, Windows treats scRGB as scene-referred brightness and not display-referred brightness.
13:58 JoshuaAshton: The line before that says that
13:59 pq: I'm a lot more worried now what the Windows web page says: SDR is display-referred, and HDR is scene-referred.
13:59 swick[m]: it is not scene-referred
13:59 swick[m]: it cannot be
13:59 pq: yeah, it cannot be, but they say so
13:59 swick[m]: oh god ms
14:00 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.
14:00 swick[m]: if I had to guess what they mean I'd say they mean linear?
14:00 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
14:01 pq: I could bet this choice of wording is to avoid implying that when using PQ system, one always displays nits 1:1
14:02 swick[m]: possible...
14:02 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)
14:02 pq: only because PQ is defined in nits, but those not the same nits that will actually be displayed
14:02 JEEB: yea
14:02 pq: so they cannot say it's display-referred
14:03 swick[m]: JoshuaAshton: don't use the microsoft docs to try to understand color management :s
14:03 pq: but it also is not scene-referred, it's something in between
14:03 JEEB: scene-referred is something like HLG :P
14:03 swick[m]: yeah
14:03 JoshuaAshton: pq: More like tonemapped scene-referred
14:03 pq: I think HLG makes the same mistake with terminology
14:03 swick[m]: not even that
14:04 JoshuaAshton: I guess not
14:04 JoshuaAshton: because of eye adaptation in games and stuff :-)
14:04 JoshuaAshton: I guess that is a 'tonemapping'
14:04 swick[m]: scene-referred means you need some image state transition to output-referred
14:04 swick[m]: that is not tone mapping or gamut mapping or anything like that
14:05 JoshuaAshton: swick[m]: I am just using them to try and explain to you what I see games do.
14:06 swick[m]: games do whatever to look well on windows
14:06 JEEB: while I use those docs + what MS compositor seems to do
14:06 JEEB: I did the d3d11 colorspace stuff for mpv and finished up the libplacebo patches
14:06 JEEB: so I kinda have a grasp on what the compositor seems to be doing
14:07 pq: It's useful to understand what Windows does, for compatiblity purposes, but that's all.
14:07 JoshuaAshton: I did not see scRGB content change from 1.0f = 80 nits, on Windows in my testing for DXVK
14:08 JEEB: JoshuaAshton: with SDR output you don't see a jump of course. since compositor just clamps
14:08 JoshuaAshton: No, I mean in HDR mode
14:08 JEEB: OK, that differs from my experience
14:08 JoshuaAshton: I see sRGB content change brightness with the slider, sure, but not scRGB
14:08 JEEB: I'll try to retest later
14:09 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.
14:09 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."
14:09 JoshuaAshton: Seems to match my experience and what I am saying
14:09 JEEB: JoshuaAshton: that is :weird: if true
14:10 JoshuaAshton: Why is that weird? Every scRGB app I have seen (games) treat scRGB output the same as PQ output?
14:10 swick[m]: because scRGB is not PQ
14:10 swick[m]: but hey, windows things
14:11 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
14:11 JEEB: but if they define it like that and you need to do the boosting yourself, then sure...
14:12 swick[m]: but it's not scRGB anymore
14:13 swick[m]: it has the primaries and white point of scRGB but the reference viewing environment and reference display of PQ
14:13 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?
14:14 JEEB: nah, there is a single one
14:14 pq: hmm... some other API toggle for it elsewhere? or heaven forbid, a user setting? or a difference between Windows versions?
14:15 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
14:15 JoshuaAshton: There is only one "DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709"
14:15 JEEB: yea
14:15 pq: ok
14:15 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."
14:15 JEEB: I mean, if they actually document it like that then most likely I misremembered my testing results with the compositor
14:15 JEEB: although I'll still attempt to retest at some point
14:16 JEEB: but it's *weird* if that's how it gets handled with HDR output in compositor
14:16 pq: yeah, it doesn't make sense to me
14:16 JEEB: since you can easily get white -> grey with screens without the remapping
14:16 pq: maybe we'll understand why once we try it ourselves
14:17 pq: in a Wayland compositor where we know what it does and can see the alternative result ourselves
14:18 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
14:18 pq: cool
14:19 pq: maybe they have an assumption that when you start viewing HDR content, you turn off the room lights? :-)
14:20 JEEB: if that was the case, they wouldn't boost sRGB to HDR graphics white :)
14:20 pq: but that's for regular apps with lights on, still in HDR mode
14:21 JEEB: lol
14:21 pq: ..because otherwise the monitor has much less headroom for HDR highlights
14:22 pq: it's wild but I can almost buy that argument
14:23 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.
14:26 pq: and who'd play games or watch movies with lights on at office brightness levels
15:30 zamundaaa[m]: pq: I do that. I guess we'll need a brightness slider for HDR content too
15:34 haasn: absolute luminance was a mistake
15:34 haasn: HLG could have prevented this, but industry decided to follow dolby's crap standards
15:36 haasn: can we just pretend PQ doesn't exist in wayland
15:36 haasn: can we also pretend HLG doesn't exist
15:36 haasn: can we use something like S-Log or V-Log
21:19 wlb: wayland-protocols Merge request !209 opened by Simon Ser (emersion) build: add Wayland subproject https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/209