Add xkb support

[legionus]

It's very nice to be able to use the keymap from the xkbcommon project. Using xkbcommon a keymap is created and then converted to a kernel keymap as far as possible.

This support does not replace regular keymaps. There are no plans for this. The command looks like:

loadkeys --xkb-layout="us,ru,fr" --xkb-options="grp:caps_toggle"

This implementation is inspired by the console-setup project. Many thanks to Anton Zinoviev for help.

At the moment compose is not implemented. This is because xkbcommon does not provide an API for iterating over a compose table. I hope to solve this problem in the future.

[wismill]

What is the status of this feature? Do you need some help?

At the moment compose is not implemented. This is because xkbcommon does not provide an API for iterating over a compose table. I hope to solve this problem in the future.

FYI this is implemented since libxkbcommon 1.6, see the corresponding release notes.

[legionus]

What is the status of this feature? Do you need some help?

Actually yes, I need help. I really miss the testing. Since keymap is created on the fly it is very hard to test that the conversion works for all languages and switch combinations.

The other problem is compose. I have not been able to figure out how to solve this problem yet.

FYI this is implemented since libxkbcommon 1.6, see the corresponding release notes.

I know. I'll use this in the next version of my patch: https://github.com/legionus/kbd/commits/xkbcommon-v3/

The problem with compose is that libxkbcommon provides a single huge tree of all compose of any length for all languages. But kernel only supports 256 entries of length 2. The difficulty is how to select the necessary compose entries. I added a few tricks to eliminate the “extra” compose, but it still wasn't enough.

I can explain in more detail if you're interested in diving into it.

[wismill]

I really miss the testing. Since keymap is created on the fly it is very hard to test that the conversion works for all languages and switch combinations.

Could you indicate me how to run the tests? I am using podman with latest Ubuntu, but there is an error with unreachable /dev/tty60. Then I would need some guidance, e.g. what existing test could I adapt? I am not much familiar with AutoTools.

The problem with compose is that libxkbcommon provides a single huge tree of all compose of any length for all languages. But kernel only supports 256 entries of length 2. The difficulty is how to select the necessary compose entries. I added a few tricks to eliminate the “extra” compose, but it still wasn't enough.

Let’s check if I understand the current tricks:

1. Discard sequence of 3+ keysyms
2. Discard sequence with keysyms than cannot be converted to kbd
3. Discard if result keysym than cannot be converted to kbd

First comment: the result XKB keysym is optional, so you better check:

1. Resulting string, if any, then try to convert it to a kbd keysym directly or use xkb_utf32_to_keysym() then your translation table.
2. Else use the result XKB keysym and convert it.

Secondly, any sequence than cannot be typed on the current layout can be dropped as well. Unfortunately there is no API like e.g. xkb_keymap_has_keysym(), so you would have to implement it.

Then it may still not be enough to reduce the compose table, so last resort is to provide a score to each keysym in the keymap in function of its level and/or group:

• keysym on higher levels are less likely to be used.
• if a keysym is on multiple levels, keep the score of the lowest level.
• this individual keysym scores are used to compute the score of each Compose sequence as the product of both keysyms’ scores.
• if there are too many sequences, drop the ones that are less likely to be used.
• I would add a “security” to always keep sequences starting with a dead_* and having its sequence on the first 2 levels.
• Maybe sequences that result in a keysym already present in the keymap can be dropped as well, or at least have a bad score.

This would require an intermediate storage, to be finally converted to kbd Compose table once it fits into 256 sequences.

Then I would test this on various layouts, in particular those with many dead keys, and see if these tricks are good enough.

[legionus]

Could you indicate me how to run the tests? I am using podman with latest Ubuntu, but there is an error with unreachable /dev/tty60.

Some of the tests may be harmful to your system. Since such tests truly load keymap, such tests will need real root and such tests cannot be run in podman.

I made them to execute these tests in github actions. You can clone my repository and use the master or for-master brunch to check your commits.

The rest of the tests can be run make check from a normal user. These tests will not cause any problems to the system.

Then I would need some guidance, e.g. what existing test could I adapt? I am not much familiar with AutoTools.

