KDE's Nate Graham On X11 Being A Bad Platform & The Wayland Future

[darkonix]

I'd say the problem with nvidias drivers are they are to fast, so calls they expect to take a long time don't and that trips up various bugs in the wayland compositors. Thats the usual issue when moving to hardware accelerated calls.

It cant be the drivers themselves because X11 doesnt have anything like the same problems, completely the opposite, X11 wipes the floor with the windows drivers.

It is drivers limitations for some issues. It is documented by NVidea: https://download.nvidia.com/XFree86/...nd-issues.html. not sure if they improved something since publishing this list.

It would be weird if the issue was that the driver answers too fast. Where did you saw that?

[mSparks]

It would be weird if the issue was that the driver answers too fast. Where did you saw that?

Its a common race condition when you move from a code path that was software accelerated/slow to one that is hardware accelerated/fast.

original dev assumes B always finishes after A, then when B gets fast it now finishes before A, causing problems.

this can be as simple as
A=simpleasyncfunc()
B=complexasyncfunc()
wait(B)
func(A)
func(B)

on a slow code path this can "always work" without issue, but if "B" suddenly gets hardware acceleration and A doesnt, suddenly its trying to do something with A before its ready, and boom it blows up.

In practice the dependancies are much more complex than this, its much harder to track them, and when it blows up it can be entirely non obvious why, it's also what makes languages like go and java attractive.

[DMJC]

I wasn't lying about the notifications area, turns out Debian's packages for MATE on Wayland are actually broken. To work on Wayland MATE-Panel applets have to be compiled inside the main mate-panel process. I logged bugs with upstream and then updated the Debian developers with the problem once I was informed by the upstream developers. It's going to be years before Wayland is ready to be used as a daily driver. Both from packaging not being up to date, but also the changes needed to Wayland compositors, Wayland Session Managers and other components which just aren't packaged/working/complete yet. For example, Wayfire doesn't remember monitor layout (not order, that seems to be ok). Everytime I reconnect my system to Wayland I have to move my laptop screen below one of my two 30 Inch monitors in the layout so I can have the mouse behave as expected.

image.png

[sfjuocekr]

If only we could watch videos, game or do whatever in 4K on a 4K monitor with scaling set to 200% on Wayland...

Right now, you basically have a 1080 image stretched to 4K because the entire viewport is scaled instead.

[DrYak]

yet somebody does use the following:
- Functions to query window status, mouse position and all
- Hotkeys
- Automation (xdotool)

(also add screen sharing and clipboard access to the list).


Your example rely on the fact that X11 protocol has zero security and any client connecting to the server can basically listen to any event, query any information, and inject any keypress/mouseclick back.
This allow cool stuff like Synergy.
But, this is a frightening gaping hole in security.

Wayland by default only allows apps to access their own information and space (well except stuff running on XWayland, but that's not the subject).
Anything else require the software requesting permission to do, requires special systems to access (portals, etc.), and can be sandboxed away.

Now it is possible to do everything you list, it's just that it requires a different and more secure approach under Wayland (e.g.: Waynergy can do all these that you list, Firefox can do screen sharing using portals and pipewire, etc.)