Wayland's Weston Compositor Introduces Kiosk/Fullscreen Shell

[phoronix]

Phoronix: Wayland's Weston Compositor Introduces Kiosk/Fullscreen Shell

While there is already the Cage kiosk full-screen shell as well as the likes of Ubuntu's Mir Kiosk Shell, Wayland's Weston reference compositor now has its own implementation...

http://www.phoronix.com/scan.php?page=news_item&px=Wayland-Weston-Kiosk-Shell

[tildearrow]

Nonsense rant:

It just feels to me that Wayland was never designed for real desktop usage, but rather just for embedded and stuff like that.
The lack of server-side decorations support is an example.
The fact that most Wayland compositors use OpenGL ES rather than real OpenGL is another example.


Heck, the Weston repo even has a whole directory for IVI (in-vehicle infotainment) support, which clearly indicates Wayland was never designed for the desktop.
Oh, and look at the vast amount of experimental compositors out there.

[Emmanuel Deloget]

Nonsense rant:

It just feels to me that Wayland was never designed for real desktop usage, but rather just for embedded and stuff like that.
The lack of server-side decorations support is an example.
The fact that most Wayland compositors use OpenGL ES rather than real OpenGL is another example.


Heck, the Weston repo even has a whole directory for IVI (in-vehicle infotainment) support, which clearly indicates Wayland was never designed for the desktop.
Oh, and look at the vast amount of experimental compositors out there.

I think you got it the wrong way. As evidence I would say that Wayland works fine for the desktop, as mutter or KWin can say. I'm sure other window manager have similar programs.

The thing is: X11 works badly for embedded plaforms and wayland is a good way to, for the very first time, propose an somewhat standardized alternative to the dreaded direct /dev/fb access. So as a consequence wayland is seeing some success in the embedded world. So it's not that wayland is designed for the embedded world; it's that the embedded world seized wayland because it's way better than X11 for this specific use case.

[ezst036]

Hopefully this will lead (quickly) to the rise of an on screen keyboard for use on touch screens that works in nearly universal situations. Currently, this is a very sore spot.

[Britoid]

Nonsense rant:

It just feels to me that Wayland was never designed for real desktop usage, but rather just for embedded and stuff like that.
The lack of server-side decorations support is an example.
The fact that most Wayland compositors use OpenGL ES rather than real OpenGL is another example.


Heck, the Weston repo even has a whole directory for IVI (in-vehicle infotainment) support, which clearly indicates Wayland was never designed for the desktop.
Oh, and look at the vast amount of experimental compositors out there.

The lack of server side decorations isn't an example of why Wayland isn't desktop friendly. If that was the case compositors on other platforms wouldn't be desktop friendly either.

There's no reason to have the compositor drawing anything, it's just going to muck your compositor design and we see the reasons why KDE is so behind when it comes to their Wayland implementation compared to GNOME that stuck closely to the reference compositor.

Time to follow other platforms and keep window creation where it belongs, in the toolkit.

[Gusar]

I know I'm feeding the troll, but...

144Hz, that's exactly the problem, way too much depends on what the compositor has implemented and how well it is implemented. In the X world, you can mix and match various components from different projects to create something that works well, because there's standards that facilitate interoperability. Not possible in the Wayland world, because protocols that would allow it don't exist. And may not ever exist. The issue with "blame your compositor" is that you don't choose just the compositor, you're forced to also take the entire environment that comes bundled with the compositor. And if that environment doesn't suit you, well, tough luck.

And that's why people say Wayland is still not ready on the desktop even though it has widespread use in the embedded world, because on the desktop it's largely a "Gnome or bust" thing. And that's not a failing of other compositor developers, as you'll for sure try to spin it, it's a failure of Wayland to provide the required protocols. Some environments refusing to implement certain protocols that do already exist is another problem.


Britoid, the problem with your argument is that there is no "the toolkit". While some will see this as a negative, I see it as a plus that you aren't limited to the whims of a single toolkit's developers and even have the ability to not use a toolkit at all. Such a multi-toolkit environment can work well, it just needs well defined interfaces at a lower level.

[oiaohm]

