3 ms·
> Xorg and Wayland compositors use the same underlying APIs Not really. KWin has Wayland specific paths that simply don't work on X and developers are increasi
by shmerl 3y ago
> Xorg and Wayland compositors use the same underlying APIs
Not really. KWin has Wayland specific paths that simply don't work on X and developers are increasingly simply not bothering to go out of their way with X if something isn't possible to implement over it. So X use case is going to further deteriorate, that's inevitable.
- badsectoracula 3y ago> Not really. KWin has Wayland specific paths that simply don't work on X What exactly do you refer to? Note that i meant the kernel APIs to drive the hardware as what i replied to was Xorg not keeping up with newer hardware, not toolkits.
- shmerl 3y agoI mean stuff like bugs with boot screen leaking data not being fixed with X and so on.
- badsectoracula 3y agoHow does that have anything to do with X not keeping up with new hardware or using the same kernel APIs as Wayland for communicating with said hardware? What you describe is a minor annoyance at most, not at all on the same level as being unable to use X because of newer hardware. Even if it isn't fixed, one can still be worked around or just ignored, but the other just makes the whole thing literally unusable.
- shmerl 3y agoThat means that X case will become increasingly broken. It won't work and won't be supported, newer hardware or not. And X won't have parity for hardware features anyway. Like HDR - it will be Wayland only. And so on and so forth. So X is fried on all ends in the long term. It's not that it's not possible to use kernel interfaces - it's just no one will bother putting an effort in developing X. It's already happening.