I can no longer change keycodes since switching to the new input layer.
Has anyone been able to?
--
Skip
On Mon, Sep 30, 2002 at 10:40:10AM -0400, Skip Ford wrote:
> I can no longer change keycodes since switching to the new input layer.
> Has anyone been able to?
I've tested it and it should work. What exactly doesn't work for you?
What are you trying to do?
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlik wrote:
> On Mon, Sep 30, 2002 at 10:40:10AM -0400, Skip Ford wrote:
>
> > I can no longer change keycodes since switching to the new input layer.
> > Has anyone been able to?
>
> I've tested it and it should work. What exactly doesn't work for you?
> What are you trying to do?
I'm trying to assign keycodes using the kbd package. Multimedia keys
and some regular keys. Here is one example. The key I'm pressing is
e05e.
~# showkey
kb mode was XLATE
press any key (program terminates 10s after last keypress)...
keycode 116 press
keycode 116 release
~# getkeycodes
Plain scancodes xx (hex) versus keycodes (dec)
0 is an error; for 1-88 (0x01-0x58) scancode equals keycode
0x58: 88 54 28 27 0 43 0 0
0x60: 85 86 90 91 92 93 14 94
0x68: 95 79 0 75 71 121 0 123
0x70: 82 83 80 76 77 72 1 69
0x78: 87 78 81 74 55 73 70 99
Escaped scancodes e0 xx (hex)
e0 00: 252 0 0 65 99 0 0 0
e0 08: 0 0 0 0 0 0 0 0
e0 10: 0 0 0 0 0 0 0 0
e0 18: 0 0 0 0 0 0 0 0
e0 20: 0 0 0 0 0 0 0 0
e0 28: 0 0 251 0 0 0 0 0
e0 30: 0 0 0 0 0 0 0 0
e0 38: 0 0 0 0 0 0 0 0
e0 40: 0 0 0 0 0 0 0 0
e0 48: 0 0 0 0 0 0 0 0
e0 50: 0 0 0 0 0 0 0 0
e0 58: 0 0 0 0 0 0 0 0
^^^ <-- e05e
e0 60: 252 253 0 0 0 0 0 0
e0 68: 0 0 0 0 0 0 0 0
e0 70: 254 0 0 0 0 0 0 0
e0 78: 0 0 0 0 0 0 0 255
~# setkeycodes e05e 89
~# getkeycodes
Plain scancodes xx (hex) versus keycodes (dec)
0 is an error; for 1-88 (0x01-0x58) scancode equals keycode
0x58: 88 54 28 27 0 43 0 0
0x60: 85 86 90 91 92 93 14 94
0x68: 95 79 0 75 71 121 0 123
0x70: 82 83 80 76 77 72 1 69
0x78: 87 78 81 74 55 73 70 99
Escaped scancodes e0 xx (hex)
e0 00: 252 0 0 65 99 0 0 0
e0 08: 0 0 0 0 0 0 0 0
e0 10: 0 0 0 0 0 0 0 0
e0 18: 0 0 0 0 0 0 0 0
e0 20: 0 0 0 0 0 0 0 0
e0 28: 0 0 251 0 0 0 0 0
e0 30: 0 0 0 0 0 0 0 0
e0 38: 0 0 0 0 0 0 0 0
e0 40: 0 0 0 0 0 0 0 0
e0 48: 0 0 0 0 0 0 0 0
e0 50: 0 0 0 0 0 0 0 0
e0 58: 0 0 0 0 0 0 89 0
^^^^ <-- e05e
e0 60: 252 253 0 0 0 0 0 0
e0 68: 0 0 0 0 0 0 0 0
e0 70: 254 0 0 0 0 0 0 0
e0 78: 0 0 0 0 0 0 0 255
~# showkey
kb mode was XLATE
press any key (program terminates 10s after last keypress)...
keycode 116 press
keycode 116 release
----------------------------------------------------------
The same thing happens with every key. I've tried every config option
that seems even remotely related to keyboards and nothing changes. It's
detected as:
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
It's a PS2 keyboard attached via PS2/AT adapter. The actual changes I'm
trying to make are the same ones I've been using through all of 2.4 and
2.5
--
Skip
On Tue, Oct 01, 2002 at 08:31:05AM -0400, Skip Ford wrote:
> Vojtech Pavlik wrote:
> > On Mon, Sep 30, 2002 at 10:40:10AM -0400, Skip Ford wrote:
> >
> > > I can no longer change keycodes since switching to the new input layer.
> > > Has anyone been able to?
> >
> > I've tested it and it should work. What exactly doesn't work for you?
> > What are you trying to do?
>
> I'm trying to assign keycodes using the kbd package. Multimedia keys
> and some regular keys. Here is one example. The key I'm pressing is
> e05e.
Ok, the problem is that because the ioctls are no longer i386-centric,
the layout of the tables has changed.
What used to be scancode e05e is now scancode 15e, basically all
scancodes beginning with e0 are now offset by just 100 hex.
getkeycodes/setkeycodes translates e05e to de, while the table needs 15e.
> ~# showkey
> kb mode was XLATE
>
> press any key (program terminates 10s after last keypress)...
> keycode 116 press
> keycode 116 release
>
> ~# getkeycodes
> Plain scancodes xx (hex) versus keycodes (dec)
> 0 is an error; for 1-88 (0x01-0x58) scancode equals keycode
>
> 0x58: 88 54 28 27 0 43 0 0
> 0x60: 85 86 90 91 92 93 14 94
> 0x68: 95 79 0 75 71 121 0 123
> 0x70: 82 83 80 76 77 72 1 69
> 0x78: 87 78 81 74 55 73 70 99
>
> Escaped scancodes e0 xx (hex)
>
> e0 00: 252 0 0 65 99 0 0 0
> e0 08: 0 0 0 0 0 0 0 0
> e0 10: 0 0 0 0 0 0 0 0
> e0 18: 0 0 0 0 0 0 0 0
> e0 20: 0 0 0 0 0 0 0 0
> e0 28: 0 0 251 0 0 0 0 0
> e0 30: 0 0 0 0 0 0 0 0
> e0 38: 0 0 0 0 0 0 0 0
> e0 40: 0 0 0 0 0 0 0 0
> e0 48: 0 0 0 0 0 0 0 0
> e0 50: 0 0 0 0 0 0 0 0
> e0 58: 0 0 0 0 0 0 0 0
> ^^^ <-- e05e
> e0 60: 252 253 0 0 0 0 0 0
> e0 68: 0 0 0 0 0 0 0 0
> e0 70: 254 0 0 0 0 0 0 0
> e0 78: 0 0 0 0 0 0 0 255
Ignore getkeycodes output, except for the 0x58-0x7f the output is not
correct anymore. (e000-e07f lines show entries for scancodes 0x80-0xff,
as they always did, though).
> ~# setkeycodes e05e 89
Use setkeycodes 15e 89
> ~# getkeycodes
> Plain scancodes xx (hex) versus keycodes (dec)
> 0 is an error; for 1-88 (0x01-0x58) scancode equals keycode
>
> 0x58: 88 54 28 27 0 43 0 0
> 0x60: 85 86 90 91 92 93 14 94
> 0x68: 95 79 0 75 71 121 0 123
> 0x70: 82 83 80 76 77 72 1 69
> 0x78: 87 78 81 74 55 73 70 99
>
> Escaped scancodes e0 xx (hex)
>
> e0 00: 252 0 0 65 99 0 0 0
> e0 08: 0 0 0 0 0 0 0 0
> e0 10: 0 0 0 0 0 0 0 0
> e0 18: 0 0 0 0 0 0 0 0
> e0 20: 0 0 0 0 0 0 0 0
> e0 28: 0 0 251 0 0 0 0 0
> e0 30: 0 0 0 0 0 0 0 0
> e0 38: 0 0 0 0 0 0 0 0
> e0 40: 0 0 0 0 0 0 0 0
> e0 48: 0 0 0 0 0 0 0 0
> e0 50: 0 0 0 0 0 0 0 0
> e0 58: 0 0 0 0 0 0 89 0
> ^^^^ <-- e05e
> e0 60: 252 253 0 0 0 0 0 0
> e0 68: 0 0 0 0 0 0 0 0
> e0 70: 254 0 0 0 0 0 0 0
> e0 78: 0 0 0 0 0 0 0 255
>
> ~# showkey
> kb mode was XLATE
>
> press any key (program terminates 10s after last keypress)...
> keycode 116 press
> keycode 116 release
>
> ----------------------------------------------------------
> The same thing happens with every key.
No, keycodes without e0 should be fine.
> I've tried every config option
> that seems even remotely related to keyboards and nothing changes. It's
> detected as:
>
> input: AT Set 2 keyboard on isa0060/serio0
> serio: i8042 KBD port at 0x60,0x64 irq 1
>
> It's a PS2 keyboard attached via PS2/AT adapter. The actual changes I'm
> trying to make are the same ones I've been using through all of 2.4 and
> 2.5
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlik wrote:
> On Tue, Oct 01, 2002 at 08:31:05AM -0400, Skip Ford wrote:
> > Vojtech Pavlik wrote:
> > > On Mon, Sep 30, 2002 at 10:40:10AM -0400, Skip Ford wrote:
> > >
> > > > I can no longer change keycodes since switching to the new input layer.
> > > > Has anyone been able to?
> > >
> > > I've tested it and it should work. What exactly doesn't work for you?
> > > What are you trying to do?
> >
> > I'm trying to assign keycodes using the kbd package. Multimedia keys
> > and some regular keys. Here is one example. The key I'm pressing is
> > e05e.
>
> Ok, the problem is that because the ioctls are no longer i386-centric,
> the layout of the tables has changed.
>
> What used to be scancode e05e is now scancode 15e, basically all
> scancodes beginning with e0 are now offset by just 100 hex.
>
> getkeycodes/setkeycodes translates e05e to de, while the table needs 15e.
>
> Ignore getkeycodes output, except for the 0x58-0x7f the output is not
> correct anymore. (e000-e07f lines show entries for scancodes 0x80-0xff,
> as they always did, though).
>
> > ~# setkeycodes e05e 89
>
> Use setkeycodes 15e 89
setkeycodes rejects it.
~# setkeycodes 15e 89
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 changed setkeycodes.c to add 256 instead of 128 and bumped up the
bounds checking, but it's still strange. It now works for e063, but
still doesn't work for e05e. Many other keys in the same area as 0x5e
don't work. The only one that does work that I tried is e063.
Will you be releasing an updated kbd package?
> > The same thing happens with every key.
>
> No, keycodes without e0 should be fine.
Turns out the "regular" keys I referred to really are extended keys.
--
Skip
On Tue, Oct 01, 2002 at 11:32:02AM -0400, Skip Ford wrote:
> Vojtech Pavlik wrote:
> > On Tue, Oct 01, 2002 at 08:31:05AM -0400, Skip Ford wrote:
> > > Vojtech Pavlik wrote:
> > > > On Mon, Sep 30, 2002 at 10:40:10AM -0400, Skip Ford wrote:
> > > >
> > > > > I can no longer change keycodes since switching to the new input layer.
> > > > > Has anyone been able to?
> > > >
> > > > I've tested it and it should work. What exactly doesn't work for you?
> > > > What are you trying to do?
> > >
> > > I'm trying to assign keycodes using the kbd package. Multimedia keys
> > > and some regular keys. Here is one example. The key I'm pressing is
> > > e05e.
> >
> > Ok, the problem is that because the ioctls are no longer i386-centric,
> > the layout of the tables has changed.
> >
> > What used to be scancode e05e is now scancode 15e, basically all
> > scancodes beginning with e0 are now offset by just 100 hex.
> >
> > getkeycodes/setkeycodes translates e05e to de, while the table needs 15e.
> >
> > Ignore getkeycodes output, except for the 0x58-0x7f the output is not
> > correct anymore. (e000-e07f lines show entries for scancodes 0x80-0xff,
> > as they always did, though).
> >
> > > ~# setkeycodes e05e 89
> >
> > Use setkeycodes 15e 89
>
> setkeycodes rejects it.
>
> ~# setkeycodes 15e 89
> 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 changed setkeycodes.c to add 256 instead of 128 and bumped up the
> bounds checking, but it's still strange. It now works for e063, but
> still doesn't work for e05e. Many other keys in the same area as 0x5e
> don't work. The only one that does work that I tried is e063.
There is another thing that has changed - the scancode numbers. So if
you're using the same commands as on 2.4, you're setting scancodes for
different keys. We now use 'at keyboard - set 2' scancodes as opposed to
'xt keyboard - set 1' used by the older driver. See the 'dmesg' output
for keys ("unknown scancode ...") that are not known to the keyboard
driver.
> Will you be releasing an updated kbd package?
Well, I'm not the maintainer of the kbd package, but I probably will
have to release a new tool to set the keycode table.
> > > The same thing happens with every key.
> >
> > No, keycodes without e0 should be fine.
>
> Turns out the "regular" keys I referred to really are extended keys.
>
> --
> Skip
--
Vojtech Pavlik
SuSE Labs
On Tue, Oct 01, 2002 at 05:54:28PM +0200, Andries Brouwer wrote:
> On Tue, Oct 01, 2002 at 05:41:29PM +0200, Vojtech Pavlik wrote:
>
> > > Will you be releasing an updated kbd package?
> >
> > Well, I'm not the maintainer of the kbd package, but I probably will
> > have to release a new tool to set the keycode table.
>
> If possible, make it as a patch of the old [gs]etkeycodes, and such
> that it recognizes the kernel version and does the right thing
> on both 2.4 and 2.6. This is a fairly obscure area, so the utility
> should be as self-documenting as possible.
Ok. Where is the most recent version of [gs]etkeycodes?
--
Vojtech Pavlik
SuSE Labs
On Tue, Oct 01, 2002 at 05:41:29PM +0200, Vojtech Pavlik wrote:
> > Will you be releasing an updated kbd package?
>
> Well, I'm not the maintainer of the kbd package, but I probably will
> have to release a new tool to set the keycode table.
If possible, make it as a patch of the old [gs]etkeycodes, and such
that it recognizes the kernel version and does the right thing
on both 2.4 and 2.6. This is a fairly obscure area, so the utility
should be as self-documenting as possible.
Andries
On Tue, Oct 01, 2002 at 05:55:37PM +0200, Vojtech Pavlik wrote:
> Ok. Where is the most recent version of [gs]etkeycodes?
In kbd-1.06. It is from May 2001, and I have been planning kbd-1.07
for a while but there were no urgent changes, just more fonts and
keymaps and the like. When you are done it is a good occasion for
kbd-1.07.
Andries
Begin3
Title: Keyboard and console utilities for Linux
Version: 1.06
Entered-date: 2001-05-19
Description: loadkeys dumpkeys setfont chvt openvt kbd.FAQ A20 etc.
Keywords: keyboard mapping console font unicode
Author: several
Maintained-by: Andries E. Brouwer ([email protected])
Primary-site: ftp://ftp.win.tue.nl/pub/linux-local/utils/kbd
773433 kbd-1.06.tar.gz
Alternate-site: ftp://ftp.*.kernel.org/pub/linux/utils/kbd
Alternate-site: ftp://sunsite.unc.edu/pub/Linux/system/keyboards
Alternate site: ftp://ftp.cwi.nl/pub/aeb/kbd
Copying-policy: GPL
End
Vojtech Pavlik wrote:
> On Tue, Oct 01, 2002 at 12:49:08PM -0400, Skip Ford wrote:
> >
> > The new AT driver
> > doesn't log any 'unknown scancode' messages for the same buttons the
> > old XT driver did.
>
> That means it understands them. If it did not, showkey -s wouldn't work.
>
> Just update the keymap - you don't need to change the scancode table if
> the keys are working.
How do I make use of these keycodes in a map file?
0 press
1 release
14 release
0 press
1 release
15 release
--
Skip
On Tue, Oct 01, 2002 at 12:49:08PM -0400, Skip Ford wrote:
> Vojtech Pavlik wrote:
> > On Tue, Oct 01, 2002 at 11:32:02AM -0400, Skip Ford wrote:
> > > Vojtech Pavlik wrote:
> > >
> > > setkeycodes rejects it.
> > >
> > > I changed setkeycodes.c to add 256 instead of 128 and bumped up the
> > > bounds checking, but it's still strange. It now works for e063, but
> > > still doesn't work for e05e. Many other keys in the same area as 0x5e
> > > don't work. The only one that does work that I tried is e063.
> >
> > There is another thing that has changed - the scancode numbers. So if
> > you're using the same commands as on 2.4, you're setting scancodes for
> > different keys. We now use 'at keyboard - set 2' scancodes as opposed to
> > 'xt keyboard - set 1' used by the older driver. See the 'dmesg' output
> > for keys ("unknown scancode ...") that are not known to the keyboard
> > driver.
>
> showkey is still showing me the same scancodes.
The raw mode showkey -s is now using to show scancodes is completely
simulated by the kernel.
> The new AT driver
> doesn't log any 'unknown scancode' messages for the same buttons the
> old XT driver did.
That means it understands them. If it did not, showkey -s wouldn't work.
> > > Will you be releasing an updated kbd package?
> >
> > Well, I'm not the maintainer of the kbd package, but I probably will
> > have to release a new tool to set the keycode table.
>
> Sorry about that. Didn't mean to volunteer you. Thanks for all your
> help. I'll try to verify the scancodes I'm using.
Just update the keymap - you don't need to change the scancode table if
the keys are working.
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlik wrote:
> On Tue, Oct 01, 2002 at 01:41:27PM -0400, Skip Ford wrote:
> > Vojtech Pavlik wrote:
> > > On Tue, Oct 01, 2002 at 12:49:08PM -0400, Skip Ford wrote:
> > > >
> > > > The new AT driver
> > > > doesn't log any 'unknown scancode' messages for the same buttons the
> > > > old XT driver did.
> > >
> > > That means it understands them. If it did not, showkey -s wouldn't work.
> > >
> > > Just update the keymap - you don't need to change the scancode table if
> > > the keys are working.
> >
> > How do I make use of these keycodes in a map file?
> >
> > 0 press
> > 1 release
> > 14 release
> >
> > 0 press
> > 1 release
> > 15 release
>
> 0,1,14 is keycode 142 (Sleep) and 0,1,15 is keycode 143 (WakeUp),
> encoded because medium raw mode cannot handle keycodes above 128. If
> loadkeys doesn't allow keycodes 142 and 143, well, I'll have to fix it.
You'll have to fix it. I tried those before I asked. Actually I tried
141 and 142 but I was close. loadkeys rejects anything >= NR_KEYS (128)
All of my keys are recognized so I don't need any setkeycodes
functionality at all. I can probably get loadkeys to load my map so I
should be ok now. I was making things a lot harder than they had to be.
--
Skip
Vojtech Pavlik wrote:
> On Tue, Oct 01, 2002 at 11:32:02AM -0400, Skip Ford wrote:
> > Vojtech Pavlik wrote:
> >
> > setkeycodes rejects it.
> >
> > I changed setkeycodes.c to add 256 instead of 128 and bumped up the
> > bounds checking, but it's still strange. It now works for e063, but
> > still doesn't work for e05e. Many other keys in the same area as 0x5e
> > don't work. The only one that does work that I tried is e063.
>
> There is another thing that has changed - the scancode numbers. So if
> you're using the same commands as on 2.4, you're setting scancodes for
> different keys. We now use 'at keyboard - set 2' scancodes as opposed to
> 'xt keyboard - set 1' used by the older driver. See the 'dmesg' output
> for keys ("unknown scancode ...") that are not known to the keyboard
> driver.
showkey is still showing me the same scancodes. The new AT driver
doesn't log any 'unknown scancode' messages for the same buttons the
old XT driver did.
> > Will you be releasing an updated kbd package?
>
> Well, I'm not the maintainer of the kbd package, but I probably will
> have to release a new tool to set the keycode table.
Sorry about that. Didn't mean to volunteer you. Thanks for all your
help. I'll try to verify the scancodes I'm using.
--
Skip
On Tue, Oct 01, 2002 at 01:41:27PM -0400, Skip Ford wrote:
> Vojtech Pavlik wrote:
> > On Tue, Oct 01, 2002 at 12:49:08PM -0400, Skip Ford wrote:
> > >
> > > The new AT driver
> > > doesn't log any 'unknown scancode' messages for the same buttons the
> > > old XT driver did.
> >
> > That means it understands them. If it did not, showkey -s wouldn't work.
> >
> > Just update the keymap - you don't need to change the scancode table if
> > the keys are working.
>
> How do I make use of these keycodes in a map file?
>
> 0 press
> 1 release
> 14 release
>
> 0 press
> 1 release
> 15 release
0,1,14 is keycode 142 (Sleep) and 0,1,15 is keycode 143 (WakeUp),
encoded because medium raw mode cannot handle keycodes above 128. If
loadkeys doesn't allow keycodes 142 and 143, well, I'll have to fix it.
--
Vojtech Pavlik
SuSE Labs
On Tue, Oct 01, 2002 at 02:11:53PM -0400, Skip Ford wrote:
> Vojtech Pavlik wrote:
> > On Tue, Oct 01, 2002 at 01:41:27PM -0400, Skip Ford wrote:
> > > Vojtech Pavlik wrote:
> > > > On Tue, Oct 01, 2002 at 12:49:08PM -0400, Skip Ford wrote:
> > > > >
> > > > > The new AT driver
> > > > > doesn't log any 'unknown scancode' messages for the same buttons the
> > > > > old XT driver did.
> > > >
> > > > That means it understands them. If it did not, showkey -s wouldn't work.
> > > >
> > > > Just update the keymap - you don't need to change the scancode table if
> > > > the keys are working.
> > >
> > > How do I make use of these keycodes in a map file?
> > >
> > > 0 press
> > > 1 release
> > > 14 release
> > >
> > > 0 press
> > > 1 release
> > > 15 release
> >
> > 0,1,14 is keycode 142 (Sleep) and 0,1,15 is keycode 143 (WakeUp),
> > encoded because medium raw mode cannot handle keycodes above 128. If
> > loadkeys doesn't allow keycodes 142 and 143, well, I'll have to fix it.
>
> You'll have to fix it. I tried those before I asked. Actually I tried
> 141 and 142 but I was close. loadkeys rejects anything >= NR_KEYS (128)
>
> All of my keys are recognized so I don't need any setkeycodes
> functionality at all. I can probably get loadkeys to load my map so I
> should be ok now. I was making things a lot harder than they had to be.
Well, if you get loadkeys to load the high keycodes, then indeed
everything is fine.
Ok, another utility to release an update for. Thanks for your
cooperation.
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlik wrote:
>
> Well, if you get loadkeys to load the high keycodes, then indeed
> everything is fine.
Disregard my other email. I can get it to work if I redefine NR_KEYS in
keyboard.h then rebuild the kernel and loadkeys using the new value.
My map with extended keycodes loads and all the multimedia keys work
without using setkeycodes. Have I done something horrible by upping
NR_KEYS?
--
Skip
On Tue, Oct 01, 2002 at 04:04:27PM -0400, Skip Ford wrote:
> Vojtech Pavlik wrote:
> >
> > Well, if you get loadkeys to load the high keycodes, then indeed
> > everything is fine.
>
> Disregard my other email. I can get it to work if I redefine NR_KEYS in
> keyboard.h then rebuild the kernel and loadkeys using the new value.
>
> My map with extended keycodes loads and all the multimedia keys work
> without using setkeycodes. Have I done something horrible by upping
> NR_KEYS?
I don't think so it should be fine - actually NR_KEYS should be the same
as KEY_MAX in input.h probably.
--
Vojtech Pavlik
SuSE Labs
On Tue, Oct 01, 2002 at 06:29:55PM +0200, Andries Brouwer wrote:
> On Tue, Oct 01, 2002 at 05:55:37PM +0200, Vojtech Pavlik wrote:
>
> > Ok. Where is the most recent version of [gs]etkeycodes?
>
> In kbd-1.06. It is from May 2001, and I have been planning kbd-1.07
> for a while but there were no urgent changes, just more fonts and
> keymaps and the like. When you are done it is a good occasion for
> kbd-1.07.
>
> Andries
>
> Begin3
> Title: Keyboard and console utilities for Linux
> Version: 1.06
> Entered-date: 2001-05-19
> Description: loadkeys dumpkeys setfont chvt openvt kbd.FAQ A20 etc.
> Keywords: keyboard mapping console font unicode
> Author: several
> Maintained-by: Andries E. Brouwer ([email protected])
> Primary-site: ftp://ftp.win.tue.nl/pub/linux-local/utils/kbd
> 773433 kbd-1.06.tar.gz
> Alternate-site: ftp://ftp.*.kernel.org/pub/linux/utils/kbd
> Alternate-site: ftp://sunsite.unc.edu/pub/Linux/system/keyboards
> Alternate site: ftp://ftp.cwi.nl/pub/aeb/kbd
> Copying-policy: GPL
> End
Ok, here is a patch that should make it work correctly on all existing
kernels.
You may want to check that loadkeys supports keycodes over 127 (and for
future, over 255), too. I updated only getkeycodes/setkeycodes.
diff -urN kbd-1.06/src/getkeycodes.c kbd-1.06-new/src/getkeycodes.c
--- kbd-1.06/src/getkeycodes.c Fri Oct 8 21:45:54 1999
+++ kbd-1.06-new/src/getkeycodes.c Mon Oct 7 12:38:47 2002
@@ -21,8 +21,9 @@
int
main(int argc, char **argv) {
- int fd, sc;
+ int fd, sc = 0;
struct kbkeycode a;
+ int old_kernel = 0;
set_progname(argv[0]);
@@ -36,30 +37,47 @@
if (argc != 1)
usage();
fd = getfd();
+
+ a.scancode = 0; /* Old kernels don't support */
+ a.keycode = 0; /* scancodes below SC_LIM. */
+ if (ioctl(fd,KDGETKEYCODE,&a))
+ old_kernel = 1;
+
printf(_("Plain scancodes xx (hex) versus keycodes (dec)\n"));
- printf(_("0 is an error; for 1-88 (0x01-0x58) scancode equals keycode\n"));
- for(sc=88; sc<256; sc++) {
- if (sc == 128)
- printf(_("\n\nEscaped scancodes e0 xx (hex)\n"));
+ if (old_kernel) {
+ printf(_("0 is an error; for 1-88 (0x01-0x58) scancode equals keycode\n"));
+ sc = 0x89;
+ }
+
+ while (1) {
+ if (old_kernel) {
+ if (sc == 128)
+ printf(_("\n\nEscaped scancodes e0 xx (hex)\n"));
+ if (sc == 256) {
+ printf("\n");
+ return 0;
+ }
+ }
if (sc % 8 == 0) {
- if (sc < 128)
- printf("\n 0x%02x: ", sc);
- else
- printf("\ne0 %02x: ", sc-128);
- }
-
- if (sc <= 88) {
- printf(" %3d", sc);
- continue;
+ if (old_kernel) {
+ if (sc < 128)
+ printf("\n 0x%02x: ", sc);
+ else
+ printf("\ne0 %02x: ", sc-128);
+ } else
+ printf("\n 0x%04x: ", sc);
}
-
a.scancode = sc;
a.keycode = 0;
if (ioctl(fd,KDGETKEYCODE,&a)) {
- if (errno == EINVAL)
+ if (errno == EINVAL) {
+ if (!old_kernel) {
+ printf("\n");
+ return 0;
+ }
printf(" -");
- else {
+ } else {
perror("KDGETKEYCODE");
fprintf(stderr, _("failed to get keycode for scancode 0x%x\n"),
sc);
@@ -67,6 +85,8 @@
}
} else
printf(" %3d", a.keycode);
+
+ sc++;
}
printf("\n");
return 0;
diff -urN kbd-1.06/src/setkeycodes.c kbd-1.06-new/src/setkeycodes.c
--- kbd-1.06/src/setkeycodes.c Fri Oct 8 21:42:02 1999
+++ kbd-1.06-new/src/setkeycodes.c Mon Oct 7 12:40:08 2002
@@ -27,7 +27,7 @@
int
main(int argc, char **argv) {
char *ep;
- int fd, sc;
+ int fd, sc, old_kernel = 0;
struct kbkeycode a;
set_progname(argv[0]);
@@ -43,17 +43,20 @@
usage(_("even number of arguments expected"));
fd = getfd();
+ a.scancode = 0; /* Old kernels don't support */
+ a.keycode = 0; /* scancodes below SC_LIM. */
+ if (ioctl(fd,KDGETKEYCODE,&a))
+ old_kernel = 1;
+
while (argc > 2) {
a.keycode = atoi(argv[2]);
a.scancode = sc = strtol(argv[1], &ep, 16);
if (*ep)
usage(_("error reading scancode"));
- if (a.scancode > 127) {
+ if ((a.scancode & ~0xff) == 0xe000) {
a.scancode -= 0xe000;
- a.scancode += 128;
+ a.scancode += old_kernel ? 128 : 256;
}
- if (a.scancode > 255 || a.keycode > 127)
- usage(_("code outside bounds"));
if (ioctl(fd,KDSETKEYCODE,&a)) {
perror("KDSETKEYCODE");
fprintf(stderr, _("failed to set scancode %x to keycode %d\n"),
--
Vojtech Pavlik
SuSE Labs
On Mon, Oct 07, 2002 at 02:06:03PM +0200, Vojtech Pavlik wrote:
> Ok, here is a patch that should make it work correctly on all existing
> kernels.
Thanks!
Andries
Vojtech Pavlik wrote:
> On Tue, Oct 01, 2002 at 06:29:55PM +0200, Andries Brouwer wrote:
> >
> > In kbd-1.06. It is from May 2001, and I have been planning kbd-1.07
> > for a while but there were no urgent changes, just more fonts and
> > keymaps and the like. When you are done it is a good occasion for
> > kbd-1.07.
>
> Ok, here is a patch that should make it work correctly on all existing
> kernels.
>
> You may want to check that loadkeys supports keycodes over 127 (and for
> future, over 255), too. I updated only getkeycodes/setkeycodes.
loadkeys and the kernel itself both reject attempts to set keycodes with
a value >= NR_KEYS (128).
In kbd-1.06/src/loadkeys.y::addkey()
if (index < 0 || index >= NR_KEYS)
lkfatal0(_("addkey called with bad index %d"), index);
And inside linux/drivers/char/vt_ioctl.c::do_kdsk_ioctl()
if (i >= NR_KEYS || s >= MAX_NR_KEYMAPS)
return -EINVAL;
I had to change each of those to KEY_MAX. Both files use NR_KEYS in
other places so I don't what the correct fix is. I guess NR_KEYS is
still correct for some keyboards?
--
Skip
On Mon, Oct 07, 2002 at 09:23:26AM -0400, Skip Ford wrote:
> Vojtech Pavlik wrote:
> > On Tue, Oct 01, 2002 at 06:29:55PM +0200, Andries Brouwer wrote:
> > >
> > > In kbd-1.06. It is from May 2001, and I have been planning kbd-1.07
> > > for a while but there were no urgent changes, just more fonts and
> > > keymaps and the like. When you are done it is a good occasion for
> > > kbd-1.07.
> >
> > Ok, here is a patch that should make it work correctly on all existing
> > kernels.
> >
> > You may want to check that loadkeys supports keycodes over 127 (and for
> > future, over 255), too. I updated only getkeycodes/setkeycodes.
>
> loadkeys and the kernel itself both reject attempts to set keycodes with
> a value >= NR_KEYS (128).
>
> In kbd-1.06/src/loadkeys.y::addkey()
>
> if (index < 0 || index >= NR_KEYS)
> lkfatal0(_("addkey called with bad index %d"), index);
>
> And inside linux/drivers/char/vt_ioctl.c::do_kdsk_ioctl()
>
> if (i >= NR_KEYS || s >= MAX_NR_KEYMAPS)
> return -EINVAL;
>
> I had to change each of those to KEY_MAX. Both files use NR_KEYS in
> other places so I don't what the correct fix is. I guess NR_KEYS is
> still correct for some keyboards?
Ok, I fixed it now in the kernel [#define NR_KEYS (KEY_MAX+1)].
I think the loadkeys source probably shouldn't check for the limit (as
that can change between kernels), and instead rely on the kernel
rejecting invalid values.
--
Vojtech Pavlik
SuSE Labs