bad scancode for USB keyboard

bad scancode for USB keyboard

[Bernardo Innocenti]

Hello,

I have a USB keyboard (Logitech Internet Navigator).
This keyboard has two "backslash + bar" keys, one of which
is located next to the RETURN key.

The backslash key always worked fine in 2.4.x, but in 2.6.x
and 2.6.0, the scancode reported by showkey is "84", which is
usually associated with the "Prevconsole" function in most
keymaps.

Editing the keymap fixes the problem, but of course this must
be a bug in the kernel driver.  I compared the 2.4.23 version
of kbdmap.c with 2.6.0, but didn't find any obvious reason for
this difference.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: bad scancode for USB keyboard

[Bernardo Innocenti]

Fredrik Olausson wrote:

(I've re-posted to lkml in case someone else finds it useful)

> Bernardo Innocenti wrote:
>> I have a USB keyboard (Logitech Internet Navigator).
>> This keyboard has two "backslash + bar" keys, one of which
>> is located next to the RETURN key.
>>
>> The backslash key always worked fine in 2.4.x, but in 2.6.x
>> and 2.6.0, the scancode reported by showkey is "84", which is
>> usually associated with the "Prevconsole" function in most
>> keymaps.
>>
>> Editing the keymap fixes the problem, but of course this must
>> be a bug in the kernel driver.  I compared the 2.4.23 version
>> of kbdmap.c with 2.6.0, but didn't find any obvious reason for
>> this difference.
>
> I have the same problem with a Logitech cordless desktop.
> I can easily change the keycode to generate the right characters when in 
> console-mode, but XFree gives that key and the Print Screen key the same 
> keycode.
> After changing the xmodmap I can get the unmodified character, 
> but modifiers doesn't work, it just gives me the same character not 
> matter what modifier I use (shift, alt, alt_gr etc.)

I had fixed my console keymap too, but I've not been able to
figure out how to change the X keymap.  I've been looking in
the /usr/X11R6/lib/X11/xkb/ directory, but perhaps XKB is not
being used for old-style keyboard mapping?

Could you provide detailed instructions?  C coding with missing
backslash and bar keys is quite hard :-)

Of course, I still thing its' a 2.6 kernel bug and it should be
fixed.  Vojtech, do you have an idea why it's happening?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: bad scancode for USB keyboard

[Vojtech Pavlik]

On Wed, Jan 07, 2004 at 03:27:42AM +0100, Bernardo Innocenti wrote:

> >I have the same problem with a Logitech cordless desktop.
> >I can easily change the keycode to generate the right characters when in 
> >console-mode, but XFree gives that key and the Print Screen key the same 
> >keycode.
> >After changing the xmodmap I can get the unmodified character, 
> >but modifiers doesn't work, it just gives me the same character not 
> >matter what modifier I use (shift, alt, alt_gr etc.)
> 
> I had fixed my console keymap too, but I've not been able to
> figure out how to change the X keymap.  I've been looking in
> the /usr/X11R6/lib/X11/xkb/ directory, but perhaps XKB is not
> being used for old-style keyboard mapping?
> 
> Could you provide detailed instructions?  C coding with missing
> backslash and bar keys is quite hard :-)
> 
> Of course, I still thing its' a 2.6 kernel bug and it should be
> fixed.  Vojtech, do you have an idea why it's happening?

The reason is that this key is not the ordinary backslash-bar key, it's
the so-called 103rd key on some european keyboards. It generates a
different scancode.

2.4 used the same keycode for both the scancodes, 2.6 does not, so that
it's possible to differentiate between the keys on keyboards that have
both this one and also the standard backslash-bar.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: bad scancode for USB keyboard

[Bernardo Innocenti]

