[BUG] constant AltGr modifier on Finnish keyboard layout

[mvaaltola]

Rofi version (rofi -v)

1.7.3

Configuration

https://gist.github.com/mvaaltola/dbda2ead10ad52f8625a57af883d43db

Launch command

rofi -show drun

Step to reproduce

• run localectl set-x11-keymap us,fi pc105 qwerty grp:ctrls_toggle,caps:escape
• open rofi, type asd, everything works fine
• hit left+right ctrl keys at the same time to change keyboard layout to fi
• type asd again, the output is əßð i.e. as if the AltGr modifier key was held down when typing

Expected behavior

Display correct characters (asd instead of əßð) when using the Finnish keyboard layout.

Actual behavior

When using the Finnish keyboard layout, characters are displayed in rofi as if the AltGr key is held down. For example, e becomes €, a becomes ə etc.

Additional information

Other software, e.g. Visual Studio Code, displays characters correctly when using the same font and keyboard layout.

[DaveDavenport]

I cannot get the double 'control' key switching to work to reproduce it. Wonder why.

[mendes-davi]

Also facing the same issue with the XkbVariant intl for the us keyboard.

[DaveDavenport]

I need more information on how to reproduce, for me it seems to work, but I have not been able to change keyboard layout using double ctrl.

[mendes-davi]

Currently on archlinux and I've noticed that libxkb-common got updated to 1.4.1-1 (2022-05-21). This is the changeog libxkbcommon/NEWS.

[mvaaltola]

I'm also on Arch and have libxkbcommon 1.4.1-1. I tried downgrading to 1.4.0-1 but this did not solve the issue.

@DaveDavenport If grp:ctrls_toggle does not work for you for whatever reason, you can try another toggle. See grep "grp:.*toggle" /usr/share/X11/xkb/rules/base.lst for a list of all options. For example, I was also able to produce this issue again by:

• run setxkbmap -model pc105 -layout us,fi -option grp:rctrl_toggle to set the kb layout for only current X session, i.e. not persistently like localectl
• open rofi, type hello, everything is fine
• hit right ctrl to switch keyboard layout to fi. type hello, output is h€/œ

[DaveDavenport]

got it to work with that on one laptop (bit trail and error), and it works for me (tm). Ubuntu 20.04, with i3.
I can switch between us/fi within rofi and it works correctly, I don't get h€/œ (unless I hold right alt), even when switching back and forth within rofi.

(did not get it to work on popos or newer ubuntu )

[mvaaltola]

I managed to isolate this issue to xkeyboard-config. After downgrading from 2.36-1 (from 2022-06-03) to 2.35.1-1 (from 2022-02-10) and rebooting everything works as it should. Upgrading back to 2.36-1 causes the issue to return.

[DaveDavenport]

thanks for figuring that out.

I just recorded it working... I type 'hello' then hit the right alt, type hello. hit the switch key and repeat.

[ProspectPyxis]

Having the same issue here with a different keyboard layout. Interestingly, it looks like the order of the layouts matter.

setxkbmap -layout us,us -variant colemak_dh, -options grp:win_space_toggle

works fine between both layouts, but

setxkbmap -layout us,us -variant ,colemak_dh -options grp:win_space_toggle

breaks when switching to the second layout.

[ghost]

im having this same issue! together with custom scripts in my PATH not working when pressing a shortcut in i3, ill see if thats related to xkeyboard-config as well

[ProspectPyxis]

Confirming that downgrading xkeyboard-config solved the issue for me.

[ghost]

same for me, the other issues i had werent related

[kalex3]

same, i confirm that downgrading xkeyboard-config works

[andyrtr]

Affected people should report this to the xkeyboard-config tracker .

[bonfus]

Affected people should report this to the xkeyboard-config tracker .

This has been reported

https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/341

Soon closed because it's not a xkeyboard-config bug.

[DaveDavenport]

That was very unhelpful into solving the issue.
It works in X therefor Y broken. 👎

SardemFF7 question never answered.

(not saying that rofi is not at fault)

[DaveDavenport]

I can see the keycode and modmask that is correct (from what I can see), what I get back from xkb_state_key_get_utf8 is wrong when switched to other layout.

[DaveDavenport]

@raven2cz you should be able to add info to this issue? and not sure why you think this issue is (going to be) closed.

[DaveDavenport]

according to xkb_state_mod_index_is_active, Mod5 is active when in finish layout and indicated it is consumed .. is this a xkbcommon issue ( I have 0 experience with xkbcommon)?

[kurganme]

Hi, maybe my experience can be useful to debug this problem.
I usually use this configuration with an American keyboard:
setxkbmap -layout 'us,us(intl)' -option '' -option 'grp:caps_toggle,grp_led:caps'
It is very convenient for me: it allows me to switch between the pure American layout and the international American layout (with dead keys) using the CAPSLOCK key. When I need to lock capitals I use the SHIFT+CAPSLOCK sequence. It works perfectly well with any software for X but with rofi version 1.7.3 it has similar behavior to what OP complained about. If I am in pure American layout mode everything works correctly while with the American International layout (the one specified as secondary) it behaves as if AltGr is always pressed.
I also noticed that if I reverse the order of the two configurations:
setxkbmap -layout 'us(intl),us' -option '' -option 'grp:caps_toggle,grp_led:caps'
in American international layout mode everything works correctly while with the pure American layout (the one specified as secondary) it behaves as if the SHIFT key is always pressed.
This problem occurs only with rofi and with no other application.

