Yep. Sucks. It's the only thing I miss about gaming on Windows. Hopefully xlibre will be adding that in.
...VRR, Mixed refresh rate/DPI displays, Zero-copy video acceleration...
I know that the first two work fine on xorg [0]. It's not entirely clear what you're talking about with the third, but I know that xorg supports compositor bypass for windows so that programs can interact with the graphics card without the windowing system getting in the way. Like, I think this is a thing people were talking about working on back when Compiz and its wobbly windows was new and exciting.
If that isn't what you mean by your third thing, perhaps you'd be interested in specifying what video acceleration mechanism xorg doesn't have?
...support for tiled GPUs.
Doesn't that only matter for Apple Silicon(TM) machines, and maybe some ARM machines with integrated graphics? If folks want that, it's "just" a matter of writing the drivers to make it happen and getting them into an xorg fork. Can you show me a feature or features of xorg that makes it impossible.. other than FDO's tactical neglect?
EDIT: Actually, I dimly recall some old hardware that I think was supported by DRM that did tiled rendering. Maybe it was some PowerVR stuff? If my memory isn't failing me, then there's the counter to claims that it's impossible for xorg to support. :P
[0] Source: Me having these work just fine for quite a long time now on my personal machines that run xorg.
You will also need toolkits/games to add support for any additional protocol, which I doubt they will.
It's not entirely clear what you're talking about with the third
Zero-copy video means you can play vides in web pages hardware accelerated and have no copy of the video frame required to send it to the display. This saves a lot of power.
it's "just" a matter of writing the drivers to make it happen and getting them into an xorg fork
Compositing with Xorgs model and applying any kind of screen effect would be extremely painful on tiling GPU because of how the screen is passed back and fourth to the compositor. Given compositing in Wayland compositors is passive, it does not have that issue.
Notice how Wayland on the RPi had performance that it simply couldn't gain under Xorg.
Me having these work just fine for quite a long time now on my personal machines that run xorg
Good for you. But we have modern hardware and demands that simply Xorg doesn't meet and the protocol is archaic that adding support isn't worth it.
None of that matters if you don't have a HDR monitor, only have one monitor, and when absolute basics of window management are somehow broken under KDE Wayland. Why that even has anything to do with Wayland I don't know. I just know that it all works perfectly when I use KDE X11. Maybe other DEs/WMs have better Wayland implementations, I don't know.
I use KDE and have for 10+ years. In my experience, kwin is the most stable and performant it's ever been. I don't notice anything at all, ever. Under X, it was common to get stuttering, tears, and dropped frames. Not anymore. I mean I run 2 204hz 1440p monitors. And it's perfect, always.
I'm not saying you're wrong, but it's clear that basics of window management are not universally broken under Wayland. It works well for me and has for a couple of years.
None of that matters if you don't have a HDR monitor, only have one monitor, and when absolute basics of window management are somehow broken under KDE Wayland
So you think we should have one protocol for people who have HDR etc and another for those that don't?
Yeah, but it works under KDE+X11. Wayland it the thing that changes. I think KDE has it's own Wayland implementation? kwin_wayland is what is broken, probably. Why they broke it when porting it from X11 I don't know. But the effect is the same: Can't use it as of now.
I don't condemn the protocol. I specifically mention the buggy implementation. I say that I use X11 because KDE's Wayland implementation is so buggy.
I want to use KDE. KDE was perfect for me before Wayland. I don't criticize Wayland here, I criticize KDE Wayland. And I'm worried because very soon KDE will delete X11 support.
But you can condemn the organization and people pushing for the deprecation and abandonment of another protocol, when the alternative one (Wayland) has nowhere near the level and quality of support and breadth of capabilities as the existing one. GP puts the blame on KDE - and it would be partially their responsibility if they were to drop X11, for sure, but the underlying initiative is RedHat/IBM's.
Nixos unstable atm fwiw, which you'd expect would pick up fixes early. But my particular setup with displayport DPMS stuff keeps going wrong, and there's a bunch of WONTFIX under KDE afaict.
Ehhh I know people love that and swear by it, and maybe it's fine, but I wouldn't expect it to have great integration and a solid, reliable, desktop experience on nixos.
Comments
HDR, VRR, Mixed refresh rate/DPI displays, Zero-copy video acceleration, support for tiled GPUs
Yeh... we should totally keep to X11.... especially when toolkits start to drop support.
Yep. Sucks. It's the only thing I miss about gaming on Windows. Hopefully xlibre will be adding that in.
I know that the first two work fine on xorg [0]. It's not entirely clear what you're talking about with the third, but I know that xorg supports compositor bypass for windows so that programs can interact with the graphics card without the windowing system getting in the way. Like, I think this is a thing people were talking about working on back when Compiz and its wobbly windows was new and exciting.
If that isn't what you mean by your third thing, perhaps you'd be interested in specifying what video acceleration mechanism xorg doesn't have?
Doesn't that only matter for Apple Silicon(TM) machines, and maybe some ARM machines with integrated graphics? If folks want that, it's "just" a matter of writing the drivers to make it happen and getting them into an xorg fork. Can you show me a feature or features of xorg that makes it impossible.. other than FDO's tactical neglect?
EDIT: Actually, I dimly recall some old hardware that I think was supported by DRM that did tiled rendering. Maybe it was some PowerVR stuff? If my memory isn't failing me, then there's the counter to claims that it's impossible for xorg to support. :P
[0] Source: Me having these work just fine for quite a long time now on my personal machines that run xorg.
You will also need toolkits/games to add support for any additional protocol, which I doubt they will.
Zero-copy video means you can play vides in web pages hardware accelerated and have no copy of the video frame required to send it to the display. This saves a lot of power.
Compositing with Xorgs model and applying any kind of screen effect would be extremely painful on tiling GPU because of how the screen is passed back and fourth to the compositor. Given compositing in Wayland compositors is passive, it does not have that issue.
Notice how Wayland on the RPi had performance that it simply couldn't gain under Xorg.
Good for you. But we have modern hardware and demands that simply Xorg doesn't meet and the protocol is archaic that adding support isn't worth it.
None of that matters if you don't have a HDR monitor, only have one monitor, and when absolute basics of window management are somehow broken under KDE Wayland. Why that even has anything to do with Wayland I don't know. I just know that it all works perfectly when I use KDE X11. Maybe other DEs/WMs have better Wayland implementations, I don't know.
I use KDE and have for 10+ years. In my experience, kwin is the most stable and performant it's ever been. I don't notice anything at all, ever. Under X, it was common to get stuttering, tears, and dropped frames. Not anymore. I mean I run 2 204hz 1440p monitors. And it's perfect, always.
I'm not saying you're wrong, but it's clear that basics of window management are not universally broken under Wayland. It works well for me and has for a couple of years.
Multiple monitors care about this :)
So you think we should have one protocol for people who have HDR etc and another for those that don't?
Gnome /Wayland on Fedora44. No issues to report. AMD, but previously NVIDIA 4060.
Issue is not wayland but KDE from what I understand here
Yeah, but it works under KDE+X11. Wayland it the thing that changes. I think KDE has it's own Wayland implementation? kwin_wayland is what is broken, probably. Why they broke it when porting it from X11 I don't know. But the effect is the same: Can't use it as of now.
You can't condemn a protocol because there are bad or buggy implementations.
HTML5 was not shitty because internet explorer was a shitty browser.
I don't condemn the protocol. I specifically mention the buggy implementation. I say that I use X11 because KDE's Wayland implementation is so buggy.
I want to use KDE. KDE was perfect for me before Wayland. I don't criticize Wayland here, I criticize KDE Wayland. And I'm worried because very soon KDE will delete X11 support.
But you can condemn the organization and people pushing for the deprecation and abandonment of another protocol, when the alternative one (Wayland) has nowhere near the level and quality of support and breadth of capabilities as the existing one. GP puts the blame on KDE - and it would be partially their responsibility if they were to drop X11, for sure, but the underlying initiative is RedHat/IBM's.
What is Wayland as a protocol missing?
Wish I could use it, I really tried! I have some HDR screens I want to actually run HDR on. But KDE Plasma + Wayland keep crashing out on me.
Which distro?
Nixos unstable atm fwiw, which you'd expect would pick up fixes early. But my particular setup with displayport DPMS stuff keeps going wrong, and there's a bunch of WONTFIX under KDE afaict.
Ehhh I know people love that and swear by it, and maybe it's fine, but I wouldn't expect it to have great integration and a solid, reliable, desktop experience on nixos.
KDE/X11 is rock solid, at least
Which toolkits are dropping support for X11?
AFAICR, few toolkits support Wayland (even though the two major ones, GTK and Qt, do).