* KDSETKEYCODE work with new input layer? @ 2002-09-30 14:40 Skip Ford 2002-10-01 9:54 ` Vojtech Pavlik 0 siblings, 1 reply; 21+ messages in thread From: Skip Ford @ 2002-09-30 14:40 UTC (permalink / raw) To: linux-kernel I can no longer change keycodes since switching to the new input layer. Has anyone been able to? -- Skip ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-09-30 14:40 KDSETKEYCODE work with new input layer? Skip Ford @ 2002-10-01 9:54 ` Vojtech Pavlik 2002-10-01 12:31 ` Skip Ford 0 siblings, 1 reply; 21+ messages in thread From: Vojtech Pavlik @ 2002-10-01 9:54 UTC (permalink / raw) To: Skip Ford; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 9:54 ` Vojtech Pavlik @ 2002-10-01 12:31 ` Skip Ford 2002-10-01 13:17 ` Vojtech Pavlik 0 siblings, 1 reply; 21+ messages in thread From: Skip Ford @ 2002-10-01 12:31 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 12:31 ` Skip Ford @ 2002-10-01 13:17 ` Vojtech Pavlik 2002-10-01 15:32 ` Skip Ford 0 siblings, 1 reply; 21+ messages in thread From: Vojtech Pavlik @ 2002-10-01 13:17 UTC (permalink / raw) To: Skip Ford; +Cc: Vojtech Pavlik, linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 13:17 ` Vojtech Pavlik @ 2002-10-01 15:32 ` Skip Ford 2002-10-01 15:41 ` Vojtech Pavlik 0 siblings, 1 reply; 21+ messages in thread From: Skip Ford @ 2002-10-01 15:32 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 15:32 ` Skip Ford @ 2002-10-01 15:41 ` Vojtech Pavlik 2002-10-01 15:54 ` Andries Brouwer 2002-10-01 16:49 ` Skip Ford 0 siblings, 2 replies; 21+ messages in thread From: Vojtech Pavlik @ 2002-10-01 15:41 UTC (permalink / raw) To: Skip Ford; +Cc: Vojtech Pavlik, linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 15:41 ` Vojtech Pavlik @ 2002-10-01 15:54 ` Andries Brouwer 2002-10-01 15:55 ` Vojtech Pavlik 2002-10-01 16:49 ` Skip Ford 1 sibling, 1 reply; 21+ messages in thread From: Andries Brouwer @ 2002-10-01 15:54 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: Skip Ford, linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 15:54 ` Andries Brouwer @ 2002-10-01 15:55 ` Vojtech Pavlik 2002-10-01 16:29 ` Andries Brouwer 0 siblings, 1 reply; 21+ messages in thread From: Vojtech Pavlik @ 2002-10-01 15:55 UTC (permalink / raw) To: Andries Brouwer; +Cc: Vojtech Pavlik, Skip Ford, linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 15:55 ` Vojtech Pavlik @ 2002-10-01 16:29 ` Andries Brouwer 2002-10-07 12:06 ` Vojtech Pavlik 0 siblings, 1 reply; 21+ messages in thread From: Andries Brouwer @ 2002-10-01 16:29 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: Skip Ford, linux-kernel 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 (aeb@cwi.nl) 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 16:29 ` Andries Brouwer @ 2002-10-07 12:06 ` Vojtech Pavlik 2002-10-07 12:52 ` Andries Brouwer 2002-10-07 13:23 ` Skip Ford 0 siblings, 2 replies; 21+ messages in thread From: Vojtech Pavlik @ 2002-10-07 12:06 UTC (permalink / raw) To: Andries Brouwer; +Cc: Vojtech Pavlik, Skip Ford, linux-kernel 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 (aeb@cwi.nl) > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-07 12:06 ` Vojtech Pavlik @ 2002-10-07 12:52 ` Andries Brouwer 2002-10-07 13:23 ` Skip Ford 1 sibling, 0 replies; 21+ messages in thread From: Andries Brouwer @ 2002-10-07 12:52 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: Skip Ford, linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-07 12:06 ` Vojtech Pavlik 2002-10-07 12:52 ` Andries Brouwer @ 2002-10-07 13:23 ` Skip Ford 2002-10-07 13:39 ` Vojtech Pavlik 1 sibling, 1 reply; 21+ messages in thread From: Skip Ford @ 2002-10-07 13:23 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: Andries Brouwer, linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-07 13:23 ` Skip Ford @ 2002-10-07 13:39 ` Vojtech Pavlik 0 siblings, 0 replies; 21+ messages in thread From: Vojtech Pavlik @ 2002-10-07 13:39 UTC (permalink / raw) To: Skip Ford; +Cc: Vojtech Pavlik, Andries Brouwer, linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 15:41 ` Vojtech Pavlik 2002-10-01 15:54 ` Andries Brouwer @ 2002-10-01 16:49 ` Skip Ford 2002-10-01 16:51 ` Vojtech Pavlik 1 sibling, 1 reply; 21+ messages in thread From: Skip Ford @ 2002-10-01 16:49 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 16:49 ` Skip Ford @ 2002-10-01 16:51 ` Vojtech Pavlik 2002-10-01 17:41 ` Skip Ford 0 siblings, 1 reply; 21+ messages in thread From: Vojtech Pavlik @ 2002-10-01 16:51 UTC (permalink / raw) To: Skip Ford; +Cc: Vojtech Pavlik, linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 16:51 ` Vojtech Pavlik @ 2002-10-01 17:41 ` Skip Ford 2002-10-01 17:39 ` Vojtech Pavlik 0 siblings, 1 reply; 21+ messages in thread From: Skip Ford @ 2002-10-01 17:41 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 17:41 ` Skip Ford @ 2002-10-01 17:39 ` Vojtech Pavlik 2002-10-01 18:11 ` Skip Ford 0 siblings, 1 reply; 21+ messages in thread From: Vojtech Pavlik @ 2002-10-01 17:39 UTC (permalink / raw) To: Skip Ford; +Cc: Vojtech Pavlik, linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 17:39 ` Vojtech Pavlik @ 2002-10-01 18:11 ` Skip Ford 2002-10-01 18:38 ` Vojtech Pavlik 0 siblings, 1 reply; 21+ messages in thread From: Skip Ford @ 2002-10-01 18:11 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 18:11 ` Skip Ford @ 2002-10-01 18:38 ` Vojtech Pavlik 2002-10-01 20:04 ` Skip Ford 0 siblings, 1 reply; 21+ messages in thread From: Vojtech Pavlik @ 2002-10-01 18:38 UTC (permalink / raw) To: Skip Ford; +Cc: Vojtech Pavlik, linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 18:38 ` Vojtech Pavlik @ 2002-10-01 20:04 ` Skip Ford 2002-10-01 20:53 ` Vojtech Pavlik 0 siblings, 1 reply; 21+ messages in thread From: Skip Ford @ 2002-10-01 20:04 UTC (permalink / raw) To: Vojtech Pavlik; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KDSETKEYCODE work with new input layer? 2002-10-01 20:04 ` Skip Ford @ 2002-10-01 20:53 ` Vojtech Pavlik 0 siblings, 0 replies; 21+ messages in thread From: Vojtech Pavlik @ 2002-10-01 20:53 UTC (permalink / raw) To: Skip Ford; +Cc: Vojtech Pavlik, linux-kernel 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2002-10-07 13:33 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-09-30 14:40 KDSETKEYCODE work with new input layer? Skip Ford 2002-10-01 9:54 ` Vojtech Pavlik 2002-10-01 12:31 ` Skip Ford 2002-10-01 13:17 ` Vojtech Pavlik 2002-10-01 15:32 ` Skip Ford 2002-10-01 15:41 ` Vojtech Pavlik 2002-10-01 15:54 ` Andries Brouwer 2002-10-01 15:55 ` Vojtech Pavlik 2002-10-01 16:29 ` Andries Brouwer 2002-10-07 12:06 ` Vojtech Pavlik 2002-10-07 12:52 ` Andries Brouwer 2002-10-07 13:23 ` Skip Ford 2002-10-07 13:39 ` Vojtech Pavlik 2002-10-01 16:49 ` Skip Ford 2002-10-01 16:51 ` Vojtech Pavlik 2002-10-01 17:41 ` Skip Ford 2002-10-01 17:39 ` Vojtech Pavlik 2002-10-01 18:11 ` Skip Ford 2002-10-01 18:38 ` Vojtech Pavlik 2002-10-01 20:04 ` Skip Ford 2002-10-01 20:53 ` Vojtech Pavlik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).