xkeyboard-config: Cannot type Shift+Fx with default settings #17
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The kernel currently maps Fn+Fx to Fx (and naked Fx to the media keys), as intended. However, something in xkeyboard-config with the default settings (jp/applealu_jis, but I'm guessing this affects all models using the default applealu models) is mapping Shift+Fx again to the media keys (in fact, not the same set of media keys as on the physical keys). As a result, Shift+Fn+Fx, which is supposed to register as Shift+Fx, instead registers as Shift+. (Tested on KDE Plasma)
Maybe it's time to create new keyboard models for Apple Silicon (and then also consider dealing with the Fn key business there instead of the kernel)?
reproduced on iso and ansi variants. I was confused for a little since F3 - F7 are not mapped and work as expected. The other keys seem to map to the media key on the key cap though.
This is a good argument for defining new keyboard layouts for Apple Macbooks (at least starting with Apple silicon). This should also help with the inconsistent mapping on different ISO variants.
I'm preparing spi-hid and hid_apple/magicmouse for upstream submission but I'll put that on hold until we have new xkeyboard-config layouts.
Metadata Update from @jannau:
Metadata Update from @jannau:
Looks like the lines following https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/master/symbols/macintosh_vndr/apple#L75 are responsible for this.
This is confusing. On top of this, there's an issue where the xwayland keyboard state is not synced properly (possibly triggered by a user switch?). A second ago, in xev, only F11-F12 got remapped for me (hijacked by kde hotkeys), but that's because those are the only media keys that have Shift+ chord global hotkeys. I toggled the keyboard model to something else and back, and now xwayland behaves consistently (F1-F2 remapped, F3-F6 passed through (I'm guessing your F7 was an off by one?), F7-F10 remapped, F11-F12 not reported as they are global hotkeys).
While xwayland was behaving unexpectedly (as intended, but not reproducing the bug), kde global hotkey capture buttons did report the media keys. So it was strictly an xwayland keymap sync issue.
F1-F2 do not match the caps, they are being mapped to keyboard brightness, not screen brightness.
yes, F7 was off-by-one and I missed
keyboardbefore brightness down/up for F1/F2.Defining Shift + Display brightness down/up as Keyboard brightness down/up looks useful in the absence physical keyboard brightness keys. Makes probably more sense as default shortcut in desktop environments rather than xkeyboard-config.
I tested with KDE's custom shortcut input field which which complains about the conflict with the existing mapping for the audio volume control but shows Shift + Volume Up/Down.
also for reference recent applealu related PRs:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/792
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/793
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/809
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/812
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/813
Shift+brightness is actually "small step" (1%) monitor brightness control by default. I usually map alt(option) as the modifier for keyboard brightness. Should just be a default on the KDE Plasma side, it doesn't make sense to bake into the keymap as a hack.
bits/090-spi-hid has now fnmode 4 which restrict extra fn kw maps to backspace, enter, up, right, down, left. This is the intended mapping for upstream linux and should allow testing new xkeyboard keyboard layouts.