"J. Aho" <gen...@kotiaho.net> writes: > On 05/08/2024 18.30, Daniel Frey wrote: >> Is it just me or is wayland nowhere near primetime? > > There are still issues with wayland, not sure how up to date this page is: > https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
it's either out of date or fearmongering. I'd presume the former if not
for the first emphasised paragraph of the post: "DO NOT USE A WAYLAND
SESSION! Let Wayland not destroy everything and then have other people
fix the damage it caused. Or force more Red Hat/Gnome components (glib,
Portals, Pipewire) on everyone".
but, each "point" it makes can individually be debunked also. I'm not
very interested in doing that beyond oneliners though (which is
apparently enough for the author of the original post).
- Wayland is broken by design - X is and has been for decades.
- A crash in the window manager takes down all running applications -
a crash in X takes down all running applications. only the label of
what crashed differs
- You cannot do a lot of things that you can do in Xorg by design -
irrefutable as it is not specific enough (but, it is true that a lot
of hacks X allows aren't permitted in wayland)
- There is not one /usr/bin/wayland display server application that is
desktop environment agnostic and is used by everyone (unlike with
Xorg) - correct, this is also true of X WMs, and though people
pretend all X desktops worked the same, anyone who has used a Java
program, for instance, knows this is false
the following point is the same
- Wayland breaks screen recording applications - this is false, either
1) screen recording works via portals, or 2) screen recording works
via xwaylandvideobridge
- Wayland breaks screen sharing applications - same as above
- Wayland breaks automation software - see libei, I also have remote
input working via kde connect, which relies on the same mechanisms
automation would rely on
- Wayland breaks Gnome-Global-AppMenu (global menus for Gnome) -
possibly, I don't know, I don't use GNOME or global menus
- Wayland broke global menus with KDE platformplugin - just tried krita,
seems to works fine
- Wayland breaks global menus with non-KDE Qt platformplugins - tried
qtdesigner, seems to work fine
- Wayland breaks AppImages that don't ship a special Wayland Qt plugin -
I'm not sure what was anticipated - shipping outdated libraries will
invariably break. note that Qt also doesn't work on X if you delete
the XCB plugin.
- Wayland breaks Redshift - this is true, but redshift isn't that
special - I have redshift functionality in KDE, I had it in Sway, I
know for a fact it's there in GNOME, just the redshift program is
broken
- Wayland breaks global hotkeys - they never worked, and continue not
to, the reasoning for not allowing the hack X allows is quite good,
see
https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html
- Wayland does not work for Xfce? -
https://wiki.xfce.org/releng/wayland_roadmap
- Wayland is biased toward Linux and breaks BSD - I've seen and worked
on hobby OSes that implement Wayland just fine. obviously, porting is
required (and it was required for X, eg OpenBSD still has homebrew X),
but AFAIK freebsd runs wayland, and I know at least of one wayland
desktop supports freebsd. it is ironic to bring up bsd when one of
the arguments is "everyone has to reimplement basic functionality"
given BSD kernel diversity, though
- Wayland complicates server-side window decorations - CSD seems logical
to me, at least in large part, so I'm not sure this actually matters.
however, I know that SSD support exists.
- Wayland breaks windows rasing/activating themselves - good! this is
popup prevention, and doesn't actually impede *any* valid activation
(window alerts still work, fresh apps windows will still come into
focus, so do popups, etc, just fine)
- Wayland breaks RescueTime - yes, because it relies on clients spying
on eachother
- Wayland breaks window managers - I'm not sure what they mean here
- Wayland requires JWM, TWM, XDM, IceWM,... to reimplement Xorg-like
functionality - libraries exist. note that WMs aren't no work either.
anyone who has written one will be able to tell you that there are a
lot of workarounds to implement to get WMs to work fine.
- Wayland breaks _NET_WM_STATE_SKIP_TASKBAR protocol - unsure, really,
literally never had to do that. i'll trust the electron devs on it
not existing though
- Wayland breaks NoMachine NX - I'm not sure what this program is
either, it seems to be remote desktop, and according to the linked
post it works now? /me shrugs - wayvnc exists anyway (for wlroots,
IIRC KDE implements RDP)
- Wayland breaks xclip - I was able to edit my clipboard with it, so I
don't know what they mean. xwayland certainly forwards the clipboard
- Wayland breaks SUDO_ASKPASS - what?
- Wayland breaks X11 atoms - cars break horse saddles
- Wayland breaks games - i played elden ring earlier today. there's
this myth of forced double buffering on wayland that I presume is
related, I'm not sure where it stems from but it's quite untrue. even
adaptive sync on my freesync display worked fine. I do not know the
intricacies of display syncing but I am 100% certain that double
buffering is not forced
- Wayland breaks xdotool - correct, actually; and unsurprisingly,
similarly to rescuetime, xdotool relied on protocol flaws to work,
libei exists to replace it
- Wayland breaks xkill - not really surprising, again, since it exploits
flaws in X. ISTR hitting a button accidentally that gave me a 'kill
window' in my plasma wayland session, though, so I'm sure similar
functionality exists
- Wayland breaks screensavers - ironically, those never worked on X, but
do on wayland, because the compositor can actually redirect keys
properly rather than trying to patchwork around X
- Wayland breaks setting the window position - yes, intentionally,
wayland is declarative wrt window positioning (you might notice that
if you right click, the popup position is as you'd expect - this is
because the client tells the compositor where /relative to a surface/
it wants some other surface to appear, rather than a global position).
- Wayland breaks color mangement - did this ever work on X? unsure,
but I know HDR was being worked on recently. my display is a regular
RGB 24-bit display so I do not know how well it works.
- Wayland breaks DRM leasing - decently sure this was implemented in
wlroots, kde and gnome some years back, but I don't have the hardware
to test.
> "not all" highlights one of the fundamental problems with Wayland -
> there is fragmentation
not all X servers implement <XYZ>, not all X WMs implement <ABC>
(e.g. again dwm doesn't implement EWMH). this isn't new
- Wayland breaks In-home Streaming - I'm not sure what this means, but
they cite steam remote play (together), a feature that I used on kde
wayland, so there's that
- Wayland breaks NetWM - so do X WMs (dwm for instance)
- Wayland breaks window icons - this is true actually, I found it
surprising but not particularly important since you can still have
functional window icons (and I see a window icon on the very window
I'm typing this in) by providing a desktop file
- Wayland breaks drag and drop - I'm really not sure what to say here -
I've used that feature.
- Wayland breaks ./windowmanager --replace - X lacks --replace, but kwin
and probably others don't
- Wayland breaks Xpra - probably true but I never used Xpra so I can't
be sure
what these kinds of posts omit is that X is fundamentally broken and
misfit to modern systems. the code is also unmaintained and not the
greatest. the creation of wayland wasn't accidental, nor was it some
ploy to undermine the desktop, nor ...
there's a new graphics stack because the old one didn't work, and I'm
not sure where this kind of response to it comes from - it seems similar
to the systemd debacle. see also
https://www.youtube.com/watch?v=GWQh_DmDLKQ (by a former X developer,
so, someone with qualifications)
what these posts /also/ lack is enthusiastic contributors who'll
actually pick up the mantle of maintaining and improving X.
I have been using wayland for probably four or so years now, and I've
only so far missed a standard for global shortcuts (note, a _standard
for it_, not a hack-job allowing clients to listen to keystrokes
globally and react to them, leading to weird conflicts and fragmented
configuration; something integrated into desktops, that's not a job of
individual clients to implement, so, really, I'm missing that in X also).
> My SailfishOS based phone uses wayland and on that it's been working fine, on
> my desktop with a nVidia RTX I haven't managed to even login into a wayland
> session,
hmm, on my 1050Ti PC I run kde plasma just fine. I don't know anyone
with an RTX card to ask them if it works for them, though - but it could
be some misconfiguration (you need some USE flags on the nvidia drivers
IIRC, and some compositors, like sway, require an extra flag).
> but on my laptop with i915 it works fine most of the time and it leave
> me think that the developers behind wayland are mainly using intel
> graphics cards and then blame the graphics driver when things don't
> work on other hardware.
not really - all the drivers in mesa are supported by most developers,
and frequently tested. I actively use NVidia, AMD and Intel cards, and
out of those, NVidia is the only one with occasional bugs (which are, no
doubt, in the driver..)
> I would say for general use wayland ain't up for it's task, if you have the
> right hardware and you mainly use the browser, then it works.
i don't have the right hardware (proprietary nvidia card as i
mentioned), nor do i primarily use the browser (i work a lot of gtk and
qt programs, and I know wine also works fine, probably through
xwayland), so I have to disagree.
have a lovely day
--
Arsen Arsenović
signature.asc
Description: PGP signature
