Specific char doesn't work

[Kreepzzz]

Hi,

I work on Linux but I'd like to work with Mac shortcuts, I've install your app and the shortcut with CMD+keys is ok. But when I want to write specific char like { or [ I can't, nothing append.

Can you tell me if I've to do something to activate or configure that ?

I'm on ubuntu / gnome with a MX Keys.

Thank you,

[rbreaves]

Likely a language issue & you’ll need to figure out your proper key code & get it added to my forked xkeysnail package & @joshgoebel would need the patch as well.

I think it’s a keys.py or input file. We’ll need more info to fix, this a UK layout?

[Kreepzzz]

Hi, no it's a French Layout (AZERTY). I use the MX Keys keyboard with windows and mac key but with the physic keyboard I've the same "bug".

[joshgoebel]

Any reason we don't just ask uses to run evtest and press the keys and post output?

[rbreaves]

I sometimes do, but I don’t recall which app lines up w/ the key/input py file if any exactly w/o translating it..

xev, showkeys, xbindkeys, & the one you mentioned are all good.

I think showkeys is really useful as it can do keycodes or scancodes.

[joshgoebel]

I was super annoyed that xev seems to show me diferent keycodes (not scancodes) than evtest... when I thought that keycode was supposed to be keycode. In my experiences so far evtest is always spot on correct. I'm going to go try showkeys now.

[joshgoebel]

All I see in AUR is wshowkeys for wayland, is that what you meant? i haven't played with the wayland.

[rbreaves]

All I see in AUR is wshowkeys for wayland, is that what you meant? i haven't played with the wayland.

It’s either showkey or showkeys, either way I dogfood on Ubuntu the most. No idea what AUR uses & I’m not ever on wayland.

[joshgoebel]

But when I want to write specific char like { or [ I can't, nothing append.

I'm not sure why we would just DROP keys though... if we were hit with a keycode that literally didn't exist in the list the software should crash... and if the mappings are just wrong somehow (I'm not sure that would be our issue) then those keys should still be typing SOMETHING.

Very curious to see what your evtest says...

[Event: time 1655411602.243474, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7002f
Event: time 1655411602.243474, type 1 (EV_KEY), code 26 (KEY_LEFTBRACE), value 0
Event: time 1655411602.571503, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70030
Event: time 1655411602.571503, type 1 (EV_KEY), code 27 (KEY_RIGHTBRACE), value 1

That key pair []{} should be the left and right brace...

[joshgoebel]

@rbreaves Do you have cases of the software just dropping keys silently in the past because of language issues?

[rbreaves]

I’ll have to look at this later in the evening. And I’m not sure, isn’t the first post about issues w/ other languages though.

[joshgoebel]

And I’m not sure, isn’t the first post about issues w/ other languages though.

I'd love to learn more. This sounds quite strange. All we do (for most letters) is pass thru the keycodes... I mean if software has local specific keymappings that would be a problem... but otherwise the D key should be the D key... you hit D you get D... whatever D means in your language/locale. Possibly there is a big piece here I'm still missing?

[rbreaves]

Language aside MX Logitech keyboards often cause some level of grief as it requires the user to pipe in the specific input device via --device or they’re often not detected at all.

in general though xkeysnail is working on a fairly low level compared to xkb so Kinto probably has less issues now than it did when I was on xkb.

[joshgoebel]

Well, I'd wager I've already fixed that but if not and it's truly that hard to detect what is and isn't a keyboard I've already said the right solution is a small built in whitelist.

[Kreepzzz]

Hello, I'm sorry but I didn't understand if you were expecting an action from me?

[joshgoebel]

• Run evtest from a console
• Hit the keys in question that aren't working
• Post the output here

[Kreepzzz]

Ok I've re installed kinto and done some tests, and when I'm on keyboard type : Apple If i do ALT GR + 5 => { so it's good, but if i do ALT LEFT + 5 => nothing On mx keys the CMD key is on ALT LEFT, and if I do a CMD/ALT LEFT + Z that doesn't undo.

I've tried evtest with physical keyboard and MX keys and I always have this error message :

***********************************************
  This device is grabbed by another process.
  No events are available to evtest while the
  other grab is active.
  In most cases, this is caused by an X driver,
  try VT-switching and re-run evtest again.
  Run the following command to see processes with
  an open fd on this device
 "fuser -v /dev/input/event3"

---

[joshgoebel]

I've tried evtest with physical keyboard and MX keys and I always have this error message :

You'll keed to stop running Kinto and xkeysnail in order to run evtest.

[joshgoebel]

ALT GR + 5 => {

What is GR... when you get evtest working you should push that key too so we can see the keycode that's reported.

[Kreepzzz]

When i push ALT GR is got this keycode reoprted :

Event: time 1655467682.754460, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1655467682.754460, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1655467682.754460, -------------- SYN_REPORT ------------
Event: time 1655467685.954924, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e6
Event: time 1655467685.954924, type 1 (EV_KEY), code 100 (KEY_RIGHTALT), value 1
Event: time 1655467685.954924, -------------- SYN_REPORT ------------
Event: time 1655467685.954983, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e6
Event: time 1655467685.954983, type 1 (EV_KEY), code 100 (KEY_RIGHTALT), value 0
Event: time 1655467685.954983, -------------- SYN_REPORT ------------

And when i push on ALT i got this :

Event: time 1655467748.454920, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1655467748.454920, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1655467748.454920, -------------- SYN_REPORT ------------
Event: time 1655467749.917633, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e2
Event: time 1655467749.917633, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 1
Event: time 1655467749.917633, -------------- SYN_REPORT ------------
Event: time 1655467750.052537, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e2
Event: time 1655467750.052537, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 0
Event: time 1655467750.052537, -------------- SYN_REPORT ------------

[joshgoebel]

Ok, that all looks boringly as expected... what your calling "Alt GR" I'd just call "right alt" and that's what we call it everywhere, Key.RIGHT_ALT.

What specific combos (please show us the source from your config) are you having trouble with? If you're using Alt or M in your mapping it should work with BOTH keys, and if you're only using LM or LAlt it should only work with one (the behavior you are seeing).

[joshgoebel]

And I thought your original question was about braces, but you didn't shows us the evcode output for your []{} keys...

[Kreepzzz]

And I thought your original question was about braces, but you didn't shows us the evcode output for your []{} keys...

Sorry I forget this, this is the output when I push "5" key where is ( or [ :

Event: time 1655470988.648938, -------------- SYN_REPORT ------------
(Event: time 1655470988.738728, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70022
Event: time 1655470988.738728, type 1 (EV_KEY), code 6 (KEY_5), value 0
Event: time 1655470988.738728, -------------- SYN_REPORT ------------
Event: time 1655470989.368947, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e6
Event: time 1655470989.368947, type 1 (EV_KEY), code 100 (KEY_RIGHTALT), value 1
Event: time 1655470989.368947, -------------- SYN_REPORT ------------
Event: time 1655470989.548755, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70022
Event: time 1655470989.548755, type 1 (EV_KEY), code 6 (KEY_5), value 1
Event: time 1655470989.548755, -------------- SYN_REPORT ------------
[Event: time 1655470989.638883, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70022
Event: time 1655470989.638883, type 1 (EV_KEY), code 6 (KEY_5), value 0
Event: time 1655470989.638883, -------------- SYN_REPORT ------------
Event: time 1655470989.661275, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e6
Event: time 1655470989.661275, type 1 (EV_KEY), code 100 (KEY_RIGHTALT), value 0
Event: time 1655470989.661275, -------------- SYN_REPORT ------------

And this is the output for the key "4" where is ' and { :

Event: time 1655471061.885941, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70021
Event: time 1655471061.885941, type 1 (EV_KEY), code 5 (KEY_4), value 0
Event: time 1655471061.885941, -------------- SYN_REPORT ------------
Event: time 1655471062.200879, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e6
Event: time 1655471062.200879, type 1 (EV_KEY), code 100 (KEY_RIGHTALT), value 1
Event: time 1655471062.200879, -------------- SYN_REPORT ------------
Event: time 1655471062.381011, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70021
Event: time 1655471062.381011, type 1 (EV_KEY), code 5 (KEY_4), value 1
Event: time 1655471062.381011, -------------- SYN_REPORT ------------
{Event: time 1655471062.471198, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70021
Event: time 1655471062.471198, type 1 (EV_KEY), code 5 (KEY_4), value 0
Event: time 1655471062.471198, -------------- SYN_REPORT ------------
Event: time 1655471062.561089, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e6
Event: time 1655471062.561089, type 1 (EV_KEY), code 100 (KEY_RIGHTALT), value 0
Event: time 1655471062.561089, -------------- SYN_REPORT ------------

[joshgoebel]

"5" key where is ( or [ : "4" where is ' and { :

I don't understand you... the 4 and 5 key are just the 4 and 5 key... are you referring to the shifted variants of those keys? On my keyboard shift-5 is % and shift-4 is $... Or if you're talking about a keymap please show us the code from your config as previously requested.

Perhaps a photo of your actual keyboard (or those keys) could help?

[Kreepzzz]

With a photo it will be better : https://resource.logitech.com/content/dam/logitech/en/products/keyboards/mx-keys-for-business/gallery/mx-keys-business-keyboard-gallery-fra-graphite-1.png

[joshgoebel]

Ok, that's both cool and weird... so BEFORE you install Kinto, what keys do you press on the keyboard to access those alternative functions of the 4 and 5 keys? Are you saying those same combos don't work after installing Kinto?

[Kreepzzz]

Before installing kindo when I use windows or linux, if I do RIGHT_ALT + 4 I have { And if I use my keyboard with a mac, when I do OPT / démarrer or OPT / Ctrl + 5 I have {

And with kinto

And if I use keyboard type 'Apple' with kinto the shortcuts CMD + key doesn't work. And with windows / mac keyboard type shortcuts works but OPT + 5 or OPT + 4 doesn't work that change the tab on firefox or change the windows.

[joshgoebel]

MX Keys is NOT an apple keyboard, so I'm pretty sure that's the wrong choice.

RIGHT_ALT + 4 I have { OPT / Ctrl + 5 I have {

I assume for 5 you meant [ not {... so open evtest again and hit:

• RIGHT_ALT + 4
• RIGHT_ALT + 5

Show us the output.

[Kreepzzz]

This is the output for the RIGHT_ALT + 4 :

Event: time 1655476158.990795, -------------- SYN_REPORT ------------
Event: time 1655476160.498341, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e2
Event: time 1655476160.498341, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 1
Event: time 1655476160.498341, -------------- SYN_REPORT ------------
Event: time 1655476160.678317, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70021
Event: time 1655476160.678317, type 1 (EV_KEY), code 5 (KEY_4), value 1
Event: time 1655476160.678317, -------------- SYN_REPORT ------------
^['Event: time 1655476160.745851, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70021
Event: time 1655476160.745851, type 1 (EV_KEY), code 5 (KEY_4), value 0
Event: time 1655476160.745851, -------------- SYN_REPORT ------------
Event: time 1655476160.903829, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e2
Event: time 1655476160.903829, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 0
Event: time 1655476160.903829, -------------- SYN_REPORT ------------

And this the other :

Event: time 1655476213.283565, -------------- SYN_REPORT ------------
Event: time 1655476215.375845, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e2
Event: time 1655476215.375845, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 1
Event: time 1655476215.375845, -------------- SYN_REPORT ------------
Event: time 1655476215.623490, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70022
Event: time 1655476215.623490, type 1 (EV_KEY), code 6 (KEY_5), value 1
Event: time 1655476215.623490, -------------- SYN_REPORT ------------
^[(Event: time 1655476215.713892, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70022
Event: time 1655476215.713892, type 1 (EV_KEY), code 6 (KEY_5), value 0
Event: time 1655476215.713892, -------------- SYN_REPORT ------------
Event: time 1655476215.871038, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e2
Event: time 1655476215.871038, type 1 (EV_KEY), code 56 (KEY_LEFTALT), value 0
Event: time 1655476215.871038, -------------- SYN_REPORT ------------

[joshgoebel]

Before installing kindo when I use windows or linux, if I do RIGHT_ALT + 4 I have { And if I use my keyboard with a mac, when I do OPT / démarrer or OPT / Ctrl + 5 I have {

Does this still work in a raw linux terminal (outside of X Windows), or only in X11?

[Kreepzzz]

I work on linux with my MX keys keyboard and it's work in terminal or other app, but i'd like to use mac shortcut :roll_eyes:

[joshgoebel]

it's work in terminal or other app,

I mean the text console, not a X window terminal... if you boot your computer to a text console rather than graphical environment, does those combos on the keyboard still work, or do they only work in X? From your answer I can't be certain.

[rbreaves]

@Kreepzzz with your keyboard being able to operate in either macOS or Windows mode have you tried both modes with Kinto and changed its keyboard setting accordingly? It is possible that one mode may work better than another.

Also there is an option in the Kinto app & system tray just go to Customize -> Tweaks menu & turn off the normal remapping on the right side of your keyboard by checking "AltGr on Right Cmd" - and that may resolve your issue right there as I implemented that a long time ago for multi-language keyboard users, until now though I did not think you were referring to AltGr and a combo press.

I am guessing we've had a miscommunication because US & maybe UK keyboard don't need/require AltGr for much of anything that I am aware of. Not sure if I can make change to account for this or not, perhaps we I detected the users language type for their keyboard I could just set AltGr to be on by default. Only leave it off for US/UK users.

[joshgoebel]

turn off the normal remapping on the right side of your keyboard by checking "AltGr on Right Cmd"

If they do that what are you changing behind the scenes?

[rbreaves]

If they do that what are you changing behind the scenes?

In his case, if he is in mac mode these lines here - they're currently uncommented, so they will become commented out again and then Kinto will restart itself.

    # Key.RIGHT_META: Key.RIGHT_CTRL, # Mac - Multi-language (Remove)
    # Key.RIGHT_CTRL: Key.RIGHT_META, # Mac - Multi-language (Remove)

https://github.com/rbreaves/kinto/blob/7c6c56f7c3c6807a146b9212874bd019412d858f/linux/kinto.py#L149

In theory though.. the most proper fix might actually be to place whatever value AltGr is on the 2nd key closest to the spacebar on the right side, but every laptop and keyboard is different, so I do not like making assumptions about the users key layout.. so instead I just turn that side of the remapping off entirely.

[rbreaves]

Out of curiosity I decided to look at how old this fix was.. 23 months ago o.o. I am feeling old now lol, I was thinking oh this happened probably like 8-12 months ago..

https://github.com/rbreaves/kinto/issues/192

[joshgoebel]

Oh, they want a REAL Alt-GR key and we're turning it into another key entirely during the remap... (with the simple solution being to leave it alone)... but that AltGR behavior itself is configured somewhere in the kernel/X11, no? My Right Alt doesn't magically behavior as an Alt-GR key that I know of...

[rbreaves]

but that AltGR behavior itself is configured somewhere in the kernel/X11, no?

I would assume so but I have enough laptops laying around to know that manufacturers of PC's are freaking weird when it comes the modifier keys on the right side of their keyboard layouts so I yea the simplest solution is to leave it be and if they're an international user then I will assume they're keyboard at least has an AltGr key on the right side if nothing else.

In theory they could also have an Ctrl &/or Super key, but I do not know that for a fact & have not been motivated to write extra code to have users press their keys for me lol.

[rbreaves]

I will close this ticket as soon as @Kreepzzz responds, but I am pretty sure this will likely solve their problem.

[joshgoebel]

I will assume they're keyboard at least has an AltGr key on the right side if nothing else.

The logs they posted from evtest just called it Right_Alt though, so that makes me think it's a software not hardware thing.

Ok, maybe it's always software... I thought there was a Key.ALT_GR but now I'm not finding it, must have been my imagination and "Alt as GR" is just a software mapping...

[rbreaves]

Don't get me started into how AltGr ought to look in evtest or anything else lol. I have no real idea, could be handled all in xkb for all I know. Probably a combo of detecting a multi-language keyboard or having the user set theirs as such.

[RedBearAK]

@rbreaves @joshgoebel

It's becoming more common that 3rd party keyboards have both a "Windows" and a "Mac/iOS" layout mode. Probably due to the popularity of iOS devices, rather than any real surge in absolute numbers of Mac owners. So some of the earliest troubleshooting questions in situations like this should probably be, "What is the exact model of your keyboard (if external)? Is it international or US, and does it have different layout modes for PCs and Macs or Apple mobile devices? What does it say on the key 2nd to the left of the space bar? "

A big clue that someone has one of these keyboards is if they say that they used a key like "Opt | Ctrl" or "Opt | demarrer" (French for "Start") or "Opt | Start". These are not normal labels for modifier keys on a keyboard that doesn't have a switchable layout.

There was someone recently with issues with a Logitech K780 that were apparently solved by forcing the keyboard into Apple layout mode and choosing "Apple" in Kinto for the keyboard type. The K780 appeared to be choosing which layout mode to use automatically, so it was probably defaulting to the Windows layout since the user was connecting it to a PC. But there were keyboard keys that could be used to force it into the other layout.

I have more than one cheap wireless keyboard now, plus a Logitech K480 that's several years old, that has the ability to switch layouts in this way. This is an additional layer of confusion for users trying to get the expected result from Kinto. I think in most cases users will be best served by getting the keyboard into the Mac/iOS layout mode and having the user choose "Apple" as the keyboard type. But at the very least everyone should try to be on the same page as quickly as possible about what layout the keyboard is actually using, and whether it has multiple layouts.

In some cases users may even think it is logical to switch the actual keyboard layout after installing Kinto, or use one layout while using Kinto and another when Kinto is disabled, not realizing this is completely unnecessary and will disrupt the modifier remapping. It can never be assumed that end users actually understand what Kinto does behind the scenes.

And of course any time someone brings up "AZERTY" or some other non-US layout, the "AltGr on Right Cmd" tweak for international users should come up. But that's on top of making sure the user is actually using the appropriate layout and keyboard type selection to begin with. (And not messing with the default keyboard definition in KDE settings, which identifies even real Apple keyboards as "Generic 101-key PC" or something. That can lead some users astray before they discover Kinto, as they may try to change the keyboard to "Apple | Apple" in KDE settings so that it's "correct".)

Not sure if I can make change to account for this or not, perhaps we I detected the users language type for their keyboard I could just set AltGr to be on by default. Only leave it off for US/UK users.

At least asking the user if they are on a US/UK or International keyboard during install and then enabling or disabling AltGr would probably reduce support issues. Seems like the installer used to ask me about that in the past, if I wanted to activate AltGr on Right Cmd, before there was a GUI window implemented. I don't think it does anymore.

[Kreepzzz]

@Kreepzzz with your keyboard being able to operate in either macOS or Windows mode have you tried both modes with Kinto and changed its keyboard setting accordingly? It is possible that one mode may work better than another.

Also there is an option in the Kinto app & system tray just go to Customize -> Tweaks menu & turn off the normal remapping on the right side of your keyboard by checking "AltGr on Right Cmd" - and that may resolve your issue right there as I implemented that a long time ago for multi-language keyboard users, until now though I did not think you were referring to AltGr and a combo press.

I am guessing we've had a miscommunication because US & maybe UK keyboard don't need/require AltGr for much of anything that I am aware of. Not sure if I can make change to account for this or not, perhaps we I detected the users language type for their keyboard I could just set AltGr to be on by default. Only leave it off for US/UK users.

Hi and thank you for your help, I've tried this and it's work, I can use that but as I said on Mac I use the Opt | Ctrl" or "Opt | demarrer" + 5 to do a bracket and with this configuration actually I've to use CMD.

Do you know if it's possible to set this key OPT ?

[rbreaves]

Do you know if it's possible to set this key OPT ?

Saying you want to use the Opt key on the right side as AltGr? That I’m not sure.. you either need to figure out if xkeysnail even offers AltGr at all, don’t think it does as Alt Right I don’t think does it..

the other option is to use the keytables app & remap those 2 keys on a very low level outside of Kinto/xkeysnail all together. Might be just as well & easier to use xmodmap on those 2.. I dunno.

[joshgoebel]

Saying you want to use the Opt key on the right side as AltGr?

@rbreaves Is that unusual? Is the CMD key typically used? I'm not sure why xkeysnail couldn't handle this- you'd just have to be careful how you muck with the right side of the keyboard mappings.

Although I guess if the request is that "Real right control" be AltGr we have a big problem since you rely on that so heavily as "Cmd"...

Opt | Ctrl" or "Opt | demarrer"

These keynames (alone) aren't useful to us... it would be better if anytime you mentioned a key you always included the output evtest gives you (the keyname) for that key so we know what hardware keys you are actually discussing.

[RedBearAK]

@joshgoebel @rbreaves @Kreepzzz

I feel like nobody is asking the question of whether the Option key is actually the key that anyone would use to access the circled characters on an actual Apple keyboard with French AZERTY layout.

It appears that it is, on the ABC Extended French AZERTY keyboard input source. But the layout of characters on keys on the Apple keyboard viewer doesn't exactly match the photo of the Logitech keyboard.

Numbers can't be accessed without Shift. This matches the Logitech. The numbers row is symbols and accents without Shift.

Rounded braces are on the 5 key and the key to the right of the zero key (I believe the symbol you get with Shift is the degree symbol). [Edit: Looked it up, it is indeed the degree sign.]

On the Apple keyboard viewer, curly braces are on Option+5 and Option+"key to the right of zero".

On the Apple keyboard viewer, square braces are on Shift+Opt+5 and Shift+Opt+"key to the right of zero". So, same keys for all "braces".

However on the Logitech photo the curly braces appear to be on AltGr+4 and AltGr+"key with plus/equals to the left of Backspace". Different keys from the square and rounded braces.

So the physical layout of the Logitech is a bit different from an actual Apple keyboard. But the desired characters would indeed be accessed with Option shortcuts on an AZERTY Mac keyboard.

Of course, this is just the ABC Extended version built into macOS, not a physical Apple keyboard. There are photos of Apple laptops with AZERTY layout with the braces on entirely different keys, between the letters and the vertically oriented Enter key. And other photos of the same Logitech keyboard model with French AZERTY with still different positions for the braces, on the minus/equals keys.

There seems to be no real agreement on how non-US keyboards are laid out.

What I'm really wondering on this switchable keyboard is whether the [Gr] function is actually locked to the "Cmd | Alt [Gr]" key regardless of layout mode. The [Gr] doesn't show up on any other key. In which case it seems like it would be difficult to move that function onto the Option keys and get access to the Alt[Gr] characters on the keyboard.

Wish I had the actual keyboard to work with, so I could see the real key codes coming from all these keys. For instance, the key with right rounded brace (parentheses) on this keyboard is on what would be the minus/underscore key, and of course the key list doesn't have things like underscore or right parentheses because those are accessed with Shift+minus or Shift+zero. So I don't quite understand how some of the keys here on an international layout can even work properly at all with xkeysnail/keyszer.

[rbreaves]

It does surprise me that I’ve yet to have a user send me a non-US keyboard 😂.

[RedBearAK]

@rbreaves @joshgoebel

I picked up a new-old-stock Apple French AZERTY layout USB keyboard. Let me know if you want me to try anything specific. I've just done some basic experimenting here.

Interestingly, evtest shows the exact same events for the same physical key location whether I use the internal laptop keyboard on my Acer, or the external Apple USB AZERTY keyboard. With the standard US keyboard layout active in the DE settings.

If I switch to a French AZERTY layout, the internal and external keyboard both start acting as if they are a French AZERTY keyboard, as far as most applications are concerned. But evtest continues to show the same key events.

So with US layout chosen in software, the number row on the AZERTY keyboard that shows numbers as the "Shifted" character will come out as normal without Shift. But switching in software to the French AZERTY layout causes even the laptop's US labeled internal keyboard to require Shift to access the numbers on the number row. Yet with AZERTY active, evtest still shows that the "4" key is KEY_4.

This seems to confirm my theory that all keyboards are the same internally, and the existing key events are simply translated by keyboard layout software settings to produce characters to match the labels on the keys. Thus explaining the usefulness of buying a set of adhesive stickers to change your physical key labels. In this way, you can easily use non-US keyboards as US keyboards, and US keyboards as non-US keyboards. Other than the fact the non-US keyboards often have a few additional keys to help out with accents and characters that US keyboards simply don't have, they are essentially interchangeable.

There is a key just to the right of the left Shift key on the AZERTY keyboard, with the left and right angled brackets. This has an evtest key event of KEY_102ND. This exists in key.py.

Event: time 1657412965.721775, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70064
Event: time 1657412965.721775, type 1 (EV_KEY), code 86 (KEY_102ND), value 0
Event: time 1657412965.721775, -------------- SYN_REPORT ------------

    ZENKAKUHANKAKU = 85
    KEY_102ND = 86
    F11 = 87
    F12 = 88

Unfortunately the "alternate" characters on the actual keyboard and the GNOME layout viewer are not all the same. The physical keyboard only shows a single Alt_Gr (or "Level3" as it's shown on the software layout viewer) character. A Euro symbol on what identifies as the RIGHT_BRACE key.

On the software layout viewer the alternate character on that key is "¤" (apparently a generic symbol for unspecified currency). Seems possible to get to it as long as I enable the Alt_Gr tweak in the Kinto config.

Now to try the various braces on 4, 5 and the Degree key, which would normally be the minus key.

Normal, Shifted, Alt_Gr: ' 4 { ( 5 [ ) ° ]

All seems to be working as it shows on the software layout viewer. And I actually did that with the internal Acer keyboard, just by switching to AZERTY and looking at the keyboard viewer.

So, since the key events according to evtest don't actually change when switching layouts, the same physical keys will perform the same shortcuts on each keyboard, regardless of the active keyboard layout. Cmd+Shift+Braces will switch tabs whether the AZERTY software layout is active or not, even though the labels on the keys of the physical AZERTY keyboard are Caret/Umlaut (Left Brace key) and Dollar/Asterisk/Euro (Right Brace key).

I set up a nested shortcut test that just types Right_Brace as output.

    C("Alt-Grave"): {                       # Dead Keys Accent Grave
        C("x"): {
            C("z"): C("Right_Brace"),

The output from this with the US software layout is of course ]. A right brace.

But with the AZERTY layout active the result is $. Which is the character on the key in the right brace location.

So keyszer/xkeysnail is still "typing" what it sees as RIGHT_BRACE and that gets translated by the keyboard layout into the appropriate character for that key on that layout, to be received by an application.

To actually get a right brace to come out from the AZERTY layout, the remapper would need to have a way to "type" Alt_Gr+Degree (usually the physical Minus key). Well, I guess that's just RAlt-Minus, unless it depends on exactly how the DE is set up to use a key for special "Level3" characters. Right now I have "Right Alt" designated in the GNOME settings, in addition to the Alt_Gr tweak in Kinto's config.

And it looks like that does work for the AZERTY layout. This produces a right brace when AZERTY is active:

    C("Alt-Grave"): {                       # Dead Keys Accent Grave
        C("x"): {
            C("z"): C("RAlt-Minus"),

Confused yet? I sure am. Seems problematic to have a completely different key.py for non-US keyboard layouts. And actual keyboard shortcut actions don't seem to change. It's like the keyboard layout is only changing things on a certain layer, above where shortcuts are dealt with. Terminal, text editor and web browser all continue to do tab navigation the same way when I switch to AZERTY.

But when "typing" out strings this causes a lot of mismatching:

Inputs:
C("RC-Alt-2"): [ST("\u00a1🌹Strings are useful ~!@#$%^&*()_+{}:\"<>? ,.;'[]-=/\\` 12345🌹\u00a1"),Key.ENTER,Key.ENTER], 
C("Shift-Alt-RC-u"): [C("Shift-slash"),UC(0x00a1),UC(0x00a2),UC(0x00a3),C("Shift-slash"),C("Enter")],

AZERTY layout result:
§¡¢£§
¡🌹Strings qre useful ²1234567890°+M̈%./§ ;:mù⁾=!*² &é"'(🌹¡

QWERTY layout result:
?¡¢£?
¡🌹Strings are useful ~!@#$%^&*()_+{}:"<>? ,.;'[]-=/\` 12345🌹¡

As I suspected, when the remapper tries to "type" an "a" with the AZERTY layout active, it ends up being a "q".

And you should be able to test all of this just by changing your own keyboard layout. No need to acquire a "real" non-US keyboard, from what I can tell. The labels on the keys won't even necessarily completely match the layout on the keyboard viewer, although it would probably be closer with something like the Logitech MX Keys.

[joshgoebel]

Wow, thanks for the detailed writeup.

If I switch to a French AZERTY layout, the internal and external keyboard both start acting as if they are a French AZERTY keyboard, as far as most applications are concerned. But evtest continues to show the same key events.

I assumed as much on some level, but the applying to all keyboards shows that it's working at a layer above the individual devices.

unless it depends on exactly how the DE is set up to use a key for special "Level3" characters

It does in my experience... though this could vary by distro I suppose as well and their own default setups.

But when "typing" out strings this causes a lot of mismatching:

Yeah, that is going to get pretty complex and require reverse mappings built into keyszer... so I'm happy pushing that off to another day... if possible we'd perhaps want to look to supporting the operating systems own keyboard mapping tables rather than reinvesting the wheel here.

[RedBearAK]

@joshgoebel

we'd perhaps want to look to supporting the operating systems own keyboard mapping tables

Yes.

I had an idea that there should be a translation layer wrapped around key.py as a central place to fix things using existing layout tables. But the fact that keyboard shortcut responses don’t change when the layout changes kind of threw that idea out the window. Ultimately it would seem that if the user wants to “type” something that is meant for an app to recognize as a string rather than a shortcut of some kind, the only way to make it work reliably across layouts is to make them use the string processor function for that purpose.

I can’t see a way around the fact that all of the shortcuts in the config file will always have to refer to the way the keys are labeled on a US layout. Potentially very confusing for any non-US user trying to fix a shortcut or implement a new one.

Existing layout info should at least be able to create a forward-reverse reference table so that someone with AZERTY or something else could look up the proper key label to use to make a shortcut work. To make the labeled Ctrl-Less_Than do something on AZERTY it would need to be Ctrl-Key_102nd.

Or they can be told to run evtest with a filter to simplify the output to just the key label they need to find.

[joshgoebel]

Well it's more complex than just keys because it gets into key combos... these mapping tables usually have keycodes on one side and then variants on the other:

keycode       plain   with shift    with alt   with super  with alt-gr (scancodes)
Key.A          'a'       'A'                

So keyscodes directly only map to plain... and then to map from scancode back to keycode requires knowing which modifier you also need to hold... and assuming all your modifiers are discrete... hence alt-gr MUST be a different key than alt or there is no way to hold AltGr-Alt-B as you might need on some keyboard to get a certain character, etc.

This is probably going to remain largely unsolved until we find someone super interested in this in particular... but then (other than the tables themselves) it might actually be a simple mapping layer between two or three things, but I'm not certain.