Strange behaviour with Windows keyboard

[keeferrourke]

First of all, kudos! I love this script! :) It worked perfectly on an Ubuntu VM that I was running on a Macbook Pro the other day :tada:

On one of my workstations (Fedora 31), I use Tilix as my main terminal emulator, and to my surprise, after running setup.py Tilix doesn't work as expected.

I picked the following options from the setup script:

Kinto - Type in Linux like it's a Mac.

    1. ❖  Windows 
    2. ⌘  Mac 
    3. ✇  Chromebook 

Please enter your keyboard type (1 - 3) : 1

1. Windows
Description: Standard Windows 104 Keyboards

Please enter your keyboard config (1 - 1) : 1

My keyboard (Pok3r RGB) bottom-row layout is: Ctrl_L, Super_L, Alt_L, Space, Alt_R, Fn, Menu, Ctrl_R

(Button combos entered below are as printed on my keyboard)

Tilix

• Alt+C acts as Ctrl+C
• Ctrl+C just enters 'c'
• Super+C does nothing
• Ctrl+Shift+C enters 'C'
• Alt+Shift+C copies (Alt+Shift+V pastes)

Gnome-terminal also didn't work as expected:

Gnome-terminal

• Alt+C enters 'c'
• Ctrl+C enters 'c'
• Super+C copies (Super+V pastes)

I find this super confusing, so maybe some output from xev will be more helpful :)

On pressing Alt_L, xev reports:

KeyPress event, serial 37, synthetic NO, window 0x8000001,
    root 0x19c, subw 0x0, time 978177417, (12,-10), root:(26,1677),
    state 0x0, keycode 64 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x8000001,
    root 0x19c, subw 0x0, time 978177480, (12,-10), root:(26,1677),
    state 0x4, keycode 64 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

On pressing Super_L, xev reports:

KeyPress event, serial 37, synthetic NO, window 0x8000001,
    root 0x19c, subw 0x0, time 978176288, (12,-10), root:(26,1677),
    state 0x0, keycode 133 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x8000001,
    root 0x19c, subw 0x0, time 978176360, (12,-10), root:(26,1677),
    state 0x8, keycode 133 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

On pressing Ctrl_L, xev reports:

KeyPress event, serial 34, synthetic NO, window 0x8000001,
    root 0x19c, subw 0x0, time 978174870, (12,-10), root:(26,1677),
    state 0x0, keycode 37 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x8000001,
    root 0x19c, subw 0x0, time 978174964, (12,-10), root:(26,1677),
    state 0x40, keycode 37 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

On my keyboard layout, I would've expected Ctrl to stay Ctrl, Super_L to become Option/Alt_L, and Alt_L to become Cmd/Super_L.

[rbreaves]

Hmmm that is odd. The key layout between Apple keyboard w/ hid driver and windows ought to be identical, but yea when using the VM you would use the Apple keyboard without the driver. I will test out my vm with a normal windows keyboard to see what it does, maybe something is slightly off and I did not realize it.

[keeferrourke]

Actually on a second read-through the readme, I'm not sure if xev would be considered a GUI or terminal application... And the keymap might actually make sense, since Ctrl acts like Cmd in Linux GUI apps.

Strange terminal behaviour remains though :P

[keeferrourke]

@rbreaves thanks for the super fast reply! :smile:

[rbreaves]

By default xev will be picked up as a terminal thing unless you stop the keyswap from running via systemctl --user stop keyswap.

You can pull up the ~/.config/kinto/user_config.json file though and manually run through each keymap scenario and then use xev or xbindkeys --key or xbindkeys --multikey.

[rbreaves]

If you don't mind please check out the latest in the current dev branch, it occurred due to Kinto switching over from Super to using Hyper to then remap to Ctrl+Shift. I am very surprised no one mentioned it before now or that I did not notice. I have been mostly using my Apple laptop keyboard or my chromebooks though.

[rbreaves]

What surprises me most though is that it sorta ignore an earlier keymapping, but then it doesn't as well. I'd think this would been stacking, in which case it would have been fine. Oh well xkb is anything but straight forward imo.

3185bc068a72076985b1d52fa43862215903dec6

You can also check it out on master too, I went ahead and merged it. I am pretty confident that this is fully resolved now.

[keeferrourke]

I'll check it out and report back soon :)

[rbreaves]

Will re-open if it needs to be.