Bug 8068 - Geometry and keycodes for MacBook/MacBook Pro
Geometry and keycodes for MacBook/MacBook Pro
Status: RESOLVED FIXED
Product: xkeyboard-config
Classification: Unclassified
Component: General
unspecified
x86 (IA32) Linux (All)
: high normal
Assigned To: xkb
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-30 03:08 UTC by Alexander Larsson
Modified: 2006-09-06 10:10 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
macbook support and alt_win option (13.77 KB, patch)
2006-08-30 03:09 UTC, Alexander Larsson
Details | Splinter Review
New version (without altwin part) (13.90 KB, patch)
2006-08-31 08:35 UTC, Alexander Larsson
Details | Splinter Review
swap_ralt_rwin (1.91 KB, patch)
2006-08-31 15:50 UTC, Sergey V. Udaltsov
Details | Splinter Review
swap lalt and lwin (1.88 KB, patch)
2006-09-01 14:27 UTC, Sergey V. Udaltsov
Details | Splinter Review
Set Mod4 (237 bytes, patch)
2006-09-05 07:38 UTC, Denis Barbier
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Larsson 2006-08-30 03:08:11 UTC
I've written a geometry spec and rules for the MacBook/MacBook Pro.

It also includes a new option altwin:alt_win which puts alt on the windows keys.
The window key is actually the apple key for the macbook of course, but its the
key next to the spacebar where i'm used to alt being.
Comment 1 Alexander Larsson 2006-08-30 03:09:07 UTC
Created attachment 6746 [details] [review]
macbook support and alt_win option
Comment 2 Joe Shaw 2006-08-30 09:34:08 UTC
This key layout also applies to older Mac laptops too (powerbook, ibook), so
maybe it should be named "applenotebook" or something more generic.
Comment 3 Sergey V. Udaltsov 2006-08-30 16:39:12 UTC
Alexander, your patch generally makes sense to me, but there are some questions:
1. It would be easier for me to accept two patches: one for alt_win, another for
macbook. Since alt_win is a small patch, I'd commit it faster.
2. Why do you need macbook78? If we just define only one macbook model (which
will be exactly same as your macbook79) - what's the problem with it? My
objection is based on the fact that you put country/language attribute (US/Intl)
into the model name - which I do not like.
3. Would it be possible to implement macbook keyboard inside symbols/inet? I
would like to move as much code out of *_vndr directories as possible. Actually,
there is already PowerG5 keyboard in symbols/inet file - may be we could just
merge all these definitions into inet(mac) symbols or smth?
4. Would it be possible to implement "switch win and alt" as a separate
XkbOption? So people could use on other keyboards. And - I would not enable it
by default on macbook keyboard model (would not "include", in XKB terms). At the
end of the day, it is incorrect when default behavior does not match the
engraved labels (even if people consider these labels to be engraved "incorrectly").
5. I do not really like the idea of switching RALT and "right apple" on keycode
level. Could you please do it in the symbols file?

That's basically it. More questions may follow as we go;)
Comment 4 Alexander Larsson 2006-08-31 00:34:36 UTC
1. I can split up the patch

2. There are two types of keyboards on MacBooks. Some have 78 keys (the US
versions) and some have 79 (the international versions). The difference between
them are similar to the difference between pc104 and pc105. The two models are
used so that  you get the correct geometry displayed.

3. It could be implemented anywhere I guess. I just assumed that that the apple
vendor area would be the right place for it since its from apple. Merging the
mac extra symbols sounds like it could work, as at least for the eject button
the keys seems to be the same.

4. I tried to implement switch win and alt, but I failed. There was always
something that didn't quite work. Like emacs didn't handle meta (alt) correctly
and things like that. It might be doable, but you would need to know more about
xkb than I.

5. I had similar troubles with this as the switch win and alt thing. Using
symbol changes i could make it give Alt_R instead of Super_R, but the whole
machinery that turns Alt_R into ModeShift or whatever didn't happen, so it
didn't actually work for producing the ModeShift keys. Same here, i just don't
know this shit well enough to understand all the details. I can give it another
try though.
Comment 5 Denis Barbier 2006-08-31 03:00:24 UTC
Sergey, I am currently discussing issues about macintosh layouts
at http://lists.debian.org/debian-powerpc/2006/08/msg00322.html
I believe that moving everything away from macintosh_vndr is
a bad idea, see for instance the KP_Equal issue in
 http://lists.debian.org/debian-powerpc/2006/08/msg00351.html
Before reading this bugreport I implemented another solution by
providing a new macbook model with keycodes swapped.

The discussion on the debian-powerpc mailing list is an attempt
to get feedback from users, nothing is settled, I provide
unofficial packages at the moment and will send the patch here
when bugs are fixed.  You will have the last word since I do
not want to diverge too much from pristine sources.
Comment 6 Alexander Larsson 2006-08-31 08:35:52 UTC
Created attachment 6765 [details] [review]
New version (without altwin part)

