Raspberry Pi OS Adds Experimental Wayland Support

[Waethorn]

The Honeycomb board is pretty close (I have a Radeon in the PCIe slot on mine), but the ARM maintainers have been dragging their feet on allowing merging important commits. Also, when I ordered it, it took many months to arrive.

https://www.phoronix.com/forums/foru...83#post1313883

So....no, then. By all accounts, the Raspberry Pi 4 is also "pretty close" but the same lack of hardware vendor support applies. So what would be a few weeks for support between the introduction of a new x86 processor/SoC to Linux kernel support (and they start submitting intro hardware support change requests on pre-release hardware) turns into years after launch for ARM. How can you build hardware and not have working software from the start? It's useless without it.

[Nuc!eoN]

Would wayland also work on a Raspberry Pi 1 Model B ?

[DanaG]

So....no, then. By all accounts, the Raspberry Pi 4 is also "pretty close" but the same lack of hardware vendor support applies. So what would be a few weeks for support between the introduction of a new x86 processor/SoC to Linux kernel support (and they start submitting intro hardware support change requests on pre-release hardware) turns into years after launch for ARM. How can you build hardware and not have working software from the start? It's useless without it.

Don't blame the vendor, blame the ARM maintainers who have been blocking them for over a year! Apparently they've had multiple rounds of: submit patch, maintainer requests trivial change, push another version, another trivial change, push another, maintainer complains about a nitpick that was there in v1 of patch yet wasn't mentioned before. Also, some cases where all they want to add is a simple ACPI property like AMD did for the Steam Deck, but somehow the same approach isn't good enough for the ARM maintainers.

There's also even a bug in memcpy on Cortex-A72 that corrupts device memory writes, but that fix has been getting crickets chirping, too.
I wonder if it would help to have Phoronix write an article about the stuff?

This is the primary developer working on the stuff; check out his conversations for how roadblocked the work has been.
https://twitter.com/linux4kix/status...Cyga36jdwoAAAA

https://twitter.com/linux4kix/status/1384117286236155912

[dragon321]

Yeah, for sure useful functionality is a terrible idea.

This mentality is what prevents Wayland from being taken further. If security is a concern, a permission system wouldn't hurt.

It's not functionality that is terrible idea. It's actual implementation that is terrible idea. X11 let's you do all these features because every client have free access to the other clients and can grab input or output without any restrictions. While it can be used for useful functionality it can be also easily used for other things, including malicious software. It also difficult to control. For example there is no option to block X11 application from getting keyboard input but allow it to grab other application contents in the same time. You have to choose between isolating X11 application completely and letting it to do everything that every other X11 application can do.

Of course I'm not saying that these features shouldn't be implemented in Wayland. These are useful and important features that Wayland should provide. But obviously it shouldn't be implemented in the same way as X11 does. They should be available in the way that lets compositor and user easily control and disable selected features without breaking others. Allowing selected applications to have free access to others and imitating X11 protocol is also not very good solution. It would make something like X11 with extra steps. Just like on X11 it would also make permission control difficult.

[jacob]

Placing the ability to set hotkeys in the same privilege level as "creating files in a direct way" is like placing the ability to bake a cake in the same privilege level as being able to manufacture an atomic bomb.

In both cases they are a mis-feature that is a security and integrity liability and shouldn't be allowed by the OS. That something was possible previously doesn't mean it's good, in this case it means that it was a design mistake that is now corrected at long last. Wayland has never promised that everything that existed under X11 would be preserved. To the contrary, one of its explicit goals of is to make sure that the "features" of X11 that have been shown to be harmful are no longer possible.

...and therefore lead to fragmentation, requiring developers to duplicate a lot of code to handle every possible compositor's way of doing data query/global hotkeys (if the compositor even provides a way to do so) when it was all possible with one piece of code under X11.

If you fear fragmentation, blame those who can't resist always reinventing the wheel with their me-too compositor of the week.

Nope, not really. Just look at these multiple issues regarding the lack of a global hotkeys protocol and the proposed all-different incompatible solutions.

Again, that doesn't make it a worthwhile complaint. The idea that global hotkeys should somehow be implemented by a separate program that the compositor knows nothing about (and vice versa) is simply terrible design. If people want global hotkeys, the right way to do it is as a compositor extension. And if someone things that there 'must" be dozens of incompatible compositors... well, their loss.