I recently purchased a MacBook Pro (the new model) with the express purpose of getting Gentoo on it. Well, that was not a simple task. The most annoying thing was the keyboard. The physical layout is a more or less standard Danish qwerty layout, but no of the layouts in X would convince the MacBook of actually printing the character that was on the key. It took about a week or so of trial and error in "/usr/share/X11/xkb" to produce a layout that worked and was choosable with the Gnome Keyboard Preferences application. I've no idea on how to actually get the right source version and then making a diff as I can't find a public CVS repository so I hereby submit a tar-ball with my modified xkb files in the hope that they can get into the official tree.
Created attachment 11912 [details] Modified file in /usr/share/X11/xkb You will need to add: "/usr/bin/eject" XF86Eject to your ~/.xbindkeysrc file if you want the Eject key to work.
Jules, The public CVS is on freedesktop.org. See here: http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Development Could you please make a patch against a current CVS? Also, I am not sure your variant is macbookpro-specific. Could we call it just "mac"?
(In reply to comment #2) > Jules, > > The public CVS is on freedesktop.org. See here: > > http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Development OK, thanks :-) > Could you please make a patch against a current CVS? Sure. I'll try to do that tomorrow. > Also, I am not sure your > variant is macbookpro-specific. Could we call it just "mac"? I can see several Mac related keyboard layouts in my Gentoo xkb tree. So I honestly wasn't sure what to call it. I therefore just took a Mac'ish but unique name. One more thing: My modification are probably awful. xkb isn't exactly the best documented pieces on a typical linux box... Best regards, jules
Created attachment 11925 [details] [review] Danish keyboard mapping OK, it was'nt so simple to make a patch after all. All of my other modified files (base.lst , base.xml and symbols.dir) seems to be auto-generated. I have no idea on how to decide what should be in the cvs files in order of generating a real patch against current cvs HEAD. If someone know then please look at my modified files in the previous attachment and put it into cvs so that my changes are not lost for other MacBook Pro users. Thanks, jules
Ok, now your patch makes sense to me. So, some critics:) 1. There is no keypad(comma), only kpdl(comma). Same about dot 2. The part about UP/DOWN/LEFT/RIGHT is a bit suspicious to me. Are you saying there are no such keys in macbook pro? If so, that part belongs to inet file (for example, create new model macbook). In the end, that part is not dk-specific, is it? 3. As I said, let's call this variant just "mac". 4. The patch for base.xml.in is missing (though I can figure it out myself).
BTW, I strongly recommemd reading this: http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Rules
(In reply to comment #5) > Ok, now your patch makes sense to me. So, some critics:) > > 1. There is no keypad(comma), only kpdl(comma). Same about dot Yes, I was also wondering about that part.. The reason is that I'm working on Gentoo, so I have nothing to do with 'keypad(comma)'. My part is the 'MacBook Pro' section. > 2. The part about UP/DOWN/LEFT/RIGHT is a bit suspicious to me. Are you saying > there are no such keys in macbook pro? Yes, amazing isn't it? It has only PageUp and PageDown. If so, that part belongs to inet file > (for example, create new model macbook). In the end, that part is not > dk-specific, is it? No, I guess not. > 3. As I said, let's call this variant just "mac". OK, fine with me :-) > 4. The patch for base.xml.in is missing (though I can figure it out myself). I couldn't find base.xml in cvs, only the '.in' file.
(In reply to comment #6) > BTW, I strongly recommemd reading this: > > http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Rules Will do. Thanks, jules
BTW - as told above, I know next to nothing about xkb configuration. I figured it out like a blind man finding gold. Will you do the necessary changes in my "patch" or should I do my homework better? One more thing. The PageUp, PageDown, Home and End buttons has arrows on them, so I think that they have dual function on native Mac OS X. I'll try to attach a picture of it in the next few days. Best regards, jules
> BTW - as told above, I know next to nothing about xkb configuration. I figured > it out like a blind man finding gold. Will you do the necessary changes in my > "patch" or should I do my homework better? Well, if you are interested - I'd prefer you to do the "homework":) > One more thing. The PageUp, PageDown, Home and End buttons has arrows on them, > so I think that they have dual function on native Mac OS X. I'll try to attach > a picture of it in the next few days. Ok, thanks, it would help.
OK, the picture was too big for bugzilla. You can get it here instead: http://www.omesc.com/sites/default/files/downloads/IMG_1756.JPG HTH, jules
Also notice that characters such as {[]}~ and | are missing on the keyboard. I had too add them at their 'natural' places.
I see. Very uncomfortable keyboard...
I finally got some time to look into this again. I think I managed to produce patches for dk and base.xml.in. I'm not sure if the keyboard is MacBook Pro specific enough to warrant the name "macbookpro" but it should be easy enough to change if you dislike it. I'll attach the patches ASAP and I hope that they can be used.
Created attachment 12020 [details] [review] Danish MacBook Pro keyboard mapping
Created attachment 12021 [details] [review] Patch to base.xml.in
BTW - I hope that symbols.dir and base.lst are auto-generated by the build system as I couldn't find them in cvs.
I still do not like the idea to have up/down/left/right in the Danish layout. Could you please put them in the separate model (as described in the contribution rules)? PS symbols.dir and base.lst are really autogenerated
(In reply to comment #18) > I still do not like the idea to have up/down/left/right in the Danish layout. > Could you please put them in the separate model (as described in the > contribution rules)? Yes, I'll try doing that tomorrow. > PS symbols.dir and base.lst are really autogenerated Good ;-)
Created attachment 12034 [details] [review] Danish keyboard on new Santa Rosa MacBook Pro OK, I looked at inet and I hope this patch fixes all outstanding issues. But, and this is a big but, I do not feel comfortable with this patch as I do not understand "the big picture" with these xkb files (despite all of your help). Thanks, jules
I like that version much better. I'll commit it asap (probably with a couple of minor touches).
Thanks :-)
Ghm, I looked at the way mac keyboards are organized (you know, these vars in base.lists.part) and found the situation is more complex than I expected: 1. All $macbooks use special set of keycodes, see keycodes/macintosh and keycodes/macintosh(badmap). These keycodes are slightly different from pc, FK13-FK15, KPEQ, TLDE, LSGT are redefined. Is this correct for your model? 2. All $macbooks have geometry description in geometry/macintosh So, may be your model should not be in $macbooks list, should it? Then, 3. Every $maclaptop is using symbols/inet(apple) and symbols/level3(enter_switch). So, may be your model should not be in $maclaptop either? 4. For $macs, there is a list $macvendorlayouts - which gives special layouts for mac only (see symbols/macintosh_vndr/*). There is already dk in that list. Did you try that layout? May be, your layout should be added there? The plot really thinkens from that point:)
(In reply to comment #23) > Ghm, I looked at the way mac keyboards are organized (you know, these vars in > base.lists.part) and found the situation is more complex than I expected: > 1. All $macbooks use special set of keycodes, see keycodes/macintosh and > keycodes/macintosh(badmap). These keycodes are slightly different from pc, > FK13-FK15, KPEQ, TLDE, LSGT are redefined. Is this correct for your model? How do I verify that? > 2. All $macbooks have geometry description in geometry/macintosh > So, may be your model should not be in $macbooks list, should it? > Then, > 3. Every $maclaptop is using symbols/inet(apple) and > symbols/level3(enter_switch). So, may be your model should not be in $maclaptop > either? > > 4. For $macs, there is a list $macvendorlayouts - which gives special layouts > for mac only (see symbols/macintosh_vndr/*). There is already dk in that list. > Did you try that layout? May be, your layout should be added there? I did try the different Mac layout that the Gnome keyboard Preferences app offered, such as the MacBook/MacBook Pro and MacBook/MacBook Pro (Intl). They did not work. The only layout that works for me is the "Generic 102-key (Intl) PC" combined with my keymap. > The plot really thinkens from that point:) Oh, yes. I feel that I'm on very thin ice here ;-) I'm willing to try/test anything you throw at me, but I'm afraid that I can't be of any qualified value for you as my hackings in xkb configuration is based on hope and gut feeling not firm technical knowledge... Anything I can do?
> > FK13-FK15, KPEQ, TLDE, LSGT are redefined. Is this correct for your model? > How do I verify that? Using xev utility - it displays keycodes (unfortunately not translated to mnemonic names). The first thing to check is these keys - whether they generate keycodes like they are defined in keycodes/xfree86 - or in keycodes/macintosh (any part of it). > I did try the different Mac layout that the Gnome keyboard Preferences app > offered, such as the MacBook/MacBook Pro and MacBook/MacBook Pro (Intl). They > did not work. OK I see. > Oh, yes. I feel that I'm on very thin ice here ;-) I'm willing to try/test > anything you throw at me, but I'm afraid that I can't be of any qualified value > for you as my hackings in xkb configuration is based on hope and gut feeling > not firm technical knowledge... I totally understand. So we have a great opportunity to improve your xkb skills:) Actually, there is no black magic here. We just will try to determine - why and how existing MacBook definitions are different from what you've got. So, let's start with keycodes as I described above.
(In reply to comment #25) > > > FK13-FK15, KPEQ, TLDE, LSGT are redefined. Is this correct for your model? > > How do I verify that? > Using xev utility - it displays keycodes (unfortunately not translated to > mnemonic names). The first thing to check is these keys - whether they generate > keycodes like they are defined in keycodes/xfree86 - or in keycodes/macintosh > (any part of it). Hmm... TLDE I know of - it's '~'. But '~' does not appear on the keyboard at all (see the picture). The keycode I get when I press apple key + the ^ key is 35 (keysym 0xfe53, dead_tilde) on release and press. I get another character if I press the 'alt' key and then the ^ key (dead_diaresis) but the same keycode. I don't know if this is what you want to know? What is FK13-FK15, KPEQ, and LSGT? Thanks, jules
> What is FK13-FK15, KPEQ, and LSGT? Ghm, these keys seem to be missing. You have only 12 functional keys. You do not have keypad's EQUAL (well, may be you do - with Fn key pressed?), but certainly you do have less-greater key LSGT. What is its keycode?
(In reply to comment #27) > > What is FK13-FK15, KPEQ, and LSGT? > Ghm, these keys seem to be missing. You have only 12 functional keys. You do > not have keypad's EQUAL (well, may be you do - with Fn key pressed?), but > certainly you do have less-greater key LSGT. What is its keycode? The keycode of the '<>' button is 94. The '?+=' button has keycode 20 and gives '±' when I hold down the apple key while pressing it. It gives '+' when I hold down the alt or Fn key. It does also gives '+' when no modifier keys are pressed.
> The keycode of the '<>' button is 94. Which definitely tells us that macintosh(badmap) is not for you. In addition, since you did not provide explicit geometry definition (would you consider doing it BTW?) - we'd not put you into $macbooks. We'll put your model into $macs - so at least people would see generic Mac keyboard geometry I'd also put your model into $maclaptops - so that you'd be able to switch to the 3rd level using the key on the right from the right apple key (on the left from arrow keys). That's what people use on other mac laptops. I do not think that level3(win_switch) is correct here. Which of the keys on the picture behaves as the "win" key? What is the keycode? Regarding the up/down/left/right - are you 100% sure these keys do not work on the hardware level so that you have to define 3rd and 4th level explicitly? Could you please test it - just leave inet(media_common) in inet(macbookpro), commenting everything else. If it is the case - it would mean your model is very close to macbook79... > The '?+=' button has keycode 20 and gives '±' when I hold down the apple key > while pressing it. It gives '+' when I hold down the alt or Fn key. It does > also gives '+' when no modifier keys are pressed. Ok, it means you really have no KPEQ key as such.
(In reply to comment #29) > > The keycode of the '<>' button is 94. > Which definitely tells us that macintosh(badmap) is not for you. In addition, > since you did not provide explicit geometry definition (would you consider > doing it BTW?) If time permits, yes. Do you have a HOWTO/guide pointer? > - we'd not put you into $macbooks. > > We'll put your model into $macs - so at least people would see generic Mac > keyboard geometry > > I'd also put your model into $maclaptops - so that you'd be able to switch to > the 3rd level using the key on the right from the right apple key (on the left > from arrow keys). That's what people use on other mac laptops. I do not think > that level3(win_switch) is correct here. Which of the keys on the picture > behaves as the "win" key? What is the keycode? The apple key is the "win" key. I'll check the keycode when I get back home again. > Regarding the up/down/left/right - are you 100% sure these keys do not work on > the hardware level so that you have to define 3rd and 4th level explicitly? 90% sure. > Could you please test it - just leave inet(media_common) in inet(macbookpro), > commenting everything else. If it is the case - it would mean your model is > very close to macbook79... Is there a way to test it from my Gentoo system just by editing the existing xkb configuration files? I'm not all that exited about installing these files from cvs... > > The '?+=' button has keycode 20 and gives '±' when I hold down the apple key > > while pressing it. It gives '+' when I hold down the alt or Fn key. It does > > also gives '+' when no modifier keys are pressed. > Ok, it means you really have no KPEQ key as such. No, apparently not.
> If time permits, yes. Do you have a HOWTO/guide pointer? No, there is no such things (feel free to contribute:). People usually just look at existing geometries. The syntax is simple and straightforward though... Actually, I probably would consider creating a gallery... But do not hurry - first I want to make 101% sure the model macbook79 is not good enough for you. > > Regarding the up/down/left/right - are you 100% sure these keys do not work on > > the hardware level so that you have to define 3rd and 4th level explicitly? > 90% sure. In MacOS, do you press Fn+Up to get PgUp - or Cmd+Up? > Is there a way to test it from my Gentoo system just by editing the existing > xkb configuration files? I'm not all that exited about installing these files > from cvs... Just look into /usr/share/X11/xkb. Sure, it always helps to backup existing files;) One important thing - in rules/base, please replace macintoch(badmap) to macintoch(goodmap) - it is in "model->keycodes" section. It seems your kernel was fixed, so "badmap" is wrong for you.
(In reply to comment #31) > > > Regarding the up/down/left/right - are you 100% sure these keys do not work on > > > the hardware level so that you have to define 3rd and 4th level explicitly? > > 90% sure. > In MacOS, do you press Fn+Up to get PgUp - or Cmd+Up? 'page^' == up 'fn + page^' == PgUp 'apple + page^' == scrolls all the way up
(In reply to comment #32) > (In reply to comment #31) > > > > Regarding the up/down/left/right - are you 100% sure these keys do not work on > > > > the hardware level so that you have to define 3rd and 4th level explicitly? > > > 90% sure. > > In MacOS, do you press Fn+Up to get PgUp - or Cmd+Up? > > 'page^' == up > 'fn + page^' == PgUp > 'apple + page^' == scrolls all the way up BTW - I forgot: By 'page^' I mean the key that is marked with the word 'page' and a little black up-arrow. You can see it in the lower right corner of the keyboard picture.
> 'page^' == up > 'fn + page^' == PgUp > 'apple + page^' == scrolls all the way up This conflicts with your patch. With your patch, apple+page^ would be PgUp. My point is: if "fn + page^" works as PgUp regardless of XKB (does it work or not?), I'd prefer just using model macbook79 and not creating new model. If 'fn + page^" does not work 'll have to find workaround (and probably put it into existing macbook79 (but I'd prefer to hear Denis's opinion on this).
(In reply to comment #34) > > 'page^' == up > > 'fn + page^' == PgUp > > 'apple + page^' == scrolls all the way up > > This conflicts with your patch. With your patch, apple+page^ would be PgUp. My > point is: if "fn + page^" works as PgUp regardless of XKB (does it work or > not?), I'd prefer just using model macbook79 and not creating new model. If 'fn > + page^" does not work 'll have to find workaround (and probably put it into > existing macbook79 (but I'd prefer to hear Denis's opinion on this). I'll check this ASAP when I get home again.
(In reply to comment #35) > (In reply to comment #34) > > > 'page^' == up > > > 'fn + page^' == PgUp > > > 'apple + page^' == scrolls all the way up > > > > This conflicts with your patch. With your patch, apple+page^ would be PgUp. My > > point is: if "fn + page^" works as PgUp regardless of XKB (does it work or > > not?), I'd prefer just using model macbook79 and not creating new model. If 'fn > > + page^" does not work 'll have to find workaround (and probably put it into > > existing macbook79 (but I'd prefer to hear Denis's opinion on this). > > I'll check this ASAP when I get home again. You are right. Removing my modifications for UP, DOWN, LEFT and RGHT makes these keys work with Fn+key instead of apple+key. >
> You are right. Removing my modifications for UP, DOWN, LEFT and RGHT makes > these keys work with Fn+key instead of apple+key. Great! Which means you really have to use the model MacBook Pro (intl) AKA macbook79 - just replace (locally on your machine) keycodes macintosh(badmap) with macintosh(goodmap) in rules/base. That's more or less it, about the model. Now, about your dk variant. Could you please check the file symbols/macintosh_vndr/dk for me - there are several variants in it. Do they make sense at all? Which would be the closest to the one you want? Please understand me right - I have no intention to drop your variant, I am just trying to figure out the situation with Danish layouts for macs, ok?
(In reply to comment #37) > > You are right. Removing my modifications for UP, DOWN, LEFT and RGHT makes > > these keys work with Fn+key instead of apple+key. > Great! Which means you really have to use the model MacBook Pro (intl) AKA > macbook79 - just replace (locally on your machine) keycodes macintosh(badmap) > with macintosh(goodmap) in rules/base. I have this in rules/base: ! option = keycodes apple:badmap = +macintosh(badmap) apple:goodmap = +macintosh(goodmap) Do you want me to drop the 'badmap' line? > That's more or less it, about the model. Now, about your dk variant. Could you > please check the file symbols/macintosh_vndr/dk for me - there are several > variants in it. Do they make sense at all? Which would be the closest to the > one you want? The closest one is 'basic' I think... > Please understand me right - I have no intention to drop your variant, I am > just trying to figure out the situation with Danish layouts for macs, ok? Absolutely! I'm extremely grateful for your help with xkb on my Mac. Please believe me, I have no feelings in particular for my variant - I just want my keyboard to work :-)
> ! option = keycodes > apple:badmap = +macintosh(badmap) > apple:goodmap = +macintosh(goodmap) > > Do you want me to drop the 'badmap' line? No, that is not important. What's important is the "model -> keycodes" section. Do you see any mentioning of badmap there? $macbooks = macintosh+macintosh(badmap) It should be changed to goodmap. > The closest one is 'basic' I think... Would it make sense to add a couple of lines to "basic" to make it work as you want? > Absolutely! I'm extremely grateful for your help with xkb on my Mac. Please > believe me, I have no feelings in particular for my variant - I just want my > keyboard to work :-) OK, I am happy to share your wish:)
(In reply to comment #39) > > ! option = keycodes > > apple:badmap = +macintosh(badmap) > > apple:goodmap = +macintosh(goodmap) > > > > Do you want me to drop the 'badmap' line? > No, that is not important. What's important is the "model -> keycodes" section. > Do you see any mentioning of badmap there? > $macbooks = macintosh+macintosh(badmap) > > It should be changed to goodmap. I've changed badmap into goodmap in the line above, but when I choose MacBook/MacBook Pro (Intl) I get a partially non-functioning keyboard and this: ################################################ Error activating XKB configuration. It can happen under various circumstances: - a bug in libxklavier library - a bug in X server (xkbcomp, xmodmap utilities) - X server with incompatible libxkbfile implementation X server version data: The X.Org Foundation 70200000 If you report this situation as a bug, please include: - The result of xprop -root | grep XKB - The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd ################################################ I then have to change back to Generic 102-key (Intl) PC with my dk variant. > > The closest one is 'basic' I think... > Would it make sense to add a couple of lines to "basic" to make it work as you > want? I wouldn't really know. If you say it would work, then yes.
Try setxkbmap -model macbook79 -layout dk -option '' Will it work for you?
(In reply to comment #41) > Try > > setxkbmap -model macbook79 -layout dk -option '' > > Will it work for you? No. The @ character is gone from the appropriate key. I can't find ~{[]} either. The special Danish characters æøåÆØÅ works as expected though.
At least you could setup that configuration - so why not hack macintosh_vndr/dk a bit, adding 6 missing keys? Would it be possible? > No. The @ character is gone from the appropriate key. I can't find ~{[]} > either. The special Danish characters æøåÆØÅ works as expected though.
(In reply to comment #43) > At least you could setup that configuration - so why not hack macintosh_vndr/dk > a bit, adding 6 missing keys? Would it be possible? Sure, I'll try. What about the error in comment 40? Is it harmless?? > > No. The @ character is gone from the appropriate key. I can't find ~{[]} > > either. The special Danish characters æøåÆØÅ works as expected though. >
> Sure, I'll try. What about the error in comment 40? Is it harmless?? Not really, though it is GNOME's issue so let's not discuss it here;) At least till we sorted the layout thing, ok?:)
(In reply to comment #45) > > Sure, I'll try. What about the error in comment 40? Is it harmless?? > > Not really, though it is GNOME's issue so let's not discuss it here;) At least > till we sorted the layout thing, ok?:) OK :-)
Created attachment 12128 [details] [review] Minimal patch for Sanat Rosa MacBook Pro Hi again, I've played with the macbook79 dk layout file and the attached patch will make my keyboard work with this command: setxkbmap -model macbook79 -layout dk -option '' -variant santarosa I had to make a new variant as I had to redefine BKSL and TLDE. Is this patch OK with you? Best regards, jules
I really like that patch! Just two lines - that's laconism for you! I will commit it - I'll just call it "macbookpro", if you don't mind.
Committed!
(In reply to comment #49) > Committed! Thanks a lot :-)
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.