This new patch is against the current cvs. It has some changes compared to the
old one:
1. The geometries are renamed, since they could be used for other mac laptops
too
2. Right Alt is not handled in the keycodes part. Instead its handled by using
inet(apple_laptop) which maps the enter key (next to the option key) to alt_r
3. Mappings for more special keys. Unfortunately there is no perfect match for
all the keys.

With this patch the power_g5 and the macbooks will use the standard pc maps,
whereas the other macintosh stuff use the old macintosh_vndr stuff. The vendor
mac maps didn't really work well for me. At least the swedish one lacked all
the alt-gr keys. I think the right approach is to move to using a variant like
se(mac) or se(mac_nodeadkeys) if you really want to fix the few differences
from the pc maps. (This is only affects one key for swedish at least.)

I tried again to implement swap alt and win keys, but I'm just not able to make
it work. Help would be appreciated.
Comment 7 Sergey V. Udaltsov 2006-08-31 14:45:54 UTC
I committed your stuff, except for geometry - I merged your apple to existing
macintosh and changed names. Other than this, it should be ok now. Will look
into alt_win issue. At the moment, could you please check that my commit is ok.
Comment 8 Sergey V. Udaltsov 2006-08-31 15:49:23 UTC
Alexander, I created swap_ralt_rwin (see attachment). Could you please try it
and if it does not work - tell me how I could check it.
Comment 9 Sergey V. Udaltsov 2006-08-31 15:50:23 UTC
Created attachment 6772 [details] [review]
swap_ralt_rwin
Comment 10 Alexander Larsson 2006-09-01 03:30:46 UTC
Oh, thats not what i want. I want the left alt and the left windows key to swap
places, because my keyboard looks like:
[ctrl][alt][win][   space   ][win][kp_enter]

The apple_laptop stuff turns kp_enter into Mode_Shift, so i get an AltGr, but i
really like the left alt key to be right next to the space bar.
Comment 11 Alexander Larsson 2006-09-01 03:31:11 UTC
Also, it seems like you commited the swap patch to cvs.
Comment 12 Alexander Larsson 2006-09-01 03:31:41 UTC
Oh, and the rest of the commit worked fine.
Comment 13 Alexander Larsson 2006-09-01 03:34:06 UTC
Oh, it would be nice to get real KeySyms for the brightness up/down and laptop
light off/up/down keys.
Comment 14 Sergey V. Udaltsov 2006-09-01 03:35:52 UTC
Ghm, I thought you wanted RAlt/RWin swapped. OK, I'll try to swap LAlt and LWin.

