Feasbility of an embedded backend?

I think that an embedded backend (based on libDRM and kernel modesetting APIs) would be very useful as currently their are only 2 options for embedded: qt and flutter. I’m happy to attempt to build an embedded backend with the help of GitHub - CuarzoSoftware/SRM: Simple Rendering Manager, but I would like some pointers such as, does GTK already have a way to build backends? If so are their any examples of this and do I have to build the code into GTK, or can I build it into a separate project? ETC. Thanks for the help.

1 Like

GTK already has multiple windowing system backends:

Writing a native framebuffer windowing system backend is perfectly possible, assuming that every dependency is going to be satisfied. You can look at the existing backends to have an idea of the requirements of GTK when it comes to functionality provided by a windowing system.

Nobody is working on this, so if you want to write a backend, feel free to work on it.

Windowing system backends can only be in-tree.

1 Like


Alternatively, I heard about the Mir project, which is a Wayland server targeting embedded devices.

Could it fit your needs?

1 Like

IMO, there has to be a very good case made for why this is going to better than a simple Wayland server, considering the amount of things from Wayland that will need to be reimplemented. That library is not doing any input handling which IMO is the most complicated part. And likely it will need a form of window management implemented too, to get dialogs and popups to work correctly.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.