Keyboard Logitech MX Keys Mac

funsheep commented 1 year ago

Keyboard Logitech MX Keys Mac connected via bluetooth to an intel laptop with a build-in classic windows keyboard
Environment

(EV) Toshy env module sees this environment: DISTRO_NAME = 'elementary' DISTRO_VER = '7' SESSION_TYPE = 'x11' DESKTOP_ENV = 'pantheon'

Keyboard Layout is setup as "German (Macintosh)".

Right now,

option and command are switched
command + l for (at) sign (since option and command are switched) produces '¬'
command + e for Euro sign produces '´'

Right now, idk how to fix the layout for the MX keys.

funsheep commented 1 year ago

funsheep@laptop:~$ toshy-devices

List of devices seen by the keymapper (keyszer):

keyszer v0.7.1

Device Name Phys

/dev/input/event0 Power Button PNP0C0C/button/input0 /dev/input/event1 Lid Switch PNP0C0D/button/input0 /dev/input/event2 Sleep Button PNP0C0E/button/input0 /dev/input/event3 Power Button LNXPWRBN/button/input0 /dev/input/event4 AT Translated Set 2 keyboard isa0060/serio0/input0 /dev/input/event5 SynPS/2 Synaptics TouchPad isa0060/serio2/input0 /dev/input/event6 Video Bus LNXVIDEO/video/input0 /dev/input/event7 Video Bus LNXVIDEO/video/input0 /dev/input/event8 Intel HID events
/dev/input/event9 Chicony USB2.0 Camera: Chicony usb-0000:00:14.0-8/button /dev/input/event10 HDA NVidia HDMI/DP,pcm=3 ALSA /dev/input/event11 HDA NVidia HDMI/DP,pcm=7 ALSA /dev/input/event12 HDA NVidia HDMI/DP,pcm=8 ALSA /dev/input/event13 HDA NVidia HDMI/DP,pcm=9 ALSA /dev/input/event14 HDA Intel PCH Mic ALSA /dev/input/event15 HDA Intel PCH Front Headphone ALSA /dev/input/event16 HDA Intel PCH HDMI/DP,pcm=3 ALSA /dev/input/event17 HDA Intel PCH HDMI/DP,pcm=7 ALSA /dev/input/event18 HDA Intel PCH HDMI/DP,pcm=8 ALSA /dev/input/event19 MX Keys Mac Keyboard 20:79:18:14:12:60 /dev/input/event20 MX Keys Mac Mouse 20:79:18:14:12:60 /dev/input/event22 Logitech MX Master 3 for Mac 20:79:18:14:12:60 /dev/input/event21 Keyszer (virtual) Keyboard py-evdev-uinput

Just to provide the complete list.

funsheep commented 1 year ago

The build-in keyboard shows the same switched keys problem with alt and windows-key. also the same special characters appear when trying to enter (at)-sign or euro-sign.

funsheep commented 1 year ago

This is the verbose output: (DD) KBTYPE: 'Windows' | Default type for dev (cached): 'MX Keys Mac Keyboard'

RedBearAK commented 1 year ago

@funsheep

The swapped modifiers is relatively easy to solve, following the instructions in the FAQ:

https://github.com/RedBearAK/toshy#my-keyboard-is-not-recognized-as-the-correct-type

For each keyboard device, you can tell Toshy which type it is, to put the modifiers in the right place for each device. Like this:

###################################################################################################
###  SLICE_MARK_START: kbtype_override  ###  EDITS OUTSIDE THESE MARKS WILL BE LOST ON UPGRADE

keyboards_UserCustom_dct = {
    # Add your keyboard device here if its type is misidentified by isKBtype() function
    # Valid types to map device to: Apple, Windows, IBM, Chromebook
    # Example:
    'My Keyboard Device Name': 'Apple',
    ' AT Translated Set 2 keyboard': 'Apple',
    'MX Keys Mac Keyboard': 'Apple',
}

###  SLICE_MARK_END: kbtype_override  ###  EDITS OUTSIDE THESE MARKS WILL BE LOST ON UPGRADE
###################################################################################################

Also, for 'MX Keys Mac Keyboard' specifically, I can add that device to the built-in device list so it would automatically work correctly in the future.

But the larger problem you may have is that the keymapper uses a key definition file that is only designed for a standard US keyboard layout of key codes. So if you are actually using a German keyboard layout, you may have issues with certain shortcuts or macros. Anything that gets transformed by the keymapper will act as if you are using a US layout.

An example of what happens is that Cmd+A on an AZERTY layout will act as if you pressed Cmd+Q on a US QWERTY layout.

It is possible to create a modified key definition file to work around some of this, but it is not straightforward to completely solve the problem. And the keymapper has no easy way to detect the keyboard layout.

