ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
ManMower has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
spstarr has quit [Remote host closed the connection]
rgallaispou has quit [Read error: Connection reset by peer]
<pq>
emersion, I think Wayland core does not have the sRGB rule, so adding that would be a mistake. The color encoding is undefined there, but in practise it is "whatever each output thinks it is" which may not be sRGB.
<pq>
So the rule belongs in the CM&HDR extension where it already is.
<pq>
emersion, what I mean is, people can build a working system by just a bolt-on assumption that all color is specified in whatever they choose instead of sRGB. Think of closed/embedded systems that do not need Wayland-level interoperatbility.
<pq>
or they can have alternative CM and/or HDR protocol extensions.
<pq>
There is also the option of "legacy color management", where you use e.g. colord to save/retrieve the monitor color profile and applictions that care will use that and render for the output directly, assuming the compositor does not mangle color values.
<emersion>
okay, that's a shame because it's pretty confusing
<emersion>
clients who want to effectively work with the existing ecosystem must know about the unwritten sRGB rule
<pq>
Why do they need to know that when the compositor does not implement any color management?
<emersion>
to look like every other client
<pq>
what could make them look any different?
<emersion>
sending linear instead of sRGB
<pq>
no one sends linear - if they try, they see their mistake on the first visual test run - like in Xorg
c7s has joined #wayland
<pq>
(now we are talking about desktop systems btw., or something where you need Wayland-level interoperability)
<emersion>
okay, so just hope clients realize their colors are borked
<emersion>
i've been used to better standards
<pq>
I guess the most we could say in Wayland core is that the color properties are compositor implementation defined, which may delegate to be DRM driver implementation defined.
rgallaispou has joined #wayland
<emersion>
LMS is a whole other mess (if you're talking about that?)
<emersion>
KMS*
<pq>
yup
<pq>
do you remember problems with old games, like the first Quake, where the image was far too dark?
<pq>
like, when those games were new'ish
<emersion>
no, too young for this
<jadahl>
those games with their updated game engines fake gamma game side now
<jadahl>
but not all
<jadahl>
so Xwayland probably need fake-gamma to make those work if it doesn't already
<pq>
mmhm... the difference of mistaking linear vs. sRGB EOTF is pretty striking. As in, close to unplayable.
<jadahl>
yea, completely unplayable
<jadahl>
and looks like a mess when the game crashed leaving a messed up gamam lut
<emersion>
so we don't need to define what our color formats mean anymore
<emersion>
if clients swap channels, they'll realize soon enough regardless
rgallaispou has quit [Read error: Connection reset by peer]
<pq>
jadahl, you mean those games used to produce linear color values and expect the display server to apply gamma?
<emersion>
there are no clients which only do black and white anyways
<jadahl>
pq: i mean e.g. the quake games set gamma via randr
<jadahl>
then when one attempted to run those via wayland it failed miserably
<SardemFF7>
wow, it’s the first time in a long time that I feel “young” :-D I actually don’t remember Quake 1 (only Quake 2 ><)
<jadahl>
but when running them via x11, they set the gamma, but if they crashed, nothing set it back
<jadahl>
SardemFF7: didn't quake 2 have the same behavior?
<jadahl>
(I only played q1 and q3 :P)
<pq>
emersion, I think pixel formats are much better defined and relied upon: no-one would knowling make the decision that R values shall indicate the level of blue light.
<pq>
*kowingly
<pq>
*knowingly
<pq>
jadahl, ah
<pq>
so, there is a funny story here I believe
<jadahl>
in later years the fun part is that there was some kind of "command" in the quake console to not use "native gamma" so it could be fixed
maxzor has quit [Ping timeout: 480 seconds]
<pq>
hmm, or maybe there isn't
<jadahl>
it's practically the same disaster as games changing the resolution
<pq>
yeah, why compute gamma in the game, when you can upload any LUT you wanted into the video card.
<jadahl>
except everything will look super white instead of super large
<jadahl>
(when the game didn't exit cleanly)
<pq>
...which is how X11 worked, also for the color maps: each window could install a color map, which makes all other windows look bad while that one window is "active".
<pq>
only once hardware evolved enough so that dealing with window colormaps independently became possible that thing was fixed for good, instead of just hoping that no-one installs their own colormap.
<jadahl>
isn't it more that the color manager set the _ICC_PROFILE atom on the root window that defines what profile is used? then apps try to make themself look correct given it
* jadahl
recently tried to read the X11 color management documentation only to reach dead links
<MrCooper>
FWIW currently Xwayland doesn't support any gamma correction, waiting for the CM protocol for that
<SardemFF7>
my experience with colormaps is “you have to use them to get compositing but they have no purpose any more” so it’s interesting learning about them in the good ol’ days :-D
<pq>
SardemFF7, are you confusing colormaps with Visuals, perhaps?
<jadahl>
MrCooper: so I will finally be able to play my quake1 without having to re-find that setting, yay
<SardemFF7>
pq: IIRC, you need both, for some weird reason
<pq>
SardemFF7, oh, k.
<jadahl>
CS:GO.... that's not thaaat old..
<kennylevinsen>
only 9.5 years
st3r4g has joined #wayland
<pq>
SardemFF7, I guess one uses that to have the TrueColor colormap? Just to say that one is not using anything else that I wouldn't know how to handle.
<pq>
DirectColor colormap seems to be the kind of "use my custom look-up tables for the R, G and B values".
<pq>
PseudoColor is what one might know as "paletted color", a single-channel image where the integer value indexes into an array of RGB triplets.
<pq>
emersion, I think what you are looking for is literally the CM&HDR extension, or more like a sub-set of it that would define the color encoding.
<pq>
That would make the sRGB assumption discoverable to clients.
<pq>
or the sRGB EOTF assumption
<pq>
I don't think we can simply retro-fit it into Wayland core, because it may invalidate existing "not an open desktop" systems.
<pq>
another thing Wayland leaves undefined is which matrix to use for YUV-RGB conversion.
<pq>
emersion, or, one could write a "best practises for Wayland on desktops" specification.
<pq>
there are many other things Wayland does not defined, like scaling, which means that implementing fractional scaling is possible.
maxzor has joined #wayland
<pq>
The question about blending in linear vs. non-linear under the assumption of sRGB EOTF is yet another one.
<pq>
I guess the interpretation of the alpha channel is one too.
dcz_ has joined #wayland
<pq>
People are just accustomed that alpha means coverage in a window system.
<pq>
We could define all these, but I think they would need to be discoverable to clients, does the compositor behave in a certain way or do we just not know.
<pq>
The benefit from that would be that if WLCS or anything like it gains traction, it can use the discovery to gate tests and whine about missing guarantees.
<pq>
OTOH, would normal clients do anything with this information? In some special cases, yeah, like wanting specific blending behavior between sub-surfaces.
<pq>
then again, that's a slippery slope leading towards sub-surfaces becoming a rendering API - after blending you want to nail down scaling (wp_viewport).
<pq>
So we want to specify compositor results in detail, or do we keep them as "best effort" like until now?
<pq>
*Do
<Levans>
I have a question regarding buffer damage. If I understand correctly, it is valid for a client to update its contents by submitting a buffer to the compositor where only the damaged regions actually contain up-to-date content (and AFAIK Firefox relies on this for example), is that right?
<kennylevinsen>
nope
<kennylevinsen>
The buffer submitted must be fully valid. Damage is a (necessary) optimization, but at any point the compositor may need to read the full buffer as the authoritative state of the window content
<Levans>
Ah. So stuff like wleird's "damage-paint" is actually not valid behavior?
marmarek is now known as Guest7856
marmarek has joined #wayland
<kennylevinsen>
Lynne: For example, if parts of the window was obscured before but is now unobscured, the compositor needs to source the those parts of the window from somewhere. Or, if the part is transparent and we're blending towards a background, or if a transparent window on top changes, etc.
<kennylevinsen>
that would actually be a good idea
* emersion
files issue
<kennylevinsen>
damage-paint leaves the rest of the buffer empty, right?
Guest7856 has quit [Ping timeout: 480 seconds]
<Levans>
So a client doing double buffering must ensures that it correctly updates its buffers with all previous content updates before submitting them, so that every submitted buffer contains a fully up-to-date image of the contents of the surface. Correct?
<kennylevinsen>
Levans: It's a common way to validate that the compositor does damage correctly btw - I made a similar test client for eglSwapBuffersWithDamage in... glutin? I forget.
<kennylevinsen>
Yes
<pq>
Levans, yes.
<Levans>
Ok, thanks!
<Levans>
That was my initial understanding, but people made me doubt that :<
<Levans>
(quoting wleird and firefox as examples)
<kennylevinsen>
firefox is not a good reference client, but maybe we should add a note to wleird
<emersion>
ahah
<pq>
I wrote such a non-conformant client as part of Weston's test suite for testing damage handling too.
<emersion>
yeah, definitely add a note to wleird's "paint-damage"
<emersion>
but i understood what you said as "add firefox in the list of clients in wleird's README"
<kennylevinsen>
Levans: Note that there are various tricks available to clients to figure out how to do the least amount of work, such as observing backbuffer "age" to only re-touch "expired" regions, either by memcpy or re-render.
<kennylevinsen>
well, let's you fetch the age at least
<kennylevinsen>
emersion: hah! it definitely deserves an honorable mention :P
<emersion>
EGL_KHR_partial_update is a whole other matter
<emersion>
EGL_EXT_buffer_age + EGL_KHR_swap_buffers_with_damage is the usual combo
<emersion>
EGL_KHR_partial_update is about giving some kind of damage info to the driver, and not to the WSI
<emersion>
and it's a different kind of damage from the one you give to the WSI
<emersion>
i'd suggest ignoring it at first
<emersion>
because it's too easy to get confused
<kennylevinsen>
... emersion speaketh the truth, I mixed them up and only looked for buffer age.
<Levans>
Maybe it could be worth adding a note in the protocol spec of wl_surface.damage and wl_surface.damage_buffer saying explicitly that the whole buffer still needs to be up to date, and not only the damaged regions?
<emersion>
i thought there was already a note, but maybe not?
yoslin has quit [Quit: WeeChat 3.3]
<kennylevinsen>
it's not explicit about it, but: wl_surface::damage: "This request is used to describe the regions where the pending buffer is different from the current surface contents"
<Levans>
Some people interpreted it the other way, so I think it can be made more explicit
<kennylevinsen>
interested in making an MR for it? :)
<Levans>
I guess I can do that :p
<Levans>
not right now though, but yeah
yoslin has joined #wayland
flacks has quit [Quit: Quitter]
flacks has joined #wayland
Poly[m] has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
marmarek is now known as Guest7859
marmarek has joined #wayland
caveman has quit [Remote host closed the connection]
<zamundaaa>
What can I expect with cursor and overlay planes regarding modesets? Could en/disabling a cursor plane require a modeset? Or en/disabling overlay planes; or switching them between crtcs?
caveman has quit [Quit: caveman]
caveman has joined #wayland
<emersion>
in general these things don't require a modeset
<emersion>
but the only way to make sure is it atomic-test it, since that's driver-specific
gryffus has joined #wayland
<zamundaaa>
Thanks. That uncertainty is unfortunate, KWin caches all state for the next frame, but if en/disabling planes could require modesets then it can't properly test that until it doesn't need to do a modeset to enable the primary plane (or change other properties that do require a modeset)
<zamundaaa>
So if you want to be completely safe there's basically the choice between waiting to enable cursor planes until I don't need a modeset otherwise, or doing it with modesets and attaching completely transparent buffers as a fallback to "disable" them?
fmuellner has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
<emersion>
for cursor planes you don't need atomic tests
<emersion>
except if you set props like rotation and such
spstarr has quit [Remote host closed the connection]