6 ms·
Not quite overall, at least from my perspective. 1. Adaptive sync still needs Wayland protocol support, before compositors can pick it up. It already works on
by shmerl 7y ago
Not quite overall, at least from my perspective.
1. Adaptive sync still needs Wayland protocol support, before compositors can pick it up. It already works on X.
2. Some major features like common frameworks for screen capturing need to be agreed on, in order to avoid reinventing the wheel in tons of incompatible ways. Did everyone agree to use Pipewire, or it's still bikeshedded with everyone trying to do their own thing? I wasn't following this recently.
3. KWin has some major bugs to fix for the Wayland session, like subsurfaces clipping issue.
4. Support for Wacom drawing tablets is still missing in KWin on Wayland.
And so on.
- AnIdiotOnTheNet 7y agoWhat I'm hearing is, by the time Wayland is actually on par with X, feature-wise, it will by time for a whole new rewrite because something else will be fundamentally different in the way graphics are rendered. Windows went full compositor with Vista in 2006, with all the features and then some of its predecessor (except you can't have windows with no v-sync). 14 years later Wayland almost has a standardized way of taking screenshots.
- shmerl 7y agoPossibly the part of the problem is, that there is no single owner and no one directs it. Everything seems chaotic, many things are low priority for developers, while in practice they are high priority for users and so on. I suppose that's the natural consequence of Linux desktop stack being developed so collaboratively. And the fact that desktop itself is so fragmented (KDE, Gnome, etc.) doesn't help either. Resources are spread quite thin. The major problem with Wayland is, that unlike X which is a unified point of collaboration, Wayland compositors need to do all the work on their own (unless they figure out how to share the effort, which doesn't go too well so far). So problems of fragmentation and lack of resources are only amplified in Wayland case, causing a huge delay in overall progress. And I'm not saying all the above is a bad thing (some argue choices are good and etc.). But the downsides are obvious. Personally, I'd prefer developers focusing more on KDE, but Gnome users would likely disagree.
- MayeulC 7y agoThis is not out of the realm of the possibility. But by the time a new protocol is needed, applications will hopefully be much cleaner if they migrated to Wayland in between (less X-specific hacks, better compartmentalization of features). It would probably be easier to implement interface for backwards compatibility with Wayland than try to emulate the monolithic X (well, Xwayland is X running under Wayland because there's no other choice, so that's a possibility as well).
- Vogtinator 7y ago> 3. KWin has some major bugs to fix for the Wayland session, like subsurfaces clipping issue. You're probably seeing a Qt bug there, not KWin: https://bugreports.qt.io/browse/QTBUG-54888 https://bugreports.qt.io/browse/QTBUG-54888
- shmerl 7y agoThat's a different one, and it is a problem with KWin: * https://bugs.kde.org/show_bug.cgi?id=387313 https://bugs.kde.org/show_bug.cgi?id=387313 * https://phabricator.kde.org/T10530 https://phabricator.kde.org/T10530