144Hz, that's exactly the problem, way too much depends on what the compositor has implemented and how well it is implemented. In the X world, you can mix and match various components from different projects to create something that works well, because there's standards that facilitate interoperability. Not possible in the Wayland world, because protocols that would allow it don't exist. And may not ever exist. The issue with "blame your compositor" is that you don't choose just the compositor, you're forced to also take the entire environment that comes bundled with the compositor. And if that environment doesn't suit you, well, tough luck.

And that's why people say Wayland is still not ready on the desktop even though it has widespread use in the embedded world, because on the desktop it's largely a "Gnome or bust" thing. And that's not a failing of other compositor developers, as you'll for sure try to spin it, it's a failure of Wayland to provide the required protocols. Some environments refusing to implement certain protocols that do already exist is another problem.

Sorry but 144Hz is right most likely not for the reasons he thinks. And you need to remove your rose colour glasses about X11 because the compositor screws things over..

Lets say you need a desktop with full Accessibility features on Linux does not matter of it X11 or Wayland it is Gnome or bust. X11 does not provided the required protocols for Accessiblity yes its AT-SPI2 stuff that is between the assistance applications to dbus to the applications in use to get information. Issue is since X11 servers stopped rendering fonts the result has been client(by X11 define) rendered fonts that means asking what Text is on X button from X11 server tells you basically nothing. X11 protocol has trimmed it supported protocols to the point you are doing a hell of a lot around the outside of X11.

Does X11 protocols provide any interface for doing proper GPU accelerated screen capture again the answer is no. X11 mandates that all screen be merged into a single image this is highly not useful either if you have one monitor that is HDR and one that is not so another case of horrible no. What about mixing high dpi monitors with old standard monitors again the X11 protocol single screen idea comes back and be a nightmare..

Gusar once you start looking closer X11 has not been working well at all. Now fixing X11 is going to basically gut it. Like screen capture using pipe-wire allows using GPU accelerated screen capture. AT-SPI2 stuff is required for disabled interfaces

There are a lot of things when you look at X11 protocols made no sense to be mainline X11 protocols. Screen capture independent to the main X11 protocol is the way the pipewire screen capture is does make sense of that screen capture method can be replaced without having to alter core protocol. Just like those who wrote X11 protocol originally could not dream that we would have multi screen setups. Lot of Wayland choices that applications don't know where they are on screen or how they are being displayed is future proofing.

There have been different X11 screen compositors that have resulted in doing screen captures and getting black windows or missing missing windows.

Horrible as it is there are a stack of unfix-able problems with X11 only fix is basically scrap the protocol because too many features were welded into the core protocol without being individually replaceable. So you arguement about you can mix and match various components from different projects and make something that works well is in fact the problem with X11 protocol where its in fact blocking mixing and matching various components because too much was weld into the core protocol.

We need a core protocol with a collection of individual replaceable protocol parts and the core protocol must only contain the future proof stuff or close to future proof stuff. So the highly restricted Wayland core protocol makes sense. Now getting all the individual replaceable protocol parts done that is one hell of a job.

[Gusar]

Good post oiaohm, you've listed a few genuine weak points of X11. But that still does not address the issues of Wayland, issues that do have solutions in X - lack of interoperability, requiring tight coupling between compositor and environment - panel/task manager, desktop manager, screen configuration, input configuration, etc, etc. In Wayland, input and screen configuration is limited by what the compositor devs decided to expose in their environment's configuration panel. There's no xinput or xrandr, environment-independent command-line tools that expose *everything* the underlying protocol is capable of.

Then, only recently have wlroots devs written a protocol that allows communication between window management and panels/task managers, so that you're not limited to the panel/task manager that the compositor is coupled with. Now the question becomes, will the protocol see widespread adoption? The Weston panel is very basic, use of that protocol would allow you to use a different panel with Weston. Will this become a reality, will Weston get support for that protocol? Will Gnome and KDE? I kinda doubt it. So you'll be limited to compositors that do implement the protocol, basically wlroots-based ones. Limitations like that all over the place.

[Gusar]

Facts are not trolling. But whether what you're spouting is a "fact" is a matter of debate. You did exactly what I said you would, pin the problem on compositor devs rather than the state and completeness of the protocol. And you did nothing to address the main issue, which is that it isn't just about the compositor, but that you're forced to also take the entire environment that comes with it. How about that fact, hmm?

[oiaohm]

