Update #1: Too many layers

March 6, 2016

I've been digging, trying to implement the loading of xkb files on Gala, turns out that stuff has been abstracted several layers deep, which makes it difficult to experiment with this stuff without bothering people upstream and having to make changes and coordinate with several different projects (and teams). Because what I've been trying to do is rather experimental, I don't want to just create patches for a lot of projects and argue they should merge my code because I think it will be good (I don't even know that myself), instead what I've been trying to do is implement stuff and see how well it works out and if I really think it's useful for others. I'm also looking to add the least amount of code to Gala, so rewriting the whole keyboard handler seems like the most extreme solution, and I am trying not to come to this.

I will try to explain briefly all the layers involved with keyboard handling on Gala, before in place of this I had about 3 paragraphs trying to do so but they were mostly just ranting about the excessive abstractedness of the whole thing, but in the end I don't think that's relevant for the discussion and I don't have a global understanding of all projects to question decisions made by others, so I will just point out important details I've seen I need to get things done. For this I will just show a diagram of how systems interact (it's important to note that this relationships are only related to keyboard handling I have no idea how these systems interact for example for graphics).

There are 5 projects here, arrows represent where some project calls a library from someone else. Gala is written in Vala which means calling C code from here is not a trivial task. Mutter and Clutter are written in C but using GObject and Glib, this both ease calling it from Vala code but because they are in the end just C code they can easily call C libraries like XLib, or libxkbcommon. This makes them our most accessible interfaces to lower level interfaces from Gala. Also a sidenote about Mutter is that it aims to be both compatible with Wayland and X11 so it has two backends to support this, but it also means we can't expect Wayland specific functionality to be provided from it.

I think Gala uses Mutter's X11 backend but I don't know how can I test this to be sure. The problem of this is that the API provided by Mutter to set the keyboard layout only uses the RMVLO description which seems to be a legacy interface that comes from the fact that this is what setxkbmap does and was the easiest to copy, as opposed to what xkbcomp does which implied understanding the xkb description specification and how to upload it to the X server (both approaches in the end invoke the xkb compiler every time a layout switch happens which is one of the issues I'm trying to solve). Because Mutter cares about providing functionality available only to X11 and Wayland it's unlikely that an API that uses libxkbcommon to load xkb files will be provided.

Although Mutter with it's native backend does use libxkbcommon to change the keyboard layouts, when trying to call the function that does this from Gala I stumbled upon several issues, the most important one seems to be that X11 grabs input devices and does not let Clutter listen to events, an assertion on the library fails saying “Clutter is not the device manager”. Also, this interface is not part of the API stability guarantees which on one hand could bring some problems in the future, but even more frustratingly: makes them completely unusable from Vala code, because as it turns out outputting #define symbols through Vala is impossible (we just need to add the line #define CLUTTER_ENABLE_COMPOSITOR_API ) and even worse do it before the #include directive for the library. So at this point using Clutter's keyboard handling on the native backend becomes unfeasible.

So, what do we do now? Well I've come to the conclusion that right now the simplest approach is to make functionality to load libxkbcomon's keymap format into X11 directly on Gala. Currently for testing what I did before I created a .vapi file by hand for libxkbcommon so I can now use it from Gala, I haven't seen bindings for XKBLib so I may have to do this next, we'll see how that all goes. If I'm successful with this then maybe it would help Mutter to include an API for this, so I could upstream some of it if it would actually work for someone else.

As a minor side rant, I have to say that I wished Gala would have a more monolithic design and would not impose OOP through Vala in the way it does. I mean, the most complex, big and by far successful free software project is the Linux Kernel and it's also a huge monolithic piece of code, I think segregating functionality around several projects adds a lot of overhead for people trying to help. It's true that the codebase would grow substantially, but I think having code that actually does something as opposed to glue code would ease fixing problems and trying out new things.