I’ve written some other posts on Wayland recently, and it’s time for another one! Feel free to skip it it you aren’t interested in a discussion of Wayland and platforms. Many may …
Your issue is you’re assuming all things must be standardized in a monolithic fashion.
The whole point of Wayland is that monoliths are bad in an environment as diverse as the Linux desktop.
Either libinput will be improved or it will be replaced as needed.
I’d argue portals are deficient because Wayland implementations in general are not complete. An org like KDE or GNOME has a fair bit of man power but they’re still in a position where they need to keep X11 functional and they need to carry forward decades of features. Even if Wayland was flawless from the onset that’s a huge undertaking.
Wayland is one part of what needs to be a collection of specifications, but the point is to have a specification instead of an implementation. You can actually have implementations that make different trade-offs and optimize different use cases that way.
That doesn’t prelude something like mir or wlroots acting as a base layer for desktops that don’t want to build up from the specification … but it does allow KDE to write a compositor that does exactly what KDE needs/wants … instead of the X11 mess where you can “turn the compositor off” which results in effectively two classes of desktop, one of which is used for gaming, the other for general desktop use … or any of its various other issues.
They don’t have to be specified in a monolithic fashion, but some things - like the input plumbing and session management examples I made - do have to be specified for for software to work when running under different compositors. FD.o basically exists because we already learned this lesson with other compat problems, and solved it without putting it in the X monolith - it’s why things like ICCM and EWMH happened; there were more details than were in the existing APIs that everyone needed to agree on to make software interoperate.
Competing implementations are great, but once you have significant inertia behind competing implementations which are not compatible or at least interoperable, you’ve fragmented the already-small Linux market share into a maze of partially-incompatible micro-platforms. We’re not going to have compositing and non-compositing, we’re going to have 3ish (KDE/Qt [kde], Gnome/Gtk who aren’t even doing documented protocols, and Everyone else - mostly [wlr] extensions) incompatible sets of protocols for basic functionality.
Looking at the slow bitter process to extend or replace components once implementations that rely on them exist, that’s not something to count on. Remember how it took 15 years of contention to eventually transition to D-Bus after CORBA/Bonobo and DCOP? That’s whats about to happen with things like the incompatible gtk and qt session management schemes. And that resolution was forced by the old HAL system using it, not the other parties involved getting their shit together of their own accord.
One place we’re about to see innovation is wayland-stack-bypassing workarounds. Key remapping is currently in that category, the wayland protocols suite punted… so instead, keyd sniffing all the HID traffic at the evdev and/or uinput layer and outputting the rule-edited streams to virtual HID devices. That one does have a certain global elegance (works on ttys!), but it’s also layering violations with privileged processes.
I’m not going to say that there haven’t been balls that have been dropped on some things. Like, we should’ve come out of the gate with a protocol for remote desktop access as an example.
However, when all these X11 developers say it’s time to move on, I’m inclined to believe them.
We’ve already had the fragmentation between different desktops on various things, dbus APIs as an example have often been KDE or GNOME specific. It’s been a long standing complaint really. And well, as much as I’m sympathetic I think we get more from flatpak than we lose from Wayland. There are going to be specific niche programs that need to deal with specific APIs but in general, I think it’s easier than ever to ship “one package” and have it just work where you need it to.
Based on the inertia that wayland has I’d be shocked if it takes 15 years for one or two dominate APIs for various missing pieces to emerge with one becoming the standard.
Your issue is you’re assuming all things must be standardized in a monolithic fashion.
The whole point of Wayland is that monoliths are bad in an environment as diverse as the Linux desktop.
Either libinput will be improved or it will be replaced as needed.
I’d argue portals are deficient because Wayland implementations in general are not complete. An org like KDE or GNOME has a fair bit of man power but they’re still in a position where they need to keep X11 functional and they need to carry forward decades of features. Even if Wayland was flawless from the onset that’s a huge undertaking.
Wayland is one part of what needs to be a collection of specifications, but the point is to have a specification instead of an implementation. You can actually have implementations that make different trade-offs and optimize different use cases that way.
That doesn’t prelude something like mir or wlroots acting as a base layer for desktops that don’t want to build up from the specification … but it does allow KDE to write a compositor that does exactly what KDE needs/wants … instead of the X11 mess where you can “turn the compositor off” which results in effectively two classes of desktop, one of which is used for gaming, the other for general desktop use … or any of its various other issues.
They don’t have to be specified in a monolithic fashion, but some things - like the input plumbing and session management examples I made - do have to be specified for for software to work when running under different compositors. FD.o basically exists because we already learned this lesson with other compat problems, and solved it without putting it in the X monolith - it’s why things like ICCM and EWMH happened; there were more details than were in the existing APIs that everyone needed to agree on to make software interoperate.
Competing implementations are great, but once you have significant inertia behind competing implementations which are not compatible or at least interoperable, you’ve fragmented the already-small Linux market share into a maze of partially-incompatible micro-platforms. We’re not going to have compositing and non-compositing, we’re going to have 3ish (KDE/Qt [kde], Gnome/Gtk who aren’t even doing documented protocols, and Everyone else - mostly [wlr] extensions) incompatible sets of protocols for basic functionality.
Looking at the slow bitter process to extend or replace components once implementations that rely on them exist, that’s not something to count on. Remember how it took 15 years of contention to eventually transition to D-Bus after CORBA/Bonobo and DCOP? That’s whats about to happen with things like the incompatible gtk and qt session management schemes. And that resolution was forced by the old HAL system using it, not the other parties involved getting their shit together of their own accord.
One place we’re about to see innovation is wayland-stack-bypassing workarounds. Key remapping is currently in that category, the wayland protocols suite punted… so instead, keyd sniffing all the HID traffic at the evdev and/or uinput layer and outputting the rule-edited streams to virtual HID devices. That one does have a certain global elegance (works on ttys!), but it’s also layering violations with privileged processes.
I’m not going to say that there haven’t been balls that have been dropped on some things. Like, we should’ve come out of the gate with a protocol for remote desktop access as an example.
However, when all these X11 developers say it’s time to move on, I’m inclined to believe them.
We’ve already had the fragmentation between different desktops on various things, dbus APIs as an example have often been KDE or GNOME specific. It’s been a long standing complaint really. And well, as much as I’m sympathetic I think we get more from flatpak than we lose from Wayland. There are going to be specific niche programs that need to deal with specific APIs but in general, I think it’s easier than ever to ship “one package” and have it just work where you need it to.
Based on the inertia that wayland has I’d be shocked if it takes 15 years for one or two dominate APIs for various missing pieces to emerge with one becoming the standard.