News for hackers. Stuff that matters.

A comment on Guide: Full Wayland Setup for Linux. Parent comment

Re:Guide: Full Wayland Setup for Linux by jude- on Wednesday March 10, 2021 @03:58PM (#26416149)
The other two concerns in GP are no screen tearing, and better hidpi / multi-monitor support. Is it truly less work and less disruptive to address these to concerns within X11 than it is to throw X11 out (and also leave all nvidia users high and dry)? Also, keep in mind that throwing X11 out and replacing it will take more than just technical legwork -- it will also take ecosystem buy-in and standardization, and if we're being honest with ourselves, this is the harder problem. Recall that the X11 ecosystem has a 30-year head start on this, and there's a crap-ton of 3rd party software that assumes an X11 environment that Wayland is going to need to emulate. If X11 does indeed go the way of the dodo, I think we can reasonably expect another 30 years of bug reports in the form of "Fuck Wayland! I upgraded to Wayland and my $IMPORTANT_THING broke!". I very much doubt that at the end of the day the switch to Wayland is going to be overall easier than just fixing X11, but would love to be convinced otherwise.
[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by cycloptic on Wednesday March 10, 2021 @04:28PM (#26416500)
The usual way to fix other concerns like that has been to add more WM atoms or add more X extensions, which is a similarly uphill battle requiring buy-in and standardization, and typically old X clients just won't be updated to support those new things. The way to get the most value out of such things would be to add support to the major toolkits, but those have already been ported to Wayland for some years now.

The backwards compatibility is done through XWayland which functions similarly to XQuartz, in that it is just the Xorg server running using Wayland as a backend driver.

[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by jude- on Wednesday March 10, 2021 @06:14PM (#26417786)
What do you think is more of an uphill battle, in terms of time and energy sunk? Adding another X extension that can be incrementally deployed, or trying to phase X out by maintaining both an X11 and Wayland back-end for all apps trying to avoid breakage?

This doesn't even speak to X11 apps that aren't built with toolkits (for example, I use xterm, xpdf, xfig, Openbox, etc.).

XWayland is a nice idea, don't get me wrong. But it's not a 100% replacement either. Distros offering XWayland are even up-front about it's shortcomings [1][2][3].

[1] https://wiki.debian.org/Wayland

[2] https://docs.fedoraproject.org/en-US/quick-docs/debug-waylan...

[3] https://wiki.archlinux.org/index.php/wayland#XWayland

[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by cycloptic on Wednesday March 10, 2021 @06:30PM (#26417976)
There isn't much difference there, but it would be more of an uphill battle if you tried to put everything different that Wayland does into X extensions. That still requires maintaining an extra code path for old X servers that don't support the new extensions, and creates additional risk of breaking things and causing regressions in the X server because of all the new code you're adding.

Clients like term, xpdf, and xfig should work fine in XWayland. Window managers won't work without getting ported, but someone has been working on a port of Openbox: https://github.com/johanmalm/labwc

[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by jude- on Wednesday March 10, 2021 @08:28PM (#26419013)
> That still requires maintaining an extra code path for old X servers that don't support the new extensions, and creates additional risk of breaking things and causing regressions in the X server because of all the new code you're adding.

Yes, agreed! But why is it _more_ risky to do that than to throw the whole X server concept away and start from scratch? Rewriting such a widely-used piece of infrastructure from the ground up is a super-risky proposition.

[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by cycloptic on Thursday March 11, 2021 @05:39PM (#26429927)
That's mostly a misconception, Wayland implementations don't need to start from scratch. Weston and wlroots are minimal from-scratch implementations, but GNOME and KDE for example do their implementations by re-using most of the code from their X compositor.
[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by jude- on Thursday March 11, 2021 @07:32PM (#26430867)
Great! So instead of having one standard way to do video/input multiplexing, we have at least four -- GNOME's, KDE's, wlroots, and weston (and probably a smattering of others). If I want to write a program that works with "Wayland," I'm either going to have to test them on all of the widely-used compositors (because of course they're not all going to behave exactly the same way), or I'm going to have to just punt on them. The former option is 4x the work, and the latter option is me telling users "Hey everone, remember that program that used to run everywhere in every window manager ever that you all know and love and depend on to do your jobs? Well, now it only works on GNOME, since that's all the time I have to support it. Good luck non-GNOME users!"

EDIT: Before you say "just use a toolkit, it'll take care of everything," I can already tell you that users don't care. They only care that the app that used to work in KDE no longer works in KDE. They're not going to complain to Qt or Kwin; they're going to complain to the app author. So the app author becomes responsible for the additional burden of testing their software in a bunch of different compositors, for zero gain.

[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by cycloptic on Thursday March 11, 2021 @07:41PM (#26430940)
Is that any different from normal? In my experience, if you're shipping a product on a Linux-based desktop, usually you target a specific set of distributions, i.e. the default configuration of the last few LTS versions of RHEL or Ubuntu or whatever, which at least for those examples all happen to be GNOME based. Customers who come with some weird hacked-up distribution would be on their own for support anyway, they can try it but there's no guarantee it will work. If KDE (or something else) really is doing something different here then you would have had to extend the same amount of effort as you did previously.
[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by jude- on Thursday March 11, 2021 @08:49PM (#26431395)
Before, a graphical program would run just fine under GNOME or KDE because it wasn't GNOME or KDE handling the video/input multiplexing facilities. But now with Wayland, a graphical program not only needs to target distros, but specific configurations of those distros (i.e. Debian/GNOME, OpenSUSE/KDE, etc.). This isn't helping fragmentation.
[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by cycloptic on Thursday March 11, 2021 @09:27PM (#26431606)
That's only if you're using functionality specific to the DE, which is handled mostly the same as it is under X. GNOME and KDE for example tend to provide their functionality as dbus services. If you just have a simple app that needs no special privileges or features then that will work just the same. If you use GTK or Qt, the transition will be mostly seamless and would only be a problem if you were circumventing that and calling Xlib or xcb directly.
[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by jude- on Thursday March 11, 2021 @11:44PM (#26432300)
No, this happens if the particular Wayland compositor you're running the program on happens to implement a Wayland protocol or extension you use in a "unique" way that causes your app to break. This wan't a problem with X.org because all distros used the same X.org (or, if they used an older X.org, and if that led to breakage, the solution for users was always the same: upgrade X.org).

I already explained above why "just use a popular toolkit" isn't a viable solution. Users do not care whose fault it is; all they care about is that your app used to work in KDE and now it doesn't in GNOME (the problem is even worse in Wayland than I'm letting on, because with Wayland, the DE controls the compositor and renderer -- there are so many more ways for the DE-specific code to interfere with the graphical program than there was with X.org).

[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by cycloptic on Friday March 12, 2021 @12:09PM (#26438000)
Sure but that's not any different if your application depended on some other GNOME or KDE specific API. If KDE decides an API is KDE only and GNOME doesn't want to make their own implementation then there's not much that you could ever do about that. The point with using a toolkit is that it's an abstraction layer that handles the differences between window systems and implementations for you. It would be better if you mentioned the specific reason why your app is breaking because that would likely be a bug in the toolkit.
[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by jude- on Friday March 12, 2021 @03:18PM (#26440387)
Except now the whole X server is part of a GNOME-specific or KDE-specific API.

The bug is "Wayland makes it so programs don't reliably run anymore because they are no longer guaranteed to work with all window managers and desktop environments." It's an architectural flaw.

[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by cycloptic on Friday March 12, 2021 @03:25PM (#26440469)
Not really, shared functionality there is in the core wayland protocol and in the standard set of wayland extensions, or in some other standard dbus interface. (generic ones usually go in the org.freedesktop namespace) If you depend on GNOME-specific or KDE-specific APIs then yes, you would have to deal with those being unsupported outside. Not much has changed there.
[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by jude- on Friday March 12, 2021 @09:58PM (#26443490)
sigh In one ear, out the other.
[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by kaba0 on Wednesday March 10, 2021 @06:42PM (#26418110)
Nvidia cards with proprietary drivers are supported under gnome’s and plasma’s wayland implementations.
[ Parent | on HN ]
Re:Guide: Full Wayland Setup for Linux by jude- on Wednesday March 10, 2021 @08:14PM (#26418896)
Ah, I didn't know that. Kudos to them!
[ Parent | on HN ]