Running on bare GPU on an appliance and also via winit on desktop?

[barries]

We have a native eframe app based that runs quite well on Linux and Windows, and we'd like to add the capability for it to run on an embedded linux tablet PC with no windowing system as a full screen app that uses the GPU directly (i.e. without X11). This allows us to demo and develop normally, but run on a stripped down OS. It's a medical device, so the less software on the tablet the better, where "better" means more reliability and security, with a nice dash of faster boot time for flavor.

How would we approach adding support for a non-windowing, bare GPU full screen mode on Linux if X11 isn't present at runtime? Or, failing that, a separate build configuration?

Thanks!

[YgorSouza]

I think the question is essentially whether there is an existing integration that works on embedded linux. But I don't know the answer, since I haven't worked with that platform and don't know its constraints. It should be noted that egui doesn't support no-std. Issue #2755 asked for it, but it was closed because no one at the time had a concrete use case. That makes it impossible to use egui in bare metal applications (except maybe ESP32), but I don't know if it's a problem for embedded linux.

[barries]

This is a full PC and has, for example, libc.so.6, so no need for nostd, though thanks for pointing it out.

The only reason not to add a windowing system or compositor is to reduce complexity, image size, vulnerability surface, etc. We don't need one--this app is full screen and is the only app.

So, being new to this, I'm wondering if we can configure (at startup, if on Linux and DISPLAY is empty) eframe to use a backend that doesn't need winit (like wgpu + OpenGL ES? not sure because new to this) , configuring eframe and/or winit to run one full screen "window" without having to talk to, e.g. X11 or Wayland...

This feels like what running under WASM must be like--no windowing system, just a (full screen) rectangle egui can draw on via wgpu, etc., and using system APIs instead of WASM apis to get touch input and, perhaps one day, keyboard input.