Hello, I have bought a Happy Hacking keyboard for mac with japanese layout, but strangely it behaves like PC. For instance, the key labelled "Kana" gives the keycode 129 which is associated to Henkan_Mode, which does not exist in Macintosh. http://www.pfu.fujitsu.com/hhkeyboard/lite2mac/images/kb220ma1_l.jpg http://www.pfu.fujitsu.com/hhkeyboard/lite2mac/ Would you be interested to help me to prepare a patch to make this keyboard behave like a proper macintosh keyboard? Have a nice day, -- Charles Plessy Wako, Saitama, Japan
Ok, sure I can help. What kind of help do you need? I am not sure I understand what "proper macintosh keyboard" would be in that context. What kind of behavior would you expect from the Kana key?
(In reply to comment #1) > Ok, sure I can help. What kind of help do you need? I am not sure I understand > what "proper macintosh keyboard" would be in that context. Hi, Although it should be better checked with other keyboards (I can ask this on a ppc mailing list), I expect all the japanese keyboards shipped with iMacs (at least the G5 ones) to give the same keycodes. http://charles.plessy.org/mac/A1048.html The HK lite2 for mac (japanese edition) does not exactly reproduce this, at least the eject, eisu and kana keys give 170, 131 and 129 instead of 204, 210 and 209. So if I understand correctly, I should produce a file which imports the mac japanese keyboard and modifies it. The first obstacle is that there is no such file: https://bugs.freedesktop.org/show_bug.cgi?id=8503 (do you remember ;) Luckily, since this I again have access to a proper mac keyboard. Shall I repoen this bug first ? The help I need for you is to tell me if I should try to modify the jp106 keyboard as in this bug, or if I should try to create a file in the macintosh_vndr directory, and if I have to touch files from other directories. > What kind of behavior would you expect from the Kana key? > On macintosh, kana swiches to japanese input, and eisu switches to latin characters. The PC keys act more like toggles, where the same key alternates the modes. If eisu and kana have their own keycodes, I think that then we can easily ask input methods to emulate the macintosh behavior. Have a nice day,
> Luckily, since this I again have access to a proper mac keyboard. Shall I > repoen this bug first ? I do not think it is necessary. Let's discuss it here. > The help I need for you is to tell me if I should try > to modify the jp106 keyboard as in this bug, or if I should try to create a > file in the macintosh_vndr directory, and if I have to touch files from other > directories. I do not have strong preferences. I think modifying jp106 would be slightly better option, don't you think?
> I do not have strong preferences. I think modifying jp106 would be slightly > better option, don't you think? Let us start with just one key. On mac keyboards there are usually two command keys (⌘), and the keyboard I bought has the same. However, it seems to to send different keycodes: for the left command key, it sends 49, which is associated to TLDE in keycodes/xfree86. In this same file, TLDE is aliased to HZTG. In symbols/jp, HZTG gives Zenkaku_Hankaku. I have two questions : - which file to modify to introduce support of my keyboard ? - with setxkbmap -layout jp, will I refresh from the changes in whatever file, or only in symbols/jp ?
> - which file to modify to introduce support of my keyboard ? May be, it would be a good idea to start with changing keycodes/macintosh. Add another section "hhk" and put keycode 49 as LALT. Would it be correct? > - with setxkbmap -layout jp, will I refresh from the changes in whatever file, > or only in symbols/jp ? It refreshes the entire configuration from /usr/share/X11/xkb (or wherever it is located on your system)
I tried the following modification, but with commands such as the following (or variants of), I can not manage to apply them to my current setting... setxkbmap -model "macintosh+macintosh(hhk)" -layout "jp" Can you indicate me the correct syntax? --- macintosh.old 2007-08-27 22:01:49.000000000 +0900 +++ macintosh 2007-08-27 22:17:45.000000000 +0900 @@ -179,3 +179,16 @@ alias <ALGR> = <RALT>; }; + +xkb_keycodes "hhk" { + + <LWIN> = 49; + <EISU> = 131; + <KANA> = 129; + <RWIN> = 208; + + <FK13> = 111; + <FK14> = 78; + <FK15> = 110; +}; +
> setxkbmap -model "macintosh+macintosh(hhk)" -layout "jp" This would not work. Either you should use low level components (see what setxkbmap generates with -print option) or modify rules/base so that model hhk would be mapped to the correct keycodes. HTH
OK, so after grepping files around, I finally modified rules/base: --- xfree86.old 2007-08-27 22:42:53.000000000 +0900 +++ base 2007-08-27 22:43:27.000000000 +0900 @@ -119,6 +119,7 @@ ! option = keycodes apple:badmap = +macintosh(badmap) apple:goodmap = +macintosh(goodmap) + apple:hhk = +macintosh(hhk) ! model layout = geometry thinkpad us = thinkpad(us) setxkbmap -layout "jp" -option 'apple:hhk' does apply my changes now :) Was it the correct approach? If yes, I will modify the changes: I think that something like hhk:macintosh or hhk:lite24mac would be a better name...
No, that is wrong. Please modify model->keycodes section instead of option->keycodes. The name of the model I propose is macintosh_hhk.
> No, that is wrong. Please modify model->keycodes section instead Something like this ? --- base.old 2007-08-27 22:42:53.000000000 +0900 +++ base 2007-08-27 23:07:50.000000000 +0900 @@ -104,6 +104,7 @@ macintosh_old = macintosh(old) $macbooks = macintosh+macintosh(badmap) $macs = macintosh + macintosh_hhk = macintosh+macintosh(hhk) * = xfree86 ! layout[1] = keycodes
That's better. But I'd rather use include "macintosh" in the keycodes file (to include base list of keycodes). And correspondingly macintosh_hhk = macintosh(hhk) in the rules. BTW, rules/base is the result of the build process, the primary file is rules/base.m_k.part
(In reply to comment #11) > That's better. But I'd rather use > include "macintosh" > in the keycodes file (to include base list of keycodes). And correspondingly > macintosh_hhk = macintosh(hhk) > in the rules. OK, the following patch seems to do the job: diff -ru xkeyboard-config-1.0~cvs.20070721_old/keycodes/macintosh xkeyboard-config-1.0~cvs.20070721/keycodes/macintosh --- xkeyboard-config-1.0~cvs.20070721_old/keycodes/macintosh 2006-09-18 23:17:01.000000000 +0900 +++ xkeyboard-config-1.0~cvs.20070721/keycodes/macintosh 2007-08-29 23:15:00.000000000 +0900 @@ -179,3 +179,19 @@ alias <ALGR> = <RALT>; }; + +xkb_keycodes "hhk" { + include "macintosh" + + <AC12> = 51; + + <LWIN> = 49; + <EISU> = 131; + <KANA> = 129; + <RWIN> = 208; + + <FK13> = 111; + <FK14> = 78; + <FK15> = 110; +}; + diff -ru xkeyboard-config-1.0~cvs.20070721_old/rules/base.m_k.part xkeyboard-config-1.0~cvs.20070721/rules/base.m_k.part --- xkeyboard-config-1.0~cvs.20070721_old/rules/base.m_k.part 2006-10-17 04:04:52.000000000 +0900 +++ xkeyboard-config-1.0~cvs.20070721/rules/base.m_k.part 2007-08-29 22:58:51.000000000 +0900 @@ -9,4 +9,5 @@ macintosh_old = macintosh(old) $macbooks = macintosh+macintosh(badmap) $macs = macintosh + macintosh_hkk = macintosh(hkk) * = xfree86 > BTW, rules/base is the result of the build process, the primary file is > rules/base.m_k.part Wow, is there a place where the split of the base file is explained? Have a nice day, -- Charles
That patch make sense. It does not include base.xml.in part - but that' ok, I'll add it myself. Also, there was a small typo - hkk instead of hhk. No, there is no document explaining the way to build base file. If you could spend some time drafting it - I would be most grateful (and sure could help with that). Anyway, your patch is committed. Thanks.
> No, there is no document explaining the way to build base file. If you could > spend some time drafting it - I would be most grateful (and sure could help > with that). Why not? But for the moment I do not understand very well the logic behind the file names. Can you give me some hints?
> Why not? But for the moment I do not understand very well the logic behind the > file names. Can you give me some hints? Sure. The general pattern is base.{from}_{to}.part {from} is a combination of m,l,v,o (model/layout/variant/option), {to} is a combination of {k,t,c,s,g,c} (keycodes/type/compat/symbols/geometry). Each part define a set of rules on how to translate particular combination of {from} into {to}. In addition, in {from} part, layout can have index (1-4) if the rule should be applied to the layout in particular position. Also, there are: - base.lists.part which defines some common set of "variables" (lists) used in other parts - base.hdr.part which is just a set of comments to be put on top of the resulting file - HDR which is a set of all section headers (to be put before every base.*.part) - merge.sh which performs actual merging Does it make sense? Also, there is rules/compat subdirectory which is used to generate compatibilityu rules. But that's another story (which would be good to describe as well).
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.