Interesting. Does anyone know what kind of stake Collabora has in Wayland? So far it has seemed to me that there aren’t many commercial backers of Wayland. But if there is, I guess it’s good for the project. Creating a desktop environment of high quality takes lots of really hard work, just look at all the enourmous resources that Next/Apple/Microsoft has spent on their desktop environments.
> So far it has seemed to me that there aren’t many commercial backers of Wayland.
A very decent % of car-automotive infotainment systems are GENIVI[1] and Automotive Grade Linux based, which have been Wayland based.
LG's webOS runs on Wayland.
Much of Collabora's interest comes from involvement with Chrome & ChromeOS. I originally was thinking ChromeOS switched entirely to Wayland, but looking around I'm having a hard time confirming. I believe this is true: ChromeOS has an "Aura" shell which leverages the Chrome infrastructure. Chrome has it's own "Ozone" api for rendering. A lot of Collabora work & other has gone into the Ozone's Wayland backend.
In the future, the Lacros[2] project intends to run Chrome the browser inside their Chrome-based Exo/Exosphere display server, which is impemented in Aura. Kind of weird situation. Still not sure what Aura or Exo directly uses, whether it keeps a Mus or other special Ozone backend, or whether it too will run on Wayland, but the browser inside ChromeOS is going to be running on Wayland "soon".
One can also run Android apps under Spruv[3], which targets Wayland.
Best most important technology development happening on the planet. Join those pushing for a better "brighter" future.
Wayland is heavily used in the embedded world. But the embedded world is not using KWin, Mutter or Sway but instead more minimal compositors like Qt Wayland compositor or Weston.
Non desktop usecases are actually a major driver for wayland adoption, because x11 is very much designed for desktop, whereas wayland is intended to be more general.
Well, the intention is that there are desktop-specific protocols (for example, xdg-shell) that would be implemented by desktop compositors (such as KDE, GNOME, and wlroots), but wouldn't need to be implemented in other environments. The problem is currently there are several use cases where such protocols either don't exist, or are not standardized across multiple compositors.
I want to be clear about something. I don't care how those use cases get addressed.
I do care very much about Unix remaining Unix. And the way X was implemented is multi-user graphical computing. That's got a lot of advantages and lot of use cases that people put to good use.
X works works over the network because Unix does things over the network. X is multi-user, like Unix is multi-user.
Same goes for multi-headed systems, multiple displays all kinds of user interface devices. You name it.
The problem quite simply is the new development isn't unix-like in the way X was Unix like.
The question is whether people will accept a lesser Unix then they know is currently possible.
Afaik all of those things work fine with wayland, at least with wlroots. It is true that wayland isn't network transparent, but it can be used over the network with things like wayvnc and waypipe. Now you can say that those aren't really mature yet, and I would agree with you. I think wayland's readiness is often over-exagerated. However, I don't think any of the things you pointed out are compelling evudence that wayland isn't unix like.
Otoh, I do think wayland departs from Unix in how it requires the "compositor" to perform to many roles. While in X, the compositor, window manager, etc. can be and often are seperarate processes from the x server, in wayland the compositor also needs to be the window manager, the keyboard layout manager, xwayland server, etc. And at least according some developers for a popular desktop environment, it is also the compositors responsibility to perform other tasks such as screen capture, vnc server, taskbar, lockscreen, etc. It isn't possible to do something like use i3 as the window manager for kde in wayland.
For some people, yes. But if you don't need those things, or your compositor and apps of choice support the same protocols, it is possible to switch to wayland.
But the greater frustration here seems to be lack of interest in multi user graphical computing.
Without the basic nature of X being a priority, the whole system is less. X was done the way Unix was.
People thought through general purpose multi user networked computing. Sometimes just multi user, serial tty style.
The gift of C was that same level of thought behind multi hser graphical computing. Again, sometimes networked, in the same fashion as above.
Current efforts are not multi user graphical computing as a focus.
It is said it can be.
Many who understand how to use X think it should be. Unix is a powerful OS, with some of that potential being sidelined to optimize for specific cases.
Do you have any examples you could point to? A few years back I looked into this and the only real viable option was Qt Embedded, which is expensive for embedded and requires royalties to be paid on per-device basis. I wonder how much things have changed since then and whether there's now a viable FOSS GUI stack for embedded Linux.
Qt Embbedded is a full featured GUI framework and you don't need it. You can just use QtWayland for free and run any GUI apps that targets Wayland (GTK, Qt...).
One of the most used is probably Tizen, an embedded OS by Samsung for smartwatches (they don't use Google WatchOS) and TVs.
