Hi, macintosh(macbook) keycodes have been requested by BZ8068. Joe Shaw told that this name is misleading, because this model also applies to older Mac laptops. According to debian-powerpc folks, the situation is quite different, kernel should always send the same keycodes as with PC keyboards. See drivers/macintosh/adbhid.c in linux tree: switch (original_handler_id) { default: printk("<unknown>.\n"); input_dev->id.version = ADB_KEYBOARD_UNKNOWN; break; case 0x01: case 0x02: case 0x03: case 0x06: case 0x08: case 0x0C: case 0x10: case 0x18: case 0x1B: case 0x1C: case 0xC0: case 0xC3: case 0xC6: printk("ANSI.\n"); input_dev->id.version = ADB_KEYBOARD_ANSI; break; case 0x04: case 0x05: case 0x07: case 0x09: case 0x0D: case 0x11: case 0x14: case 0x19: case 0x1D: case 0xC1: case 0xC4: case 0xC7: printk("ISO, swapping keys.\n"); input_dev->id.version = ADB_KEYBOARD_ISO; i = hid->keycode[10]; hid->keycode[10] = hid->keycode[50]; hid->keycode[50] = i; break; case 0x12: case 0x15: case 0x16: case 0x17: case 0x1A: case 0x1E: case 0xC2: case 0xC5: case 0xC8: case 0xC9: printk("JIS.\n"); input_dev->id.version = ADB_KEYBOARD_JIS; break; } The problem is that kernel misdetects keyboard under some circumstances. For instance when an USB keyboard is plugged in, the kernel detects the internal keyboard and set keyboard to ISO instead of ANSI (or the opposite). According to BZ8068, MacBook keyboards are also misdetected, Hopefully kernel will get fixed in the future to recognize MacBook keyboards, and users will then need to use macintosh(macintosh) keycodes and no more macintosh(macbook), which will be very confusing. Alexander and Joe, any opinion about this? (I took the liberty to Cc you, hope you do not mind) Here are some links: http://lists.debian.org/debian-powerpc/2006/09/msg00102.html http://lists.debian.org/debian-powerpc/2006/09/msg00130.html
Why should they use macintosh(macintosh) instead of macintosh(macbook), even if we fix the macintosh(macbook) version to not swap the keys? They definately do not have the same geometry for instance, so if you use macintosh(macintosh) then the gnome utilities will show the wrong graphical layout. Also, by selecting macbook instead of the generic one you automatically get inet(apple_laptop) which is needed to get a mode switch key. Sure, macintosh(macintosh) might "work", but macintosh(macbook) would work better. I see no reason to remove it at all. But sure, once the kernel is fixed we should probably remove the key remapping.
> Why should they use macintosh(macintosh) instead of macintosh(macbook), even if > we fix the macintosh(macbook) version to not swap the keys? > > They definately do not have the same geometry for instance, so if you use > macintosh(macintosh) then the gnome utilities will show the wrong graphical > layout. Also, by selecting macbook instead of the generic one you automatically > get inet(apple_laptop) which is needed to get a mode switch key. There is some misunderstanding, I am at the moment only discussing keycodes, in particular keycodes/macintosh(macbook), this is not related to geometry and symbols. I propose to rename keycodes/macintosh(macbook) into keycodes/macintosh(swap) or keycodes/macintosh(badmap) or something else because the macbook name is misleading, this is a kernel issue which might get fixed in the future, this is not related to MacBook models.
Ah, that makes more sense. keycodes/macintosh(badmap) sounds good to me.
Ok, thanks. By the way, since Mac models will need keycodes/macintosh or keycodes/macintosh(badmap) depending on their kernel, an option may be a better idea. Sergey, do you have any problem with adding a ! option = keycodes apple:badmap = +macintosh(badmap) section in rules/base? If not, I will send a proper patch.
Created attachment 6949 [details] [review] Rename keycodes/macintosh(macbook) This patch removes keycodes/macintosh(macbook) and adds two options: apple:badmap and apple:goodmap. The former is called for $macbooks, so there is no change, except that users can override model keucodes if needed.
Looks good to me.
Created attachment 7049 [details] [review] Patch updated This updated patch adds apple:badmap into rules/base.xml.in. Macbooks use this option, so when the kernel gets fixed, keys will be swapped again, which is why apple:goodmap is provided so that users can fix their XKB configuration without upgrading xkeyboard-config. I do not know though if apple:goodmap should also be put in rules/base.xml.in
This patch looks clean enough for me. Though I am not excited about the whole idea - but since we have to support these odd ADB keyboards, it seems to be the best we can do for now.
Just one question: whether keycodes from macintosh(goodmap) should be used in any existing ruleset? Or available as independent XkbOption?
Anyway, existing patch is committed.
> Just one question: whether keycodes from macintosh(goodmap) should be used in > any existing ruleset? Or available as independent XkbOption? Macintosh keycodes should be similar to PC. (There are also changes for multimedia keys which need more investigations, this is why I kept macintosh and did not replace it by xfree86 for now) But international Macintosh keyboards are special, 2 keys are swapped. Kernel handles this situation, it swaps the keycodes returned by these two keys when he detects such a keyboard. Of course, this autodetection sometimes fails, this is why people complained about these 2 swapped keys. Currently macbook7{8,9} models have keycodes macintosh+macintosh(badmap) because it is known that Linux kernel misdetect it. It will hopefully be fixed in the future, and macintosh(badmap) will have to be dropped, otherwise keys are swapped again. This can be done by upgrading xkeyboard-config (but this is difficult because keycodes configuration depend on kernel version), or with this apple:goodmap option which cancels macintosh(badmap). So for now this option is useless, but it will become useful in the future if kernel gets fixed.
ok, I see now. Thanks Denis, closing this one.
Denis, don't you think it is time to switch macbooks to use apple(goodmap)? It seems in #12716, kernel is now using proper mapping.
I agree by principle; this is a kernel issue, so it is better to be safe on our side and let kernel folks fix it.
Deal, the change is committed
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.