[DaveDavenport]

thanks for the extra information, all information helps.

The ordering of layout making a difference seriously confuses me.

[DaveDavenport]

This seems to be relevant to the issue:
https://github.com/sardemff7/libnkutils/blob/d08fa898d71da4c11653284968ec14384dd70b6a/src/bindings.c#L1202

[DaveDavenport]

diff --git a/source/xcb.c b/source/xcb.c
index f53aa3a2..f81015f9 100644
--- a/source/xcb.c
+++ b/source/xcb.c
@@ -1257,8 +1257,8 @@ static void main_loop_x11_event_handler_view(xcb_generic_event_t *event) {
     gchar *text;

     xcb->last_timestamp = xkpe->time;
-    text = nk_bindings_seat_handle_key_with_modmask(
-        xcb->bindings_seat, NULL, xkpe->state, xkpe->detail,
+    text = nk_bindings_seat_handle_key/*_with_modmask*/(
+        xcb->bindings_seat, NULL, /*xkpe->state,*/ xkpe->detail,
         NK_BINDINGS_KEY_STATE_PRESS);
     if (text != NULL) {
       rofi_view_handle_text(state, text);

This helps for me, but no real reasoning yet, just trail and error.

[raven2cz]

diff --git a/source/xcb.c b/source/xcb.c
index f53aa3a2..f81015f9 100644
--- a/source/xcb.c
+++ b/source/xcb.c
@@ -1257,8 +1257,8 @@ static void main_loop_x11_event_handler_view(xcb_generic_event_t *event) {
     gchar *text;

     xcb->last_timestamp = xkpe->time;
-    text = nk_bindings_seat_handle_key_with_modmask(
-        xcb->bindings_seat, NULL, xkpe->state, xkpe->detail,
+    text = nk_bindings_seat_handle_key/*_with_modmask*/(
+        xcb->bindings_seat, NULL, /*xkpe->state,*/ xkpe->detail,
         NK_BINDINGS_KEY_STATE_PRESS);
     if (text != NULL) {
       rofi_view_handle_text(state, text);

This helps for me, but no real reasoning yet, just trail and error.

Inside of this issue
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/341#note_1474160

There are two points which "maybe" can help. Morgane Glidic discussed this topic. I assume she will understand the given code well. Could you discuss this with her? Second, Benno writes this sentence: "It seems it uses state.compat_state instead of state.mods."

Do you have possibility to test the issue now? By the example with setxkbmap -layout 'us,us(intl)' -option '' -option 'grp:caps_toggle,grp_led:caps'.

[DaveDavenport]

I did read the topic and that benno remark is not helpful; it has zero explanation, zero reference to documentation nor exists anywhere in rofi/libnkutils/xkbcommon from what I can see. Its an off-the cuff remark that adds nothing. It seems to be an xlib thing, and it was already pointed out rofi does not use that.

Given my posts above, I am pretty sure I know what goes wrong and where. By disabling some code (see above patch) it fixes it for me, I just don't understand why that code is originally there.

[sardemff7]

Apparently it was a fix for #611 in 8f8c43e
So I would still argue that it’s weird that a change in xkeyboard-config would break what the X server directly sends me when at the time was exactly what I had to use to get something else working

[raven2cz]

I did read the topic and that benno remark is not helpful; it has zero explanation, zero reference to documentation nor exists anywhere in rofi/libnkutils/xkbcommon from what I can see. Its an off-the cuff remark that adds nothing. It seems to be an xlib thing, and it was already pointed out rofi does not use that.

Given my posts above, I am pretty sure I know what goes wrong and where. By disabling some code (see above patch) it fixes it for me, I just don't understand why that code is originally there.

Benno makes new comment now. Maybe help? If not, maybe discuss the problem directly with him again. It seems that he wants to coop with it.

[DaveDavenport]

Quick summary for myself:
It seems this: xserver #300 issue, and the workaround for this issue introduced in #611 is what coming back to haunt us.
Given that the issue is open for almost 5 years in xserver, I don't expect that one to get fixed.

I think the best solution is to change the default to not use the work-around, this will 're-open' #611 but should fix this issue.
I could add a -broken-xserver-i300 flag that restores this behavior, also not ideal..

[DaveDavenport]

Can anybody can please confirm the above commit helps.

[tkaepp]

For me the commit works.
rofi -v: Version: 1.7.3-97-git-af976c37 (git-r3/HEAD)
I'm using us,ch layouts with setxkbmap -layout us,ch -option grp:alt_shift_toggle

[raven2cz]

@DaveDavenport WORKS! Perfect, thx!

[cphyc]

Works for me as well with an international US keyboard!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.