1 keysym 2 keycodes

[sahinf]

Hi,

How should a duplicate keycode->keysym mapping be handled?
This thread says that it's not 100% reliable to convert keysyms to keycodes.

In my case, I am using the SwayWM with the following evdev layout

default xkb_keycodes "evdev" {
...
	<PRSC> = 107;
...
...
	// Extended keys that may be generated on "Internet" keyboards.
	// evdev has standardize names for these.

	<LNFD> = 109;	// #define KEY_LINEFEED            101

	// Key codes below are autogenerated
	<I120> = 120;		// #define KEY_MACRO               112
...
...
	<I218> = 218;		// #define KEY_PRINT               210
...
}

But both keycodes 107 (PRSC) and 218 (<I218>) get mapped to the keysymbol for XKB_KEY_Print 0xff61=65377

(gdb) print xkb_state_key_get_one_sym(config->keysym_translation_state, 107)
$8 = 65377
(gdb) print xkb_state_key_get_one_sym(config->keysym_translation_state, 218)
$9 = 65377
(gdb) bt
#0  cmd_bindsym (argc=6, argv=0x5555561324e8) at ../sway/commands/bind.c:577
#1  0x000055555556dc9f in config_command (exec=0x55555618b3a0 "bindsym --to-code Print exec ~/bin/script-testing.sh notify-brightness up", new_block=0x7fffffffdfc8)
    at ../sway/commands.c:426
#2  0x0000555555570e2d in read_config (file=0x55555614a4c0, config=0x55555614f8c0, swaynag=0x55555614f8c8) at ../sway/config.c:824
#3  0x000055555556fa9b in load_config (path=0x5555560a20c0 "/home/furkan/.config/sway/config", config=0x55555614f8c0, swaynag=0x55555614f8c8) at ../sway/config.c:437
#4  0x000055555556fe75 in load_main_config (file=0x0, is_active=false, validating=false) at ../sway/config.c:509
#5  0x000055555557d283 in main (argc=1, argv=0x7fffffffe2d8) at ../sway/main.c:351

There are workarounds like deleting the automatically generated internet keys from evdev file or using bindcode api directly vs making bindsym do the conversion but I'd like to know what's wrong here to problems like this in the future.

[wismill]

Quoting Peter’s answer from the thread you pointed (emphasis mine):

Basically the program I’m working on was originally designed for X11, and I’m trying to adapt it to Wayland. I’m trying to find an equivalent to XKeysymToKeycode().

it doesn't, but if you look at xkbcli how-to-type and it's source
(tools/how-to-type.c) that's the closest approximation.

What does this program do? Does it iterate through all possible keycodes and lookup the keysym for them?

please look at the source, it's not a huge program.

It would be useful if you could describe your use case, because I cannot guess it from your snippet.

[sahinf]

I'm running SwayWM and trying to bindsym --to-code Print however it fails the binding because I have 2 keycodes that map to keysym Print and of those keycodes is an auto generated virtual key that I didn't even knew existed.

[wismill]

As a general advice, please do not assume too much when presenting a use case or filing an issue: not everybody use Sway or know the bindsym tool (I do no not, for one).

It seems you try to bind a keysym to some action but your tool does not support having a keysym mapped to multiple key codes, does it? Since you opened an issue here, I assume you have some code using the libxkbcommon API. Could you maybe link it here if it’s open source, and give a complete context?

I have 2 keycodes that map to keysym Print and of those keycodes is an auto generated virtual key that I didn't even knew existed.

I do not understand the last part, do you mean <I218>/KEY_PRINT by “virtual key”?

[sahinf]

As a general advice, please do not assume too much when presenting a use case or filing an issue: not everybody use Sway or know the bindsym tool (I do no not, for one).

I did not think the compositor I am using matters since the crux of the issue is libxkbcommon api so I did not initially present that context

I assume you have some code using the libxkbcommon API

No need to assume, the gdb snippet that you ignored is evidence

(gdb) print xkb_state_key_get_one_sym(config->keysym_translation_state, 107)
$8 = 65377
(gdb) print xkb_state_key_get_one_sym(config->keysym_translation_state, 218)
$9 = 65377
(gdb) bt
#0  cmd_bindsym (argc=6, argv=0x5555561324e8) at ../sway/commands/bind.c:577
#1  0x000055555556dc9f in config_command (exec=0x55555618b3a0 "bindsym --to-code Print exec ~/bin/script-testing.sh notify-brightness up", new_block=0x7fffffffdfc8)
    at ../sway/commands.c:426
