ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<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...
<kelnos>
... notification windows, placing them by setting anchors and margins
<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)
<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...
zamundaaa[m] has joined #wayland
<zamundaaa[m]>
Why would you need to query the output, instead of just letting the compositor put the notification on the active output?
<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.”
<kennylevinsen>
from the layer shell protocol - no need to detect anything
<kennylevinsen>
Just make the notification surface without specifying an output and it’ll show up the right place
<psykose>
yeah, fnott does that
<psykose>
(also optionally has a config to hardcode the output)
<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
<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
<kennylevinsen>
But I dont know if a compositor that doesn’t use the focused output
<kennylevinsen>
*of
<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
glennk has quit [Ping timeout: 480 seconds]
riteo_ has joined #wayland
riteo has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
Company has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
Company has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest492
Guest2598 has quit [Ping timeout: 480 seconds]
andymandias has quit [Ping timeout: 480 seconds]
Brainium has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
lbia_ has joined #wayland
lbia has quit [Ping timeout: 480 seconds]
Guest492 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest496
mclasen has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
mxz_ has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz__ has quit [Ping timeout: 480 seconds]
mxz_ is now known as mxz
Brainium has joined #wayland
Company has quit [Remote host closed the connection]
kts has joined #wayland
gryffus has quit [Read error: Connection reset by peer]
gryffus has quit [Read error: Connection reset by peer]
<kennylevinsen>
zzag: the error is if it is not a multiple of bytes per *block*
<emersion>
it's for YUV and such
mceier has quit [Ping timeout: 480 seconds]
<emersion>
hmm
<emersion>
but yeah, still, for RGB it's the same as component
<emersion>
er
<emersion>
pixel
<emersion>
without this memory is not aligned
mceier has joined #wayland
<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?
lsd|2 has joined #wayland
<emersion>
I don't remember off hand
<emersion>
maybe git blame says
<emersion>
maybe wl_shm has more details
<zzag>
it does not
<zzag>
it's pretty light on the details
<zzag>
with my kwin hat, I prefer wlroots' behavior
<emersion>
I'm away atm, but will try to dig deeper
kts has joined #wayland
kts has quit []
Guest514 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest523
mclasen has joined #wayland
flokli has quit [Quit: WeeChat 4.3.5]
kts has joined #wayland
coldfeet has quit [Remote host closed the connection]
narodnik has quit [Quit: WeeChat 4.3.5]
kts has quit [Quit: Konversation terminated!]
cool110_ has joined #wayland
cool110_ is now known as Guest526
flokli has joined #wayland
Guest523 has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
coldfeet has joined #wayland
kts has joined #wayland
coldfeet has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
iconoclasthero has joined #wayland
kts has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
Moprius has joined #wayland
mclasen has joined #wayland
Moprius has quit []
coldfeet has joined #wayland
Brainium has joined #wayland
kts has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
<mclasen>
so, now that swick got banned, who is going to complete the color management protocol work?
<mclasen>
pq: you ?
<daniels>
mclasen: it's not helpful to directly pressure individual people and link it to this
<daniels>
the CM work started a long time ago with a different set of people, and it will continue over time as well
<mclasen>
I was not pressuring anybody. I was asking a question
<mclasen>
we'll carry this downstream then, fine
<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
<mclasen>
whatever, sure
<daniels>
why so antagonistic?
<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?
<mclasen>
your answer sounded very officious passive-agressive to me. If I misread it, I apologize
<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
<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?
caveman has joined #wayland
agd5f_ has joined #wayland
<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
agd5f_ has quit []
agd5f_ has joined #wayland
<mclasen>
that work is happening
<jadahl>
indeed
<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
<zamundaaa[m]>
so far, noone's disagreed to needing at least one compositor and one client implementation for each feature
<mclasen>
I have a gtk branch that uses set_primaries and set_luminance
agd5f has joined #wayland
<jadahl>
zamundaaa[m]: fwiw, there are mutter implementations for parametric, and iirc set_primaries
<zamundaaa[m]>
Good. KWin supports all the features except icc, we just need client implementations for everything
<jadahl>
I see three open MRs to the color branch. is there any that *needs* to be there in the initial version?
agd5f_ has quit [Ping timeout: 480 seconds]
<mclasen>
both kwin and mutter branches currently target xx-color-management-v4
<mclasen>
gtk too
<daniels>
Weston has v4 already
<daniels>
we're currently working on parametric
<daniels>
(fsvo 'we' that exclusively refers to people who aren't me)
<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
AnuthaDev has joined #wayland
<zamundaaa[m]>
"Add event for compromised/intended color presentation" doesn't need to be in v1
<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
<zamundaaa[m]>
It would be useful, yes
<LaserEyess>
because gtk/mutter/kwin impls are nice but they're also probably too close to the source so to speak
<daniels>
LaserEyess: yes, very useful
<LaserEyess>
ok, I'll look into that then
<daniels>
there should be a gst implementation in fairly short order as well
<LaserEyess>
exciting!
<LaserEyess>
it's Actually Happening™
<zamundaaa[m]>
jadahl the third, "Define out of bounds pixel values", having well defined behavior for clients there would be good
Company has joined #wayland
<jadahl>
zamundaaa[m]: should probably hold off with "nice to haves" IMO, but defining undefined behavior sounds more important
<jadahl>
but needs pq it seems
Brainium has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
Hmm, actually, if we clamp out of bounds pixel values, we need the scRGB transfer function
<zamundaaa[m]>
As linear is defined from [0; 1] according to H.273
kts has joined #wayland
tzimmermann has quit [Quit: Leaving]
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
MrCooper has quit [Remote host closed the connection]
chamlis has quit [Remote host closed the connection]
chamlis has joined #wayland
MrCooper has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
swick[m] has quit [Ping timeout: 480 seconds]
swick[m] has joined #wayland
gryffus_ has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
gryffus_ has joined #wayland
coldfeet has quit [Remote host closed the connection]
agd5f_ has joined #wayland
agd5f has quit [Read error: Connection reset by peer]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
coldfeet has joined #wayland
leon-anavi has quit [Quit: Leaving]
coldfeet has quit [Remote host closed the connection]
Brainium has joined #wayland
kts has quit [Quit: Konversation terminated!]
feaneron has joined #wayland
rasterman has joined #wayland
nerdopolis has joined #wayland
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
Brainium has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
AnuthaDev has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
Moprius has joined #wayland
Moprius has quit [Remote host closed the connection]
Brainium has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
narodnik has joined #wayland
gryffus_ has quit [Read error: Connection reset by peer]
gryffus_ has joined #wayland
mvlad has quit [Remote host closed the connection]
<JoshuaAshton>
If you want existing games to work at all, you need to expose that and have it work
mclasen has joined #wayland
<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
<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 :/)
<JEEB>
gotcha
<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.
<Company>
Windows uses scrgb afaik
<Company>
for regular composited mode
<Company>
and PQ for exclusive(?) fullscreen
<Company>
with HDR
<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
<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
<JoshuaAshton>
There's plenty of hardware to do that... :P
<Company>
yeah, I'm just saying that games wanting to run in a windowed mode need to support scrgb
<JoshuaAshton>
Nope
<JEEB>
nope
<JEEB>
mpv works just fine windowed in BT.2020+PQ mode
<Company>
doesn't that then mean windows has to reconvert it back to scrgb for compositing?
<JEEB>
and I wouldn't be surprised if in BT.2020+PQ mode the Windows compositor would just be passing those values through
<JoshuaAshton>
Can just unpq it, multiply by 2020 -> 709
<JoshuaAshton>
yea
<JEEB>
and if not passing through, yea. it would be linearizing and then delinearizing again
<Company>
so you get some GPU performance issues if you don't do scrgb
<JEEB>
I expect only if application and compositor outputs mismatch
<JoshuaAshton>
This is what our display pipeline looks like on Deck for each type of input
<Company>
I would have expected the scrgb pipeline and the srgb pipeline to be the same
<JoshuaAshton>
Definitely not, we treat them very differently
<Company>
does that all run in dedicated hw?
<JoshuaAshton>
Yes
<Company>
yeah, that makes sense then
<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.
<Company>
because I'm thinking application/compositor here and I only have GL
<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
<JoshuaAshton>
Using that is also a good option for bringup before that cross-vendor color op stuff lands too
<Company>
I would treat scrgb and srgb differently in the spec just because they come from different places
<Company>
and if it ever turns out there are subtle differences, it's easy to retrofit
<Company>
JoshuaAshton: I suppose you could accept linear (both bt2020 and scrgb) and just skip the TF step?
<JoshuaAshton>
If you don't want to do any 3D LUTs in hardware, sure
gryffus_ has quit []
gryffus_ has joined #wayland
<Company>
what I want is hand linear buffers to KMS, so I don't have to run the PQ oetf
<Company>
because I want to composite my UI with linear blending, and when I do that, I'm left with a linear buffer
<JoshuaAshton>
You can do that, yeah.
<Company>
but then, who does the oetf for me?
<JoshuaAshton>
the display hardware
<Company>
"I" in this case might be an application aiming for direct scanout btw
<JoshuaAshton>
to be clear this is not possible right now, unless you are using AMD_PRIVATE_COLOR interfaces
<Company>
yeah, that's fine with me - I just care that the hardware can do that
<Company>
if the hardware can do it, we can write protocols and APIs that expose that
<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
<DemiMarie>
How likely is it that using hardware offload on multiple devices will result in identical output?
<Company>
DemiMarie: "identical" is already a tricky question because you have monitors involved
<Company>
and if I change my monitor for "game mode" to "graphics mode", everything looks entirely different already
<JoshuaAshton>
Well, userspace is the one generating the LUTs and setting the operations to do, so it should
<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
<Company>
DemiMarie: it can also be a driver bug and a monitor bug
<Company>
DemiMarie: and currently, I don't have an easy way to do that while working on HDR things
<DemiMarie>
Company: does that mean that closed-loop calibration is the only option?
<Company>
I think the only option for a while is going to be "looks good enough"
<DemiMarie>
Company: can Windows and macOS do better?
<Company>
and the people who actually care will have a very hard time
<DemiMarie>
That’s why I’m concerned with the protocol being descriptive and not prescriptive.
<Company>
no idea about mac, but Windows users have the same monitors...
<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.
gryffus_ has quit [Ping timeout: 480 seconds]
<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
<DemiMarie>
Company: the idea is to use a feedback loop to solve this
<Company>
I suspect people don't want it solved
<DemiMarie>
Which people?
<DemiMarie>
I suspect there are some in the visual media space who do.
<Company>
the ones who like their colors to look "warm"
<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.
<Company>
yeah, there will be a few who do care, and those can guarantee that their monitors are calibrated properly
<DemiMarie>
Correct
<Company>
and in those cases you can ensure that the output that is produced is correct
<Company>
however
<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.
<Company>
no, I don't think that's an issue
<DemiMarie>
why?
<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?
<Company>
because you will be able to convince each of those systems to do the same thing in whatever resembles pass-through
<Company>
as an application developer, you cannot do that - and you shouldn't be able to
<Company>
in the general case
<Company>
you can do that - and you should be able to - in the special case of a cooperating user
<DemiMarie>
correct
<Company>
so night light off, no brightness correction, things like that
<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.
<kennylevinsen>
the exact implementation of e.g. icc shaders might differ but it should just be rounding errors
<DemiMarie>
Also, in the specific case of Qubes OS, I’m concerned that this is (what appears to be) a lot of complexity.
<Company>
the compositor does not have to provide pass-through mode ofc
<Company>
but you don't have to use one that doesn't
<kennylevinsen>
The concept of “passthrough” doesn’t really make sense once color management is involved
<Company>
kennylevinsen: it kinda does once you think about VMs and screencasting
<kennylevinsen>
Thats just another input with a color description to go with it, no?
<kennylevinsen>
For screencasting, an output with some preset color description rather than that of a monitor
<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
<Company>
the OBS studio feedback image basically
<Company>
and once that works, the application layer is bascailly out of the loop and it's between the compositor and the hardware
<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
<Company>
apart from video encoding artifacts, nothing should change if we keep that going for half an hour
<DemiMarie>
kennylevinsen: from a VM perspective, I’m quite concerned about the use of ICC profile files.
<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
<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
<Company>
DemiMarie: on a 200% monitor it already doesn't - or if you zoom in or out
<Company>
kennylevinsen: I meant "passthrough" as "no effects are applied that modify colors", not as no transformations at all
<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
<Company>
ie brightness, nightlight, whatever
<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.
<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.
<Company>
yeah, that could work
<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.
<kennylevinsen>
Having each VM show neutral content and have the host deal with the output details make more sense
<DemiMarie>
kennylevinsen: What is the reason for `wp_image_description_creator_icc_v1`?
<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.
gryffus_ has joined #wayland
<mclasen>
if icc profiles are a problem for your, you can simply make your compositor not support them
<mclasen>
everything is optional in this protocol
<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
<kennylevinsen>
DemiMarie: ah, your concern is in the image descriptions for the clients buffers
<zamundaaa[m]>
Demi: `wp_image_description_creator_icc_v1` is for getting something as close to "pass through" as possible
<zamundaaa[m]>
So far, only Weston supports it though
<zamundaaa[m]>
KWin only allows parametric image descriptions for clients, if an ICC profile is set, that's an exclusively compositor side thing
<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
gryffus_ has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
vincejv has joined #wayland
<DemiMarie>
kennylevinsen: exactly!
<DemiMarie>
zamundaaa: That makes sense.
<DemiMarie>
I’m glad that I can just not support wp_image_description_creator_icc_v1 and not break lots of applications.