There was another user who was on a German keyboard, but they were using a US layout because they found it easier for coding. So they didn't encounter this layout issue, even though they were using a German keyboard.

RedBearAK commented 1 year ago

@funsheep

If your special characters look like the layout pictured here:

http://iks.cs.ovgu.de/~elkner/keyboard/mac/germankbd.html

Then you will also have another problem, which is that the Option-key special character layouts that I've implemented are only for the standard US layout and the ABC Extended (US) layout. So many of the special characters that you get on a real Mac with Option and Shift+Option won't be in the places you expect.

This is another thing that would need to be modified for non-US keyboard layouts. I have a GitHub repo where I documented the entire collection of special characters for each of the two layouts that I implemented.

https://github.com/RedBearAK/optspecialchars

If someone were to make a new scheme for a different keyboard layout, that documentation would be the place to start. But how it gets implemented would depend on whether you're using the standard key definition file or a new one that matches the keyboard layout better.

The whole situation around non-US layouts is very bad, due to how the keymapper works close to the hardware level.

RedBearAK commented 1 year ago

@funsheep

It might not be as bad as I thought. If you go into the Preferences sub-menu in the tray icon menu and enable "Alt_Gr on Right Cmd", you should be able to access all the level 3/4 extra characters on your German layout. This is set up to work only with the Cmd (or Alt on a PC keyboard) key on the right side of the space bar. That's usually where Alt_Gr is on a PC keyboard.

But, you'll also need to set the "OptSpec Layout" to "Disabled", or it will interfere with the Alt_Gr key.

Otherwise you might be OK for most keyboard shortcuts on the German layout. But if you use shortcuts like Cmd+Z by using what would be the "Y" key on a QWERTY keyboard layout, you'd need to set up a general remap for that (and the actual "Y" key on your layout).

If you let me know about specific problems I can help you fix them. It doesn't look like the layout is nearly as different from the US layout as French AZERTY with its inverted number keys row and other issues.

funsheep commented 1 year ago

@RedBearAK

Thanks to your suggestions I can finally enter @ and \ Works as expect in windowed applications now. I will let you know if I encounter additional problems.

Anyway: Would it be helpful to start documenting this layout as you did for the US? Would this result in "German Layout Support" in the future? Maybe?

RedBearAK commented 1 year ago

Anyway: Would it be helpful to start documenting this layout as you did for the US? Would this result in "German Layout Support" in the future? Maybe?