(In reply to comment #10)
> Oh, thats not what i want. I want the left alt and the left windows key to swap
> places, because my keyboard looks like:
> [ctrl][alt][win][   space   ][win][kp_enter]
> 
> The apple_laptop stuff turns kp_enter into Mode_Shift, so i get an AltGr, but i
> really like the left alt key to be right next to the space bar.
Comment 15 Sergey V. Udaltsov 2006-09-01 03:36:34 UTC
How do you mean "real keysyms"? New entries in keysymdef.h?

(In reply to comment #13)
> Oh, it would be nice to get real KeySyms for the brightness up/down and laptop
> light off/up/down keys.
> 

Comment 16 Alexander Larsson 2006-09-01 03:48:29 UTC
Yeah, and XKeysymDB. New symbols something like:
XF86BrightnessUp, XF86BrightnessDown, XF86KeyboardLightOff,
XF86KeyboardLightDown, XF86KeyboardLightUp.
Comment 17 Sergey V. Udaltsov 2006-09-01 03:50:04 UTC
Good idea! Try to push it on #freedesktop (at freenode). Or in xorg maillist.
These symbols could be useful.

(In reply to comment #16)
> Yeah, and XKeysymDB. New symbols something like:
> XF86BrightnessUp, XF86BrightnessDown, XF86KeyboardLightOff,
> XF86KeyboardLightDown, XF86KeyboardLightUp.

Comment 18 Sergey V. Udaltsov 2006-09-01 14:27:08 UTC
Alexander, could you please check new patch?
Comment 19 Sergey V. Udaltsov 2006-09-01 14:27:48 UTC
Created attachment 6787 [details] [review]
swap lalt and lwin
Comment 20 Alexander Larsson 2006-09-04 05:21:22 UTC
With that selected, neighter alt-x or win-x gives me "meta-x" in emacs, so its
missing some compatibility thing.
Comment 21 Sergey V. Udaltsov 2006-09-04 10:45:51 UTC
Alex,

Since I don't have emacs, I cannot really test it. Could you please run emacs on
any system where it works correctly - and send me the output of "xev" utility
when you press "meta-x" - and also the output of xev utility on the broken
system? I would like to compare them and see whether I can spot the difference.
Thanks
Comment 22 Alexander Larsson 2006-09-05 04:09:24 UTC
Pressing alt-x with the normal setup (emacs works):

KeyPress event, serial 29, synthetic NO, window 0x3a00001,
    root 0x3e, subw 0x0, time 2107944547, (78,141), root:(88,214),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False
KeyPress event, serial 29, synthetic NO, window 0x3a00001,
    root 0x3e, subw 0x0, time 2107945947, (78,141), root:(88,214),
    state 0x8, keycode 53 (keysym 0x78, x), same_screen YES,
    XLookupString gives 1 bytes: (78) "x"
    XmbLookupString gives 1 bytes: (78) "x"
    XFilterEvent returns: False
KeyRelease event, serial 29, synthetic NO, window 0x3a00001,
    root 0x3e, subw 0x0, time 2107946083, (78,141), root:(88,214),
    state 0x8, keycode 53 (keysym 0x78, x), same_screen YES,
    XLookupString gives 1 bytes: (78) "x"
    XFilterEvent returns: False
KeyRelease event, serial 29, synthetic NO, window 0x3a00001,
    root 0x3e, subw 0x0, time 2107947155, (78,141), root:(88,214),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Pressing win-x (really apple-x) with altwin(swap_lalt_lwin):

KeyPress event, serial 29, synthetic NO, window 0x3600001,
    root 0x3e, subw 0x0, time 2108234854, (119,109), root:(124,742),
    state 0x0, keycode 115 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False
KeyPress event, serial 29, synthetic NO, window 0x3600001,
    root 0x3e, subw 0x0, time 2108235430, (119,109), root:(124,742),
    state 0x8, keycode 53 (keysym 0x78, x), same_screen YES,
    XLookupString gives 1 bytes: (78) "x"
    XmbLookupString gives 1 bytes: (78) "x"
    XFilterEvent returns: False
KeyRelease event, serial 29, synthetic NO, window 0x3600001,
    root 0x3e, subw 0x0, time 2108235662, (119,109), root:(124,742),
    state 0x8, keycode 53 (keysym 0x78, x), same_screen YES,
    XLookupString gives 1 bytes: (78) "x"
    XFilterEvent returns: False
KeyRelease event, serial 29, synthetic NO, window 0x3600001,
    root 0x3e, subw 0x0, time 2108236446, (119,109), root:(124,742),
    state 0x8, keycode 115 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
Comment 23 Denis Barbier 2006-09-05 07:38:01 UTC
Created attachment 6824 [details] [review]
Set Mod4

There are two problems: Mod4 was not updated, and Macintosh layouts use
different modifiers.  This patch fixes the former, I am still working on
the latter
Comment 24 Sergey V. Udaltsov 2006-09-05 07:45:34 UTC
Denis, in both cases the state is 8, which is Mod1. Why do you think Mod4 is
relevant?
Comment 25 Denis Barbier 2006-09-05 08:08:18 UTC
Because some apps, like emacs, manage modfiers on their own.
See 'xmodmap -pm', Super_L is defined for both mod1 and mod4.
With my patch, I believe that emacs should work on pc models,
but I did not test because it is not installed.
Comment 26 Sergey V. Udaltsov 2006-09-05 08:24:23 UTC
Ghm. Then I hate those apps:) Thanks for the explanation. Let's wait whether
this fix help Alexander.

(In reply to comment #25)
> Because some apps, like emacs, manage modfiers on their own.
> See 'xmodmap -pm', Super_L is defined for both mod1 and mod4.
> With my patch, I believe that emacs should work on pc models,
> but I did not test because it is not installed.

Comment 27 Denis Barbier 2006-09-05 08:37:14 UTC
In fact my previous explanation was quite inaccurate.
The real problem is that <LALT> was still bound to
mod1, and thus Alt-x and Win-x both produced x with
state 8 with xev, so this is really an XKB problem.
Comment 28 Sergey V. Udaltsov 2006-09-05 08:40:31 UTC
> The real problem is that <LALT> was still bound to
> mod1, and thus Alt-x and Win-x both produced x with
> state 8 with xev, so this is really an XKB problem.
But it is not a problem if LALT is bound to Mod1 as long as LWIN is bound to it
as well (as we see, it is bound - LWIN changes the state to 8). So from this
explanation is it not clear why LWIN-x (which is effectively "Mod1"-x) does not
work in emacs. I will think your explanation about internal handling of
modifiers in emacs is more correct.
Comment 29 Alexander Larsson 2006-09-06 01:34:34 UTC
Patch in comment 23 works great! Excellent!
Comment 30 Sergey V. Udaltsov 2006-09-06 10:07:38 UTC
(In reply to comment #29)
> Patch in comment 23 works great! Excellent!
> 

OK, I'll commit it. Great thanks to Denis.
Comment 31 Sergey V. Udaltsov 2006-09-06 10:10:22 UTC
committed.