[1.1.81 Linux] keyboard shortcuts with key combinations or mouse-click fail to set

[fdefkeh]

- New install of 1.1.81 with default settings and no mods
- Discovered when attempting:
-- Stack Transfer (Left-Control + Left-Mouse-Click)
-- Copy (Left-Control + C)
- Keyboard shorts using key combinations fail to set. Examples:
-- Left-Control + (key or mouse-click)
--- Attempting to set this keyboard shortcut only registers Left-Control key
-- Shift + (key or mouse-click)
--- Attempting to set this keyboard shortcut only registers Shift key

[Donion]

Thanks for the report, unfortunately I wasn't able to reproduce the issue on my end.
Does it happen for you also in the previous version, 1.1.80?
Can you provide some details about your setup, desktop environment, window manager? Do you have some custom settings with your mouse and keyboard?

[fdefkeh]

Hi,

No, this does not occur in 1.1.80.

The window manager is i3 (i3-wm 4.22-3) and using Xorg with xorg-xinput 1.6.3-3

No, I do not have any custom setups related to keyboard or mouse

Another interesting thing to note is that, for example, Right-Control + C works fine.
I can set that keybinding and the shortcut works as expected.

Let me know if you need additional logs or troubleshooting.

[raiguard]

I'm not able to reproduce this either, on very similar i3 and xorg-xinput versions. Which distribution are you running?

[fdefkeh]

Hi,

I'm running Arch Linux

Code: Select all

# uname -r
6.3.1-arch1-1

[n16f]

Hi, just was notified that my bug report (viewtopic.php?f=47&t=106134&p=584956#p584956) is a duplicate of this one.
I can confirm I have the same issue. No problem with 1.1.80 and before, broken with 1.1.81.

fdefkeh: are you using "setxkbmap -option 'ctrl:nocaps'"? It is extremely common and causes both CapsLock and LeftControl to send the same "Control_L" key code. I never saw any application affected by this, but who knows.

I also saw that 1.1.81 includes an update of libsdl. It might change something related to keyboard input.

[fdefkeh]

Hi,

Yes, good catch!
I have the following set up in .Xmodmap
Keycode 66 is where I re-map CAPS to Control_L

.Xmodmap:

Code: Select all

clear lock
clear control
clear mod1
clear mod2
clear mod3
clear mod4
clear mod5
keycode 66 = Control_L
keycode 135 = Super_R
add control = Control_L Control_R
add mod1 = Alt_L Alt_R Meta_L
add mod2 = Num_Lock
add mod4 = Super_L Super_R
add mod5 = Mode_switch ISO_Level3_Shift

[Donion]

Thanks for the additional info!. We're able to reproduce the issue by mapping caps to ctrl.
I'm not sure how we will solve this and when that could be. In the meantime you should remove the remapping or use the 1.1.80.

[n16f]

I blocked update to stay on 1.1.80, hopefully you guys can find what the problem is. I've been using this mapping for 10+ years with a wide range of applications, never had any problem. Are you doing some kind of low level keyboard manipulation? Normally if you rely on symbol keysyms you should never see the difference between Control_L from LeftControl (0xffe3 here) and Control_L from CapsLock (0xff09), and the keycode (37) and state (0x4) are the same.

Feel free to ping me if you need to run some tests or get additional information.

[Donion]

I imagined you wouldn't want to remove the mapping
I wasn't clear, what I meant is that we know what the problem is (scancode vs keycode/keysym) but we need to figure out/decide which solution would be best.

[n16f]

Ah my bad, I misunderstood.

Glad you already know what the problem is. Good luck!

[Donion]

There turned out to be several issues related to remapped modifier keys across different platforms and environments so it took a lot of investigating and testing.
The issues should be now fixed for the next release.
Thanks for the reports and thanks to raiguard and StrangePan for their help on this.

[n16f]

That was fast, thank you! I'll make sure to test the next version.

[n16f]

I just tested with 1.1.85, and it works as expected. Thank you again!