I'm one of the resident Wayland critics, and one of my most painful Wayland experiences was in a similar embedded/Yocto setting. A kiosk-style device where I had a perfectly working system for X. Sometimes there'd be one program drawing to the screen, sometimes two or three, and they very easily arranged themselves on the screen in the right position/size.
Then I had to port this stuff to a different hardware platform that only supported Wayland. The programs could no longer place themselves where they wanted to, and a simple helper/manager script I had based on xdotool of course also no longer worked. As an extra bonus, on the X variant I'd use x11vnc for maintenance purposes to find out exactly what was being shown, which also broke down on Wayland. Took weeks to get things ported, leaving a few rough edges that were worse than on X, and not a single thing that was better for the system developer's or the end users from Wayland.
I'm sure some of that has improved since. One of my first attempts there was to use ivi-shell, but occasionally I needed to show a browser on the screen and at that time Chromium had too many random crashes under Weston.
> I don’t know (yet) where this change happens. This rules out this option for the time being.
This is the actual problem. I have used yocto for close to a decade. This conclusion is wrong, the fix is right there. The rest of the article is superfluous.
Their solution works, and I’ve resorted to things like that before, but it is not “the most correctestest way” because, in my experience if you need to use sed in a recipe you’re way off the reservation and there is usually a “better” way.
It is pretty emblematic of issues in yocto, though. It has an impressive capability for action-at-a-distance, which is at once powerful and very difficilt to inspect.
As per the article, Yocto runs GUI applications as root, and you need workarounds to run them as non-root.
Running arbitrary GUI applications as root is such a huge red flag that I'd suggest just looking at another distribution instead of resorting to workarounds.
Yocto doesn't run GUI applications, it's a framework to make your own distro. The fact that many users are too lazy to create a user to run their application as, speaks of the embedded space in general rather than Yocto in particular.
> I'd suggest just looking at another distribution
You won't find one. With many vendors, it's the only option.
It's designed for embedded systems: it's not so much arbitrary GUI applications as a specific one, in fact the OS is more like a library for a single application than a traditional server or desktop OS. It's not that much unlike a single-process docker container, one where it can be quite hard to draw meaningful security boundaries within it. (you can, of course, run stuff as different UIDs, but generally the application needs to have permission to do basically everything on the system, one way or another).
I'm one of the resident Wayland critics, and one of my most painful Wayland experiences was in a similar embedded/Yocto setting. A kiosk-style device where I had a perfectly working system for X. Sometimes there'd be one program drawing to the screen, sometimes two or three, and they very easily arranged themselves on the screen in the right position/size.
Then I had to port this stuff to a different hardware platform that only supported Wayland. The programs could no longer place themselves where they wanted to, and a simple helper/manager script I had based on xdotool of course also no longer worked. As an extra bonus, on the X variant I'd use x11vnc for maintenance purposes to find out exactly what was being shown, which also broke down on Wayland. Took weeks to get things ported, leaving a few rough edges that were worse than on X, and not a single thing that was better for the system developer's or the end users from Wayland.
I'm sure some of that has improved since. One of my first attempts there was to use ivi-shell, but occasionally I needed to show a browser on the screen and at that time Chromium had too many random crashes under Weston.
> I don’t know (yet) where this change happens. This rules out this option for the time being.
This is the actual problem. I have used yocto for close to a decade. This conclusion is wrong, the fix is right there. The rest of the article is superfluous.
Their solution works, and I’ve resorted to things like that before, but it is not “the most correctestest way” because, in my experience if you need to use sed in a recipe you’re way off the reservation and there is usually a “better” way.
It is pretty emblematic of issues in yocto, though. It has an impressive capability for action-at-a-distance, which is at once powerful and very difficilt to inspect.
As per the article, Yocto runs GUI applications as root, and you need workarounds to run them as non-root.
Running arbitrary GUI applications as root is such a huge red flag that I'd suggest just looking at another distribution instead of resorting to workarounds.
Yocto doesn't run GUI applications, it's a framework to make your own distro. The fact that many users are too lazy to create a user to run their application as, speaks of the embedded space in general rather than Yocto in particular.
> I'd suggest just looking at another distribution
You won't find one. With many vendors, it's the only option.
It's designed for embedded systems: it's not so much arbitrary GUI applications as a specific one, in fact the OS is more like a library for a single application than a traditional server or desktop OS. It's not that much unlike a single-process docker container, one where it can be quite hard to draw meaningful security boundaries within it. (you can, of course, run stuff as different UIDs, but generally the application needs to have permission to do basically everything on the system, one way or another).
> Running arbitrary GUI applications as root is such a huge red flag
Yes, but...
For many embedded applications, getting any sort of execution on the GUI thread/process is game over anyways.
idk what this says about anything