Wayland 1.21 Alpha Finally Introduces High-Resolution Scroll Wheel Support

[Quackdoc]

That the problem. Trying to part solution that end up not being cursed in future. DRM Leading is basically full screen we don't have a window mode of it.

DRM support would not be a big problem if Nvidia was on the same page as everyone else with their implementation. The reality is if direct DRM out was nice stable and uniform applications most likely would not have to pick up the bits it would be the toolkits.

Graphic stack is a true head ache location.

Direct scan out is not DRM leasing. Here is a brief write from Zamunda (sorry if I spelt it wrong) from the gaming on wayland blog post

application contents can be put directly on the screen with the display hardware (which is called “direct scanout”. You may have heard the X related term “unredirection” used for the same thing, too). This removes unnecessary copies and provides some nice efficiency and latency benefits - even in windowed mode, if the compositor and hardware support it

the goal would if possible, to use this to allow the app to do it's own color management, since many apps already do to some degree, and use direct scan out, even if fullscreen, all the compositor would need to do is send HDR metadata.

[oiaohm]

honestly I think we do need a short term solution a temporary solution that wouldn't fuck us over down the line would be DRM leasing, but it's unreasonable to ask apps to add DRM support. I think if possible, HDR with direct scanout would work fine. and shouldn't get in the way of things down the line.

That the problem. Trying to part solution that end up not being cursed in future. DRM Leading is basically full screen we don't have a window mode of it.

DRM support would not be a big problem if Nvidia was on the same page as everyone else with their implementation. The reality is if direct DRM out was nice stable and uniform applications most likely would not have to pick up the bits it would be the toolkits.

Graphic stack is a true head ache location.

[Quackdoc]

Sounds about right it took about 20 years to get somewhat functional color management in SDR screens. Looks like HDR is going to take longer to get somewhat sorted out.

There are a lot of issues that people point to with Wayland that when you look closer there was not a good implementation anywhere to copy. Yes those areas are fairly much start from scratch and hope to get it right this time.. Yes starting from scratch on something complex like color management is a path to years of arguments just getting the core design sorted out before coding anything.

honestly I think we do need a short term solution a temporary solution that wouldn't fuck us over down the line would be DRM leasing, but it's unreasonable to ask apps to add DRM support. I think if possible, HDR with direct scanout would work fine. and shouldn't get in the way of things down the line.

[oiaohm]

I wonder how old my non existent kids will be by then. maybe graduating highschool.

Sounds about right it took about 20 years to get somewhat functional color management in SDR screens. Looks like HDR is going to take longer to get somewhat sorted out.

There are a lot of issues that people point to with Wayland that when you look closer there was not a good implementation anywhere to copy. Yes those areas are fairly much start from scratch and hope to get it right this time.. Yes starting from scratch on something complex like color management is a path to years of arguments just getting the core design sorted out before coding anything.

[Quackdoc]

they aim to do it "right" this time.. Not that broken mess, where only the application does the color translation into the output buffer..
And they want to combine HDR+Color Management which makes perfect sense.

I wonder how old my non existent kids will be by then. maybe graduating highschool.

[Spacefish]

The proposals for HDR Support + Color Management in Wayland are really nice.
See: https://gitlab.freedesktop.org/pq/color-and-hdr

they aim to do it "right" this time.. Not that broken mess, where only the application does the color translation into the output buffer..
And they want to combine HDR+Color Management which makes perfect sense.

Once this is implemented / agreed on, on the protocol level we need to have compositor support for it and later on support by the libraries used by the applications which render stuff.

Once this is implemented Linux Desktop will have one of the best HDR/Color Management systems out there. As the whole "pipeline" is aware of what´s going on and you will be able to control a lot of things, like how to handle legacy applications without color management support and so on.

Remember on windows it was a broken mess, which changed from version to version.. First HDR / Wide Gamut support, just threatet every "legacy" output surface as sRGB and did a sRGB -> Monitor Color Space / Gamma conversion (which is the right thing to do). Then users started to complain about "washed out colors".. After that they changed it to just lineary map "legacy" output surfaces to the monitor color space and gamma, which lead to extreme colors... In the current version they do something in between and have a slider to change the gamma mapping of SDR-Content to the output "HDR" brightnesses.. You can´t control how "legacy" colors are mapped to your output devices color space, as far as i know.

Will be a lot better on wayland, once the whole proposal is agreed on and implemented (see link above).

[Quackdoc]

Rec.2020 can encompass P3, AdobeRGB, and CMYK. All current HDR video formats are encoded in Rec.2020. But the sad reality is "HDR" monitors in year 2022 aren't really capable of displaying the whole range of Rec.2020. All of them are doing their own clamping / de-saturating transform. The lazy "temporary stop gap" path is of course let video players bypass the OS and feed the video stream directly to monitors, which will do their own thing and output whatever those monitors like. "Color management" is gibberish to most consumers anyway. But this path is useless for wide gamut photo editing and photo management.

yeah, finding a compatible HDR is the biggest issue.