Vojtech Pavlik wrote:
> On Wed, Jan 07, 2004 at 03:27:42AM +0100, Bernardo Innocenti wrote:
> 
>>>I have the same problem with a Logitech cordless desktop.
>>>I can easily change the keycode to generate the right characters when in 
>>>console-mode, but XFree gives that key and the Print Screen key the same 
>>>keycode.
>>>After changing the xmodmap I can get the unmodified character, 
>>>but modifiers doesn't work, it just gives me the same character not 
>>>matter what modifier I use (shift, alt, alt_gr etc.)
>>
>>I had fixed my console keymap too, but I've not been able to
>>figure out how to change the X keymap.  I've been looking in
>>the /usr/X11R6/lib/X11/xkb/ directory, but perhaps XKB is not
>>being used for old-style keyboard mapping?
>>
>>Could you provide detailed instructions?  C coding with missing
>>backslash and bar keys is quite hard :-)
>>
>>Of course, I still thing its' a 2.6 kernel bug and it should be
>>fixed.  Vojtech, do you have an idea why it's happening?
> 
> The reason is that this key is not the ordinary backslash-bar key, it's
> the so-called 103rd key on some european keyboards. It generates a
> different scancode.

Yes, I've found out it's 84 for the key besides/below the enter key.

> 2.4 used the same keycode for both the scancodes, 2.6 does not, so that
> it's possible to differentiate between the keys on keyboards that have
> both this one and also the standard backslash-bar.

I see...  So it appears the fix has to be done in the kbd package and in
XFree86.

The default console keymap should be changed like this:

 < keycode  84 = Last_Console
 > keycode  84 = backslash        bar

Andries Brouwer appears to be the current maintainer of kbd, so I've
pulled him into our thread.  This is also being cross-postied to
the devel@XFree86.org list.

In addition, I'm going to open two PRs for these packages in RedHat's
bugzilla to make sure the issue gets properly fixed before it hits the
masses.

fyi, this thread was started here:

  http://www.ussg.iu.edu/hypermail/linux/kernel/0401.0/0485.html

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: bad scancode for USB keyboard

[Fredrik Olausson]

I have found a solution to the problem.
XFree86 has 2 keyboard drivers, the default one named "keyboard" and an 
alternative one named "kbd" which according to documentation on the 
XFree86 website is a new keyboard driver mostly written from scratch. 
With the kbd-driver the print-screen key and the |\-key got different 
keycodes and thus I could make the |\-key give me the proper characters.

So, to summarize. Simply changing the line:
Driver      "keyboard"
to
Driver      "kbd"
in the input-device section in the XF86Config file and fiddling a bit 
with xmodmap solved the problem for me.

Bernardo Innocenti wrote:
> Vojtech Pavlik wrote:
> 
>> On Wed, Jan 07, 2004 at 03:27:42AM +0100, Bernardo Innocenti wrote:
>>
>>>> I have the same problem with a Logitech cordless desktop.
>>>> I can easily change the keycode to generate the right characters 
>>>> when in console-mode, but XFree gives that key and the Print Screen 
>>>> key the same keycode.
>>>> After changing the xmodmap I can get the unmodified character, but 
>>>> modifiers doesn't work, it just gives me the same character not 
>>>> matter what modifier I use (shift, alt, alt_gr etc.)
>>>
>>>
>>> I had fixed my console keymap too, but I've not been able to
>>> figure out how to change the X keymap.  I've been looking in
>>> the /usr/X11R6/lib/X11/xkb/ directory, but perhaps XKB is not
>>> being used for old-style keyboard mapping?
>>>
>>> Could you provide detailed instructions?  C coding with missing
>>> backslash and bar keys is quite hard :-)
>>>
>>> Of course, I still thing its' a 2.6 kernel bug and it should be
>>> fixed.  Vojtech, do you have an idea why it's happening?
>>
>>
>> The reason is that this key is not the ordinary backslash-bar key, it's
>> the so-called 103rd key on some european keyboards. It generates a
>> different scancode.
> 
> 
> Yes, I've found out it's 84 for the key besides/below the enter key.
> 
>> 2.4 used the same keycode for both the scancodes, 2.6 does not, so that
>> it's possible to differentiate between the keys on keyboards that have
>> both this one and also the standard backslash-bar.
> 
> 
> I see...  So it appears the fix has to be done in the kbd package and in
> XFree86.
> 
> The default console keymap should be changed like this:
> 
> < keycode  84 = Last_Console
>  > keycode  84 = backslash        bar
> 
> Andries Brouwer appears to be the current maintainer of kbd, so I've
> pulled him into our thread.  This is also being cross-postied to
> the devel@XFree86.org list.
> 
> In addition, I'm going to open two PRs for these packages in RedHat's
> bugzilla to make sure the issue gets properly fixed before it hits the
> masses.
> 
> fyi, this thread was started here:
> 
>  http://www.ussg.iu.edu/hypermail/linux/kernel/0401.0/0485.html
> 

