multimedia keys not working in 2.6.0-test6

multimedia keys not working in 2.6.0-test6

[Pau Aliagas]

These are the messages I get when pressing P1 and P2 in my laptop.

kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x153, data 0x74, on isa0060/serio0).
kernel: atkbd.c: Unknown key released (translated set 2, code 0x153, data 0xf4, on isa0060/serio0).

Email and browser keys report a correct code and I can bind thm to any app 
using xbindkeys, but with thes two there's no way.

I'm running 2.6.0-test6--mm1 with the events patch removed.

Pau

Re: multimedia keys not working in 2.6.0-test6

[Andries Brouwer]

On Tue, Sep 30, 2003 at 01:54:59PM +0200, Pau Aliagas wrote:

> These are the messages I get when pressing P1 and P2 in my laptop.
> 
> kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x153, data 0x74, on isa0060/serio0).
> kernel: atkbd.c: Unknown key released (translated set 2, code 0x153, data 0xf4, on isa0060/serio0).
> 
> Email and browser keys report a correct code and I can bind thm to any app 
> using xbindkeys, but with thes two there's no way.

These keys produce scancode e0 74. Untranslated e0 53.
Entry 0x153 of atkbd_set2_keycode[] is 0, that is why
the key is called unknown.

The normal way of assigning a keycode is by using setkeycodes.
This uses the KDSETKEYCODE ioctl, but it is broken at present.

The reason is that it is written to use 0-127 for scancode xx
and 128-255 for scancode pair e0 xx. (Translated set2, of course.)
However, the current kernel untranslates what the keyboard sends
and then uses a scancode-to-keycode mapping for untranslated set 2.
That breaks this ioctl.
Moreover, it uses a shift of 256 instead of 128 for e0.
That also breaks this ioctl.

So, today the easiest way of getting these keys to work is to
edit kernel source: linux/drivers/input/keyboard/atkbd.c
and adapt atkbd_set2_keycode[0x153]. This is the line
 226,  0,  0,  0,  0,  0,153,140,  0,255, 96,  0,  0,  0,143,  0,
if I am not mistaken, of which you want to change the fourth
number, the third zero, to the desired keycode.

In the meantime we can worry about the best way to fix this ioctl.

Andries


By the way - what keyboard do you have?
e0 74 is not a very common code.
Could you collect the scancodes and keycaps for the multimedia
or other unusual keys using "showkey -s" and mail to aeb@cwi.nl ?
I would like to add your data to the database at
  http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html

Re: multimedia keys not working in 2.6.0-test6

[Vojtech Pavlik]

On Tue, Sep 30, 2003 at 04:56:21PM +0200, Andries Brouwer wrote:

> On Tue, Sep 30, 2003 at 01:54:59PM +0200, Pau Aliagas wrote:
> 
> > These are the messages I get when pressing P1 and P2 in my laptop.
> > 
> > kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x153, data 0x74, on isa0060/serio0).
> > kernel: atkbd.c: Unknown key released (translated set 2, code 0x153, data 0xf4, on isa0060/serio0).
> > 
> > Email and browser keys report a correct code and I can bind thm to any app 
> > using xbindkeys, but with thes two there's no way.
> 
> These keys produce scancode e0 74. Untranslated e0 53.
> Entry 0x153 of atkbd_set2_keycode[] is 0, that is why
> the key is called unknown.
> 
> The normal way of assigning a keycode is by using setkeycodes.
> This uses the KDSETKEYCODE ioctl, but it is broken at present.
> 
> The reason is that it is written to use 0-127 for scancode xx
> and 128-255 for scancode pair e0 xx. (Translated set2, of course.)
> However, the current kernel untranslates what the keyboard sends
> and then uses a scancode-to-keycode mapping for untranslated set 2.
> That breaks this ioctl.
> Moreover, it uses a shift of 256 instead of 128 for e0.
> That also breaks this ioctl.

It actually works pretty well on 2.6. You jsut have to pass a different
number on 2.6 than you do on 2.4 - that is:

	setkeycodes 153 148

153 is the reported scancode (e0 53 untranslated, e0 74 translated),
148 is the keycode for KEY_PROG1

