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