In thread "Re: Trying to run 2.6.0-test3", Alan Cox replied to me:
> > What will it take this time?
>
> Posting the patch with any luck ?
I knew that that would not be sufficient. On 2003.07.24, I think in the
days of 2.6.0-test1, [email protected] posted a patch for Japanese PS/2
keyboards. On 2003.08.31, in the days of 2.6.0-test4, I posted a revised
patch to include Japanese USB keyboards. 2.6.0-test5 includes neither of
them because the keyboard driver maintainers don't personally depend on
Japanese keyboards.
Since posting has not been sufficient, I beg Mr. Pavlik, just once per
release, please try pretending that you might have to depend on a Japanese
keyboard. You don't have to use one daily as your colleague Dr. Fabian
does. Just twice per release, once in a plain text console and once under
X11, please try testing a Japanese PS/2 keyboard and Japanese USB keyboard.
In particular the troublesome keys are yen bar and backslash underscore.
You don't need a Japanese font. If you use an ASCII font then the keys
display as backslash bar and backslash underscore. If you use a Japanese
font then the keys display as yen bar and yen underscore. In all cases the
ASCII backslash or JIS-Romaji yen character are code point 0x5C.
(Don't worry about the labels on the right-hand side of each key, for direct
kana input. Less than 0.1% of Japanese and other residents of Japan ever
use direct kana input under Monopolysoft Windows, and probably none at all
under Linux. When inputting Japanese, common practice is to input the
pronunciation in Italian characters and let the OS convert first to kana and
then to Kanji. We depend on the labels on the left-hand side of each key,
including the two mentioned above. Exception 1: yen and backslash are
really the same character even though the keys have different labels.
Exception 2: a shifted 0 doesn't really produce a ~ but it is enough that a
shifted ^ does so, but it doesn't matter that Linux has added real input for
a shifted 0.)
On Sun, Sep 14, 2003 at 12:51:32PM +0900, Norman Diamond wrote:
> In thread "Re: Trying to run 2.6.0-test3", Alan Cox replied to me:
>
> > > What will it take this time?
> >
> > Posting the patch with any luck ?
>
> I knew that that would not be sufficient.
Just repeat. Do not repeat the complaining because complaining
with zero information content is just discarded.
But if you repeat the patch, together with an explanation of why
this is the correct patch, sooner or later somebody will look at it.
Andries
On Sun, Sep 14, 2003 at 12:51:32PM +0900, Norman Diamond wrote:
> In thread "Re: Trying to run 2.6.0-test3", Alan Cox replied to me:
>
> > > What will it take this time?
> >
> > Posting the patch with any luck ?
>
> I knew that that would not be sufficient. On 2003.07.24, I think in the
> days of 2.6.0-test1, [email protected] posted a patch for Japanese PS/2
> keyboards. On 2003.08.31, in the days of 2.6.0-test4, I posted a revised
> patch to include Japanese USB keyboards. 2.6.0-test5 includes neither of
> them because the keyboard driver maintainers don't personally depend on
> Japanese keyboards.
>
> Since posting has not been sufficient, I beg Mr. Pavlik, just once per
> release, please try pretending that you might have to depend on a Japanese
> keyboard.
I'd like to include the japanese keyboard fixes and have it working,
however the reports I'm getting are quite confusing. It seems that there
isn't just one kind of japanese keyboards out there ...
If you manage to tell me what exactly is what key supposed to produce,
what scancode it does have on PS/2 and what HID event it sends on USB,
I'll be more than happy to fix it all.
I'll try to dig and find the patches posted on the list and make sense
out of them in the meantime, however they often break other (non-jp)
stuff.
> You don't have to use one daily as your colleague Dr. Fabian
> does. Just twice per release, once in a plain text console and once under
> X11, please try testing a Japanese PS/2 keyboard and Japanese USB keyboard.
This might be a little problematic - I don't have any Japanese keyboard
and I don't have any idea about how to buy one.
If anyone would send me samples of Japanese keyboards, you can be sure
I'd test them.
> In particular the troublesome keys are yen bar and backslash underscore.
> You don't need a Japanese font. If you use an ASCII font then the keys
> display as backslash bar and backslash underscore. If you use a Japanese
> font then the keys display as yen bar and yen underscore. In all cases the
> ASCII backslash or JIS-Romaji yen character are code point 0x5C.
IIRC these now generate proper key evens (KEY_INTL*), which are missing
in the default keymap, because the event codes are above 255, which
current 'loadkeys' utility cannot handle.
Thus this requires more work than just patching up some table. And a lot
of thinking, too, so that we both don't break older setups and make the
transition easy for new ones.
> (Don't worry about the labels on the right-hand side of each key, for direct
> kana input.
I have yet to see a Japanese keyboard to be able to worry about it. I've
seen some pictures on the web, and that's all I've seen.
> Less than 0.1% of Japanese and other residents of Japan ever
> use direct kana input under Monopolysoft Windows, and probably none at all
> under Linux. When inputting Japanese, common practice is to input the
> pronunciation in Italian characters and let the OS convert first to kana and
> then to Kanji. We depend on the labels on the left-hand side of each key,
> including the two mentioned above. Exception 1: yen and backslash are
> really the same character even though the keys have different labels.
> Exception 2: a shifted 0 doesn't really produce a ~ but it is enough that a
> shifted ^ does so, but it doesn't matter that Linux has added real input for
> a shifted 0.)
>
--
Vojtech Pavlik
SuSE Labs, SuSE CR
> > Exception 2: a shifted 0 doesn't really produce a ~ but it is enough that a
> > shifted ^ does so, but it doesn't matter that Linux has added real input for
> > a shifted 0.)
This is wrong for some keyboards.
~ is indeed shifted 0 on my keyboard - shifted ^ is an overbar.
Also, on my keyboard, - has a U.K. pound symbol as the fourth
character on the key, (the top-right character).
John.
On Sun, Sep 21, 2003 at 01:00:05PM +0100, John Bradford wrote:
> > > Exception 2: a shifted 0 doesn't really produce a ~ but it is enough that a
> > > shifted ^ does so, but it doesn't matter that Linux has added real input for
> > > a shifted 0.)
>
> This is wrong for some keyboards.
>
> ~ is indeed shifted 0 on my keyboard - shifted ^ is an overbar.
>
> Also, on my keyboard, - has a U.K. pound symbol as the fourth
> character on the key, (the top-right character).
This discussion is superfluous.
Keyboards differ - there is no way the kernel can guess at
the key label given the scancode.
That is why keymaps exist.
So, if Norman and John have keyboards with different behaviour
that just means that they must load different keymaps.
Andries
Vojtech Pavlik wrote:
> I'd like to include the japanese keyboard fixes and have it working,
> however the reports I'm getting are quite confusing. It seems that there
> isn't just one kind of japanese keyboards out there ...
The most common kinds are:
1. PS/2 JP106 layout. Electrically it is the same as any other PS/2
keyboard.
In the upper left, near the Esc key, is the hankaku/zenkaku key. The scan
code is the same as the US backquote tilde key. In Japanese Monopolysoft
systems it turns the IME on or off. This key does not produce input by
itself, but of course the scan code is used in turning the IME on or off.
In Linux traditionally it does not produce input, but I think that the
"ATOK" IME might need to be informed of keypresses.
(Historically this key used to switch between half-width and full-width
characters, but Alt + hankaku/zenkaku turned the IME on or off. Now the use
of Alt with this key is optional for this purpose, and a different operation
is needed to get half-width characters.)
To the left of the space key is the muhenkan key. To the right of the space
key are the henkan key and hiragana/katakana key. In Monopolysoft systems
these affect the IME. They do not produce input by themselves but the scan
codes are used in controlling the IME. In Linux traditionally they do not
produce input, but I think that the "ATOK" IME might need to be informed of
keypresses.
Near the upper right is the yen bar key. The scan code is one which doesn't
exist on a US keyboard. In Japanese character sets, the half-width
single-byte yen symbol is 0x5C, the same as the ASCII backslash. If a US
font is used then the character displays as a backslash. C programs and
Monopolysoft filesystems and everything interpret it the same as a backslash
because the codepoint is the same (0x5C). When shifted it is an or bar, the
same code point as an ASCII or bar.
Near the lower right is the backslash underscore key. The scan code is one
which doesn't exist on a US keyboard. If a Japanese font is used then the
backslash displays as a half-width single-byte yen symbol because the code
is the same (0x5C). In other words, the unshifted yen key and unshifted
backslash key are redundant, only one is needed, but this is not true of the
shifted versions. When shifted this one is an underscore, the same code
point as an ASCII underscore.
Regarding the caret tilde key, traditionally this was a caret overbar key.
In Japanese character sets, the overbar is the same code point as the ASCII
tilde. But no one displays it as an overbar any more, everyone displays it
as a tilde. The overbar graphic is virtually forgotten, though on some
keyboards the label still displays it as an overbar, just to cause confusion
between the underscore and the overbar. The scan code is the same as a US
keyboard's plus and equal key.
Regarding the 0 key (digit 0), it is most common for the keyboard's label to
display a tilde above the 0. When unshifted this key inputs a 0. When
shifted this key normally does not input anything, though the scan code is
observed and discarded by the driver. The exception is that Linux accepts
the scan code even when shifted, and inputs a tilde, the same code point as
the overbar or tilde mentioned above. Linux added this redundancy which
does not hurt, but it's really irrelevant.
Other keys have pretty much obvious meanings. The alphabetic QWERTY layout
is the same as a US keyboard but all the punctuation marks are moved around.
(Mr. Bradford's keyboard is strange. If his shifted 0 produces a tilde as
input even to Monopolysoft operating systems, well then OK I believe him,
but we already know his keyboard is strange.)
(By the way, NEC no longer makes old 9800 machines. Modern NEC PS/2
keyboards are the same as other PS/2 keyboards.)
2. USB JP106 layout. The scan codes of the yen bar, backslash underscore,
muhenkan, henkan, and hiragana/katakana keys are different from the PS/2
keyboard's scan codes. The driver's mapping of scan codes from USB scan
codes to PS/2 scan codes must map these keys to match what keyboards do.
When you invented other International scan codes for them, they did not
work. In the middle of the 2.4 series this was finally accepted, though I'm
not sure if you were the one who finally accepted it, or if Dr. Fabian
persuaded others.
(By the way, NEC no longer makes old 9800 machines. Modern NEC USB
keyboards are the same as other USB keyboards. But Macintosh is different
from other USB keyboards.)
3. Old NEC 9800 keyboards. Some old 9800 machines are powerful enough to
run Linux, and some can even run XFree86. So some people have even made the
old keyboards work with Linux. I don't know details though. I have never
bought nor mailed one of these.
4. Macintosh keyboards. They use USB but their scan codes are different
from everyone else's. My understanding is that the 2.4 kernel correctly
mapped Macintosh's scan codes earlier than it did for ordinary USB
keyboards. But I never tried it myself, don't know details, and have never
bought nor mailed one.
> If you manage to tell me what exactly is what key supposed to produce,
> what scancode it does have on PS/2 and what HID event it sends on USB,
> I'll be more than happy to fix it all.
I'm relieved to see your present opinion. Thank you. But I think you can
look in 2.4 kernels to see the answer.
In addition, if you use showkey -s to view scan codes, you must use a 2.4
kernel. 2.6 is broken enough to even make showkey -s output garbage.
> I'll try to dig and find the patches posted on the list
One message-id is <[email protected]> but I don't think this is an
original LKML message-id. Because of the hack I had to use in posting (to
preserve tab characters instead of letting Monopolysoft Lookout change them
to spaces), I don't have any other message-id for it. The date was
2003.8.31 and subject line was: [PATCH] 2.6.0-test4, Japanese USB
keyboards, keycodes 181 and 183.
> however they often break other (non-jp) stuff.
I sincerely doubt that. I think that the scan codes involved here are not
used in conflicting manners on other keyboards.
> If anyone would send me samples of Japanese keyboards, you can be sure
> I'd test them.
Thank you! I was afraid to ask in advance because I thought that you would
either refuse or you would ignore the suggestion. Dr. Brouwer did refuse,
about 3 years ago or so. I could not take a chance on you refusing, because
I know that you really really need them. I sent a sea mail package on
2003.8.31 (same date as posting that patch). It should arrive in a few more
weeks. It is addressed to you at the address of SuSE, copied from your
company's web site.
> > In particular the troublesome keys are yen bar and backslash underscore.
> > You don't need a Japanese font. If you use an ASCII font then the keys
> > display as backslash bar and backslash underscore.
>
> IIRC these now generate proper key evens (KEY_INTL*),
I commented on this above.
> which are missing in the default keymap,
Yes.
> because the event codes are above 255,
I don't understand your event codes very well. But showkey -s still
produces garbage, so there is still something broken between scan codes and
event codes. On a Japanese PS/2 keyboard, all scan codes are below (or
maybe equal to) 127. On a Japanese USB keyboard, scan codes can go up to
255. The troublesome keys are in the range from 128 to 255.
> Thus this requires more work than just patching up some table. And a lot
> of thinking, too, so that we both don't break older setups and make the
> transition easy for new ones.
I can't speak for future transitions, but the present breakage does break
current machines exactly in the way you say you can't.
On Sun, Sep 21, 2003 at 10:26:04PM +0900, Norman Diamond wrote:
[good description of Japanese keyboards deleted]
> > If anyone would send me samples of Japanese keyboards, you can be sure
> > I'd test them.
>
> Thank you! I was afraid to ask in advance because I thought that you would
> either refuse or you would ignore the suggestion. Dr. Brouwer did refuse,
> about 3 years ago or so.
Did I really?
But the advantage of a good description is that the information
lives on the net and can be retrieved by anybody. A piece of
hardware takes room and can be tested by only one.
I think no kernel changes are required to use Japanese keyboards today.
(But kbd has to be recompiled with NR_KEYS set to 256.)
Andries
On http://www.win.tue.nl/~aeb/linux/kbd/scancodes-6.html
there is a reasonably detailed description of the state of
affairs. Maybe nothing more is needed. Of course additions
and corrections are welcome.
On Sun, Sep 21, 2003 at 01:01:25PM +0200, Vojtech Pavlik wrote:
> If you manage to tell me what exactly is what key supposed to produce,
> what scancode it does have on PS/2 and what HID event it sends on USB,
> I'll be more than happy to fix it all.
See http://www.win.tue.nl/~aeb/linux/kbd/scancodes-6.html
Andries Brouwer:
> Norman Diamond:
> > Vojtech Pavlik:
> >
> > > If anyone would send me samples of Japanese keyboards, you can be sure
> > > I'd test them.
> >
> > Thank you! I was afraid to ask in advance because I thought that you would
> > either refuse or you would ignore the suggestion. Dr. Brouwer did refuse,
> > about 3 years ago or so.
>
> Did I really?
You did on 2001.2.23:
> > would have a use for a Japanese USB keyboard
>
> It would be too expensive to mail.
> Instead of keyboards I prefer to collect scancodes of keyboards,
> and you provided some good information.
> (I also got photographs from someone, maybe you saw:
> http://www.win.tue.nl/~aeb/linux/kbd/scancodes-3.html )
Returning to this year:
> I think no kernel changes are required to use Japanese keyboards today.
> (But kbd has to be recompiled with NR_KEYS set to 256.)
I'm not convinced yet. defkeymap.c_shipped is included in the downloadable
.bz2 file and it is inadequate.
On Mon, Sep 22, 2003 at 09:21:53PM +0900, Norman Diamond wrote:
> > I think no kernel changes are required to use Japanese keyboards today.
> > (But kbd has to be recompiled with NR_KEYS set to 256.)
>
> I'm not convinced yet. defkeymap.c_shipped is included in the downloadable
> .bz2 file and it is inadequate.
But defkeymap is inadequeate for German, it is inadequate for French,
why would it be adequate for Japanese?
It is just the random default you get when no keymap was loaded.
Andries Brouwer and Norman Diamond:
> > > I think no kernel changes are required to use Japanese keyboards
> > > today.
> > > (But kbd has to be recompiled with NR_KEYS set to 256.)
> >
> > I'm not convinced yet. defkeymap.c_shipped is included in the
> > downloadable .bz2 file and it is inadequate.
>
> But defkeymap is inadequeate for German, it is inadequate for French,
> why would it be adequate for Japanese?
I think that if defkeymap.c_shipped were inadequate for German and French
then you already would have fixed it. I don't have experience with those
keyboards but would guess that defkeymap.c_shipped is probably adequate for
loadkeys to load a working keymap for German or French.
We have already discussed the fact that defkeymap.c_shipped is not adequate
to load a working keymap for Japanese. In order to be capable of loading a
working keymap, defkeymap.c_shipped needs patching. This is why the patch
looked so big. Of course a working defkeymap.c_shipped should be generated
automatically from a different keymap file which doesn't need nearly as big
a patch. Nonetheless defkeymap.c_shipped is part of the kernel, isn't it?
No matter how what method and how small an originating patch are used in
getting this one fixed, it is a part of the kernel that is getting fixed
here, isn't it?
> It is just the random default you get when no keymap was loaded.
It is that plus more. It includes limits that prevent certain keymaps from
getting set when loaded.
> > > > I think no kernel changes are required to use Japanese keyboards
> > > > today.
> > > > (But kbd has to be recompiled with NR_KEYS set to 256.)
> > >
> > > I'm not convinced yet. defkeymap.c_shipped is included in the
> > > downloadable .bz2 file and it is inadequate.
> >
> > But defkeymap is inadequeate for German, it is inadequate for French,
> > why would it be adequate for Japanese?
>
> I think that if defkeymap.c_shipped were inadequate for German and French
> then you already would have fixed it. I don't have experience with those
> keyboards but would guess that defkeymap.c_shipped is probably adequate for
> loadkeys to load a working keymap for German or French.
Of course. It is also adequate for loadkeys to load a working keymap
for Japanese.
> In order to be capable of loading a working keymap, defkeymap.c_shipped
> needs patching.
No.
> > It is just the random default you get when no keymap was loaded.
>
> It is that plus more. It includes limits that prevent certain keymaps from
> getting set when loaded.
False.
Andries