#2  0x0000555555570e2d in read_config (file=0x55555614a4c0, config=0x55555614f8c0, swaynag=0x55555614f8c8) at ../sway/config.c:824
#3  0x000055555556fa9b in load_config (path=0x5555560a20c0 "/home/furkan/.config/sway/config", config=0x55555614f8c0, swaynag=0x55555614f8c8) at ../sway/config.c:437
#4  0x000055555556fe75 in load_main_config (file=0x0, is_active=false, validating=false) at ../sway/config.c:509
#5  0x000055555557d283 in main (argc=1, argv=0x7fffffffe2d8) at ../sway/main.c:351

In the GDB snippet, the xkb_state_key_get_one_sym function is called twice with different key codes, both returning the same symbol value (65377) for both

        <PRSC> = 107;
	<I218> = 218;		// #define KEY_PRINT               210

Please let me know if I need to further clarify.

[wismill]

No need to assume, the gdb snippet that you ignored is evidence

Nor ignored: I expected actual code, not an isolated use of a function of our API.

You did ignore my question though.

Since you do not provide further context nor code, I will just point to my previous comment and close the issue.

[wismill]

Feel free to re-opened after analyzing the code mentioned (tools/how-to-type.c) and clarifying your issue.

[sahinf]

"I do not understand the last part, do you mean /KEY_PRINT by “virtual key”?"

By virtual I mean "Internet" or "Extended" keys as described in /usr/share/X11/xkb/keycodes

Since you do not provide further context nor code, I will just point to #504 and close the issue

I used wev to get the keysyms for Keysym Print and a.

[14:     wl_keyboard] key: serial: 15105; time: 2450088; key: 107; state: 0 (released)
                      sym: Print        (65377), utf8: ''
[14:     wl_keyboard] key: serial: 15106; time: 2452220; key: 38; state: 1 (pressed)
                      sym: a            (97), utf8: 'a'

keysym for a = 97
keysym for Print = 65377

And xkbcli to map back

$ xkbcli how-to-type 97   
keysym: a (0x61)
KEYCODE  KEY NAME  LAYOUT   LAYOUT NAME          LEVEL#  MODIFIERS
38       AC01      1        English (US)         1       [ ]
$ xkbcli how-to-type 65377
keysym: UFF61 (0x100ff61)
KEYCODE  KEY NAME  LAYOUT   LAYOUT NAME          LEVEL#  MODIFIERS

Given the output of wev, I would expect to see 65377 being mapped back to keysym XKB_KEY_Print 0xff61 but it gets mapped to keysym 0x100ff61.

So this is not an issue right?

[wismill]

You need to provide the hexadecimal keysym value or keysym name via --keysym.

• xkbcli how-to-type --keysym 0x61 or xkbcli how-to-type --keysym a (2 results here)
• xkbcli how-to-type --keysym 0xff61 or xkbcli how-to-type --keysym Print and you’ll get 2 results.

It seems you got lucky with xkb_utf32_to_keysym(0x97) returning 0x61. I’ll have to check this, as this looks suspicious. And the manual page should mention hexadecimal code is expected.

EDIT: how-to-type uses strtol with base 0, which accept either 0x-prefix hexadecimal or unprefixed decimal (and octal). Nothing wrong with xkb_utf32_to_keysym then.

So this is not an issue right?

2 results pointing respectively to key codes PRSC (i.e. Linux’s KEY_SYSRQ) and I218 (KEY_PRINT) is the correct result. Whether this is an issue for what you try to do depends on your use case, which remains unclear…

[sahinf]

Whether this is an issue for what you try to do depends on your use case

Precisely why I excluded that irrelevant information from this post, it would not help you answer whether xkb_state_key_get_one_sym is working as expected or not.

which remains unclear

??
#504 (comment)

I’ll have to check this, as this looks suspicious. And the manual page should mention hexadecimal code is expected

It does not on version 1.7.0

2 results pointing respectively to key codes PRSC (i.e. Linux’s KEY_SYSRQ) and I218 (KEY_PRINT) is the correct result.

Thanks!

[wismill]

Precisely why I excluded that irrelevant information from this post, it would not help you answer whether xkb_state_key_get_one_sym is working as expected or not.

Please leave the decision to decide what is relevant to the maintainers, will you? And mind your tone.

??
#504 (comment)

I still do not know exactly what bindsym is, what you want to do if there are 2 corresponding key codes instead of one, etc. As you struggle to write your use case, maybe there is an open issue or PR in some repo that can be linked here. Or maybe ask a fellow dev to do it for you.

This issue is a puzzle

[sahinf]

"It would be useful if you could describe your use case, because I cannot guess it from your snippet."

Mind your own tone and goodbye!

[wismill]

how-to-type uses strtol with base 0, which accepts either 0x-prefix hexadecimal or unprefixed decimal (and octal). I always assumed it uses only hexadecimal. See #505 for parsing & doc improvement.

[wismill]

@sahinf So swaywm/sway#8339 is where you actually use libxkbcommon and have the issue. It would have been so much easier if you would have linked that PR in the first place, instead of declaring multiple times such context irrelevant.