Re: bad scancode for USB keyboard

[Bernardo Innocenti]

Fredrik Olausson wrote:
> I have found a solution to the problem.
> XFree86 has 2 keyboard drivers, the default one named "keyboard" and an 
> alternative one named "kbd" which according to documentation on the 
> XFree86 website is a new keyboard driver mostly written from scratch. 
> With the kbd-driver the print-screen key and the |\-key got different 
> keycodes and thus I could make the |\-key give me the proper characters.
> 
> So, to summarize. Simply changing the line:
> Driver      "keyboard"
> to
> Driver      "kbd"
> in the input-device section in the XF86Config file and fiddling a bit 
> with xmodmap solved the problem for me.

That's good news, and I'd never heard about a new keyboard driver in
XFree86... It's indeed a project full of undocumented and obscure
features.

Err... what did you exactly say on the xmodmap command line to get
it to work? -)

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: bad scancode for USB keyboard

[Eduard Bloch]

#include <hallo.h>
* Vojtech Pavlik [Wed, Jan 07 2004, 09:51:04AM]:

> The reason is that this key is not the ordinary backslash-bar key, it's
> the so-called 103rd key on some european keyboards. It generates a
> different scancode.

Fine, but there are a lot of USB keyboard that _work_ that way, where
the "103rd" key is really positioned as the one and the only one '# key.
And the current stable X release does NOT know about the new scancode.
You realize that you intentionaly broke compatibility within a stable
kernel release?

> 2.4 used the same keycode for both the scancodes, 2.6 does not, so that
> it's possible to differentiate between the keys on keyboards that have
> both this one and also the standard backslash-bar.

*May* be a nice feature, but such things require better planning.

Regards,
Eduard (going to revert that change before compiling 2.6.1 now).
-- 
Am Abend manche Hülle fällt, die sonst des Leibes Fülle hält.

[PATCH] Re: bad scancode for USB keyboard

[Vojtech Pavlik]

On Sun, Jan 11, 2004 at 05:30:50PM +0100, Eduard Bloch wrote:

> #include <hallo.h>
> * Vojtech Pavlik [Wed, Jan 07 2004, 09:51:04AM]:
> 
> > The reason is that this key is not the ordinary backslash-bar key, it's
> > the so-called 103rd key on some european keyboards. It generates a
> > different scancode.
> 
> Fine, but there are a lot of USB keyboard that _work_ that way, where
> the "103rd" key is really positioned as the one and the only one '# key.
> And the current stable X release does NOT know about the new scancode.
> You realize that you intentionaly broke compatibility within a stable
> kernel release?

Good point. And I'm suffering the consequences already. Up to the
change, I didn't know that so many keyboards are actually using this
key, so I supposed it'll be a rather low-impact change. I stand
corrected now.

Linus, Andrew, please apply this fix:

ChangeSet@1.1511, 2004-01-11 19:41:05+01:00, vojtech@suse.cz
  input: Fix emulation of PrintScreen key and 103rd Euro key for XFree86.

diff -Nru a/drivers/char/keyboard.c b/drivers/char/keyboard.c
--- a/drivers/char/keyboard.c	Sun Jan 11 19:42:55 2004
+++ b/drivers/char/keyboard.c	Sun Jan 11 19:42:55 2004
@@ -941,8 +941,8 @@
 	 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
 	 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
 	 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
-	 80, 81, 82, 83, 84, 93, 86, 87, 88, 94, 95, 85,259,375,260, 90,
-	284,285,309,311,312, 91,327,328,329,331,333,335,336,337,338,339,
+	 80, 81, 82, 83, 43, 93, 86, 87, 88, 94, 95, 85,259,375,260, 90,
+	284,285,309,298,312, 91,327,328,329,331,333,335,336,337,338,339,
 	367,288,302,304,350, 89,334,326,116,377,109,111,126,347,348,349,
 	360,261,262,263,298,376,100,101,321,316,373,286,289,102,351,355,
 	103,104,105,275,287,279,306,106,274,107,294,364,358,363,362,361,


