[PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Jan Dvorak]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

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 <johnydog@go.cz>


[-- Attachment #2: unikey.patch --]
[-- Type: text/plain, Size: 1245 bytes --]

--- linux/drivers/char/pc_keyb.c.orig	Mon Apr  9 13:58:31 2001
+++ linux/drivers/char/pc_keyb.c	Fri Apr 13 13:34:05 2001
@@ -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 */

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Guest section DW]

On Fri, Apr 13, 2001 at 03:02:19PM +0200, Jan Dvorak wrote:

> 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

> +#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

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[H. Peter Anvin]

In article <20010414002120.A15596@win.tue.nl> of
linux.dev.kernel, you write:
> On Fri, Apr 13, 2001 at 03:02:19PM +0200, Jan Dvorak wrote:
> 
> > 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
> 
> > +#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.]
> 

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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Eric W. Biederman]

"H. Peter Anvin" <hpa@zytor.com> writes:

> In article <20010414002120.A15596@win.tue.nl> of
> linux.dev.kernel, you write:
> > On Fri, Apr 13, 2001 at 03:02:19PM +0200, Jan Dvorak wrote:
> > 
> > > 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
> 
> > 
> > > +#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.]

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. 

> 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.

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

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Guest section DW]

On Mon, Apr 16, 2001 at 12:29:11AM -0600, Eric W. Biederman wrote:

> 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.

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Albert D. Cahalan]

Guest section DW writes:
> On Mon, Apr 16, 2001 at 12:29:11AM -0600, Eric W. Biederman wrote:

>> 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?

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Alan Cox]

> 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

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > 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

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Albert D. Cahalan]

H. Peter Anvin writes:

> 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.

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[H. Peter Anvin]

"Albert D. Cahalan" wrote:
> 
> H. Peter Anvin writes:
> 
> > 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

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Jan Dvorak]

On Sat, Apr 14, 2001 at 12:21:20AM +0200, Guest section DW wrote:
> 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. 

> [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 <johnydog@go.cz>

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[H. Peter Anvin]

Followup to:  <20010414201250.A7260@napalm.go.cz>
By author:    Jan Dvorak <johnydog@go.cz>
In newsgroup: linux.dev.kernel
>
> On Sat, Apr 14, 2001 at 12:21:20AM +0200, Guest section DW wrote:
> > 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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[James Simmons]

> [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.]

Or for 2.5.X you could use EVIOCGKEYCODE or EVIOCSKEYCODE using
/dev/eventX. Also the input api supports up to 220 different keys and
could support up to 255. If you app needs to use a large keycode space
then use this instead. Its better to use this interface especially
for embedded systems that have only a serial console, but sometimes
we need to use a regular keyboard. Consider for example a hand held iPAQ.
Usually their is no keyboard attached. Here you have a graphical interface
(using framebuffer) and a touch screen. So here I like to have a kernel
that uses fbdev without the VT console system and input drivers to
interface with the device. Debugging can be done by the serial console.
If I attach a keyboard I like to be able to use it without having to have
a console system needing to be built in. Remember every byte of space
counts. Getting keycode via the console layer should eventually be
replaced by this approach.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[James Simmons]

>> 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

      Why? X was designed with the idea of a input device core. Keyboards
and mice are just a extenstion of this. Now that linux has a universal
input api (/dev/input/eventX) we can wrapper X around this. I'm working on
this for embedded devices. It just plain stupid to have VT support on
something like a hand held iPAQ which doesn't usually have a keyboard
attached. Also having fbcon built in for these devices just takes up
valuable space since without a keybaord it pretty much is a waste. I
rather have fbdev by itself with input support with only serial console
support. Yes several X apps expect keybaord input coming in. Well we just
don't support those apps on a handheld device. X apps that can work
completely with a mouse would work perfectly on these embedded devices
and would be installed. Since X has this nice clean design I really like
to see XFree86 also use this approach. 
       

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[Alan Cox]

> this for embedded devices. It just plain stupid to have VT support on
> something like a hand held iPAQ which doesn't usually have a keyboard
> attached. Also having fbcon built in for these devices just takes up

It makes plenty of sence to have support for virtual terminals on the ipaq.
I agree you want it modular so you can load the vt support when you need it.

Re: [PATCH] Unisys pc keyboard new keys patch, kernel 2.4.3

[James Simmons]

>> this for embedded devices. It just plain stupid to have VT support on
>> something like a hand held iPAQ which doesn't usually have a keyboard
>> attached. Also having fbcon built in for these devices just takes up
>
>It makes plenty of sence to have support for virtual terminals on the
>ipaq. I agree you want it modular so you can load the vt support when you
>need it.

Only if you have the attachable keyboard. Other embedded devices
completely lack a keyboard. They do however have some graphical output.
If you want X on them then using the /dev/input/event interface is the way
to go. I like to see that for the desktop as well :-)