"Andries Brouwer" <[email protected]> wrote:
> 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.
Due to the complexity of this answer, I am making three separate postings.
I make no assertion that the following is correct or is a patch, but think
that it deserves consideration. I spend about one day each weekend testing
this kernel, have had patches ignored enough times, and seriously think of
rejoining the set of users who never have time to test.
----- Original Message -----
From: "Norman Diamond" <[email protected]>
To: "Alan Cox" <[email protected]>
Cc: "Greg KH" <[email protected]>; "Linux Kernel Mailing List"
<[email protected]>; "Andries Brouwer" <[email protected]>;
"Vojtech Pavlik" <[email protected]>
Sent: Monday, August 18, 2003 7:35 PM
Subject: Re: Trying to run 2.6.0-test3
> "Alan Cox" <[email protected]> replied to me.
>
> > > accept a USB keyboard but they refused. The patch which I sent to Vojtech
> > > Pavlik was ignored and these two keys continued not to work (except on my
> > > machine). Finally Mike Fabian accepted a gift of a USB keyboard and this
> > > defect in Linux got fixed. But only for somewhere around the last half of
> > > the 2.4 releases, not for 2.6.
> > > What will it take this time?
> >
> > Posting the patch with any luck ?
>
> Hirofumi Ogawa posted a patch for the yen-sign pipe key on 2003.07.23 for
> test1 but his patch still didn't get into test3. On a PS/2 keyboard that
> seems to be the only key with any problem.
>
> Yesterday when I finally tried a USB keyboard and found that the backslash
> underbar has the same problem, maybe I was the first person to even try a
> Japanese USB keyboard in 2.6, and maybe no one at all tried some number of
> 2.5 series kernels. As mentioned, usually I can only spend one day a week
> testing 2.6. I'll try to spend one day next weekend trying to figure out
> the new necessary patch. If I succeed, but if it gets ignored again, I'll
> probably rejoin the set of users who never have time to test.
>
> I really do think that if Andries Brouwer or Vojtech Pavlik would accept a
> gift of a USB keyboard then this kind of bug would be avoided a lot earlier.
>
On Sun, Sep 14, 2003 at 08:21:30PM +0900, Norman Diamond wrote:
[three separate postings]
The content of the first posting is
> +keycode 183 = backslash bar
The content of the second posting is
> +keycode 181 = backslash underscore
> + control keycode 181 = Control_backslash
> + alt keycode 181 = Meta_backslash
> +keycode 183 = backslash bar
> + control keycode 183 = Control_backslash
> + alt keycode 183 = Meta_backslash
The third posting was almost empty, but reminded me of
> > OGAWA Hirofumi posted a patch for the yen-sign pipe key on 2003.07.23
> > for test1 but his patch still didn't get into test3.
I do not think his patch is needed.
So the question arises: do we need a kernel patch, and if so, what patch?
The program loadkeys exists to load the kernel keymap with the map the user
desires. So, if you need some particular map the obvious answer is:
"use loadkeys".
There is a small snag - until 2.4 the value of NR_KEYS was 128,
while 2.6 uses 256. Moreover, the keys you want to change are above 128.
So, your old precompiled loadkeys will not do - you must recompile the
kbd package against 2.6 kernel headers, or just edit loadkeys.y and dumpkeys.c
inserting
#undef NR_KEYS
#define NR_KEYS 256
after all includes, and then compile on any Linux machine.
There is no need to have knowledge of the Japanese keymap in the kernel,
just as there is no knowledge of the German or French keymap. That
knowledge belongs in the keymap that one loads.
Andries
Andries Brouwer <[email protected]> writes:
> > > OGAWA Hirofumi posted a patch for the yen-sign pipe key on 2003.07.23
> > > for test1 but his patch still didn't get into test3.
>
> I do not think his patch is needed.
>
> So the question arises: do we need a kernel patch, and if so, what patch?
> The program loadkeys exists to load the kernel keymap with the map the user
> desires. So, if you need some particular map the obvious answer is:
> "use loadkeys".
>
> There is a small snag - until 2.4 the value of NR_KEYS was 128,
> while 2.6 uses 256. Moreover, the keys you want to change are above 128.
> So, your old precompiled loadkeys will not do - you must recompile the
> kbd package against 2.6 kernel headers, or just edit loadkeys.y and dumpkeys.c
> inserting
in input.h
#define KEY_MAX 0x1ff
in keyboard.h
#define NR_KEYS (KEY_MAX+1)
NR_KEYS is 512... Or we should use 256, you mean?
--
OGAWA Hirofumi <[email protected]>
On Wed, Sep 17, 2003 at 09:35:22PM +0900, OGAWA Hirofumi wrote:
> Andries Brouwer <[email protected]> writes:
>
> > > > OGAWA Hirofumi posted a patch for the yen-sign pipe key on 2003.07.23
> > > > for test1 but his patch still didn't get into test3.
> > until 2.4 the value of NR_KEYS was 128, while 2.6 uses 256
> in input.h
> #define KEY_MAX 0x1ff
> in keyboard.h
> #define NR_KEYS (KEY_MAX+1)
>
> NR_KEYS is 512... Or we should use 256, you mean?
Yes, I think so.
Maybe Vojtech can tell us why he wrote 512, but I just see a
large amount of wasted space (and, as you already pointed out,
the need for new ioctls) if one uses 512.
As far as I can see, everything works with 256.
Indeed, everything seems to assume 256.
Andries
Andries Brouwer <[email protected]> writes:
> On Wed, Sep 17, 2003 at 09:35:22PM +0900, OGAWA Hirofumi wrote:
> > Andries Brouwer <[email protected]> writes:
> >
> > > > > OGAWA Hirofumi posted a patch for the yen-sign pipe key on 2003.07.23
> > > > > for test1 but his patch still didn't get into test3.
>
> > > until 2.4 the value of NR_KEYS was 128, while 2.6 uses 256
>
> > in input.h
> > #define KEY_MAX 0x1ff
> > in keyboard.h
> > #define NR_KEYS (KEY_MAX+1)
> >
> > NR_KEYS is 512... Or we should use 256, you mean?
>
> Yes, I think so.
>
> Maybe Vojtech can tell us why he wrote 512, but I just see a
> large amount of wasted space (and, as you already pointed out,
> the need for new ioctls) if one uses 512.
>
> As far as I can see, everything works with 256.
> Indeed, everything seems to assume 256.
That sounds good to me. Vojtech, did we need NR_KEYS(KEY_MAX?) greater
than 256?
--
OGAWA Hirofumi <[email protected]>
On Tue, Sep 16, 2003 at 03:43:05PM +0200, Andries Brouwer wrote:
> I do not think his patch is needed.
>
> So the question arises: do we need a kernel patch, and if so, what patch?
> The program loadkeys exists to load the kernel keymap with the map the user
> desires. So, if you need some particular map the obvious answer is:
> "use loadkeys".
>
> There is a small snag - until 2.4 the value of NR_KEYS was 128,
> while 2.6 uses 256. Moreover, the keys you want to change are above 128.
> So, your old precompiled loadkeys will not do - you must recompile the
> kbd package against 2.6 kernel headers, or just edit loadkeys.y and dumpkeys.c
> inserting
>
> #undef NR_KEYS
> #define NR_KEYS 256
>
> after all includes, and then compile on any Linux machine.
>
> There is no need to have knowledge of the Japanese keymap in the kernel,
> just as there is no knowledge of the German or French keymap. That
> knowledge belongs in the keymap that one loads.
There is a slight problem, and that is that NR_KEYS is (KEY_MAX+1) in
recent 2.6's and that's 512. And that doesn't fit into a byte. There
were some patches floating around to enhance the keymap loading ioctls.
They will be needed, along with a new version of loadkeys.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Sun, Sep 21, 2003 at 01:06:29PM +0200, Vojtech Pavlik wrote:
> There is a slight problem, and that is that NR_KEYS is (KEY_MAX+1) in
> recent 2.6's and that's 512. And that doesn't fit into a byte. There
> were some patches floating around to enhance the keymap loading ioctls.
> They will be needed, along with a new version of loadkeys.
Yes - a lot of trouble.
As far as I can see, the space between 256 and 511 is never used.
More in particular, there are lots of places where the kernel
seems to assume that only 256 is used.
So, instead of requiring new ioctls and new loadkeys etc
I would prefer to make NR_KEYS 256, if possible.
So the question is: why did you require 512?
Andries
On Sun, Sep 21, 2003 at 02:39:34PM +0200, Andries Brouwer wrote:
> On Sun, Sep 21, 2003 at 01:06:29PM +0200, Vojtech Pavlik wrote:
>
> > There is a slight problem, and that is that NR_KEYS is (KEY_MAX+1) in
> > recent 2.6's and that's 512. And that doesn't fit into a byte. There
> > were some patches floating around to enhance the keymap loading ioctls.
> > They will be needed, along with a new version of loadkeys.
>
> Yes - a lot of trouble.
> As far as I can see, the space between 256 and 511 is never used.
>
> More in particular, there are lots of places where the kernel
> seems to assume that only 256 is used.
>
> So, instead of requiring new ioctls and new loadkeys etc
> I would prefer to make NR_KEYS 256, if possible.
> So the question is: why did you require 512?
Excerpt from input.h:
#define KEY_RESTART 0x198
#define KEY_SLOW 0x199
#define KEY_SHUFFLE 0x19a
#define KEY_BREAK 0x19b
#define KEY_PREVIOUS 0x19c
#define KEY_DIGITS 0x19d
#define KEY_TEEN 0x19e
#define KEY_TWEN 0x19f
#define KEY_DEL_EOL 0x1c0
#define KEY_DEL_EOS 0x1c1
#define KEY_INS_LINE 0x1c2
#define KEY_DEL_LINE 0x1c3
So far the last defined key is KEY_DEL_LINE, with a code of 0x1c3.
That's above 256. If there are other places that require less than 256,
well, then those will need to be fixed or we're heading for trouble.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Sun, Sep 21, 2003 at 02:48:17PM +0200, Vojtech Pavlik wrote:
> > So, instead of requiring new ioctls and new loadkeys etc
> > I would prefer to make NR_KEYS 256, if possible.
> > So the question is: why did you require 512?
>
> Excerpt from input.h:
> #define KEY_TEEN 0x19e
> #define KEY_TWEN 0x19f
> #define KEY_DEL_EOL 0x1c0
> #define KEY_DEL_EOS 0x1c1
>
> So far the last defined key is KEY_DEL_LINE, with a code of 0x1c3.
> That's above 256. If there are other places that require less than 256,
> well, then those will need to be fixed or we're heading for trouble.
Hmm. The kernel assumes today that keycodes have 8 bits:
In drivers/char/keyboard.c emulate_raw() tries to invent
the codes that the keyboard probably sent and resulted in a given
keycode. It starts out
if (keycode > 255)
return -1;
In drivers/input/keyboards/atkbd.c we have tables that convert
scancodes to keycodes. The declaration is
static unsigned char atkbd_set2_keycode[512];
the unsigned char means that no keycodes larger than 255 can be returned.
It really seems a pity to have to add new ioctls, and to have to release
a new version of the kbd package, and to waste a lot of kernel space,
while essentially nobody needs the resulting functionality.
Andries
On Sun, Sep 21, 2003 at 04:49:14PM +0200, Andries Brouwer wrote:
> > > So, instead of requiring new ioctls and new loadkeys etc
> > > I would prefer to make NR_KEYS 256, if possible.
> > > So the question is: why did you require 512?
> >
> > Excerpt from input.h:
>
> > #define KEY_TEEN 0x19e
> > #define KEY_TWEN 0x19f
> > #define KEY_DEL_EOL 0x1c0
> > #define KEY_DEL_EOS 0x1c1
> >
> > So far the last defined key is KEY_DEL_LINE, with a code of 0x1c3.
> > That's above 256. If there are other places that require less than 256,
> > well, then those will need to be fixed or we're heading for trouble.
>
> Hmm. The kernel assumes today that keycodes have 8 bits:
>
> In drivers/char/keyboard.c emulate_raw() tries to invent
> the codes that the keyboard probably sent and resulted in a given
> keycode. It starts out
> if (keycode > 255)
> return -1;
That's correct, because it can only emulate about 230 different
keycodes. Note that this is not 'invent what the keyboard sent', since
in many cases the keyboard did not send any keycodes (USB) or at least
not any AT-looking keycodes.
However XFree86 (and this hack is there ONLY because of XFree86) needs
AT-looking keycodes on most architectures.
If somebody could teach XFree86 to use at least the medium raw mode
here, we could get rid both of the emulate_raw() stuff and of the
limitation of what we can pass to XFree86.
Also, this causes trouble with the japanese keys in XFree86, since the
KEY_INTL* keys are in the e0 xx range because of the emulation.
> In drivers/input/keyboards/atkbd.c we have tables that convert
> scancodes to keycodes. The declaration is
> static unsigned char atkbd_set2_keycode[512];
> the unsigned char means that no keycodes larger than 255 can be returned.
We may need to change this to a u16, IF we'll ever need to load a
keycode above 256 for an AT keyboard. Keep in mind that AT keyboards are
not the whole world. So far all the keys on AT keyboards are within the
0..255 range. That's of course not true for other, more crazy keyboards.
> It really seems a pity to have to add new ioctls, and to have to release
> a new version of the kbd package, and to waste a lot of kernel space,
> while essentially nobody needs the resulting functionality.
We could do an audit of the key definitions, document which KEY_* symbol
means exactly what (and it'd be a good thing anyway), by that try to
remove duplicities and try to stuff everything in 0..255.
We'd lose te potential possibility to map keysyms to buttons, though
since that never was used, nobody would cry probably.
However, my experience tells me that whenever some range is tight, and
0..255 is in this case, we will very soon overflow as new weird devices
come into market.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Sun, Sep 21, 2003 at 07:07:10PM +0200, Vojtech Pavlik wrote:
> > static unsigned char atkbd_set2_keycode[512];
>
> We may need to change this to a u16, IF we'll ever need to load a
> keycode above 256 for an AT keyboard. So far all the keys on AT keyboards
> are within the 0..255 range. That's of course not true for other,
> more crazy keyboards.
>
> > It really seems a pity to have to add new ioctls, and to have to release
> > a new version of the kbd package, and to waste a lot of kernel space,
> > while essentially nobody needs the resulting functionality.
>
> We could do an audit of the key definitions, document which KEY_* symbol
> means exactly what (and it'd be a good thing anyway), by that try to
> remove duplicities and try to stuff everything in 0..255.
Yes.
I think that if you remove everything that is not used inside the kernel,
the rest fits problemless into 0..255.
> We'd lose te potential possibility to map keysyms to buttons, though
> since that never was used, nobody would cry probably.
>
> However, my experience tells me that whenever some range is tight, and
> 0..255 is in this case, we will very soon overflow as new weird devices
> come into market.
True. In the long run more may be needed. (If we really want to assign
a different keycode to each possible picture on a key.)
I would be happy if we could pass smoothly from old to new - no new
ioctls for 2.6.0 yet, a kbd package that only changes the NR_KEYS define,
and later worry about whether we really need lots of keycodes.
Everything we add will never go away, so we must be slow in adding.
Andries
On Sun, Sep 21, 2003 at 07:42:00PM +0200, Andries Brouwer wrote:
> > > static unsigned char atkbd_set2_keycode[512];
> >
> > We may need to change this to a u16, IF we'll ever need to load a
> > keycode above 256 for an AT keyboard. So far all the keys on AT keyboards
> > are within the 0..255 range. That's of course not true for other,
> > more crazy keyboards.
> >
> > > It really seems a pity to have to add new ioctls, and to have to release
> > > a new version of the kbd package, and to waste a lot of kernel space,
> > > while essentially nobody needs the resulting functionality.
> >
> > We could do an audit of the key definitions, document which KEY_* symbol
> > means exactly what (and it'd be a good thing anyway), by that try to
> > remove duplicities and try to stuff everything in 0..255.
>
> Yes.
>
> I think that if you remove everything that is not used inside the kernel,
> the rest fits problemless into 0..255.
But that's definitely not a way to go. Since the scancode->keycode maps
are loadable in atkbd.c and a couple other drivers. So, if you change to
'cannot be used' by the kernel, then fine ...
> > We'd lose te potential possibility to map keysyms to buttons, though
> > since that never was used, nobody would cry probably.
> >
> > However, my experience tells me that whenever some range is tight, and
> > 0..255 is in this case, we will very soon overflow as new weird devices
> > come into market.
>
> True. In the long run more may be needed. (If we really want to assign
> a different keycode to each possible picture on a key.)
I think it's a good thing to do that. It makes a lot of things simpler.
> I would be happy if we could pass smoothly from old to new - no new
> ioctls for 2.6.0 yet, a kbd package that only changes the NR_KEYS define,
> and later worry about whether we really need lots of keycodes.
> Everything we add will never go away, so we must be slow in adding.
It's not as bad as it seems. Old ioctls can go away, namely if they're
not widely used. But I agree - for 2.6 it probably is wise to try to fit
into 256 keycodes. One has to keep in mind that there might be more in
the future, though.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
Hi!
> > #define KEY_TEEN 0x19e
> > #define KEY_TWEN 0x19f
> > #define KEY_DEL_EOL 0x1c0
> > #define KEY_DEL_EOS 0x1c1
> >
> > So far the last defined key is KEY_DEL_LINE, with a code of 0x1c3.
> > That's above 256. If there are other places that require less than 256,
> > well, then those will need to be fixed or we're heading for trouble.
>
> Hmm. The kernel assumes today that keycodes have 8 bits:
>
> In drivers/char/keyboard.c emulate_raw() tries to invent
> the codes that the keyboard probably sent and resulted in a given
> keycode. It starts out
> if (keycode > 255)
> return -1;
>
> In drivers/input/keyboards/atkbd.c we have tables that convert
> scancodes to keycodes. The declaration is
> static unsigned char atkbd_set2_keycode[512];
> the unsigned char means that no keycodes larger than 255 can be returned.
>
> It really seems a pity to have to add new ioctls, and to have to release
> a new version of the kbd package, and to waste a lot of kernel space,
> while essentially nobody needs the resulting functionality.
Multimedia keyboards are very common today,
and tv cards with their remote controls need it,
too.
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...