-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [PATCH] Re: bad scancode for USB keyboard

[Olaf Hering]

 On Sun, Jan 11, Vojtech Pavlik wrote:

> On Sun, Jan 11, 2004 at 05:30:50PM +0100, Eduard Bloch wrote:
> 
> > #include <hallo.h>
> > * Vojtech Pavlik [Wed, Jan 07 2004, 09:51:04AM]:
> > 
> > > The reason is that this key is not the ordinary backslash-bar key, it's
> > > the so-called 103rd key on some european keyboards. It generates a
> > > different scancode.
> > 
> > Fine, but there are a lot of USB keyboard that _work_ that way, where
> > the "103rd" key is really positioned as the one and the only one '# key.
> > And the current stable X release does NOT know about the new scancode.
> > You realize that you intentionaly broke compatibility within a stable
> > kernel release?
> 
> Good point. And I'm suffering the consequences already. Up to the
> change, I didn't know that so many keyboards are actually using this
> key, so I supposed it'll be a rather low-impact change. I stand
> corrected now.
> 
> Linus, Andrew, please apply this fix:
> 
> ChangeSet@1.1511, 2004-01-11 19:41:05+01:00, vojtech@suse.cz
>   input: Fix emulation of PrintScreen key and 103rd Euro key for XFree86.

I tried the 2.6.1-mm2 tree and changed the 84 to 43, but that doesnt
help my USB keyboard. Showkey does still show 84.

static unsigned short x86_keycodes[256] =
...
         80, 81, 82, 83, 43, 93, 86, 87, 88, 94, 95, 85,259,375,260, 90,
...

Maybe adbhid needs a similar tweak? I could not find the place, yet.


-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

Re: [PATCH] Re: bad scancode for USB keyboard

[Vojtech Pavlik]

On Wed, Jan 14, 2004 at 02:54:33PM +0100, Olaf Hering wrote:
>  On Sun, Jan 11, Vojtech Pavlik wrote:
> 
> > On Sun, Jan 11, 2004 at 05:30:50PM +0100, Eduard Bloch wrote:
> > 
> > > #include <hallo.h>
> > > * Vojtech Pavlik [Wed, Jan 07 2004, 09:51:04AM]:
> > > 
> > > > The reason is that this key is not the ordinary backslash-bar key, it's
> > > > the so-called 103rd key on some european keyboards. It generates a
> > > > different scancode.
> > > 
> > > Fine, but there are a lot of USB keyboard that _work_ that way, where
> > > the "103rd" key is really positioned as the one and the only one '# key.
> > > And the current stable X release does NOT know about the new scancode.
> > > You realize that you intentionaly broke compatibility within a stable
> > > kernel release?
> > 
> > Good point. And I'm suffering the consequences already. Up to the
> > change, I didn't know that so many keyboards are actually using this
> > key, so I supposed it'll be a rather low-impact change. I stand
> > corrected now.
> > 
> > Linus, Andrew, please apply this fix:
> > 
> > ChangeSet@1.1511, 2004-01-11 19:41:05+01:00, vojtech@suse.cz
> >   input: Fix emulation of PrintScreen key and 103rd Euro key for XFree86.
> 
> I tried the 2.6.1-mm2 tree and changed the 84 to 43, but that doesnt
> help my USB keyboard. Showkey does still show 84.
> 
> static unsigned short x86_keycodes[256] =
> ...
>          80, 81, 82, 83, 43, 93, 86, 87, 88, 94, 95, 85,259,375,260, 90,
> ...
> 
> Maybe adbhid needs a similar tweak? I could not find the place, yet.

showkey _will_ still show 84, because the keycode still is 84. Only the
rawmode emulation was fixed. I really don't want to make the keycode 43
because the 103rd key it is a different key than backslash. 

So on console you still need to change your keymap. I could change the
keycode to be something else than 84, but that'd not help much. I'm
currently toying with the idea of detecting a keymap that expects the
key to generate code 43 and do a workaround for it ...

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR