00:03 kelnos: i suspect i already know the answer to this ("no"), but is there a way for a regular client to query the absolute pointer position, or at least figure out what output the pointer is on? use-case is a notifications daemon (which is mostly but not completely ported from x11 to wayland), and one of the options the user can choose is to have notifications pop up on the "active" monitor (that is, the one with the pointer). i'm using layer-shell for the...
00:03 kelnos: ... notification windows, placing them by setting anchors and margins
00:03 kelnos: i saw a suggestion somewhere to create transparent full-screen layer-shell surfaces on all outputs, and then see which one gets a wl_pointer.enter() event, but that feels incredibly awful (and could eat events destined for another app)
00:03 kelnos: another option is to just create the layer-shell surface, don't specify an output, map it, wait for the wl_surface.enter() event, and assume/hope that the compositor's policy is to place new layer shell surfaces on the monitor with the mouse pointer if an ouput isn't specified. and then after that, move the window to the appropriate place. i don't love that either...
00:08 zamundaaa[m]: Why would you need to query the output, instead of just letting the compositor put the notification on the active output?
00:14 kennylevinsen: kelnos: “You may pass NULL for output to allow the compositor to decide which output to use. Generally this will be the one that the user most recently interacted with.”
00:14 kennylevinsen: from the layer shell protocol - no need to detect anything
00:15 kennylevinsen: Just make the notification surface without specifying an output and it’ll show up the right place
00:15 psykose: yeah, fnott does that
00:15 psykose: (also optionally has a config to hardcode the output)
00:16 psykose: the only reason i can imagine this isn't sufficient is if a given compositor doesn't do "the most recently interacted output" and people want to work around that
00:17 kennylevinsen: The main reason for the compositor picking something else would be that it knows something the client doesn’t, e.g. a specific user preference for “primary output” or similar
00:17 kennylevinsen: But I dont know if a compositor that doesn’t use the focused output
00:17 kennylevinsen: *of
00:28 Consolatis: I'd also just create the layershell without defining an output if the users wants the "active" one, although the definition of "focused output" may but subtly different by compositors. It could for example be the one where the majority of the focused view resides or the one where the mouse cursor is located
08:43 zzag: https://gitlab.freedesktop.org/wayland/wayland/-/blob/5b692b50b9e3d379005633d4ac20068d2069849d/protocol/wayland.xml#L244 can the stride be not a multiple of "bytes per pixel"? for example, can an argb32 buffer with the width of 100px have 401 bytes stride? (I believe that the row pointers don't need to be aligned?)
08:44 zzag: I'm asking because of GL_UNPACK_ROW_LENGTH
08:44 zzag: it takes a value specified the number of pixels rather than bytes
08:45 zzag: so if a stride value of 401 is valid, then the compositor needs to consider using something else to upload the texture data?
08:46 zzag: it takes a value specifying*
08:49 zzag: wlroots refuses to upload data from such shm client buffers to opengl textures explicitly, while weston seems to take a leap of faith https://gitlab.freedesktop.org/wayland/weston/-/blob/49278973c0254c1fe5350f1f65d3862d4bb05426/libweston/renderer-gl/gl-renderer.c?page=3#L2562
08:50 zzag: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/render/gles2/texture.c?ref_type=heads#L65
08:51 zzag: and https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/baaec88e2f3d60a94610ea8c1cd067ffefe1099b/render/pixel_format.c
08:51 zzag: argh, https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/baaec88e2f3d60a94610ea8c1cd067ffefe1099b/render/pixel_format.c#L252
08:53 zzag: oh, actually, wlroots will post a protocol error if the stride is not a multiple of "bytes per pixel" https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/baaec88e2f3d60a94610ea8c1cd067ffefe1099b/types/wlr_shm.c#L339
09:45 kennylevinsen: zzag: the error is if it is not a multiple of bytes per *block*
09:52 emersion: it's for YUV and such
09:55 emersion: hmm
09:56 emersion: but yeah, still, for RGB it's the same as component
09:56 emersion: er
09:56 emersion: pixel
09:56 emersion: without this memory is not aligned
09:59 zzag: emersion: okay, so the compositor can safely reject create_buffer requests if the stride is not multiple of bytes per block or pixel, right?
10:05 emersion: I don't remember off hand
10:05 emersion: maybe git blame says
10:05 emersion: maybe wl_shm has more details
10:05 zzag: it does not
10:06 zzag: it's pretty light on the details
10:06 zzag: with my kwin hat, I prefer wlroots' behavior
10:23 emersion: I'm away atm, but will try to dig deeper
14:00 mclasen: so, now that swick got banned, who is going to complete the color management protocol work?
14:00 mclasen: pq: you ?
14:25 daniels: mclasen: it's not helpful to directly pressure individual people and link it to this
14:25 daniels: the CM work started a long time ago with a different set of people, and it will continue over time as well
14:25 mclasen: I was not pressuring anybody. I was asking a question
14:26 mclasen: we'll carry this downstream then, fine
14:27 daniels: I don't believe there's an answer on how the remaining work will be divided, but all the people interested in CM/HDR have all been talking and working together for a long time, and I'm sure they'll keep on doing the same, both upstream and downstream
14:31 mclasen: whatever, sure
14:32 daniels: why so antagonistic?
14:32 daniels: I'm answering you to the best of my ability; if you don't care enough to not snipe at an honest reply, why ask?
14:34 mclasen: your answer sounded very officious passive-agressive to me. If I misread it, I apologize
14:36 daniels: it wasn't intended as that at all - what I mean is that the work was started by pq quite a long time ago, and over time it's all had a lot of contributions from leandrohrb, swick, jadahl, JoshuaAshton, zamundaaa, as well as others like melissawen and hwentlan_ and some who I've forgotten in this list
14:37 daniels: ttbomk those people haven't got together and figured out what the plan is for continuing to push forward to getting an upstream protocol implemented and merged, but given that we've managed to get here with everyone self-organising, surely that would continue?
14:42 jadahl: if all goes well, I imagine and hope that swick will be able to continue after these months have passed, so I don't see why one would need to actively try to find "who will complete it". apart from that, what it needs now is testing and work in compositors and clients
14:44 mclasen: that work is happening
14:44 jadahl: indeed
14:44 zamundaaa[m]: I don't really want to wait for another 3 months when all we need to complete the implementations list is to complete the Mesa impl
14:45 zamundaaa[m]: and merging https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/78 I guess
14:46 jadahl: you mean we should aim for getting it upstream relatively quickly?
14:47 zamundaaa[m]: After 4.5 years, I wouldn't call it quickly, but yes
14:47 jadahl: hehe
14:48 jadahl: there is also the question what to do with the icc parts, if that only has one implementation, can it land upstream?
14:49 zamundaaa[m]: I wrote something up about that before: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_2487444
14:49 zamundaaa[m]: so far, noone's disagreed to needing at least one compositor and one client implementation for each feature
14:50 mclasen: I have a gtk branch that uses set_primaries and set_luminance
14:52 jadahl: zamundaaa[m]: fwiw, there are mutter implementations for parametric, and iirc set_primaries
14:53 zamundaaa[m]: Good. KWin supports all the features except icc, we just need client implementations for everything
14:55 jadahl: I see three open MRs to the color branch. is there any that *needs* to be there in the initial version?
14:58 mclasen: both kwin and mutter branches currently target xx-color-management-v4
14:58 mclasen: gtk too
15:01 daniels: Weston has v4 already
15:01 daniels: we're currently working on parametric
15:01 daniels: (fsvo 'we' that exclusively refers to people who aren't me)
15:02 zamundaaa[m]: <jadahl> "I see three open MRs to the..." <- scRGB would be good to have, but on compositors that support set_luminances it can be done without the MR too, so it could be added later
15:02 zamundaaa[m]: "Add event for compromised/intended color presentation" doesn't need to be in v1
15:03 LaserEyess: question since I have a strong user desire to get CM/HDR in: would a third party client (i.e. mpv) implementing this be useful? Or does it just add to the noise of impls
15:04 zamundaaa[m]: It would be useful, yes
15:04 LaserEyess: because gtk/mutter/kwin impls are nice but they're also probably too close to the source so to speak
15:04 daniels: LaserEyess: yes, very useful
15:04 LaserEyess: ok, I'll look into that then
15:05 daniels: there should be a gst implementation in fairly short order as well
15:05 LaserEyess: exciting!
15:05 LaserEyess: it's Actually Happening™
15:06 zamundaaa[m]: jadahl the third, "Define out of bounds pixel values", having well defined behavior for clients there would be good
15:10 jadahl: zamundaaa[m]: should probably hold off with "nice to haves" IMO, but defining undefined behavior sounds more important
15:10 jadahl: but needs pq it seems
15:21 zamundaaa[m]: Hmm, actually, if we clamp out of bounds pixel values, we need the scRGB transfer function
15:22 zamundaaa[m]: As linear is defined from [0; 1] according to H.273
22:15 JoshuaAshton: scRGB is not a "nice to have"
22:16 JoshuaAshton: If you want existing games to work at all, you need to expose that and have it work
22:17 JEEB: huh, so games utilize linear fp16 extended sRGB? I mean, it makes sense but somehow I assumed many just did BT.2020+PQ output
22:19 JoshuaAshton: Most of them use BT2020 + PQ, but many do just use scRGB or have an option for both (for whatever reason, usually their scRGB implementation is BAD and positive Rec.709 primaries only :/)
22:19 JEEB: gotcha
22:20 JEEB: as for macOS applications are pushed more towards scRGB for HDR than doing the HDR transfer stuff, I think? since IIRC some HDR transfer related values got deprecated and such. so clearly certain vendors prefer it.
22:23 Company: Windows uses scrgb afaik
22:24 Company: for regular composited mode
22:24 Company: and PQ for exclusive(?) fullscreen
22:24 Company: with HDR
22:24 JEEB: also linear extended sRGB is nice as it clearly defines what value should be mapped to SDR graphics white by the following bits (compositor, display). 1.0 is that. whatever the brightness at which SDR graphics white is being shown at by the compositor or display being secondary since that is up to various environmental variables
22:25 JoshuaAshton: What goes to the screen is always PQ. Windows does composite in scRGB space, but that has to go to PQ to go to the screen
22:25 JoshuaAshton: There's plenty of hardware to do that... :P
22:25 Company: yeah, I'm just saying that games wanting to run in a windowed mode need to support scrgb
22:25 JoshuaAshton: Nope
22:25 JEEB: nope
22:25 JEEB: mpv works just fine windowed in BT.2020+PQ mode
22:26 Company: doesn't that then mean windows has to reconvert it back to scrgb for compositing?
22:26 JEEB: and I wouldn't be surprised if in BT.2020+PQ mode the Windows compositor would just be passing those values through
22:26 JoshuaAshton: Can just unpq it, multiply by 2020 -> 709
22:26 JoshuaAshton: yea
22:26 JEEB: and if not passing through, yea. it would be linearizing and then delinearizing again
22:26 Company: so you get some GPU performance issues if you don't do scrgb
22:27 JEEB: I expect only if application and compositor outputs mismatch
22:27 JoshuaAshton: This is what our display pipeline looks like on Deck for each type of input
22:27 JoshuaAshton: https://github.com/ValveSoftware/gamescope/blob/master/src/docs/Steam%20Deck%20Display%20Pipeline.png?raw=true
22:30 JoshuaAshton: looks like the %20 disease got to it and the link doesn't work
22:30 JoshuaAshton: the png that is in here :frog: https://github.com/ValveSoftware/gamescope/blob/master/src/docs
22:30 Company: I would have expected the scrgb pipeline and the srgb pipeline to be the same
22:31 JoshuaAshton: Definitely not, we treat them very differently
22:31 Company: does that all run in dedicated hw?
22:31 JoshuaAshton: Yes
22:32 Company: yeah, that makes sense then
22:32 JoshuaAshton: JEEB: In my experience, 1.0 in scRGB is not really SDR graphics white -- more like PQ of 80 nits. That's how Windows treats it and how apps use it anyway.
22:32 Company: because I'm thinking application/compositor here and I only have GL
22:33 JoshuaAshton: I mean the DRM cross-vendor stuff is still in the works -- but just not using it isn't really an option for us. That's why AMD_PRIVATE_COLOR exists, and we just use that and literally like every feature of the hardware :P
22:34 JoshuaAshton: Using that is also a good option for bringup before that cross-vendor color op stuff lands too
22:34 Company: I would treat scrgb and srgb differently in the spec just because they come from different places
22:34 Company: and if it ever turns out there are subtle differences, it's easy to retrofit
22:37 Company: JoshuaAshton: I suppose you could accept linear (both bt2020 and scrgb) and just skip the TF step?
22:37 JoshuaAshton: If you don't want to do any 3D LUTs in hardware, sure
22:38 Company: what I want is hand linear buffers to KMS, so I don't have to run the PQ oetf
22:39 Company: because I want to composite my UI with linear blending, and when I do that, I'm left with a linear buffer
22:40 JoshuaAshton: You can do that, yeah.
22:40 Company: but then, who does the oetf for me?
22:41 JoshuaAshton: the display hardware
22:41 Company: "I" in this case might be an application aiming for direct scanout btw
22:41 JoshuaAshton: to be clear this is not possible right now, unless you are using AMD_PRIVATE_COLOR interfaces
22:42 Company: yeah, that's fine with me - I just care that the hardware can do that
22:42 Company: if the hardware can do it, we can write protocols and APIs that expose that
22:43 JoshuaAshton: Gamescope/Deck can direct scanout basically every form of content -- NV12 buffers straight from video hardware so you can have the GPU turn off, scRGB buffers, HDR10 buffers... all with color management, night light, mura compensation active at the same time
22:45 DemiMarie: How likely is it that using hardware offload on multiple devices will result in identical output?
22:45 Company: DemiMarie: "identical" is already a tricky question because you have monitors involved
22:46 Company: and if I change my monitor for "game mode" to "graphics mode", everything looks entirely different already
22:46 JoshuaAshton: Well, userspace is the one generating the LUTs and setting the operations to do, so it should
22:46 DemiMarie: Company: my main concern is how an application can determine if "colors don't appear accurately" is a compositor bug or an application bug
22:47 Company: DemiMarie: it can also be a driver bug and a monitor bug
22:48 Company: DemiMarie: and currently, I don't have an easy way to do that while working on HDR things
22:48 DemiMarie: Company: does that mean that closed-loop calibration is the only option?
22:49 Company: I think the only option for a while is going to be "looks good enough"
22:49 DemiMarie: Company: can Windows and macOS do better?
22:49 Company: and the people who actually care will have a very hard time
22:50 DemiMarie: That’s why I’m concerned with the protocol being descriptive and not prescriptive.
22:50 Company: no idea about mac, but Windows users have the same monitors...
22:51 DemiMarie: The one approach I am almost certain works (for still images) is to have a calibrated camera looking at the display, then adjust the inputs to the monitor until the output is the expected one.
22:51 Company: except that doesn't work if the monitor applies some weird transforms of its own - because then you mess up all the data you send
22:52 DemiMarie: Company: the idea is to use a feedback loop to solve this
22:52 Company: I suspect people don't want it solved
22:53 DemiMarie: Which people?
22:53 DemiMarie: I suspect there are some in the visual media space who do.
22:53 Company: the ones who like their colors to look "warm"
22:53 DemiMarie: The people I am thinking of are the ones who need to ensure that the colors appear on screen the way they will in print.
22:53 Company: yeah, there will be a few who do care, and those can guarantee that their monitors are calibrated properly
22:53 DemiMarie: Correct
22:54 Company: and in those cases you can ensure that the output that is produced is correct
22:54 Company: however
22:54 DemiMarie: My concern is that without a specification for correct output, an application that looks great on GNOME might not look correct on Sway or visa versa.
22:54 Company: no, I don't think that's an issue
22:55 DemiMarie: why?
22:55 DemiMarie: Thinking from an application perspective, how can I go from desired output (light from monitor) to the inputs I should use to achieve that output?
22:55 Company: because you will be able to convince each of those systems to do the same thing in whatever resembles pass-through
22:56 Company: as an application developer, you cannot do that - and you shouldn't be able to
22:56 Company: in the general case
22:56 Company: you can do that - and you should be able to - in the special case of a cooperating user
22:57 DemiMarie: correct
22:57 Company: so night light off, no brightness correction, things like that
22:57 DemiMarie: Obviously the user should be able to do what they want, but I also want to ensure that the user can put the compositor in a passthrough mode.
22:57 kennylevinsen: the exact implementation of e.g. icc shaders might differ but it should just be rounding errors
22:58 DemiMarie: Also, in the specific case of Qubes OS, I’m concerned that this is (what appears to be) a lot of complexity.
22:58 Company: the compositor does not have to provide pass-through mode ofc
22:58 Company: but you don't have to use one that doesn't
22:58 kennylevinsen: The concept of “passthrough” doesn’t really make sense once color management is involved
22:58 Company: kennylevinsen: it kinda does once you think about VMs and screencasting
22:59 kennylevinsen: Thats just another input with a color description to go with it, no?
23:00 kennylevinsen: For screencasting, an output with some preset color description rather than that of a monitor
23:00 Company: I would expect that if I do a screencast of a monitor and loop it back onto the same monitor, the output doesn't change
23:00 Company: the OBS studio feedback image basically
23:01 Company: and once that works, the application layer is bascailly out of the loop and it's between the compositor and the hardware
23:03 Company: note that you can make this more complicated: me sharing screen with you in one zoom call and you sharing it with me in another one and we showing each other the shared image
23:04 Company: apart from video encoding artifacts, nothing should change if we keep that going for half an hour
23:05 DemiMarie: kennylevinsen: from a VM perspective, I’m quite concerned about the use of ICC profile files.
23:07 Company: DemiMarie: if you want some fun: https://i.imgur.com/BMiEoyg.png - the gray level of the backgroud should match the gray of the center rows
23:08 kennylevinsen: Thats not necessarily achieved by anything passthrough - rather, by ensuring that the screen recording matches the color description stored with it or expected by the format/player. As long as that is accurate, recording and replaying should yield the same result
23:08 Company: DemiMarie: on a 200% monitor it already doesn't - or if you zoom in or out
23:09 Company: kennylevinsen: I meant "passthrough" as "no effects are applied that modify colors", not as no transformations at all
23:09 kennylevinsen: DemiMarie: applying a monitor-specific ICC profile to a VM doesn’t make any sense unless the VM is hardwired to the outputs. You’d let the parent display server deal with ICC
23:10 Company: ie brightness, nightlight, whatever
23:11 DemiMarie: kennylevinsen: I don’t think that allowing VMs to provide ICC profile data for the host will be allowed by Qubes OS’s security team.
23:14 kennylevinsen: Company: well you’d probably record it somewhere neutral before monitor corrections, but if you could store a color description (like how still photos embed ICC profiles) I imagine you could do it post-monitor-adjustment as well. You’d probably get some banding though.
23:15 Company: yeah, that could work
23:17 kennylevinsen: DemiMarie: If the display is owned by the host, the host would own the associated ICC profile. It doesn’t make much sense for the windowed output of a VM to have any monitor corrections - the window can move arbitrarily across monitors, and each VM might be out of sync.
23:17 kennylevinsen: Having each VM show neutral content and have the host deal with the output details make more sense
23:18 DemiMarie: kennylevinsen: What is the reason for `wp_image_description_creator_icc_v1`?
23:19 DemiMarie: kennylevinsen: In Qubes OS each window in the guest is a window on the host, so this isn’t any more of an issue than on bare hardware.
23:23 mclasen: if icc profiles are a problem for your, you can simply make your compositor not support them
23:24 mclasen: everything is optional in this protocol
23:24 zamundaaa[m]: JoshuaAshton: I didn't mean that scRGB support was nice to have, just that it's not strictly necessary for v1 if we can do it with linear + set_luminances. But we can't make that work, so we really need it anyways
23:25 kennylevinsen: DemiMarie: ah, your concern is in the image descriptions for the clients buffers
23:26 zamundaaa[m]: Demi: `wp_image_description_creator_icc_v1` is for getting something as close to "pass through" as possible
23:26 zamundaaa[m]: So far, only Weston supports it though
23:27 zamundaaa[m]: KWin only allows parametric image descriptions for clients, if an ICC profile is set, that's an exclusively compositor side thing
23:31 kennylevinsen: If one wanted to support client ICC profiles but didn’t trust them, I imagine you could process the profile in the VM and reduce it to the supported parameters… but yeah, not supporting it is an option
23:50 DemiMarie: kennylevinsen: exactly!
23:51 DemiMarie: zamundaaa: That makes sense.
23:51 DemiMarie: I’m glad that I can just not support wp_image_description_creator_icc_v1 and not break lots of applications.
23:52 Company: not sure what's gonna happen