| Summary: | After adding other keyboards, Japanese keyboard does not behave correctly. | ||
|---|---|---|---|
| Product: | xkeyboard-config | Reporter: | Ali Najand <a_najand> |
| Component: | General | Assignee: | xkb |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | highest | CC: | charles-debian-nospam, ek.kato, mh+freedesktop, tjk |
| Version: | unspecified | Keywords: | i18n |
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Ali Najand
2006-10-03 23:35:19 UTC
IMO the hidden attribute should be put on jp106. Denis, Actually, I was going to look at it after release, but once you started... If we make jp106 hidden - what would we do with the rules for it (there are special rules)? Delete altogether? How would people access Japanese layout then? It seems handling Japanese layout is going to be a bit of PITA - taking that it seems to be bound to the specific model IIRC. Right, * jp = pc+jp(latin)+jp:2 has also to be changed into * jp = pc+jp(latin)+jp(jp106):2 If you do not want to move the hidden attribute, this change can be performed anyway. Maybe this can be improved, but I guess that one needs to have a live demonstration to understand how special keys are used with this layout ;) I absolutely agree! What I'd dream of is some person who would know Japanese and has slightest interest in helping us with the layouts... The change you propose - I would appreciate if Ali put it into rules/base and test. I happen to be using a Japanese jp106 keyboard, and write Japanese, plus I've worked on other keyboard layouts, so maybe I can help here. At least I am interested in getting the jp keyboard to work myself. I have the keyboard on an Ubuntu system 5.10. I should really upgrade to 6.06, since there might be some changes there. The Japanese keyboard right doesn't work exactly as it does in Windows. I've used SCIM and UIM (anthy) and neither IM is able to tgake advantage of all the keys. You have to manually set their functionality in the IM's preferences. Some functionality is not configurable through the keyboard, such as swapping between kana/romaji input. See #5. The Japanese keyboard has these special keys: 1. hankaku/zenkaku kanji Should change state between entering half-sized characters such as latin and full-sized characters such as kanji. This is actually used as the key to change state between entering text via the IM and as straight text. 2. capslock, eisuu, kanjibangou Change state between entering latin numbers and Japanese numbers. Also capslock. 3. muhenkan "No change" key. Accept selected character if lookup has started, or accept input (highlighted) kana if lookup hasn't started. 4. zenkouho, henkan (jikouho), zenkouho Start lookup for the different available kanji for the input (and currently highlighted) text. Pressing the key after the lookup process has started will move to the next character (or a combination thereof). Pressing the key with the shift key down will move back to the previous character. 5. katakana/hiragana/romaji Change state between kana/romaji input. Doesn't seem to be implemented in any of the IMs. For the record, swapping default and hidden attributes did not help, I had to swap variants in symbols/jp. It looks like the 'default' keyword is unused? Dear FreeDesktopers, I have posted informations on a mailing list, in which I list keycodes that are specific to the japanese macintosh keyboard. You can have a look on it here: http://lists.debian.org/debian-powerpc/2006/10/msg00078.html I think that apart from the handling of the mac-specific keypad and multimedia keys, and apart from the eigo / kana keys, the keyboard is likely to behave like a jp106 (I did not check the altGR combinations, however). I am willing to test improvements on my mac (Debian linux ppc), but I am unable to change the relevant files by myself. Could somebody provide some to me? Have a nice day, -- Charles Plessy Wako, Saitama, Japan I checked both hiding the attributes and adding jp106 but none of them helped. Well, I cannot understand why "latin" xkb changes to "jp106" when you add new layouts? >What I'd dream of is some person who would know Japanese and
>has slightest interest in helping us with the layouts...
I can help you with Japanese if it might help you
with the Japanese layout.
Thanks lads for your readiness to help. Now that release 0.9 is out I will have more time to look at this bug. It is really high priority for me, so I'll play with it soon... I think I'm seeing something similar to that bug, though a bit different... I hava a japanese Vaio, with a japanese keyboard, and use SCIM via XIM. When SCIM is not enabled, I just use XIM to input english characters. It seems that on some key combinations, which I failed to understand what they were, the keyboard switches to katakana input style (not scim). I sometimes managed to switch back to english layout, by pressing random keys for a while. Note that if I switch to the 'default' input method in gtk instead of the xim method, then, it doesn't do this switch. If you need feedback on the issue, please ask me whatever you need :) > I checked both hiding the attributes and adding jp106 but none of them helped. > Well, I cannot understand why "latin" xkb changes to "jp106" when you add new > layouts? Well, looking at this: http://webcvs.freedesktop.org/xlibs/xkbdesc/rules/base.ml_s.part?revision=1.13&view=markup - if you have just 'jp' layout, you have jp(latin) as a first group and jp(jp106) as a second group (since it is default variant in symbols/jp). This is the third last rule. But when you add more layouts, this rule does not work any more - so you just get default jp(jp106) into the first group, and other (whatever) layout into other groups. May be, this rule should be dropped altogether - so people who want jp(latin) would add it explicitly? This is the approach taken by all other layouts (for example, Russian layout earlier included American group, now users add it explicitly). What do you think? Lads, let's define the scope of this bug. Any IM is out of it - it is just separate method, with its own approach. What I would like to get is as usable Japanese keyboard as possible using _XKB_only_. I hope you don't mind. Though I realize that most possible be we would not be able to provide all the necessary features. What might be handy is open separate bug regarding Japanese input against SCIM and cross-link two bugs (so we could blame each other;) >Well, looking at this: >http://webcvs.freedesktop.org/xlibs/xkbdesc/rules/base.ml_s.part?revision=1.13&view=markup >- if you have just 'jp' layout, you have jp(latin) as a first group and >jp(jp106) as a second group (since it is default variant in symbols/jp). This >is >the third last rule. >But when you add more layouts, this rule does not work any more - so you just >get default jp(jp106) into the first group, and other (whatever) layout into >other groups. >May be, this rule should be dropped altogether - so people who want jp(latin) >would add it explicitly? This is the approach taken by all other layouts (for >example, Russian layout earlier included American group, now users add it >explicitly). What do you think? Well, The difference between Japanese and Russian is that Russian has a complete alphabet keyboard and does not need some Input Methods for typing some of the characters as Kanjis. I think people who uses a Japanese keyboard, usually type with direct input method which is jp(latin), which special keys are included, to type in Roman Characters and they use Input methods, which usually support jp106 separately, to type in Japanese Characters; One of the ways to solve this problem is to make jp(latin) as default "jp" layout, which in almost every cases solves the Japanese Users Keboard Problems. Another way is what you described above, which sounds very good; but might be confusing for new comers and newbies. >Lads, let's define the scope of this bug. Any IM is out of it - it is just >separate method, with its own approach. What I would like to get is as usable >Japanese keyboard as possible using _XKB_only_. I hope you don't mind. Though >I realize that most possible be we would not be able to provide all the >necessary >features. >What might be handy is open separate bug regarding Japanese input against SCIM >and cross-link two bugs (so we could blame each other;) I think so too. (In reply to comment #13) > Lads, let's define the scope of this bug. Any IM is out of it - it is just > separate method, with its own approach. What I would like to get is as usable > Japanese keyboard as possible using _XKB_only_. I hope you don't mind. Doesn't XIM without the input method (be it uim, scim or whatever) enabled use XKB ? > Russian has a complete > alphabet keyboard and does not need some Input Methods for typing some of the > characters as Kanjis. Very true. > I think people who uses a Japanese keyboard, usually type > with direct input method which is jp(latin), which special keys are included, to > type in Roman Characters and they use Input methods, which usually support jp106 > separately, to type in Japanese Characters; Well, it would be a big relief if we could know it for sure - but how would we? > One of the ways to solve this problem is to make jp(latin) as default "jp" > layout, which in almost every cases solves the Japanese Users Keboard Problems. > Another way is what you described above, which sounds very good; but might be > confusing for new comers and newbies. Well, since I am not the person who would know the "right" answer - I think we could just trust any solution you propose. And actually even making jp(latin) default would not stop us from dropping that special rule, would it? > Doesn't XIM without the input method (be it uim, scim or whatever) enabled use
XKB ?
May be it does - but anyway it has its own way of defining layouts, so our
layouts database is not used at all.
Well, I was asking people (quite a few dozens of people) in my university, in the University of Tokyo, about the default jp layout and the majority of them had the same idea of making jp(latin) as the default "jp" layout is more user friendly than having kana the default layout. I don't usually use Windows, but many people also mentioned that Microsoft Windows, also uses latin characters as Japanese default layout. Also, I believe there is no problem with dropping that special rule. Instead deviding "jp" layouts into 2 layouts (latin and jp106) under jp layout, might help the few people who still want to use kana. In that case jp(pc-98xx) can also go under jp too, and make it a neat set of Japanese Layouts. (In reply to comment #19) > Well, I was asking people (quite a few dozens of people) in my university, in > the University of Tokyo, about the default jp layout and the majority of them > had the same idea of making jp(latin) as the default "jp" layout is more user > friendly than having kana the default layout. I don't usually use Windows, but > many people also mentioned that Microsoft Windows, also uses latin characters as > Japanese default layout. I can confirm that. On both Windows and Mac OS X, the default is to use the latin characters, even when in what would be their equivalent of the "input method" mode, meaning that you have to type latin characters roughly 2 by 2 to get 1 kana character, and later convert them to kanjis. You have to go through specific config panels to get to directly use the kanas from the keyboard, and most of the people don't actually know how to do it. OT: so much that the first time I asked a japanese friend if it was possible to type directly the kanas, since they are printed on the keyboard, he answered me with a categoric "no" ; and it took several persons to actually find one who knew it's possible, and even more to find one who knew how > Well, I was asking people (quite a few dozens of people) in my university, in > the University of Tokyo, about the default jp layout and the majority of them > had the same idea of making jp(latin) as the default "jp" layout is more user > friendly than having kana the default layout. I don't usually use Windows, but > many people also mentioned that Microsoft Windows, also uses latin characters as > Japanese default layout. Great! Thanks a lot for this mini-surview! So we definitely have some statistics which shows that jp(latin) should be the default variant. > Also, I believe there is no problem with dropping that special rule. Instead > deviding "jp" layouts into 2 layouts (latin and jp106) under jp layout, might > help the few people who still want to use kana. In that case jp(pc-98xx) can > also go under jp too, and make it a neat set of Japanese Layouts. I like it. So, people choosing 'Japanese' will have jp(latin) - as default. And the ones who want kana, will choose additional layout - jp(jp106). I will also look whether I could put pc-98xx into the same line. Really, lads, I like the way it is shaping into now.. (In reply to comment #20) > get 1 kana character, and later convert them to kanjis. You have to go through > specific config panels to get to directly use the kanas from the keyboard, and > most of the people don't actually know how to do it. OK, so we all happy that jp(latin) is going to be the default one. I'll try to put changes to CVS tonight. > with a categoric "no" ; and it took several persons to actually find one who > knew it's possible, and even more to find one who knew how :) Interesting story. Asian layouts is my worst nightmare, all the way I maintain xkeyboard-config;) I just happened to know this bug on planet.gnome.org, and what Ali Najand and Mike Hommey described in #19 and #20 is totally right. We normally input Japanese (compose Kana from the combination of alphabet, and then convert these Kana sequence into Kanji/Kana mixed words) using Input Method on X11, Windows and Mac OS X. So just let jp(latin) default for JP106 layout works fine. Even small number of people use direct Kana input (which is printed on each key as noted on #20) and then convert them into Kanji/Kana mixed words, this direct Kana input is also done by IM. BTW, I found another bug in jp(latin) symbol. In xkeyboard-config-0.9/symbols/jp, key <AE13> is defined as [ backslash, bar ] with "latin", but I think it should produce [ yen, bar] symbol. This fix also solves the problem in direct Kana input using IM since it makes IM possible to produce "kana_RO" and "prolongedsound" appropriately from X11's symbol "backslash" and "yen". Here is a example of JP 106 key layout. http://www.pfu.fujitsu.com/hhkeyboard/kb_collection/images/ibma01.gif -- Etsushi Kato Release manager of uim@freedesktop.org (In reply to comment #23) Etsushi, thanks for your voice. > I just happened to know this bug on planet.gnome.org, and what Ali Najand and > Mike Hommey described in #19 and #20 is totally right. Good! I am doing this change as we speak. > on X11, Windows and Mac OS X. So just let jp(latin) default for JP106 layout > works fine. Would it make sense to rename second variant jp(106) to jp(kana)? > BTW, I found another bug in jp(latin) symbol. In > xkeyboard-config-0.9/symbols/jp, key <AE13> is defined as [ backslash, bar ] > with "latin", but I think it should produce [ yen, bar] symbol. OK, I'll fix it as well. > http://www.pfu.fujitsu.com/hhkeyboard/kb_collection/images/ibma01.gif Thanks, that's handy. Though I am not sure I would be able to perform quality comparison of our kana layout and this picture;) Lads, I uploaded new stuff to CVS. Could you please have a look whether it is ok, whether it is usable for you. Any feedback would be appreciated. >Would it make sense to rename second variant jp(106) to jp(kana)?
Sounds great... Actually, jp106 is the name of the keyboard model and jp(kana)
sounds a better name for that. Thank you very much all for your help. I was a
great help.
I am going to confirm the layout today.
> Would it make sense to rename second variant jp(106) to jp(kana)? I think it's good idea. > Lads, I uploaded new stuff to CVS. Could you please have a look whether it is > ok, whether it is usable for you. Any feedback would be appreciated. It seems to work fine. I've tried new symbols/jp file on Fedora Core 5, and I can input alphabet with Jpn layout even if I have more than one layout in Keyboard Indicator applet. >> BTW, I found another bug in jp(latin) symbol. In >> xkeyboard-config-0.9/symbols/jp, key <AE13> is defined as [ backslash, bar ] >> with "latin", but I think it should produce [ yen, bar] symbol. > OK, I'll fix it as well. Thanks. But a friend of mine just talked me that it is a bad idea to produce "yen" with <AE13> on JP106 layout for the compatibility reason. In Windows, input with <AE13> key produces 0x5C (i.e. "backslash") character code but shows "Yen sign" with Japanese fonts. So could you revert the change about <AE13>? Maybe having a option to select symbol of <AE13> in "Japaneses Keyboard Options" of gnome-keyboard-properties will help. What do you think? Anyway, handling Japanese keyboard spec and character code is a really nightmare... > "Yen sign" with Japanese fonts. So could you revert the change about <AE13>? OK, I'll do it. > Maybe having a option to select symbol of <AE13> in "Japaneses Keyboard Options" > of gnome-keyboard-properties will help. What do you think? Well, I'll think of it. But for a moment it really looks like a bit of bloat to me;) > Anyway, handling Japanese keyboard spec and character code is a really nightmare... 101% agree;) Lads, since you are around, there is another interesting question. There is NEC PC98 keyboard which has separate keysyms, separate Japanese layout. Does anyone have any information about it? It would be cool to merge it into the base set. Hehe, NEC PC-98x1? It totally discontinued PC now a days. However, sometimes these are still used as a logger machine connected to old measuring instruments in university lab. Keylayout can be found here (http://www.pfu.fujitsu.com/hhkeyboard/kb_collection/images/pc9800es.gif), but I'm not sure about its keycode. Kana and Alphabet layout is as same as in JP 106 keyboard. But it has some different keys like XFER, XFER, GRPH, and so on. > (http://www.pfu.fujitsu.com/hhkeyboard/kb_collection/images/pc9800es.gif), but > I'm not sure about its keycode. Would you be able to get access to one of these machines, if they have some xorg/xfree? Just to check whether current files still make sense or not. Or find any person using it? > Kana and Alphabet layout is as same as in JP 106 keyboard. But it has some > different keys like XFER, XFER, GRPH, and so on. Yeah, I see. BTW, I reverted the change regarding AE13 symbols. > Would you be able to get access to one of these machines, if they have some > xorg/xfree? Just to check whether current files still make sense or not. Or find > any person using it? I don't have a access to PC-98, sorry. I'll try to find some people. >> Kana and Alphabet layout is as same as in JP 106 keyboard. But it has some >> different keys like XFER, XFER, GRPH, and so on. > Yeah, I see. > BTW, I reverted the change regarding AE13 symbols. Thanks. I think using "backslash" for AE13 is safe at the moment (but I prefer to use "yen" symbol for that...) I checked JIS (Japanese Industrial Standard) document about keyboard layout. There seem two documents about that. One is JIS X 6002 in 1980, assuming "yen" key is assigned as 0x5C, and have no "reverse solidus" key on the keyboard. Another is JIS X 4064 in 2002, and this document shows a example of Japanese keyboard, OADG109A (JP106 + Right/Left Windows key + Menu key), which has "yen" key and "reverse solidus" key with different character codes. In terms of JIS X 6002, we should use "backslash" for AE13. But with JIS X 4064, I think it is OK to use "yen" for AE13... Note that Windows does the ugly thing to type a yen character with both AE13 and AB11, and paths have to be written with ¥ instead of \ (as in C:¥Windows¥System32). The fact is the keyboard has ¥ written on AE13 and \ on AB11, I think the better thing to do is to have X type whatever is written on the keyboard. I don't know if there are variants with \ written on AE13, though. The problem with \ and ¥ dates from when encodings such as shift-jis couldn't display both at the same time, because someone decided \ was useless and that it could be replaced with ¥. Now that most systems use unicode or utf-8 to display characters, both can be displayed at the same time, i think it's much better for everyone if what the screen and what the keyboard display are the same. Thanks Mike. I also think that showing "yen" U+00A5 with <AE13> on X11 with UTF-8 environment is better. Sergey, it is possible to add new jp variant layout like jp(OADG106A) to xkbdesc? As I wrote in comment #32, OADG109A is the current standard Japanese keyboard layout refered in JIS. It can distinguish "YEN SIGN" and "REVERSE SOLIDUS", and also it deleted some of the key symbols which are duplicated elsewhere (e.g. "asciitilde" from <AE10> with shift modifier). The layout can be found on http://www.oadg.or.jp/images/109A.pdf (in Japanese) and the difference between OADG109 (same as jp106) and OADG109A can be found here, http://www.oadg.or.jp/images/109A_KB.pdf (symbols with red color was removed in 109A). Maybe we can stay current jp106 as default for Japanese keyboard layout for the compatibility reason, but make OADG109A layout available will be good thing. As I noted, it also solves Kana direct input with Input Method. (In reply to comment #34) > Thanks Mike. I also think that showing "yen" U+00A5 with <AE13> on X11 with > UTF-8 environment is better. So, do we finally have a consensus here? It is going to be yen but not backslash, yeah? > Sergey, it is possible to add new jp variant layout like jp(OADG106A) to xkbdesc? Sure. Just provide me with a patch. > Maybe we can stay current jp106 as default for Japanese keyboard layout for the > compatibility reason, but make OADG109A layout available will be good thing. Agree. I am always happy to include nationally standardized layouts. It sounds to me tto have ¥ on AE13 and \ on AB11. Still I want to have the merit of file names with space included. So it would be a great idea to have both of ¥ and \. NEC PCxx is a dead brand but I know a friend who is still using Debian (with no X) no it. So it is better to have it as it is... Maybe like a sub-layout for jp. jp just works fine now. Thank you very much for all of you guys here. OK, lads, I am returning "yen" (since it is what's engraved physically on Japanese keyboard) - and looking forward to getting another variant from Etsushi. I think it would be better if you file new bug for it, ok? > OK, lads, I am returning "yen" (since it is what's engraved physically on
> Japanese keyboard) - and looking forward to getting another variant from
> Etsushi. I think it would be better if you file new bug for it, ok?
Arrg, what I want to say is keeping "backslash" for current jp(latin), and
create another variant jp(OADG106A) which having "yen". Sorry for my poor English.
I'll file a new bug about adding jp(OADG106A) later today.
> Arrg, what I want to say is keeping "backslash" for current jp(latin), and > create another variant jp(OADG106A) which having "yen". Sorry for my poor English. Sorry for misunderstanding:) Ok, so let it be backslash in existing layout. > I'll file a new bug about adding jp(OADG106A) later today. Great! >> Arrg, what I want to say is keeping "backslash" for current jp(latin), and >> create another variant jp(OADG106A) which having "yen". Sorry for my poor >English. > Sorry for misunderstanding:) Ok, so let it be backslash in existing layout. Thanks :) >> I'll file a new bug about adding jp(OADG106A) later today. Actually jp(OADG109A)... Hi all, I was just wondering if one could add the macintosh keyboard by the way. It is very similar to the PC keyboard, but uses different keys for swiching the input methods: <EIGO> = 210; <KANA> = 209; (not sure if they are official names). On the version I have, there is also an extra comma key on the numeric pad (keycode 134), and four multimedia keys: <VOL-> = 174; <VOL+> = 176; <MUTE> = 160; <EJECT>= 204; (again, not sure about the names). Lastly, it seems that the AC12 key is not properly configured when using just setxkbmap -layout "jp". (please CC me, I do not check this bug everyday) -- Charles Plessy Wako, Saitama, Japan Charles, I cannot explicitly CC to you - you can just add your email to this bug. Regarding the keys, you sure can add extra variant jp(mac). The right names for the keys can be found in keycodes/xfree86: > <EIGO> = 210; The right name is <K72> > <KANA> = 209; <K71> > <VOL-> = 174; <I2E> > <VOL+> = 176; <I30> > <MUTE> = 160; <I20> > <EJECT>= 204; <K6C> > Lastly, it seems that the AC12 key is not properly configured when using just > setxkbmap -layout "jp". What should be the right mapping for it? (In reply to comment #40) Sergey, I've filed a bug about adding OADG109A in bug #8548. Please have a look. Thanks. Oops, too many typo. I'm sorry. > Sergey, I've filed a bug about adding OADG109A in bug #8548. > Please have a look. Thanks. Correct number is bug #8648. (In reply to comment #42) > Charles, I cannot explicitly CC to you - you can just add your email to this bug. Thanks for the hint, I am new to bugzilla... > Regarding the keys, you sure can add extra variant jp(mac). Great! I will try to propose something... when I will understand the syntax of the relevant files. > The right names for the keys can be found in keycodes/xfree86: Thank you. With these names I can write a file to be placed in symbols/macintosh_vndr (correct me if I am wrong). However, I saw in keycodes/xfree86 things such as alias <I03> = <NFER>. Do you think I can propose such an alias for EIGO and KANA, either in keycodes/xfree86 or keycodes/macintosh ? (same for the media keys) > > Lastly, it seems that the AC12 key is not properly configured when using just > > setxkbmap -layout "jp". > What should be the right mapping for it? Maybe I have been unclear: - With setxkbmap -layout "jp", the key with a keycode of 51 behaves as AE13 (Yen). - With setxkbmap -layout "jp" -model "jp106", the key behave correctly, as AC12 (closing bracket). I do not know it it is a general issue or if it is macintosh specific, nor if it is a problem at all. > such an alias for EIGO and KANA, either in keycodes/xfree86 or > keycodes/macintosh ? (same for the media keys) Well, may be a bit of aliases would not hurt. > - With setxkbmap -layout "jp", the key with a keycode of 51 behaves as AE13 (Yen). Because from now on, the default variant for jp is latin. > - With setxkbmap -layout "jp" -model "jp106", the key behave correctly, as AC12 > (closing bracket). Yes, it is different variant. > I do not know it it is a general issue or if it is macintosh specific, nor if it > is a problem at all. AFAIK it is not. (In reply to comment #46) > > such an alias for EIGO and KANA, either in keycodes/xfree86 or > > keycodes/macintosh ? (same for the media keys) > Well, may be a bit of aliases would not hurt. Hi Sergey, Here are two patches wich are intended to declare the two keys used in Macintoshes to handle japanese input. In my previous posts, I was wrong to call one of them EIGO, it is EISU, and it seems that it already existed somewhere else as there are "Eisu_toggle" chains in some xkbdesc files. --- /home/charles/src/xkbdesc/keycodes/xfree86 2006-09-01 06:44:13.000000000 +0900 +++ xfree86 2006-10-23 22:13:45.000000000 +0900 @@ -156,6 +156,9 @@ <XFER> = 129; // Henkan <NFER> = 131; // Muhenkan <AE13> = 133; // Yen + <EISU> = 210; // Alphanumeric mode on macintosh + <KANA> = 209; // Kana mode on macintosh + // Keys that are generated on Korean keyboards @@ -321,8 +324,8 @@ <K6E> = 206; // <I4E> <K6F> = 207; // <I4F> alias <K70> = <HKTG>; // <I50> - <K71> = 209; // <I51> - <K72> = 210; // <I52> + alias <K71> = <KANA>; // <I51> + alias <K72> = <EISU>; // <I52> alias <K73> = <AB11>; // <I53> <K74> = 219; // <I5B> <K75> = 220; // <I5C> There seems to be two approaches for the aliases. Some japanese keys hardcode the keycode and alias the <Kxy> name. But the keys which handle Corean input are doing the reverese. I chose the same method as for the other japanese keys for the sake of consistency. As the differences are tiny, I am wondering if creating a new macintosh keyboard from scratch is necessary. I think that the EISU and KANA keys are not used on PC keyboards, so it should not hurt if they are declared in the default section. --- /home/charles/src/xkbdesc/symbols/jp 2006-10-19 04:42:33.000000000 +0900 +++ jp 2006-10-23 22:45:36.000000000 +0900 @@ -87,6 +87,17 @@ symbols[Group1]= [ Hiragana_Katakana, Romaji ] }; + key <EISU> { + type[Group1]="PC_SYSRQ", + symbols[Group1]= [ Eisu_toggle ] + }; + + key <KANA> { + type[Group1]="PC_SYSRQ", + symbols[Group1]= [ Hiragana_Katakana ] + }; + + key <PRSC> { type[Group1]= "PC_SYSRQ", symbols[Group1]= [ Print, Execute ] I tried to imitate what is done for the other special keys. The goal is that they could be used to swich the input mode using input methods. When pressed, Eisu shifts the use to latin and does nothing it it is already latin. Conversely, Kana shifts to japanese input (using romanisation) or does nothing. Have a nice day, -- Charles Charles, your patch is committed. Pls check. (In reply to comment #48) > Charles, your patch is committed. Pls check. Hi, I am a bit ashamed to write this, but I broke my mac keyboard, and replaced it by a standard jp106 one for PC. I will not be able to test the patch. Sorry ! Have a nice day, -- Charles :)) It happens all the way. NP. Thanks for the help |
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.
