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]>
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
In article <[email protected]> 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
--
<[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
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 <[email protected]>
Followup to: <[email protected]>
By author: Jan Dvorak <[email protected]>
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
--
<[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
> [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 [[email protected]] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
"H. Peter Anvin" <[email protected]> writes:
> In article <[email protected]> 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
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.
"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
--
<[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
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.
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?
> 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
Alan Cox <[email protected]> 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
>> 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.
> 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.
>> 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 :-)