Good post oiaohm, you've listed a few genuine weak points of X11. But that still does not address the issues of Wayland, issues that do have solutions in X - lack of interoperability, requiring tight coupling between compositor and environment - panel/task manager, desktop manager, screen configuration, input configuration, etc, etc. In Wayland, input and screen configuration is limited by what the compositor devs decided to expose in their environment's configuration panel. There's no xinput or xrandr, environment-independent command-line tools that expose *everything* the underlying protocol is capable of.

Xinput is a good question. Input is one of these areas that have changed a lot over the years. In fact complete access to xinput you in fact want to take back. Lets say you have 2 applications with Xinput register to receive the same short cut key what one gets the short cut. Under Xinput with X11 it is serous-ally luck of the draw its everything between first one loaded or second one loaded to o my god both yes generally first loaded wins but its not absolute certainty. Next with libinput lots of your input stuff has been moved to udev controlled there are a lot of xinput options that are now no-ops..

Wayland highly restrictive base design on input is correct as it fixes up these short cut issues even allowing short cuts to be properly changed by the compositor based on active window instead of the current do you fill lucky punk with Xinput.

Xrandr is also a good way to cause many different X11 compositors to crash by changing to a mode they don't support so this need to be changed to compositor controlled so compositor can veto a gpu change they don't support so users interface does not crash. Yes the X11 design of Xrandr that it can go straight past the compositor is a really bad thing.

Then, only recently have wlroots devs written a protocol that allows communication between window management and panels/task managers, so that you're not limited to the panel/task manager that the compositor is coupled with. Now the question becomes, will the protocol see widespread adoption?.

X11 protocol did not come at first with a panel/task manager protocol as first. Next you have never read the X11 protocol implementation either instead just presume it working right I guess. Yes you have just pointed to another broken area of X11. X11 panel implementation is stupid dangerous. Application gets to tell X11 what PID(process id) number the application is. << Read that. So lets say a application decided to be a ass an tell X11 server that its PID number is the Windows manager/X11 compositor instead of it own now you close the application by panel under X11 get ready to be logged out because you just killed your X11 windows manager/compositor instead.

The section X11 protocol that allowed using third party panel at all was added 15 years after X11 protocol creation and it still designed horrible wrong. Cause of X11 protocol for panels being design horrible wrong is attempting to be totally platform neutral.

Wayland protocol has in fact implemented at this point all of X11 protocols features that worked properly and safely. Every other missing feature need to go back to the drawing board and be redone some other way as the old X11 method is broken to hell.

Most people are clueless that when they are listing missing features from Wayland that X11 has they are also in fact listing areas of X11 that causes crashes and is designed poorly.

There is more than a few X11 weak points if you pick a protocol section in use on your current day Linux desktop at random from X11 protocol you have a 70% under closer inspection that is defective. X11 protocol is more weak points than good stuff. Restoring all the functionality of X11 in way that is safe and stable is not a fast or simple process. Yes wayland protocol to redo the complete lot was the last thing the X.org developers wanted to-do they just got the point that they had worked out too much of the X11 protocol is broken and if you fix the X11 protocol server side the existing X11 applications will break.

Its horrible right to here that wayland protocol is not a optional thing Wayland work is really part of something that must be done. Of course getting all the features added back to Wayland protocol or added in as third party items is going to take time. Some of the add in like the pipewire screen capture will work under X11 so allow masking over some of the X11 design defects but even if you mask over everywhere you can with X11 you will not fix that the core is basically busted. So its really wayland or bust at this stage if people don't like wayland they will have to implement some other alternative to Wayland as X11 protocol is serous-ally broken to the point of no repair is possible.

Of course we could see like a case were the wlroot based stuff forks away from the core wayland stuff and we have a fight out between core Wayland and wlroot stuff to see what future winner we have. Even a fight like that is going to land us with something better designed than X11 protocol.

Biggest problem X11 protocol is a collection of parts over the years that developers added what ever they felt like without considering future or if what they were doing was secure now you have a stack of applications depending on X11 protocol behaving badly. End users have got use to using X11 in ways that they don't walk into the defects of the protocol most of the time.

Have you had the one where copy paste under X11 gets stuck because some application has locked the copy paste buffer before? Yes there are a lot of minor bugs like this one that X11 protocol allows to happen that users end up just learning to work around when they hit them as well that are fixed in wayland.