Unisys pc keyboard new keys patch, kernel 2.4.3
PATCH 1/1 Unisys pc keyboard new keys patch, kernel 2.4.3
Hi,
i recently met with a new (Unisys) keyboard, which have (among 'normal' windows keys) 3 more keys on top of arrows, labeled by pictures as halfsun, halfmoon, and power switch. Following patch adds 'support' for them (or at least gets rid of 'unknown scancode' messages), but beacuse i am new to kernl programming, i don't know if it is the right approach. If it'll be OK, it should apply to drivers/char/q40_keyb.c, drivers/sbus/char/sunkbd.c and drivers/sbus/char/pcikbd.c as well. I found no maintainer of charaacter devices/keyboards/input, so i am posting here.
Jan Dvorak <[email protected]>
drivers/char/pc_keyb.c renamed from drivers/char/pc_keyb.c.orig +11 -2
@@ -224,6 +224,15 @@#define E0_MSRW 126#define E0_MSTM 127 +/* +* Another new microsoft (Unikey) keyboard seems to have just another +* three keys: e0 63 (half- or rising- sun), e0 5f (halfmoon) +* and e0 5e (power button?) +*/ +#define E0_MSPOWER 128 +#define E0_MSHALFMOON 129 +#define E0_MSHALFSUN 130 +static unsigned char e0_keys[128 ] = {0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,/* 0x00-0x07 */ 0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,/* 0x08-0x0f */
@@ -236,8 +245,8 @@E0_DO ,E0_F17 ,0 ,0 ,0 ,0 ,E0_BREAK ,E0_HOME ,/* 0x40-0x47 */ E0_UP ,E0_PGUP ,0 ,E0_LEFT ,E0_OK ,E0_RIGHT ,E0_KPMINPLUS ,E0_END ,/* 0x48-0x4f */ E0_DOWN ,E0_PGDN ,E0_INS ,E0_DEL ,0 ,0 ,0 ,0 ,/* 0x50-0x57 */ -0 ,0 ,0 ,E0_MSLW ,E0_MSRW ,E0_MSTM ,0 ,0 ,/* 0x58-0x5f */ -0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,/* 0x60-0x67 */ +0 ,0 ,0 ,E0_MSLW ,E0_MSRW ,E0_MSTM ,E0_MSPOWER ,E0_MSHALFMOON ,/* 0x58-0x5f */ +0 ,0 ,0 ,E0_MSHALFSUN ,0 ,0 ,0 ,0 ,/* 0x60-0x67 */ 0 ,0 ,0 ,0 ,0 ,0 ,0 ,E0_MACRO ,/* 0x68-0x6f */ 0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 ,/* 0x70-0x77 */ 0 ,0 ,0 ,0 ,0 ,0 ,0 ,0 /* 0x78-0x7f */
drivers/char/pc_keyb.c line 234
Quoted 7 lines · Jan Dvorak
i recently met with a new (Unisys) keyboard, which have (among 'normal' windows keys) 3 more keys on top of arrows, labeled by pictures as halfsun, halfmoon, and power switch. Following patch adds 'support' for them
drivers/char/pc_keyb.c renamed from drivers/char/pc_keyb.c.orig +3
-0+#define E0_MSPOWER 128 +#define E0_MSHALFMOON 129 +#define E0_MSHALFSUN 130
No, these codes cannot be larger than 127 today.
You can use the utility setkeycodes to assign keycodes to these keys.
[One of the things for 2.5 is 15- or 31-bit keycodes.
The 7-bits we have today do no longer suffice. I have a 132-key keyboard.]
Andries
In article <[email protected]> of
linux.dev.kernel, you write:
Quoted 13 lines · Jan Dvorak
drivers/char/pc_keyb.c line 234
Quoted 8 lines
i recently met with a new (Unisys) keyboard, which have (among 'normal' windows keys) 3 more keys on top of arrows, labeled by pictures as halfsun, halfmoon, and power switch. Following patch adds 'support' for them
drivers/char/pc_keyb.c renamed from drivers/char/pc_keyb.c.orig +3
-0+#define E0_MSPOWER 128 +#define E0_MSHALFMOON 129 +#define E0_MSHALFSUN 130No, these codes cannot be larger than 127 today.
You can use the utility setkeycodes to assign keycodes to these keys.
Quoted 3 lines
[One of the things for 2.5 is 15- or 31-bit keycodes.
The 7-bits we have today do no longer suffice. I have a 132-key keyboard.]
By the way, it's for things like this that I suggested using a keycode which can be algorithmically mapped from scan codes once we go to a larger keycode space. For example, if your key generates E0 63, it would *always* have keycode 0x00E3 (227). For PC keyboards, I believe the following mapping algorithm should work onto a 15-bit keycode space (all numbers in hex):
xx -> 00xx E0 xx -> 00xx | 0080 E1 xx yy -> yyxx
(I can't remember which one of the E1 bytes that has the make/break bit, it should obviously go at the top.)
This assumes that there isn't a null byte form of E1, in which case it really can't be made to fit, but I don't think so.
This means you don't have to configure two levels (scancodes -> keycodes and keycodes -> keymap); since currently the keycodes are keyboard-specific anyway there is no benefit to the two levels.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt
Quoted 3 lines · H. Peter Anvin
This means you don't have to configure two levels (scancodes -> keycodes and keycodes -> keymap); since currently the keycodes are keyboard-specific anyway there is no benefit to the two levels.
The medium-raw level ought to be what the X11R6 protocol uses. Then the keyboard-specific stuff can be removed from XFree86, and there would be one less mapping to configure.
Quoted 11 lines · Albert D. Cahalan
Quoted 3 lines · H. Peter Anvin
This means you don't have to configure two levels (scancodes -> keycodes and keycodes -> keymap); since currently the keycodes are keyboard-specific anyway there is no benefit to the two levels.
The medium-raw level ought to be what the X11R6 protocol uses. Then the keyboard-specific stuff can be removed from XFree86, and there would be one less mapping to configure.
Uhm, doesn't work that way.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt
Quoted 2 lines · Guest section DW
No, these codes cannot be larger than 127 today.
You can use the utility setkeycodes to assign keycodes to these keys.
I always tought it is 8bit - more-than-128-keys keyboards exists quite long time.
Quoted 2 lines
[One of the things for 2.5 is 15- or 31-bit keycodes.
The 7-bits we have today do no longer suffice. I have a 132-key keyboard.]
Yes, this is necessary then. Hmm, the move to 15bits looks simple, any ideas why this wasn't implemented before ? Yes, this isn't priority, because it is working fine with setkeycodes, but anyway ...
Jan Dvorak <[email protected]>
Followup to: <[email protected]> By author: Jan Dvorak <[email protected]> In newsgroup: linux.dev.kernel
Quoted 7 lines · Guest section DW
Quoted 2 lines
No, these codes cannot be larger than 127 today.
You can use the utility setkeycodes to assign keycodes to these keys.I always tought it is 8bit - more-than-128-keys keyboards exists quite long time.
No, the top bit is make/break.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt
Quoted 18 lines · H. Peter Anvin
In article <[email protected]> of
linux.dev.kernel, you write:Quoted 16 lines · Jan Dvorak
drivers/char/pc_keyb.c line 234
Quoted 9 lines
i recently met with a new (Unisys) keyboard, which have (among 'normal' windows keys) 3 more keys on top of arrows, labeled by pictures as halfsun, halfmoon, and power switch. Following patch adds 'support' for them
drivers/char/pc_keyb.c renamed from drivers/char/pc_keyb.c.orig +3
-0+#define E0_MSPOWER 128 +#define E0_MSHALFMOON 129 +#define E0_MSHALFSUN 130No, these codes cannot be larger than 127 today.
You can use the utility setkeycodes to assign keycodes to these keys.[One of the things for 2.5 is 15- or 31-bit keycodes.
The 7-bits we have today do no longer suffice. I have a 132-key keyboard.]
If we can try to keycodes in 8-bits it would be nice. The difficulty is that X cannot handle more than 8-bits without telling it you have multiple keyboards. The keycode (at least in X) is exported to X applications. This is certainly something to coordinate with the XFree folks about. If you really need more then 8-bits.
Quoted 14 lines
By the way, it's for things like this that I suggested using a keycode which can be algorithmically mapped from scan codes once we go to a larger keycode space. For example, if your key generates E0 63, it would *always* have keycode
0x00E3(227). For PC keyboards, I believe the following mapping algorithm should work onto a 15-bit keycode space (all numbers in hex):xx -> 00xx E0 xx -> 00xx | 0080 E1 xx yy -> yyxx(I can't remember which one of the E1 bytes that has the make/break bit, it should obviously go at the top.)
Quoted 6 lines
This assumes that there isn't a null byte form of E1, in which case it really can't be made to fit, but I don't think so.
This means you don't have to configure two levels (scancodes -> keycodes and keycodes -> keymap); since currently the keycodes are keyboard-specific anyway there is no benefit to the two levels.
Hmm. I'd love to see how a mapping that takes everything into account works. In a classic pc compatible keyboard E1 is only used for the Pause key. And you need to special case Print-Screen/SysRq Pause/Break, anyway to collapse then into one keycode to really get
your keycodes correct. So I'm not certain that after special case
the two totally hosed keys if you need to handle more than the E0 prefix in which case you really only need one more bit.
Eric
Quoted 5 lines · Eric W. Biederman
If we can try to keycodes in 8-bits it would be nice. The difficulty is that X cannot handle more than 8-bits without telling it you have multiple keyboards. The keycode (at least in X) is exported to X applications. This is certainly something to coordinate with the XFree folks about. If you really need more then 8-bits.
X keycodes are unrelated to Linux keycodes.
Quoted 9 lines · Guest section DW
Quoted 5 lines · Eric W. Biederman
If we can try to keycodes in 8-bits it would be nice. The difficulty is that X cannot handle more than 8-bits without telling it you have multiple keyboards. The keycode (at least in X) is exported to X applications. This is certainly something to coordinate with the XFree folks about. If you really need more then 8-bits.
X keycodes are unrelated to Linux keycodes.
Yes, but they could be. Changing the Linux keycodes is a major break with compatibility. If the Linux keycodes are to be changed, then they ought to be become something that would allow XFree86 to become keyboard-independent. Why invent yet another encoding?
Quoted 4 lines
Yes, but they could be. Changing the Linux keycodes is a major break with compatibility. If the Linux keycodes are to be changed, then they ought to be become something that would allow XFree86 to become keyboard-independent. Why invent yet another encoding?
You dont need to break compatibility. We have cooked, raw, semi-raw type modes for keyboard right now. We just need to add semi-raw-extended and raw-extended
Quoted 7 lines · Alan Cox
Quoted 4 lines
Yes, but they could be. Changing the Linux keycodes is a major break with compatibility. If the Linux keycodes are to be changed, then they ought to be become something that would allow XFree86 to become keyboard-independent. Why invent yet another encoding?
You dont need to break compatibility. We have cooked, raw, semi-raw type modes for keyboard right now. We just need to add semi-raw-extended and raw-extended
Of course don't have raw via terminal escape string, which can be a royal pain on a remote machine, if you know how to use the raw keycodes.
Eric