Embedded doesn’t need wayland nor X.org. These two things implement desktop managers. Why would you run a desktop manager on a computer that runs one program only?
For embedded, drm/kms is IMO better level of abstraction to base on.
It only takes couple pages of code to get yourself a full-screen DRM-backed EGL context.
I did it a few times for various Linuxes using Broadcom and Mali GPUs.
I’ve evaluated Flutter couple years back, chose not to. I picked NanoVG (later on I’ve patched it a bit improving fonts https://github.com/Const-me/nanovg ), compiled a shared library, consumed from .NET Core, and implemented a GUI in C#, with animated transitions and such. Both me and my client were happy with the outcome.
Here’s why I was reluctant to choose Flutter.
1. New programming language with Flutter being the only use case. The language looks nice by itself. However, this means no library ecosystem, and non-trivial chances to waste lots of time working around bugs in language, compiler and runtime.
2. I don’t like Skia underneath, too much legacy and overall CPU-centric design. Marketing materials tells how they using GL and Vulkan for performance. Source code tells opposite story, they’re doing a lot of graphics on CPU. Unless the stuff is already implemented by some knowledgeable people outside ad. tech, e.g. MS Direct2D or nVidia’s NV_path_rendering. To be fair, Skia appears to be able to consume either of them, but none was available for my Linux target.
It depends. In this particular case, the demo seems to contain a launcher which allows to start multiple apps and switch between them. A window manager sounds preferable in this case.
Also, Flutter handles all of the Wayland/X11 implementation details. In this case it's less work to just use the already-existing backend.
> the demo seems to contain a launcher which allows to start multiple apps and switch between them.
If the count of apps is small, and all of them are written by you, it's not terribly complicated to pass exclusive access to display across processes.
Only becomes too complicated if you want many apps updating their windows at the same time, or support third-party apps.
> it's less work to just use the already-existing backend.
Short term, yes. Short term, a desktop OS and Electron is even less work.
Long term, desktop environments are huge, and you'll be dealing with long tail of issues related to their features. Each time they break something, you might need to pay hundreds of dollars just to ship the equipment to you for repairs and back.
When a desktop environment is physically missing from the system, along with all related GUI software, services, and libraries, it leaves much less things to break. Users can connect a USB/BT keyboard or mouse, no one gonna handle the events. They can do rude multitouch gestures on the touch screen, nothing unexpected gonna happen either.
> it's not terribly complicated to pass exclusive access to display across processes.
You're just starting to re-invent the Wayland protocol. You need to pass input too… and more of Wayland re-invented.
>desktop environments are huge
Weston or Cage doesn't really qualify as huge.
Also, I think you underestimate the work to write a program using KMS and libinput. It's pretty easy to write a toy app, but writing a solid framework is something else.
> You're just starting to re-invent the Wayland protocol
I think the main feature of WL is simultaneous multi-tasking. If you don't need that, a desktop is redundant. That's why Google made their own proprietary DM for android instead of adapting what Linux had.
> You need to pass input too
I haven't tried but I think multiple processes are fine reading from the same /dev/input/event[n] at the same time, they'll just get the same events. Therefore they may process or ignore these based on whether they rendering or not.
> I think you underestimate the work to write a program using KMS and libinput
Totally agree with your view. "It only takes couple pages of code to get yourself a full-screen DRM-backed EGL context." - interesting, I've been wanting to get rid of the X server and use opengl or vulkan on a mali GPU fullscreen without needing X or wayland. do you have example code online somewhere for this?
For embedded, drm/kms is IMO better level of abstraction to base on. It only takes couple pages of code to get yourself a full-screen DRM-backed EGL context. I did it a few times for various Linuxes using Broadcom and Mali GPUs.
I’ve evaluated Flutter couple years back, chose not to. I picked NanoVG (later on I’ve patched it a bit improving fonts https://github.com/Const-me/nanovg ), compiled a shared library, consumed from .NET Core, and implemented a GUI in C#, with animated transitions and such. Both me and my client were happy with the outcome.
Here’s why I was reluctant to choose Flutter.
1. New programming language with Flutter being the only use case. The language looks nice by itself. However, this means no library ecosystem, and non-trivial chances to waste lots of time working around bugs in language, compiler and runtime.
2. I don’t like Skia underneath, too much legacy and overall CPU-centric design. Marketing materials tells how they using GL and Vulkan for performance. Source code tells opposite story, they’re doing a lot of graphics on CPU. Unless the stuff is already implemented by some knowledgeable people outside ad. tech, e.g. MS Direct2D or nVidia’s NV_path_rendering. To be fair, Skia appears to be able to consume either of them, but none was available for my Linux target.