I'm not sure I understand the question.

I don't know what tests you want to add, but you can start by adding them to tests/utils.at. There is not much code in this file and it seems to me to be a good example of how to test a utility in the simplest case.

You can read about autotests here:

https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Using-Autotest.html

[legionus]

The problem with compose is that libxkbcommon provides a single huge tree of all compose of any length for all languages. But kernel only supports 256 entries of length 2. The difficulty is how to select the necessary compose entries. I added a few tricks to eliminate the “extra” compose, but it still wasn't enough.

Let’s check if I understand the current tricks:

1. Discard sequence of 3+ keysyms

2. Discard sequence with keysyms than cannot be converted to `kbd`

3. Discard if result keysym than cannot be converted to `kbd`

It's not all tricks. I remember the keys that are used in the keymap and look for composes that use those characters (see used_code).

https://github.com/legionus/kbd/blob/xkbcommon-v3/src/xkbsupport.c#L712-L727

But even that's not enough. I faced a problem that for example for russian in keymap is greek diacritics.

First comment: the result XKB keysym is optional, so you better check:

1. Resulting string, if any, then try to convert it to a kbd keysym directly or use `xkb_utf32_to_keysym()` then your translation table.

2. Else use the result XKB keysym and convert it.

You're probably right. I don't know xkb very well and my knowledge is only from what I could understand from their library code. So if you say it's better, I believe you :)

Secondly, any sequence than cannot be typed on the current layout can be dropped as well.

I'm already doing it.

https://github.com/legionus/kbd/blob/xkbcommon-v3/src/xkbsupport.c#L582

Then it may still not be enough to reduce the compose table, so last resort is to provide a score to each keysym in the keymap in function of its level and/or group:

* keysym on higher levels are less likely to be used.

* if a keysym is on multiple levels, keep the score of the lowest level.

* this individual keysym scores are used to compute the score of each Compose sequence as the product of both keysyms’ scores.

score is probably a good idea.

* if there are too many sequences, drop the ones that are less likely to be used.

I don't really understand how to formalize this.

* I would add a “security” to always keep sequences starting with a `dead_*` and having its sequence on the first 2 levels.

* Maybe sequences that result in a keysym already present in the keymap can be dropped as well, or at least have a bad score.

This would require an intermediate storage, to be finally converted to kbd Compose table once it fits into 256 sequences.

Then I would test this on various layouts, in particular those with many dead keys, and see if these tricks are good enough.

Great! Ping me if you need anything.

[wismill]

Some of the tests may be harmful to your system. Since such tests truly load keymap, such tests will need real root and such tests cannot be run in podman.

Wow, that’s good to know! So it requires true virtualization in order to be harmless.

Then I would need some guidance, e.g. what existing test could I adapt? I am not much familiar with AutoTools.

I'm not sure I understand the question.

What I mean is that instead of creating tests from scratch, how could I start with existing tests and update its source keymap so that it load XKB ones. There are many tests and I am not familiar with neither the code base nor AutoTools, so copying and adapting code is easier to start with.

I'm already doing it.

Right, I missed it. It was worth to check my understanding.

if there are too many sequences, drop the ones that are less likely to be used.

I don't really understand how to formalize this.

What about: sort sequences by score, then repeatedly drop the remaining sequence with the worst score until the table fits in kbd?

As for the score computation itself, let me take some time to design it. But the rough idea is:

1. Set initial keysym score at 2 * level, level being the lowest level it is found.
2. Divide by 2 if it’s a dead_* on the first 2 levels.
3. Sequence score is the product of the keysym in the sequence (with the result keysym).
4. The higher the score, the less likely is the sequence.

I also considered using e.g. (1 << level), but it would require to handle the very unlikely edge case of 15+ levels (if we use 32 bits int).

[legionus]

Some of the tests may be harmful to your system. Since such tests truly load keymap, such tests will need real root and such tests cannot be run in podman.

Wow, that’s good to know! So it requires true virtualization in order to be harmless.

The e2e tests make real queries to the kernel. Since all work with keymap is ioctl which changes the internal state of the kernel, it is very hard to simulate this.

