Wayland 1.21 Alpha Finally Introduces High-Resolution Scroll Wheel Support

[Quackdoc]

First, that's nothing Wayland (the protocol) needs to support. It has been written in a way that it can transport pretty much anything. That's something the Compositors will need to support.

no. wayland needs a protocol to support it while it is part of the color management work, you need a way for clients to send the required HDR metadata to the compositor (See. https://gitlab.freedesktop.org/wayla...ge_requests/14). that is something defined by the wayland protocol

Second, something like wlroots will actually be the last to ever support HDR and Color Management. GNOME is backed up by Red Hat and Collabora, they are working on implementing it into Mutter already for about one and a half year. Which company, that has the money to employ people knowing their way around color theories and sciences, backs up wlroots? Third, nobody, absolutely nobody was talking about Weston. Why should they?

wlroots has shown time and time again to be the fastest at implementing these protocols. I mentioned weston because, contrary to your misguided thoughts, it DOES require wayland protocol, (or x11 equivilent) as HDR information needs to be sent from app, to compositor, to hardware. something under waylands domain.

maybe gnome does have something unofficial going on, I haven't seen any evidence except for an arch wiki article that is disputed and provides no evidence to the claim if so, sorry, they have failed so far, and see no reason to see that change anytime soon. there are devices which video editors use like decklink that can bypass all this and be used for HDR supposedly (I don't know much about it) but even then the video editor in this case is bypassing the compositor, so something like this is for sure not what mutter is doing

And fourth: where on earth did I ever say changing bit depth was enough to achieve all of this? I very explicitly said that the work on HDR is being combined with the work on color management since both are needed to work in real life situations. Neither of them are just "changing the bit depth".
If you're too stupid to read, just leave!

did I say you did? read again what I said, I assume english isn't your first language since any native speaker would know that "you have the fools saying" means I am making fun of people who DO say that, it gives no implication to you.

[Artim]

Quackdoc I hope you're joking when you say that by simply adding some protocol magically all compositors can add HDR and color management support. Because obviously that's only the very beginning. Just to be able to be told how things want to look like doesn't magically give you actual color management capabilities. So while wlroots might be the first to include that protocol, rest assured they will be the last ones that can actually handle the content. Or who's supposed to add that?

[mdedetrich]

The only thing Wayland (the protocol) doesn't handle yet is global shortcuts. At least I don't really know if any major feature that actually needs to be added to the protocol. What is missing is support for all the functionalities in the implementations. But since there is no counterpart for the universal and central X Server and since the DEs themselves have to come up with ways not only refactoring their systems to the completely different way Wayland works AND implement everything from X Server AND everything that was possible more or less in spite of X through some sketchy workarounds; while e.g. GNOME only really started that journey in like 2014, while all that is being done my many volunteers and some company, that actually looks really good.

Actually the biggest thing that Wayland and the linux ecosystem is missing is explicit sync support throughout the protocol, and thats causing many issues for all graphics vendors and this will take many years to resolve. All of the other OS's have moved to explicit sync decades ago.

[Quackdoc]

Quackdoc I hope you're joking when you say that by simply adding some protocol magically all compositors can add HDR and color management support. Because obviously that's only the very beginning. Just to be able to be told how things want to look like doesn't magically give you actual color management capabilities. So while wlroots might be the first to include that protocol, rest assured they will be the last ones that can actually handle the content. Or who's supposed to add that?

for HDR it's actually one of the big parts, thanks to how wayland is handled with things like direct scan out for fullscreen clients, apps that do their own color management probably don't really need much more than that.

since an app can use hardware to display their contents, things like MPV and kodi which already support HDR output properly should suffice just sending metadata

[Artim]

for HDR it's actually one of the big parts, thanks to how wayland is handled with things like direct scan out for fullscreen clients, apps that do their own color management probably don't really need much more than that.

since an app can use hardware to display their contents, things like MPV and kodi which already support HDR output properly should suffice just sending metadata

Sure, because in real life use cases you will never have anything else than a program that already works around X and Wayland and does its own color management...

[Quackdoc]

Sure, because in real life use cases you will never have anything else than a program that already works around X and Wayland and does its own color management...

Im a little confused by this statement. we are not talking about color management as a whole. we are talking about HDR support, we have two immensely popular apps that already support HDR, that are widely used on linux it just so happens that neither of them work when used with x11 or wayland compositors because neither have support for HDR.

is there more needed for other apps to play nice? sure probably so. but regardless all of it needs at least part of the equation. at least we would have at the minimum two very popular applications that will work. and I would argue that most apps should do their own color management if at all possible. well, apps oriented for HDR anyway

[oiaohm]

Actually the biggest thing that Wayland and the linux ecosystem is missing is explicit sync support throughout the protocol, and thats causing many issues for all graphics vendors and this will take many years to resolve. All of the other OS's have moved to explicit sync decades ago.

https://docs.microsoft.com/en-us/win...-to-directx-12

Sorry windows all version all the though DX11 is still implicit sync in the compositor. That right Windows 7-8.1 in the graphic compositor the DWM is using Implicit sync not explicit sync. So it not decades ago its less than half a decade. Windows 10 still has options you can enable that will make DWM using implicit not explicit.

Interest point the DX11 stuff Microsoft provides implements implicit sync on top of the driver explicit sync. There are different features Microsoft have mandated be include in the windows drivers so this works. Yes this implicit sync on top of the driver explicit sync with windows is implemented kernel side and integrated with the scheduler..

There is a reason why compositors really do want to use something like a kernel implemented implicit sync it that compositor is not consuming CPU cycles that would let applications complete what they are doing.

mdedetrich there is a reason why Vulkan protocol has to deal with implicit sync when it deals with the OS this is not just for Linux this is also for older versions of Windows. Not everyone is using Windows 10 and newer who are Windows users. Worse if you have enabled legacy driver compatibility with graphics drivers in Windows 10 you are back to using implicit sync.

The reality here you arguement is over and over again with explicit sync based on ideas that are not fact.

[MrCooper]

I don't care what other people do, and I don't care to listen to what you think other people do.
There was a simple question ("what is a feature you miss") and "network transparency" was my answer to that.

Do you mind describing how you're using X11 network transparency then?

[birdie]

Ouch. Be careful what you say about HDR on Windows, 'cause last time I said something about it, I got a lenghty rant from HDR expert birdie. Bottom line was that it always works on Windows.

It doesn't always work in Windows but it's not down to Microsoft or Windows. It's down to HDR [in terms of standards] being a hot mess. And where it matters it's worked perfectly for over a decade. Multiple content creation applications (photo/video editing/mastering, CADs, 3D modelling) all work perfectly under Windows. Applications don't fall apart when you enable 30/36bit color in Windows but they may continue to use 24bit colors.

In Linux tons of applications completely fall apart when you set your Xorg color bit depth to 30 or higher, including all Chromium/Electron based applications and Steam.

So, again you are quite insincere about Windows while in Linux we have fucking nothing in terms of proper HDR support.

Forward looking modern Wayland has turned to be a huge pile of poo in terms of being useful.

[birdie]

It's worth starting each discussion about Wayland with this poo.

Needless to say it's closed for discussion, neglected and no one gives a fuck about it, just like the world continues not to give a fuck about the hot ugly mess of Linux on the desktop where nothing ever works or complete aside from absolute basic features like working with your storage or network.

Audio? Graphics subsystem? Gaming? APIs? Oh, God.