though it's not entirely useless, for photo editing and photo management, what I was talking about earlier, direct scanout should be able to work for it. hell even drm leasing would be good enough for many colorists as most I know have a dedicated monitor for displaying the picture anyway. it's just a matter of an application being able to utilize it in a meaningful way.

The laziest path that still work for photo management that I can think of:
1) Create color profiles for HDR monitors, each describing their actual individual behavior
2) Provide those profiles to the applications similar to how one would provide monitor dpi information / scale factor to applications
3) Let each applications decide what clamping / de-saturating transform they want to do and make them do by themselves.

I think this would work perfectly fine for a first steps kind of thing. it would at least set us on the right track

In such path, we can then get back to the status quo in most Windows environment - HDR / WCG photos and videos can look totally different depending on which applications you view them in, and each applications will claim what they do is the correct way while finger-pointing each others.

But before we take such path, I think the elephant in the room is we still need an OS-specified transform function for sRGB to monitor profile such that at least non-color-managed / sRGB images and videos are consistent across applications. Such transform function may or may not be hardcode-able into applications and need to be fetched dynamically from OS as different people may have different preference.....

for me, as long as we had at least drm lease level HDR it would send us on the right track. direct scanout would be the next step, and then from there just more building blocks, but HDR really is a big problem IMO that needs to be addressed sooner rather than later

[billyswong]

even if the compositor was color managed, this use case still wouldn't work as far as I am aware unless one HDR format can properly encompass another (I assume this is possible in some situations), it should likely be the top most client that wins, since it's probably a safe assumption that it is the one being focused on. but that isn't really within the realm of color management, but rather the compositor determining which metadata should be sent through

as you have different kinds of HDR, (dolby, HDR10 etc.). the issue I have is because HDR is so... annoying to work with, I think leaving it to the app to do color management is best if possible. it's not that they should have to do color management. but if possible it should be delegated to the app to do it. and ofc the hope would be to support at least fullscreen HDR at the least since a good chunk of HDR media consumption would work with this.

I use MPV as an example because it's so darn powerful, I think wayland should be able to communicate color management and all, but all said and done, if the app can do it, the app should probably do it, (though the app should allow a toggle to let the compositor do it). and bypass as much as possible.

Rec.2020 can encompass P3, AdobeRGB, and CMYK. All current HDR video formats are encoded in Rec.2020. But the sad reality is "HDR" monitors in year 2022 aren't really capable of displaying the whole range of Rec.2020. All of them are doing their own clamping / de-saturating transform. The lazy "temporary stop gap" path is of course let video players bypass the OS and feed the video stream directly to monitors, which will do their own thing and output whatever those monitors like. "Color management" is gibberish to most consumers anyway. But this path is useless for wide gamut photo editing and photo management.

The laziest path that still work for photo management that I can think of:
1) Create color profiles for HDR monitors, each describing their actual individual behavior
2) Provide those profiles to the applications similar to how one would provide monitor dpi information / scale factor to applications
3) Let each applications decide what clamping / de-saturating transform they want to do and make them do by themselves.

In such path, we can then get back to the status quo in most Windows environment - HDR / WCG photos and videos can look totally different depending on which applications you view them in, and each applications will claim what they do is the correct way while finger-pointing each others.

But before we take such path, I think the elephant in the room is we still need an OS-specified transform function for sRGB to monitor profile such that at least non-color-managed / sRGB images and videos are consistent across applications. Such transform function may or may not be hardcode-able into applications and need to be fetched dynamically from OS as different people may have different preference.....

[Quackdoc]

This is what kind of leads back to the question of HDR should be handled purely by DRM leasing with applications needing HDR with monitor setting particular mode and in fact being locked to full screen. The idea of top most client wins can end up with dangerous flicker if users rapidly tab between windows as the HDR metadata sent throw is being changed resulting in color changes.

This HDR stuff no matter what OS you look at is a cursed mess. Has not been helped with the multi incompatible HDR standards.

The hard reality all operating systems HDR support is only partly done.

I think it's fine to implement fullscreen only as a temporary stop gap, it's better then nothing for sure. and wouldn't cause too many issues. I wonder if drm leasing supports handling metadata? if so I wonder if that could be put in place today for projects like kodi and mpv.

but handling metadata swapping is something for the compositor itself to determine, isn't reliant on wayland protocols. I think the largest issue right now is that there is now viable way to handle it at all. (I hardly consider using DRM without drm leasing viable, maybe for kodi)

[oiaohm]

even if the compositor was color managed, this use case still wouldn't work as far as I am aware unless one HDR format can properly encompass another (I assume this is possible in some situations), it should likely be the top most client that wins, since it's probably a safe assumption that it is the one being focused on. but that isn't really within the realm of color management, but rather the compositor determining which metadata should be sent through

This is what kind of leads back to the question of HDR should be handled purely by DRM leasing with applications needing HDR with monitor setting particular mode and in fact being locked to full screen. The idea of top most client wins can end up with dangerous flicker if users rapidly tab between windows as the HDR metadata sent throw is being changed resulting in color changes.

This HDR stuff no matter what OS you look at is a cursed mess. Has not been helped with the multi incompatible HDR standards.

The hard reality all operating systems HDR support is only partly done.