(There is still a small bug in the bitmap setting, and I'll be fixing
that tonight, but unless you have more than one scancode generating the
same keycode, it won't bite you.)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: multimedia keys not working in 2.6.0-test6

[Pau Aliagas]

On Tue, 30 Sep 2003, Vojtech Pavlik wrote:

> On Tue, Sep 30, 2003 at 04:56:21PM +0200, Andries Brouwer wrote:
> 
> > On Tue, Sep 30, 2003 at 01:54:59PM +0200, Pau Aliagas wrote:
> > 
> > > These are the messages I get when pressing P1 and P2 in my laptop.
> > > 
> > > kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x153, data 0x74, on isa0060/serio0).
> > > kernel: atkbd.c: Unknown key released (translated set 2, code 0x153, data 0xf4, on isa0060/serio0).
> > > 
> > > Email and browser keys report a correct code and I can bind thm to any app 
> > > using xbindkeys, but with thes two there's no way.
> > 
> > These keys produce scancode e0 74. Untranslated e0 53.
> > Entry 0x153 of atkbd_set2_keycode[] is 0, that is why
> > the key is called unknown.
> > 
> > The normal way of assigning a keycode is by using setkeycodes.
> > This uses the KDSETKEYCODE ioctl, but it is broken at present.
> > 
> > The reason is that it is written to use 0-127 for scancode xx
> > and 128-255 for scancode pair e0 xx. (Translated set2, of course.)
> > However, the current kernel untranslates what the keyboard sends
> > and then uses a scancode-to-keycode mapping for untranslated set 2.
> > That breaks this ioctl.
> > Moreover, it uses a shift of 256 instead of 128 for e0.
> > That also breaks this ioctl.
> 
> It actually works pretty well on 2.6. You jsut have to pass a different
> number on 2.6 than you do on 2.4 - that is:
> 
> 	setkeycodes 153 148
> 
> 153 is the reported scancode (e0 53 untranslated, e0 74 translated),
> 148 is the keycode for KEY_PROG1
> 
> (There is still a small bug in the bitmap setting, and I'll be fixing
> that tonight, but unless you have more than one scancode generating the
> same keycode, it won't bite you.)

# setkeycodes 153 148
setkeycode: code outside bounds
usage: setkeycode scancode keycode ...
 (where scancode is either xx or e0xx, given in hexadecimal,
  and keycode is given in decimal)

I tried xx153, 0e153, 0exx153 and no way.

Pau

Re: multimedia keys not working in 2.6.0-test6

[Vojtech Pavlik]

On Tue, Sep 30, 2003 at 05:52:03PM +0200, Pau Aliagas wrote:
> On Tue, 30 Sep 2003, Vojtech Pavlik wrote:
> 
> > On Tue, Sep 30, 2003 at 04:56:21PM +0200, Andries Brouwer wrote:
> > 
> > > On Tue, Sep 30, 2003 at 01:54:59PM +0200, Pau Aliagas wrote:
> > > 
> > > > These are the messages I get when pressing P1 and P2 in my laptop.
> > > > 
> > > > kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x153, data 0x74, on isa0060/serio0).
> > > > kernel: atkbd.c: Unknown key released (translated set 2, code 0x153, data 0xf4, on isa0060/serio0).
> > > > 
> > > > Email and browser keys report a correct code and I can bind thm to any app 
> > > > using xbindkeys, but with thes two there's no way.
> > > 
> > > These keys produce scancode e0 74. Untranslated e0 53.
> > > Entry 0x153 of atkbd_set2_keycode[] is 0, that is why
> > > the key is called unknown.
> > > 
> > > The normal way of assigning a keycode is by using setkeycodes.
> > > This uses the KDSETKEYCODE ioctl, but it is broken at present.
> > > 
> > > The reason is that it is written to use 0-127 for scancode xx
> > > and 128-255 for scancode pair e0 xx. (Translated set2, of course.)
> > > However, the current kernel untranslates what the keyboard sends
> > > and then uses a scancode-to-keycode mapping for untranslated set 2.
> > > That breaks this ioctl.
> > > Moreover, it uses a shift of 256 instead of 128 for e0.
> > > That also breaks this ioctl.
> > 
> > It actually works pretty well on 2.6. You jsut have to pass a different
> > number on 2.6 than you do on 2.4 - that is:
> > 
> > 	setkeycodes 153 148
> > 
> > 153 is the reported scancode (e0 53 untranslated, e0 74 translated),
> > 148 is the keycode for KEY_PROG1
> > 
> > (There is still a small bug in the bitmap setting, and I'll be fixing
> > that tonight, but unless you have more than one scancode generating the
> > same keycode, it won't bite you.)
> 
> # setkeycodes 153 148
> setkeycode: code outside bounds
> usage: setkeycode scancode keycode ...
>  (where scancode is either xx or e0xx, given in hexadecimal,
>   and keycode is given in decimal)
> 
> I tried xx153, 0e153, 0exx153 and no way.
 
Too bad. Your setkeycodes seems to do too clever input data checking. 
Although the ioctl data type for scancode is an int, it insists on the
value fitting into a byte.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR