Bug 252235 - x11/xorg: MacBook Pro 8,3 faulty key mapping
Summary: x11/xorg: MacBook Pro 8,3 faulty key mapping
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
Depends on:
Reported: 2020-12-28 16:23 UTC by Jason W. Bacon
Modified: 2020-12-28 19:12 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)


Note You need to log in before you can comment on or make changes to this bug.
Description Jason W. Bacon freebsd_committer 2020-12-28 16:23:08 UTC
Under X11, the ` and ~ keys return < and > by default.

Found a fix in this thread:


The problem is the TLDE and LSGT mappings are switched in /usr/local/share/X11/xkb/symbols/us.

Problem does not occur on a MacBook Pro 2,2.  Maybe the keyboard scan codes are different in newer models?

Key mappings are correct in a vt console using keymap="us.macbook".

The following does NOT fix the issue:

<<<ROOT@beluga.acadix>>> /home/bacon 48 # cat /etc/X11/xorg.conf.d/macbook-xkb.conf 
Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
	Option "XkbRules" "xorg"
	Option "XkbLayout" "us"
	Option "XkbVariant" "mac"

I hacked around it for now by adding

setxkbmap -layout us -variant mac

to the Xsession file, but this of course only works after login.  Keyboard is still confused in the xdm panel, so passwords constaining ~ or ` won't work.
Comment 1 Jason W. Bacon freebsd_committer 2020-12-28 16:25:27 UTC
Forgot to mention, I also had to edit the "mac" section in /usr/local/share/X11/xkb/symbols/us, switching the LSGT and TLDE tags, otherwise the setxkbmap command would not help.
Comment 2 Michael Gmelin freebsd_committer 2020-12-28 16:33:26 UTC
(In reply to Jason W. Bacon from comment #0)

Could you try putting the config snippet below into "/etc/X11/xorg.conf.d/macbook-xkb.conf" instead of what you have in there at the moment?

Section "InputClass"
        Identifier "libinput keyboard catchall"
        MatchIsKeyboard "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
        Option "XkbRules" "evdev"
	Option "XkbLayout" "us"
	Option "XkbVariant" "mac"
Comment 3 Jason W. Bacon freebsd_committer 2020-12-28 17:27:47 UTC
(In reply to Michael Gmelin from comment #2)

Yep, that works thanks.

Would you consider this a long-term fix, or are the specifics likely to change in the not-too-distant future?
Comment 4 Michael Gmelin freebsd_committer 2020-12-28 17:39:27 UTC
(In reply to Jason W. Bacon from comment #3)

AFAIK this should be stable (given that we just moved to evdev/libinput being the default this year).

In case you're using multiple keyboards (e.g., an external USB keyboard) that have different layouts, you might want to match the input class more precisely by adding additional match rules (like MatchProduct or MatchVendor).

See also https://www.x.org/releases/current/doc/man/man5/xorg.conf.5.xhtml#heading9
Comment 5 Jason W. Bacon freebsd_committer 2020-12-28 19:12:48 UTC
Great, thanks for the additional info.

I'd love to hear from anyone using a newer MacBook about the keymap issue, given that my MacBooks range from very old to fossilized.  The problem in symbols/us is here:

xkb_symbols "mac" {

    include "us(basic)"
    name[Group1]= "English (Macintosh)";

    // Slightly improvised from http://homepage.mac.com/thgewecke/kblayout.jpg
    key <LSGT> { [   section,  plusminus,       section,        plusminus ] };
    key <TLDE> { [     grave, asciitilde,    dead_grave,        dead_horn ] };
    key <AE01> { [         1,     exclam,    exclamdown,            U2044 ] };

Switching LSGT and TLDE fixes the problem on my MacBook Pro 8,3 (from 2009), but I wonder if this would actually break newer Macs.  If that's the case, all I can think of is defining a separate variant.