Let's be very clear about what we mean by that. I'm assuming what you mean at this point is making the keymapper use a "German" key definition file, so that the key codes that the keymapper sees line up properly with what the keyboard layout says the symbol should be. (I still actually don't know for certain the precise terminology to use all the time for this stuff, and there are several levels of things going on.)

Mostly, the keyboard layout is handled by the display server, like X11/Xorg or the Wayland compositor/protocols. But there may be other levels to it, since you can choose the layout and have it work in a TTY console, as far as I know.

Anyway, the keymapper uses a file named key.py to define how the raw key codes seen by evdev map to key symbols, and as far as I know this set of definitions is copied pretty much directly from the Linux kernel input system. You can get into the Python virtual environment folder for keyszer and make a backup copy of this file, and then see if you can edit the file to make it conform to the German keyboard layout better.

In a terminal, to get there:

cd ~/.config/toshy/.venv/lib/python3.11/site-packages/keyszer/models/
cp key.py key.py.original
xdg-open key.py

You may need to modify that path if you have a different Python version in the venv. Elementary may still be on 3.9 or 3.10.

You can also just navigate to ~/.config/toshy/.venv/lib/ in your favorite file manager, and search for the key.py file from there.

I can't promise you will be successful when doing this. When I tried to fix that file to work with French AZERTY, there were issues with all the keys that were "shifted" inversely from the standard US layout. And there are lists that keyszer uses to process punctuation characters in macro strings. Those lists could also require modifications.

There may be other Linux keymappers that don't have this sort of problem with different keyboard layouts, but I think any that rely on evdev like keyszer/xkeysnail does will have the same sort of issue, since evdev is not aware of the layout at all. 😞

I wish I could offer a better solution for international keyboard users.

If you actually meant documenting the Option-key special characters available on the German layout in macOS, that would require a real Mac, and would still be reliant on fixing the key definition file to actually make it work. But having the list available would be pretty handy, potentially.

funsheep commented 5 months ago

@RedBearAK Yes, I actually meant to document that. I have a real mac available and could start with this. However, I would need some input where to start. As far as I understood it:

I make a copy from key.py
In there, I found a complete mapping between some identifiers and - probably - what you mean with key codes
Now, I would need to have some sort of program/cli that provides me with these codes.

I tried xev with some keys. However, the specified keycode and keysymbol are different to what's in the file. Could you point me into the right direction here.

funsheep commented 5 months ago

I found another interesting detail:

on the Gnome Terminal Application - the characters, like curly brackets (reached by alt_gr on the german layout) work perfectly fine - actually the Terminal application has the absolutely correct layout
only in windows applications like the text editor or webbrowser - these characters do not work and produce some recorded input with unicode mappings.

I think, we are almost there - can I somehow make every program behave (interpret the key codes) like Gnome Terminal?

RedBearAK commented 5 months ago

I found another interesting detail:

It's been a long time since I looked at this issue, but what I believe you are describing there is just that the OptSpec layout (Option-key special characters) inside Toshy's config file is only active when using "GUI" apps. You can disable the OptSpec layout for all apps from the tray icon menu.

But that doesn't actually have anything to do with the keymapper sometimes issuing the wrong combo for your German layout when using a combo that the config happens to tell the keymapper to transform into something else. That's what requires editing key.py.

I have to look over this whole thread again, but I think once you disable the OptSpec layout from the tray icon menu or the Toshy Preferences app, your German (Macintosh) should work as expected.

I'm looking into how to use the active layout keymap to make the keymapper behave differently automatically, but I don't know if I'll ever be able to finish that adaptation. It's going to be pretty complicated modifying the keymapper internally.

For fixing up the key.py file to better match the German layout key codes, try evtest, and make sure you are monitoring the real keyboard device. You'll have to disable Toshy while checking the key codes. I would concentrate on only the keys that appear to be different when looking at the US layout compared to the German layout. And even among those keys, only keys that would be part of shortcuts would really need to be fixed in key.py to begin with.

funsheep commented 5 months ago

With the disabling of the OptSpecLayout most of my issues are completely resolved. During my first tests this morning I just ran into one problem I get character ¿ with "alt_gr + ß" instead of "backslash". Anyway, thank you for the suggestion.

I am still not sure, what OptSpecLayout does (it is about the special keys like play, pause, app overview, brightness?). Therefore, to ease the (initial) pain for international users, I suggest to add a short entry that these users should try to disable this feature if they run into troubles.

~~I will now try to solve the backslash problem with the handy tutorial you issued here: https://github.com/RedBearAK/toshy/issues/268#issuecomment-2075562617~~

RedBearAK commented 5 months ago

@funsheep

I am still not sure, what OptSpecLayout does

It's specifically about the "special" characters you get on a Mac when you hold down Option or Shift+Option. Many are accented characters, but there are also a lot of special symbols like math/logic symbols, and unusual punctuation.

When you use Alt_Gr on a PC keyboard, and choose one of the "Macintosh" keyboard layouts, the characters should be largely the same as on a Mac keyboard when using macOS. So it makes my OptSpec implementation inside the Toshy config pretty pointless.

I didn't realize there were "Macintosh" keyboard layouts in Linux, so I implemented all the Option-key special characters from my own US layout, and the "ABC Extended" US layout that has more dead keys. But like key.py, these will only ever be correct for a US layout, and would not match the special characters you'd find on a real Mac with a physical German keyboard, or with the German layout selected in macOS.

Some Linux desktop environments have a "keyboard viewer" that will let you see all the characters on the chosen layout.

I suggest to add a short entry that these users should try to disable this feature if they run into troubles.

I try to address some of that in the FAQ (which is now a Wiki page). But obviously that should be improved. There are also some notes near the top of the README on the main page of the repo. But I doubt most people read much of that.

The OptSpec feature made a lot more sense when I implemented it in Windows with AutoHotkey, as part of the Kinto project. I don't think Windows allows for the selection of those "Macintosh" keyboard layout variants.

funsheep commented 5 months ago

I used the suggested viewer - I am/was totally wrong. The point with my problem of \ vs ¿ is - that the right alt key does not trigger alt_gr as I am used to - I have to press shift + alt key (in that order - for reference for other people). Then everything works as expected. I am able to enter all characters I need, even € symbols or @ :) Really nice.

So, for reference for any German keyboard users reading this:

Go to Toshy Menu > Preferences > Activate Alt_Gr on Right Cmd
check the keyboard layout in Gnome Settings > keyboard > Input Source > (three vertical dots) > View Keyboard Layout - this should show your keyboard layout and - it should show you how it changes when pressing alt or shift + alt to mimic "alt_gr".
If this shows your regular keyboard and every character at the place you expect, then you will be fine. Otherwise add in gnome settings the Input Source with the correct layout.
If pressing alt or alt_gr shows some delayed entering of unicode values like \u1234 - which result in characters entered you do not expect - then disable OptSpecLayout. Go to Toshy menu > OptSpecLayout > Disable

RedBearAK / toshy

Keyboard Logitech MX Keys Mac #79

keyszer v0.7.1

Device Name Phys