3 ms·

My main issue with Wayland is how big of a missed opportunity it is. If you're going to introduce a massive breaking change like this to modernize the Linux des

by ndiddy 3y ago

My main issue with Wayland is how big of a missed opportunity it is. If you're going to introduce a massive breaking change like this to modernize the Linux desktop, the least you can do is make it an actually compelling design. Wayland was originally created to fix the parts of Xorg that made it difficult to use it for embedded devices (digital signage, car infotainment systems, etc), so the base protocol only defines enough functionality to make that use case possible. Anything more complex than that requires using a complicated patchwork of Wayland protocol extensions, some of which are specific to certain compositors and many of which duplicate the X11 protocol extensions they're intended to replace. I'd be surprised if Wayland isn't more complicated to use than X11 in a few years. Additionally, Wayland is already showing its age. The example that first comes to mind is how events are handled. Device events are received from the kernel and placed in a 4KB buffer that clients are supposed to read from and process. If the buffer fills up without being processed (for example, if high CPU or I/O stress causes a program to get descheduled for a few seconds and the user moves his mouse over the window), the compositor will sever its connection with the program, causing it to crash. This wasn't a problem for Wayland's initial embedded use case, but if you're trying to use it on desktop with devices such as high-polling rate mice it makes it far more unstable than X11 unless you have enough system resources to guarantee that no program will ever have its event handler thread pause for any reason. See here for more information: https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 I wish that the "X11 is showing its age and should be replaced, but Wayland isn't the right option" viewpoint was more mainstream.

bzzzt 3y ago
I don't see how a client application blocking its main event handler isn't broken? If you're going to do lots of work or blocking I/O you spin it off to another thread so UI updates will be handled without pause.
- ndiddy 3y ago
  On desktop we don't have realtime scheduling. Processes can get descheduled for arbitrary amounts of time. This issue happens with well-behaved applications that don't block at all on their main event handler threads when the system is under high CPU or I/O load.

by ndiddy 3y ago

bzzzt 3y ago

I don't see how a client application blocking its main event handler isn't broken? If you're going to do lots of work or blocking I/O you spin it off to another thread so UI updates will be handled without pause.

ndiddy 3y ago
On desktop we don't have realtime scheduling. Processes can get descheduled for arbitrary amounts of time. This issue happens with well-behaved applications that don't block at all on their main event handler threads when the system is under high CPU or I/O load.