But these tests don't run by default and I've marked them down:

AT_SKIP_IF([ test "$SANDBOX" != "priviliged" ])

Then I would need some guidance, e.g. what existing test could I adapt? I am not much familiar with AutoTools.

I'm not sure I understand the question.

What I mean is that instead of creating tests from scratch, how could I start with existing tests and update its source keymap so that it load XKB ones. There are many tests and I am not familiar with neither the code base nor AutoTools, so copying and adapting code is easier to start with.

Since xkbsupport is a work in progress I added some code there that helps in debugging.

You can use LK_XKB_DEBUG env variable to enable it. If it is set to any value, it will print the information in the xkb keymap walkthrough (see xkeymap_walk_printer). If it is set to "1", the entire xkb_compose_table will be printed (see xkeymap_compose_printer). If it is set to "2", only the compose that will be used for our keymap.

I also added an environment variable LK_DUMPKEYS to be able to dump the keymap that was produced during the conversion process.

You can use loadkeys --parse to avoid loading keymap into the kernel and not break anything.

So a combination of variables and option will allow you to debug new keymap.

if there are too many sequences, drop the ones that are less likely to be used.

I don't really understand how to formalize this.

What about: sort sequences by score, then repeatedly drop the remaining sequence with the worst score until the table fits in kbd?

I like the idea. We could try it.

As for the score computation itself, let me take some time to design it. But the rough idea is:

1. Set initial keysym score at `2 * level`, `level` being the lowest level it is found.

Perhaps we can use xkb layout index as well somehow.

2. Divide by 2 if it’s a `dead_*` on the first 2 levels.

3. Sequence score is the product of the keysym in the sequence (with the result keysym).

4. The higher the score, the less likely is the sequence.

I also considered using e.g. (1 << level), but it would require to handle the very unlikely edge case of 15+ levels (if we use 32 bits int).

If I remember correctly xkb supports only 4 levels.

[wismill]

So a combination of variables and option will allow you to debug new keymap.

About the tests: it would be great if we had golden tests, i.e. parsing then dumping keymaps (check roundtrip?) and compare the output with a keymap file. All this with possibly not requiring actual changes of the system console.

Set initial keysym score at 2 * level, level being the lowest level it is found.

Perhaps we can use xkb layout index as well somehow.

I thought about this too, but there is no way to know the balance between the layouts. I would say that for console, the first layout is probably much more used, but I have no hard evidence. So I would refrain to use this until we see actual issues, despite the tricks to reduce the Compose table mentioned above.

If I remember correctly xkb supports only 4 levels.

The XKB protocol supports:

• up to 4 layouts/groups (same thing)
• 8 independent modifiers
• up to 64 levels for each layout on each key.

However, libxkbcommon supports:

• soon up to 32 layouts. But while such edge case has to be handled here, I do not think anyone would reach much more than 10 layouts, and that’s still does not seem a realistic use case for the console.
• up to 32 independent modifiers.
• currently up to 4096 levels. It is quite arbitrary but we do not expect someone to ever get close. But There is a use case for built-in dead keys that uses custom modifiers and this can make the levels count increase quickly. Such keymap would probably be generated programmatically though and I know none at the moment.

[legionus]

About the tests: it would be great if we had golden tests, i.e. parsing then dumping keymaps (check roundtrip?) and compare the output with a keymap file. All this with possibly not requiring actual changes of the system console.

I have similar test.

https://github.com/legionus/kbd/blob/master/tests/libkeymap.at#L121-L134
https://github.com/legionus/kbd/blob/master/tests/helpers/libkeymap-dumpkeys.c

However, libxkbcommon supports:

* soon up to 32 layouts. But while such edge case has to be handled here, I do not think anyone would reach much more than 10 layouts, and that’s still does not seem a realistic use case for the console.

* up to 32 independent modifiers.

* currently up to 4096 levels. It is quite arbitrary but we do not expect someone to ever get close. But There is a use case for built-in dead keys that uses custom modifiers and this can make the levels count increase quickly. Such keymap would probably be generated programmatically though and I know none at the moment.

Ah, I see.