Bug 8068

Created attachment 6746 [details] [review]
macbook support and alt_win option

This key layout also applies to older Mac laptops too (powerbook, ibook), so
maybe it should be named "applenotebook" or something more generic.

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;)

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.

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.

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.

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.

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.

Created attachment 6772 [details] [review]
swap_ralt_rwin

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.

Also, it seems like you commited the swap patch to cvs.

Oh, and the rest of the commit worked fine.

Oh, it would be nice to get real KeySyms for the brightness up/down and laptop
light off/up/down keys.

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.

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.
> 

Yeah, and XKeysymDB. New symbols something like:
XF86BrightnessUp, XF86BrightnessDown, XF86KeyboardLightOff,
XF86KeyboardLightDown, XF86KeyboardLightUp.

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.

Alexander, could you please check new patch?

Created attachment 6787 [details] [review]
swap lalt and lwin

With that selected, neighter alt-x or win-x gives me "meta-x" in emacs, so its
missing some compatibility thing.

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

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

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

Denis, in both cases the state is 8, which is Mod1. Why do you think Mod4 is
relevant?

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.

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.

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.

> 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.

Patch in comment 23 works great! Excellent!

(In reply to comment #29)
> Patch in comment 23 works great! Excellent!
> 

OK, I'll commit it. Great thanks to Denis.

committed.