Re: Fw: Re: keyboard problem with 2.6.6

Re: Fw: Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Fri, May 28, 2004 at 03:43:07PM -0700, Andrew Morton wrote:

> Guys, I agree with this person.  People are having serious problems
> with the input layer and you're just not talking to anyone.  Please come out
> and help work out a resolution.

I'm sorry for not being more responsive in the near past, I've had a
huge load of other work in addition to the input subsystem, many patches
are now in my inbox to go through.

>From today on I can work almost 100% on the input drivers, and I'll go
over all the patches and consider each one.

Regarding the raw interface to the AUX (and possibly also KBD)
interfaces, I'm not opposed to that, however, I don't see an easy way to
add it that would be able to coexist with the other drivers.

Eg. one cannot load both the 'psmouse' and the raw 'psaux' modules, as
the access to the serio port is exclusive. So far I don't very much like
the fact that one would have to unload the psmouse module to get raw
access to the port.

Regarding GPM and duplication of work between it and the kernel - as far
as I know, GPM development isn't going forward very much, and there is a
bunch of things it doesn't (and likely won't) support - like the
passthrough port on synaptics touchpads.

So, yes, I'd eventually like (and will accept patches) the kernel to be
able to use every mouse (or other device) GPM supports. I believe we're
pretty near already, except for a few rather obscure ones.

BUT, we still will need GPM, because something needs to do screen
copy-and-paste. And GPM will need to be able to implement touchpad
functionality (taps, edge scrolling, etc) from absolute pad data, like
the X synaptics driver does.

That's about it. I'd be happy to merge the raw access driver, if there
is a real need for it, and if it can be made to work together with the
other PS/2 kernel drivers.

One more thought: The emulated PS/2 mouse so many people are complaining
about is there only because applications like X cannot use the native
event interface. It was intended to be removed after that support is
added, but with X development being as slow as it is, it didn't ever
happen.

> Begin forwarded message:
> 
> Date: Fri, 28 May 2004 15:33:21 +0200
> From: Giuseppe Bilotta <bilotta78@hotpop.com>
> To: linux-kernel@vger.kernel.org
> Subject: Re: keyboard problem with 2.6.6
> 
> 
> Sau Dan Lee wrote:
> > Yeah.   They   say  the  input  system  "unifies"   the  interface  to
> > keyboard/mouse  devices.   They're   also  proud  that  the  in-kernel
> > keyboard/mouse drivers  are supporting more and more  devices.  But at
> > the same  time, they're sacrificing  flexibility by moving  many codes
> > into kernel.   (GPM supports more  mouse types!)  The new  system also
> > breaks backward compatibility.
> 
> The new system has some ups and downs. The biggest "down", 
> which is that of RAW mode not being available anymore (it's 
> emulated!) could be circumvented by having both the RAW and 
> translated codes move between layers.
> 
> Concerning GPM vs kernel support for mice, maybe we can hope 
> for a merging of the efforts and a reduction of code 
> duplication, if there is any?
> 
> Overall, I think that the new system *could* be a good starting 
> point, but it still needs a *lot* of work.
> 
> (Now, if we could have any reply from the maintainers?)
> 
> -- 
> Giuseppe "Oblomov" Bilotta
> 
> Can't you see
> It all makes perfect sense
> Expressed in dollar and cents
> Pounds shillings and pence
>                   (Roger Waters)
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Fw: Re: keyboard problem with 2.6.6

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> Regarding the raw interface to the AUX (and possibly also KBD)
> interfaces, I'm not opposed to that, however, I don't see an easy way to
> add it that would be able to coexist with the other drivers.
> 
> Eg. one cannot load both the 'psmouse' and the raw 'psaux' modules, as
> the access to the serio port is exclusive. So far I don't very much like
> the fact that one would have to unload the psmouse module to get raw
> access to the port.

The answer could be to the raw mode emulation of the current 
aux and kbd modules. The best thing would be to let the raw 
codes just bleed through the layers, together with the 
translated ones, and then letting the input event choose which 
one to pass on to the application depending on whether the 
application requested raw access or not. I don't know if this 
would work with AUX, but it would be the best solution for the 
keyboard driver.

In the specific case of the keyboard module, the biggest 
problem (I don't know if it's a bug or WAD) is that some raw 
scancodes don't get emulated correctly *unless* very specific 
keycodes are assigned to it. I have seen this happen with the 
multimedia keys on my keyboard, which do not have any keycode 
assigned by default. Basically what happens is that a key with 
scancode xx, assigned a keycode of yy might return a scancode 
of zz != xx. See for example Chris Osicki's post.

What happens is basically that the 'raw emulation' table is 
*not* updated by changes in the keycode assignments. I don't 
know if this is a bug in setkeycodes, a bug in the kernel 
modules, or some kind of misinteraction between the two.

Considering that in case of multiple keyboards one *should* 
have multiple raw emulation tables (one for each keyboard), I 
really think that it would be more troubles than anything to 
keep and maintain this 'raw emulation' method, which is why I 
suggest a 'bleed through' of raw codes, to be passed on when 
application request them.

At least in theory this shouldn't be much of a problem: just 
adding a parameter to the interface between the input events 
modules and the lower level modules.

> Regarding GPM and duplication of work between it and the kernel - as far
> as I know, GPM development isn't going forward very much, and there is a
> bunch of things it doesn't (and likely won't) support - like the
> passthrough port on synaptics touchpads.
> 
> So, yes, I'd eventually like (and will accept patches) the kernel to be
> able to use every mouse (or other device) GPM supports. I believe we're
> pretty near already, except for a few rather obscure ones.
> 
> BUT, we still will need GPM, because something needs to do screen
> copy-and-paste. And GPM will need to be able to implement touchpad
> functionality (taps, edge scrolling, etc) from absolute pad data, like
> the X synaptics driver does.
> 
> That's about it. I'd be happy to merge the raw access driver, if there
> is a real need for it, and if it can be made to work together with the
> other PS/2 kernel drivers.
> 
> One more thought: The emulated PS/2 mouse so many people are complaining
> about is there only because applications like X cannot use the native
> event interface. It was intended to be removed after that support is
> added, but with X development being as slow as it is, it didn't ever
> happen.

WRT this, would it be possible to create a GPM driver for the 
event interface? This way, once kernel support for all the GPM-
supported mice is complete, we would have the three-layered:

kernel | gpm | app

stream, which IIRC should work even with X, since X can read 
the gpm socket ...

BTW, what degree of support do we have for non-Synaptics 
touchpads, in particular ALPS?

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: Fw: Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sat, May 29, 2004 at 03:14:42PM +0200, Giuseppe Bilotta wrote:

> The answer could be to the raw mode emulation of the current 
> aux and kbd modules. The best thing would be to let the raw 
> codes just bleed through the layers, together with the 
> translated ones, and then letting the input event choose which 
> one to pass on to the application depending on whether the 
> application requested raw access or not. I don't know if this 
> would work with AUX, but it would be the best solution for the 
> keyboard driver.

With AUX it's indeed tough, since you cannot share the port for the
simple reason that you don't just listen, but also talk to the mouse.
This has led to lots of problems in the past, and the invention of
repeater mode in GPM.

With keyboard, it's doable, if the application would keep using IOCTLs
to set the LEDs. But I don't see the point of doing that. Actually, I
have a few point why NOT to do it:

1) USB keyboards don't have scancodes per se. And if you take HUT codes
as scancodes, they'd be completely different and wouldn't work with any
application. Thus there is nothing to pass on in that case.

2) Application has no bussiness knowing the raw scancodes. It should be
interested in keycodes if anything. The scancode emulation is there just
for backward compatibility, and I hope one day I'll be able to remove
it.

3) If I'd add the raw scancode passing through the input system, nobody
would fix X and friends to stop using rawmode. Ever.

> In the specific case of the keyboard module, the biggest 
> problem (I don't know if it's a bug or WAD) is that some raw 
> scancodes don't get emulated correctly *unless* very specific 
> keycodes are assigned to it. I have seen this happen with the 
> multimedia keys on my keyboard, which do not have any keycode 
> assigned by default. Basically what happens is that a key with 
> scancode xx, assigned a keycode of yy might return a scancode 
> of zz != xx. See for example Chris Osicki's post.

Yes. This is because there is a direct 1:1 mapping of keycode->scancode
in the emulation. The kernel always presents a "Linux keyboard" to
applications which insist on seeing rawmode. This "Linux keyboard" is
the same on all platforms (except mac), and thus it'd be enough to teach
X about this single "Linux keyboard", and noone would ever need to
change the xkb tables again. It's not been done yet, though.

So: If you have X configured to understand Linux scancodes (or someone
fixes it to use keycodes - the so called medium raw mode), then when you
exchange your keyboard, just a few setkeycode statements will tell the
kernel about it, and X will keep working without noticing anything.

> What happens is basically that the 'raw emulation' table is 
> *not* updated by changes in the keycode assignments. I don't 
> know if this is a bug in setkeycodes, a bug in the kernel 
> modules, or some kind of misinteraction between the two.

This is intentional. The table is static. It's purpose is not to return
the original raw codes (which in the USB case don't exist at all), but
to create some that make sense, and are always the same, for a certain
key.

> Considering that in case of multiple keyboards one *should* 
> have multiple raw emulation tables (one for each keyboard), I 
> really think that it would be more troubles than anything to 
> keep and maintain this 'raw emulation' method, which is why I 
> suggest a 'bleed through' of raw codes, to be passed on when 
> application request them.

Why would you want to have several different rawmodes bleed to
userspace? They'd be mixed together at the console, and would just be a
complete mess.

> > One more thought: The emulated PS/2 mouse so many people are complaining
> > about is there only because applications like X cannot use the native
> > event interface. It was intended to be removed after that support is
> > added, but with X development being as slow as it is, it didn't ever
> > happen.
> 
> WRT this, would it be possible to create a GPM driver for the 
> event interface?

Yes. Even better, it exists. And I though it's been integrated into GPM
as well, but I might be wrong on this one.

> This way, once kernel support for all the GPM-
> supported mice is complete, we would have the three-layered:
> 
> kernel | gpm | app

No, this isn't needed.

> stream, which IIRC should work even with X, since X can read 
> the gpm socket ...

Because it's easily possible to create a driver for X that will read the
event interface, too, for _both_ keyboard and mouse.

It's then

kernel ---- gpm
       `--- X -- app

> BTW, what degree of support do we have for non-Synaptics 
> touchpads, in particular ALPS?
 
ALPS support is in my patch queue, but there are some problems with it
(like that ALPS touchpads cannot be autodetected).

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Fw: Re: keyboard problem with 2.6.6

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> On Sat, May 29, 2004 at 03:14:42PM +0200, Giuseppe Bilotta wrote:
> 
> > The answer could be to the raw mode emulation of the current 
> > aux and kbd modules. The best thing would be to let the raw 
> > codes just bleed through the layers, together with the 
> > translated ones, and then letting the input event choose which 
> > one to pass on to the application depending on whether the 
> > application requested raw access or not. I don't know if this 
> > would work with AUX, but it would be the best solution for the 
> > keyboard driver.
> 
> With AUX it's indeed tough, since you cannot share the port for the
> simple reason that you don't just listen, but also talk to the mouse.
> This has led to lots of problems in the past, and the invention of
> repeater mode in GPM.
> 
> With keyboard, it's doable, if the application would keep using IOCTLs
> to set the LEDs. But I don't see the point of doing that. Actually, I
> have a few point why NOT to do it:
> 
> 1) USB keyboards don't have scancodes per se. And if you take HUT codes
> as scancodes, they'd be completely different and wouldn't work with any
> application. Thus there is nothing to pass on in that case.

How do USB keyboards cope with X on 2.4.x kernels? If they 
weren't usable, then it's ok to have this fake emulated raw 
mode for them, since it brings them from useless to usable. It 
doesn't *break* anything.

> 2) Application has no bussiness knowing the raw scancodes. It should be
> interested in keycodes if anything. The scancode emulation is there just
> for backward compatibility, and I hope one day I'll be able to remove
> it.

Backward compatibility, or support for the functionality not 
yet supported by the current model at the current development 
level. For example (see other post), a standard set of keycodes 
for multimedia keys on multimedia keyboards, with as much a 
widespread support for such things as X currently provides.

Please note that *when* we'll have kernel-level support and a 
kernel-level standard for these funky keyboards, it would be a 
breeze to create an inet(linux) keysym definition file, 
therefore nihiling the need for 'proper' raw access.

The problem is 'what should we do in the mean time?'

> 3) If I'd add the raw scancode passing through the input system, nobody
> would fix X and friends to stop using rawmode. Ever.

What is the *user* expected to do as we wait for things to be 
fixed? Stick to 2.4.x or hand-patching the raw mode emulation 
table and recompiling are the only sane options to keep full 
functionality *at the moment*. Which is not really that nice a 
set of options, if you ask me. Especially considering the, uhm, 
speed with which X and friends are fixed.

I do agree with you that it should be entirely up to the kernel 
to provide this kind of HAL. But since

1. the kernel still doesn't fully provide it anyway (see 
multimedia keys)
2. the applications still don't comply with it

When the kernel will provide a complete enough HAL, we can 
start talking about 'not needing a real raw mode'. *In the mean 
time*, real raw mode *is* needed.

> > Considering that in case of multiple keyboards one *should* 
> > have multiple raw emulation tables (one for each keyboard), I 
> > really think that it would be more troubles than anything to 
> > keep and maintain this 'raw emulation' method, which is why I 
> > suggest a 'bleed through' of raw codes, to be passed on when 
> > application request them.
> 
> Why would you want to have several different rawmodes bleed to
> userspace? They'd be mixed together at the console, and would just be a
> complete mess.

Ok, at this point I think I have more than abundantly answer 
the question :). I don't 'want' them. In fact, this is 
precisely the reason why I said the new input system is a good 
thing. But I *do* think that *until* its support for hardware 
completely supported by the old system is as complete as it 
used to be, and *until* its use is widespread enough in 
userspace, we *do* need real raw mode.

And differently from you, I do not think that *forcing* people 
to change to the new system by not providing any form of 
transition capability *is* the way to go. Especially when the 
biggest (complaining) userbase relies on projects which are 
known to be slow in the uptake (like X for example). It just 
pisses people off, and keeps them from using the new system, or 
increase their stress level if they must use it. Especially 
when the new system breaks things that worked smoothly before. 
Moderately expert users will just patch what is needed and move 
on, but what about all the others?

> > WRT this, would it be possible to create a GPM driver for the 
> > event interface?
> 
> Yes. Even better, it exists. And I though it's been integrated into GPM
> as well, but I might be wrong on this one.

Good I'll look into this.

> > This way, once kernel support for all the GPM-
> > supported mice is complete, we would have the three-layered:
> > 
> > kernel | gpm | app
> 
> No, this isn't needed.
> 
> > stream, which IIRC should work even with X, since X can read 
> > the gpm socket ...
> 
> Because it's easily possible to create a driver for X that will read the
> event interface, too, for _both_ keyboard and mouse.
> 
> It's then
> 
> kernel ---- gpm
>        `--- X -- app

Any chances of conflict? (No, because the kernel handles the 
stuff?)

> > BTW, what degree of support do we have for non-Synaptics 
> > touchpads, in particular ALPS?
>  
> ALPS support is in my patch queue, but there are some problems with it
> (like that ALPS touchpads cannot be autodetected).

Well, module options for type specification will probably be 
needed anyway for the keyboards, *when* we'll have a standard 
for multimedia keys, so I guess it's good to get used to having 
to specify models as module options ;)




One last thing: although here and there I might have come 
through somewhat fiercely, please understand that I'm not angry 
or pissed off or anything, it's just that I get carried on when 
talking. I really think the new method has great potential, and 
that when it'll be complete it'll be much better than the old 
one, but I really do think that something to smooth the 
transition should be provided while it gets completed.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: Fw: Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sat, May 29, 2004 at 05:12:31PM +0200, Giuseppe Bilotta wrote:

> > 1) USB keyboards don't have scancodes per se. And if you take HUT codes
> > as scancodes, they'd be completely different and wouldn't work with any
> > application. Thus there is nothing to pass on in that case.
> 
> How do USB keyboards cope with X on 2.4.x kernels? If they 
> weren't usable, then it's ok to have this fake emulated raw 
> mode for them, since it brings them from useless to usable. It 
> doesn't *break* anything.

They used emulated rawmode on 2.4.

> Backward compatibility, or support for the functionality not 
> yet supported by the current model at the current development 
> level. For example (see other post), a standard set of keycodes 
> for multimedia keys on multimedia keyboards, with as much a 
> widespread support for such things as X currently provides.
> 
> Please note that *when* we'll have kernel-level support and a 
> kernel-level standard for these funky keyboards, it would be a 
> breeze to create an inet(linux) keysym definition file, 
> therefore nihiling the need for 'proper' raw access.

The support is present in the kernel. You can use setkeycode to load that
table. Only X won't use it.

> > 3) If I'd add the raw scancode passing through the input system, nobody
> > would fix X and friends to stop using rawmode. Ever.
> 
> What is the *user* expected to do as we wait for things to be 
> fixed?

The emulated rawmode (which is needed for USB anyway) is supposed to
work well enough. It supports multimedia keys (and generates
Microsoft-compatible scancodes for most of them), and can be configured
to work with any keyboard using setkeycode.

> Stick to 2.4.x or hand-patching the raw mode emulation 
> table and recompiling are the only sane options to keep full 
> functionality *at the moment*.

No. The sane option at the moment (which isn't perfect, I admit), is to
use setkeycode to make the kernel understand the multimedia keys (you
can verify it does using evtest), and then to configure X to understand
the kernel-generated scancodes. That way you get full functionality
without any hacks.

> Which is not really that nice a 
> set of options, if you ask me. Especially considering the, uhm, 
> speed with which X and friends are fixed.

That's the main problem, actually. Were it a little bit less slow, we'd
have X using the event interface by now and all the discussion would be
moot.

> I do agree with you that it should be entirely up to the kernel 
> to provide this kind of HAL. But since
> 
> 1. the kernel still doesn't fully provide it anyway (see 
> multimedia keys)

It understands MS-compatible multimedia keys by default. For
incompatible scancode sets, you need to use setkeycode. Setkeycode
works.

> 2. the applications still don't comply with it

Unfortunately, yes.

> When the kernel will provide a complete enough HAL, we can 
> start talking about 'not needing a real raw mode'. *In the mean 
> time*, real raw mode *is* needed.

As Andries convinced me, it'll always be needed, if only for debugging
and setting up the translation tables easily (without checking the
kernel log).

I'll buy some food and start hacking at it today evening.

> Ok, at this point I think I have more than abundantly answer 
> the question :). I don't 'want' them. In fact, this is 
> precisely the reason why I said the new input system is a good 
> thing. But I *do* think that *until* its support for hardware 
> completely supported by the old system is as complete as it 
> used to be, and *until* its use is widespread enough in 
> userspace, we *do* need real raw mode.
> 
> And differently from you, I do not think that *forcing* people 
> to change to the new system by not providing any form of 
> transition capability *is* the way to go.

Note that I did provide a transition capability, although it isn't a
perfect one. If I didn't, there would be _no_ raw mode and X wouldn't
work at all, which might have been better. ;)

> Especially when the 
> biggest (complaining) userbase relies on projects which are 
> known to be slow in the uptake (like X for example). It just 
> pisses people off, and keeps them from using the new system, or 
> increase their stress level if they must use it. Especially 
> when the new system breaks things that worked smoothly before. 
> Moderately expert users will just patch what is needed and move 
> on, but what about all the others?
> 
> > > WRT this, would it be possible to create a GPM driver for the 
> > > event interface?
> > 
> > Yes. Even better, it exists. And I though it's been integrated into GPM
> > as well, but I might be wrong on this one.
> 
> Good I'll look into this.
> 
> > > This way, once kernel support for all the GPM-
> > > supported mice is complete, we would have the three-layered:
> > > 
> > > kernel | gpm | app
> > 
> > No, this isn't needed.
> > 
> > > stream, which IIRC should work even with X, since X can read 
> > > the gpm socket ...
> > 
> > Because it's easily possible to create a driver for X that will read the
> > event interface, too, for _both_ keyboard and mouse.
> > 
> > It's then
> > 
> > kernel ---- gpm
> >        `--- X -- app
> 
> Any chances of conflict? (No, because the kernel handles the 
> stuff?)

Exactly. The kernel interface is implemented so as to be used by any
number of processes simultaneously.

This is also valid for the emulated PS/2 mouse. Two opens don't hurt,
each process gets its own virtual mouse.

> Well, module options for type specification will probably be 
> needed anyway for the keyboards, *when* we'll have a standard 
> for multimedia keys, so I guess it's good to get used to having 
> to specify models as module options ;)

Module (or kernel cmdline) parameters are not a good way to go, because
they cannot be changed at runtime. For mouse models, sysfs will be used
(when I get to implementing sysfs support for serio and input layers),
and most keyboards don't need any special options, except for scrolling
keyboards - setkeycode is enough to teach the driver about the special
scancodes.

> One last thing: although here and there I might have come 
> through somewhat fiercely, please understand that I'm not angry 
> or pissed off or anything, it's just that I get carried on when 
> talking. I really think the new method has great potential, and 
> that when it'll be complete it'll be much better than the old 
> one, but I really do think that something to smooth the 
> transition should be provided while it gets completed.
 
Thanks. I hope we'll get there eventually.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Fw: Re: keyboard problem with 2.6.6

[Dmitry Torokhov]

On Saturday 29 May 2004 10:44 am, Vojtech Pavlik wrote:
> Module (or kernel cmdline) parameters are not a good way to go, because
> they cannot be changed at runtime. For mouse models, sysfs will be used
> (when I get to implementing sysfs support for serio and input layers),
> and most keyboards don't need any special options, except for scrolling
> keyboards - setkeycode is enough to teach the driver about the special
> scancodes.
> 

I have a patch that sysfsifies all serio drivers but not serio ports yet...
I wanted to get everything in shape before showing it, but if you are
interested I can rediff against the current.

-- 
Dmitry

Re: Fw: Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sat, May 29, 2004 at 12:18:30PM -0500, Dmitry Torokhov wrote:

> > Module (or kernel cmdline) parameters are not a good way to go, because
> > they cannot be changed at runtime. For mouse models, sysfs will be used
> > (when I get to implementing sysfs support for serio and input layers),
> > and most keyboards don't need any special options, except for scrolling
> > keyboards - setkeycode is enough to teach the driver about the special
> > scancodes.
> > 
> 
> I have a patch that sysfsifies all serio drivers but not serio ports yet...
> I wanted to get everything in shape before showing it, but if you are
> interested I can rediff against the current.

Show it. ;)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Fw: Re: keyboard problem with 2.6.6

[Giuseppe Bilotta]

Hi,

a couple of answers on the things I still have doubts on. Note 
that I'm using the 2.6.5 as reference. If anything has 
thoroughly changed in 2.6.6 or 7-rc1, just let me know.

Vojtech Pavlik wrote:
> On Sat, May 29, 2004 at 05:12:31PM +0200, Giuseppe Bilotta wrote:
> > Backward compatibility, or support for the functionality not 
> > yet supported by the current model at the current development 
> > level. For example (see other post), a standard set of keycodes 
> > for multimedia keys on multimedia keyboards, with as much a 
> > widespread support for such things as X currently provides.

[snip]

> The support is present in the kernel. You can use setkeycode to load that
> table. Only X won't use it.

[snip]

> The emulated rawmode (which is needed for USB anyway) is supposed to
> work well enough. It supports multimedia keys (and generates
> Microsoft-compatible scancodes for most of them), and can be configured
> to work with any keyboard using setkeycode.

By looking at the header files, or into the documentation, I 
have problems finding what keycode is supposed to be assigned 
to have a key act as the corresponding "Microsoft-compatible" 
keyboard.

My thoughts are that, even without an event driver interface 
for X, it is possible to use the present model provided that 
the emulated rawmode provides the widest possible set of 
features provided by the union of 'all' available keyboards. 
With a (possibly documented) set of keycodes that needs to be 
assigned to get this or that function.

With my limited knowledge (i.e. by what I see looking at the 
source files and include headers) I see the kernel lacking in 
two fields:

* X allows for the shift, ctrl, alt, meta, super, hyper (left 
and right) modifiers. In the kernel headers I only see 
references to shift ctrl and alt. (Actually X also has a wild 
bunch of other modifiers for group shift, composition etc.)

* No (documented) set of keycodes to assign to get mapped to 
multimedia/internet keys (volume up/down, play, stop, next, 
prev, email, internet, blah blah blah)

If we want to go the 'full emulation' way, such things must be 
set in a standard, documented way. Which is not the case yet, 
unless I'm just going blind.

> > Stick to 2.4.x or hand-patching the raw mode emulation 
> > table and recompiling are the only sane options to keep full 
> > functionality *at the moment*.
> 
> No. The sane option at the moment (which isn't perfect, I admit), is to
> use setkeycode to make the kernel understand the multimedia keys (you
> can verify it does using evtest), and then to configure X to understand
> the kernel-generated scancodes. That way you get full functionality
> without any hacks.

And I noticed there was this excellent "keyfuzz" utility 
recently released which is aimed at providing exactly this 
feauture. But it doesn't work as expected. Not yet. Because 
keycodes have to be assigned by trial and error and trying to 
re-do assignments causes strange effects since scancodes start 
shifting as well in a very strange way. Which is why at a 
certain point (over a month now) I just gave up and patched 
atkbd.c directly to have it work with my keyboard.

> > Which is not really that nice a 
> > set of options, if you ask me. Especially considering the, uhm, 
> > speed with which X and friends are fixed.
> 
> That's the main problem, actually. Were it a little bit less slow, we'd
> have X using the event interface by now and all the discussion would be
> moot.

Of course. But X is what it is and we're stuck in this 
situation.

> > I do agree with you that it should be entirely up to the kernel 
> > to provide this kind of HAL. But since
> > 
> > 1. the kernel still doesn't fully provide it anyway (see 
> > multimedia keys)
> 
> It understands MS-compatible multimedia keys by default. For
> incompatible scancode sets, you need to use setkeycode. Setkeycode
> works.

Setkeycodes works by trial and error. MS-compatible multimedia 
keys scancodes are not exactly well-documented, not anywhere I 
can see. Also, does MS-compatible mutlimedia scancodes emulate 
the whole set of keys some ridiculous humongous keys provide?

> > When the kernel will provide a complete enough HAL, we can 
> > start talking about 'not needing a real raw mode'. *In the mean 
> > time*, real raw mode *is* needed.
> 
> As Andries convinced me, it'll always be needed, if only for debugging
> and setting up the translation tables easily (without checking the
> kernel log).
> 
> I'll buy some food and start hacking at it today evening.

Thank you very much :)

> > And differently from you, I do not think that *forcing* people 
> > to change to the new system by not providing any form of 
> > transition capability *is* the way to go.
> 
> Note that I did provide a transition capability, although it isn't a
> perfect one. If I didn't, there would be _no_ raw mode and X wouldn't
> work at all, which might have been better. ;)

It would have been interesting to see the reactions :)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: Fw: Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 12:20:32PM +0200, Giuseppe Bilotta wrote:

> By looking at the header files, or into the documentation, I 
> have problems finding what keycode is supposed to be assigned 
> to have a key act as the corresponding "Microsoft-compatible" 
> keyboard.
> 
> My thoughts are that, even without an event driver interface 
> for X, it is possible to use the present model provided that 
> the emulated rawmode provides the widest possible set of 
> features provided by the union of 'all' available keyboards. 
> With a (possibly documented) set of keycodes that needs to be 
> assigned to get this or that function.

The emulated rawmode unfortunately cannot cover every keyboard out
there, because of the limitations of the PS/2 protocol, which only can
transfer about 240 different scancodes.

The event interface of course doesn't have this limitation.

> With my limited knowledge (i.e. by what I see looking at the 
> source files and include headers) I see the kernel lacking in 
> two fields:
> 
> * X allows for the shift, ctrl, alt, meta, super, hyper (left 
> and right) modifiers. In the kernel headers I only see 
> references to shift ctrl and alt. (Actually X also has a wild 
> bunch of other modifiers for group shift, composition etc.)

The kernel input layer doesn't treat modifiers as special keys, and
currently (include/linux/input.h) has shift, alt, ctrl and meta keys.
Both left and right.  This covers all keyboards I've seen so far,
including SGI, Sun, Mac, and other keyboards.

This is different from the X keysym modifiers, because the super and
hyper modifiers usually don't correspond to real physical keys on the
keyboard.

> * No (documented) set of keycodes to assign to get mapped to 
> multimedia/internet keys (volume up/down, play, stop, next, 
> prev, email, internet, blah blah blah)

include/linux/input.h has the documented set of keycodes. It's largely
based on what 2.4 uses for keycodes - sanitized PS/2 codes.

> If we want to go the 'full emulation' way, such things must be 
> set in a standard, documented way. Which is not the case yet, 
> unless I'm just going blind.

The emulated scancodes are not documented at the moment, but you can
find out a scancode for a documented keycode by looking at
drivers/char/keyboard.c, which has a mapping table in it.

> And I noticed there was this excellent "keyfuzz" utility 
> recently released which is aimed at providing exactly this 
> feauture. But it doesn't work as expected. Not yet. Because 
> keycodes have to be assigned by trial and error and trying to 
> re-do assignments causes strange effects since scancodes start 
> shifting as well in a very strange way. Which is why at a 
> certain point (over a month now) I just gave up and patched 
> atkbd.c directly to have it work with my keyboard.

It was written for 2.4 unfortunately, and 2.6's emulated rawmode
confuses it no end.

> Setkeycodes works by trial and error. MS-compatible multimedia 
> keys scancodes are not exactly well-documented, not anywhere I 
> can see. Also, does MS-compatible mutlimedia scancodes emulate 
> the whole set of keys some ridiculous humongous keys provide?

Not really. There is a method that's almost straightforward. Press the
key, type 'dmesg', and you'll see two lines suggesting the setkeycodes
command. There you get the first parameter - scancode. Then you look up
the key in include/linux/input.h, and there you find the keycode.

And then you use the command.

After that, you have the kernel acquainted with your keyboard. You can
verify with evtest (attached), that the kernel understands every key on
your keyboard correctly.

Next is X.

For X, you use showkey -s, and record the scancodes the kernel
generates. These will be the same on every machine. Then you modify xkb
to understand them.

The X step could be avoided if we had a definition file for xkb for the
kernel emulated keyboard.

> > > When the kernel will provide a complete enough HAL, we can 
> > > start talking about 'not needing a real raw mode'. *In the mean 
> > > time*, real raw mode *is* needed.
> > 
> > As Andries convinced me, it'll always be needed, if only for debugging
> > and setting up the translation tables easily (without checking the
> > kernel log).
> > 
> > I'll buy some food and start hacking at it today evening.
> 
> Thank you very much :)

It turns out it's not as easy as it seems to be. But I'll hopefully have
something finished today.

> > Note that I did provide a transition capability, although it isn't a
> > perfect one. If I didn't, there would be _no_ raw mode and X wouldn't
> > work at all, which might have been better. ;)
> 
> It would have been interesting to see the reactions :)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Fw: Re: keyboard problem with 2.6.6

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 12:20:32PM +0200, Giuseppe Bilotta wrote:
> > My thoughts are that, even without an event driver interface 
> > for X, it is possible to use the present model provided that 
> > the emulated rawmode provides the widest possible set of 
> > features provided by the union of 'all' available keyboards. 
> > With a (possibly documented) set of keycodes that needs to be 
> > assigned to get this or that function.
> 
> The emulated rawmode unfortunately cannot cover every keyboard out
> there, because of the limitations of the PS/2 protocol, which only can
> transfer about 240 different scancodes.

This is bad.

> The event interface of course doesn't have this limitation.
> 
> > With my limited knowledge (i.e. by what I see looking at the 
> > source files and include headers) I see the kernel lacking in 
> > two fields:
> > 
> > * X allows for the shift, ctrl, alt, meta, super, hyper (left 
> > and right) modifiers. In the kernel headers I only see 
> > references to shift ctrl and alt. (Actually X also has a wild 
> > bunch of other modifiers for group shift, composition etc.)
> 
> The kernel input layer doesn't treat modifiers as special keys, and
> currently (include/linux/input.h) has shift, alt, ctrl and meta keys.
> Both left and right.  This covers all keyboards I've seen so far,
> including SGI, Sun, Mac, and other keyboards.
> 
> This is different from the X keysym modifiers, because the super and
> hyper modifiers usually don't correspond to real physical keys on the
> keyboard.

Sorry but this is untrue. My Win keys are configured as super, 
for example.

> > * No (documented) set of keycodes to assign to get mapped to 
> > multimedia/internet keys (volume up/down, play, stop, next, 
> > prev, email, internet, blah blah blah)
> 
> include/linux/input.h has the documented set of keycodes. It's largely
> based on what 2.4 uses for keycodes - sanitized PS/2 codes.

Ah good. I was looking at the wrong headers :)

> > And I noticed there was this excellent "keyfuzz" utility 
> > recently released which is aimed at providing exactly this 
> > feauture. But it doesn't work as expected. Not yet. Because 
> > keycodes have to be assigned by trial and error and trying to 
> > re-do assignments causes strange effects since scancodes start 
> > shifting as well in a very strange way. Which is why at a 
> > certain point (over a month now) I just gave up and patched 
> > atkbd.c directly to have it work with my keyboard.
> 
> It was written for 2.4 unfortunately, and 2.6's emulated rawmode
> confuses it no end.

It could be updated though.

> The X step could be avoided if we had a definition file for xkb for the
> kernel emulated keyboard.

That's exactly what I'm saying. But there isn't. Which is what 
pisses off most users.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: Fw: Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 02:38:08PM +0200, Giuseppe Bilotta wrote:

> > The kernel input layer doesn't treat modifiers as special keys, and
> > currently (include/linux/input.h) has shift, alt, ctrl and meta keys.
> > Both left and right.  This covers all keyboards I've seen so far,
> > including SGI, Sun, Mac, and other keyboards.
> > 
> > This is different from the X keysym modifiers, because the super and
> > hyper modifiers usually don't correspond to real physical keys on the
> > keyboard.
> 
> Sorry but this is untrue. My Win keys are configured as super, 
> for example.

The Linux kernel reports them as KEY_LEFTMETA, KEY_RIGHTMETA and
KEY_COMPOSE.

> > > * No (documented) set of keycodes to assign to get mapped to 
> > > multimedia/internet keys (volume up/down, play, stop, next, 
> > > prev, email, internet, blah blah blah)
> > 
> > include/linux/input.h has the documented set of keycodes. It's largely
> > based on what 2.4 uses for keycodes - sanitized PS/2 codes.
> 
> Ah good. I was looking at the wrong headers :)

> > It was written for 2.4 unfortunately, and 2.6's emulated rawmode
> > confuses it no end.
> 
> It could be updated though.

It can be updated, yes.

> > The X step could be avoided if we had a definition file for xkb for the
> > kernel emulated keyboard.
> 
> That's exactly what I'm saying. But there isn't. Which is what 
> pisses off most users.

I'm not very familiar with xkb configuration. Perhaps you'd be willing
to write that definition file? I'll certainly help you from the kernel
side - I can even generate a list of keycode - scancode - meaning
relations for you.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Fw: Re: keyboard problem with 2.6.6

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 02:38:08PM +0200, Giuseppe Bilotta wrote:
> 
> > > The kernel input layer doesn't treat modifiers as special keys, and
> > > currently (include/linux/input.h) has shift, alt, ctrl and meta keys.
> > > Both left and right.  This covers all keyboards I've seen so far,
> > > including SGI, Sun, Mac, and other keyboards.
> > > 
> > > This is different from the X keysym modifiers, because the super and
> > > hyper modifiers usually don't correspond to real physical keys on the
> > > keyboard.
> > 
> > Sorry but this is untrue. My Win keys are configured as super, 
> > for example.
> 
> The Linux kernel reports them as KEY_LEFTMETA, KEY_RIGHTMETA and
> KEY_COMPOSE.

In X standard keyboards Meta is mapped as the second symbol for 
Alt.

// definition for the extra keys on 104-key "Windows95" keyboards
xkb_symbols "pc104" {
    include "us(generic101)"
    key <LALT> {	[ 	Alt_L,	Meta_L		]	};
    key <RALT> {	[	Alt_R,	Meta_R		]	};
    key <LWIN> {	[	Super_L			]	};
    key <RWIN> {	[	Super_R			]	};
    key <MENU> {	[	Menu			]	};

    // modifier mappings
    modifier_map Mod1   { Alt_L, Alt_R, Meta_L, Meta_R };
    modifier_map Mod4   { Super_L, Super_R };
}; 

// definition of Euro-style, Right "logo" key == [Mode_switch, Multi_key]
xkb_symbols "pc104euro" {
    include "us(pc104)"
    key <RALT> {        [       Mode_switch             ]       
};
    key <RWIN> {	[	Multi_key		]	};
};
 
> > > The X step could be avoided if we had a definition file for xkb for the
> > > kernel emulated keyboard.
> > 
> > That's exactly what I'm saying. But there isn't. Which is what 
> > pisses off most users.
> 
> I'm not very familiar with xkb configuration. Perhaps you'd be willing
> to write that definition file? I'll certainly help you from the kernel
> side - I can even generate a list of keycode - scancode - meaning
> relations for you.

If you do generate a list of keycode - scancode - meaning pairs 
it will surely make my life easier.

I'm not particularly familiar with xkb configuration either. I 
can *probably* make it work (i.e. test it as functional) on my 
Dell Inspiron 8200 keyboard and on a standard pc104 keyboard 
only. You probably need somebody else to work out the details 
for other keyboards, though.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: Fw: Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 06:08:39PM +0200, Giuseppe Bilotta wrote:

> > The Linux kernel reports them as KEY_LEFTMETA, KEY_RIGHTMETA and
> > KEY_COMPOSE.
> 
> In X standard keyboards Meta is mapped as the second symbol for 
> Alt.
> 
> // definition for the extra keys on 104-key "Windows95" keyboards
> xkb_symbols "pc104" {
>     include "us(generic101)"
>     key <LALT> {	[ 	Alt_L,	Meta_L		]	};
>     key <RALT> {	[	Alt_R,	Meta_R		]	};
>     key <LWIN> {	[	Super_L			]	};
>     key <RWIN> {	[	Super_R			]	};
>     key <MENU> {	[	Menu			]	};
> 
>     // modifier mappings
>     modifier_map Mod1   { Alt_L, Alt_R, Meta_L, Meta_R };
>     modifier_map Mod4   { Super_L, Super_R };
> }; 
> 
> // definition of Euro-style, Right "logo" key == [Mode_switch, Multi_key]
> xkb_symbols "pc104euro" {
>     include "us(pc104)"
>     key <RALT> {        [       Mode_switch             ]       
> };
>     key <RWIN> {	[	Multi_key		]	};
> };

Interesting. Nevertheless it's just a naming difference, and thus
shouldn't be a problem.

> > I'm not very familiar with xkb configuration. Perhaps you'd be willing
> > to write that definition file? I'll certainly help you from the kernel
> > side - I can even generate a list of keycode - scancode - meaning
> > relations for you.
> 
> If you do generate a list of keycode - scancode - meaning pairs 
> it will surely make my life easier.
> 
> I'm not particularly familiar with xkb configuration either. I 
> can *probably* make it work (i.e. test it as functional) on my 
> Dell Inspiron 8200 keyboard and on a standard pc104 keyboard 
> only. You probably need somebody else to work out the details 
> for other keyboards, though.

Ok, I'll try to produce something.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Fw: Re: keyboard problem with 2.6.6

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 06:08:39PM +0200, Giuseppe Bilotta wrote:
> 
> > > The Linux kernel reports them as KEY_LEFTMETA, KEY_RIGHTMETA and
> > > KEY_COMPOSE.
> > 
> > In X standard keyboards Meta is mapped as the second symbol for 
> > Alt.

[snip]

> Interesting. Nevertheless it's just a naming difference, and thus
> shouldn't be a problem.

Well, it's not just that, not if we want Meta kernel keys to 
become Meta X keys. Which wouldn't be a bad thing, since it 
would mean we'd have the keyboard acting the same under console 
and X. But in this case it would be nice if Linux knew about 
more modifiers than just shift, ctrl, alt, meta.

> > > I'm not very familiar with xkb configuration. Perhaps you'd be willing
> > > to write that definition file? I'll certainly help you from the kernel
> > > side - I can even generate a list of keycode - scancode - meaning
> > > relations for you.
> > 
> > If you do generate a list of keycode - scancode - meaning pairs 
> > it will surely make my life easier.
> > 
> > I'm not particularly familiar with xkb configuration either. I 
> > can *probably* make it work (i.e. test it as functional) on my 
> > Dell Inspiron 8200 keyboard and on a standard pc104 keyboard 
> > only. You probably need somebody else to work out the details 
> > for other keyboards, though.
> 
> Ok, I'll try to produce something.

Thanks.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: Fw: Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 10:51:18PM +0200, Giuseppe Bilotta wrote:

> > Interesting. Nevertheless it's just a naming difference, and thus
> > shouldn't be a problem.
> 
> Well, it's not just that, not if we want Meta kernel keys to 
> become Meta X keys. Which wouldn't be a bad thing, since it 
> would mean we'd have the keyboard acting the same under console 
> and X. But in this case it would be nice if Linux knew about 
> more modifiers than just shift, ctrl, alt, meta.

Keep in mind that the kernel keys we're talking about are keycodes, not
keysyms, and thus are not a result of a keymap. On the other hand, the
xkb tables you've shown are for keysyms.

The equivalences are:

Kernel		   XKB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KEY_LEFTALT    ==  key <LALT> 
KEY_RIGHTALT   ==  key <RALT> 
KEY_LEFTMETA   ==  key <LWIN> 
KEY_RIGHTMETA  ==  key <RWIN> 
KEY_COMPOSE    ==  key <MENU> 

There is a 1:1 mapping. 

Now, if you want to make them _do_ the same both in X and on console,
then we're talking keymaps, and there I think is no problem again,
because the kernel can handle up to 9 modifiers as far as I know,
although they don't all have names.

linux/keyboard.h:#define NR_SHIFT       9

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Fw: Re: keyboard problem with 2.6.6

[Giuseppe Bilotta]

Vojtech Pavlik wrote:
> On Sun, May 30, 2004 at 10:51:18PM +0200, Giuseppe Bilotta wrote:
> 
> > > Interesting. Nevertheless it's just a naming difference, and thus
> > > shouldn't be a problem.
> > 
> > Well, it's not just that, not if we want Meta kernel keys to 
> > become Meta X keys. Which wouldn't be a bad thing, since it 
> > would mean we'd have the keyboard acting the same under console 
> > and X. But in this case it would be nice if Linux knew about 
> > more modifiers than just shift, ctrl, alt, meta.
> 
> Keep in mind that the kernel keys we're talking about are keycodes, not
> keysyms, and thus are not a result of a keymap. On the other hand, the
> xkb tables you've shown are for keysyms.
> 
> The equivalences are:
> 
> Kernel		   XKB
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> KEY_LEFTALT    ==  key <LALT> 
> KEY_RIGHTALT   ==  key <RALT> 
> KEY_LEFTMETA   ==  key <LWIN> 
> KEY_RIGHTMETA  ==  key <RWIN> 
> KEY_COMPOSE    ==  key <MENU> 
> 
> There is a 1:1 mapping. 
> 
> Now, if you want to make them _do_ the same both in X and on console,
> then we're talking keymaps, and there I think is no problem again,
> because the kernel can handle up to 9 modifiers as far as I know,
> although they don't all have names.
> 
> linux/keyboard.h:#define NR_SHIFT       9

Point fully taken. I retreat in a corner with a big 'A' cone 
cap on my head.

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: keyboard: kernel and X

[Andries Brouwer]

On Sun, May 30, 2004 at 10:51:18PM +0200, Giuseppe Bilotta wrote:

> Well, it's not just that, not if we want Meta kernel keys to 
> become Meta X keys. Which wouldn't be a bad thing, since it 
> would mean we'd have the keyboard acting the same under console 
> and X. But in this case it would be nice if Linux knew about 
> more modifiers than just shift, ctrl, alt, meta.

The X and kernel systems are incompatible.
The Linux kernel has 8 modifiers. Any key can be a modifier.
Read keymaps(5).

Re: keyboard: kernel and X

[Giuseppe Bilotta]

Andries Brouwer wrote:
> On Sun, May 30, 2004 at 10:51:18PM +0200, Giuseppe Bilotta wrote:
> 
> > Well, it's not just that, not if we want Meta kernel keys to 
> > become Meta X keys. Which wouldn't be a bad thing, since it 
> > would mean we'd have the keyboard acting the same under console 
> > and X. But in this case it would be nice if Linux knew about 
> > more modifiers than just shift, ctrl, alt, meta.
> 
> The X and kernel systems are incompatible.
> The Linux kernel has 8 modifiers. Any key can be a modifier.
> Read keymaps(5).

There goes one of my dreams ...

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: Fw: Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sun, May 30, 2004 at 10:51:18PM +0200, Giuseppe Bilotta wrote:

> > > > I'm not very familiar with xkb configuration. Perhaps you'd be willing
> > > > to write that definition file? I'll certainly help you from the kernel
> > > > side - I can even generate a list of keycode - scancode - meaning
> > > > relations for you.
> > > 
> > > If you do generate a list of keycode - scancode - meaning pairs 
> > > it will surely make my life easier.
> > > 
> > > I'm not particularly familiar with xkb configuration either. I 
> > > can *probably* make it work (i.e. test it as functional) on my 
> > > Dell Inspiron 8200 keyboard and on a standard pc104 keyboard 
> > > only. You probably need somebody else to work out the details 
> > > for other keyboards, though.
> > 
> > Ok, I'll try to produce something.
> 
> Thanks.

Here we go. This is a list of scancodes that the kernel produces in RAW
emulation mode, independent of the keyboard type.
  
Key  Key                    Press                Release
Code Name                   ScanCode(s)          ScanCode(s)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1: KEY_ESC                01		--->	 81
  2: KEY_1                  02		--->	 82
  3: KEY_2                  03		--->	 83
  4: KEY_3                  04		--->	 84
  5: KEY_4                  05		--->	 85
  6: KEY_5                  06		--->	 86
  7: KEY_6                  07		--->	 87
  8: KEY_7                  08		--->	 88
  9: KEY_8                  09		--->	 89
 10: KEY_9                  0a		--->	 8a
 11: KEY_0                  0b		--->	 8b
 12: KEY_MINUS              0c		--->	 8c
 13: KEY_EQUAL              0d		--->	 8d
 14: KEY_BACKSPACE          0e		--->	 8e
 15: KEY_TAB                0f		--->	 8f
 16: KEY_Q                  10		--->	 90
 17: KEY_W                  11		--->	 91
 18: KEY_E                  12		--->	 92
 19: KEY_R                  13		--->	 93
 20: KEY_T                  14		--->	 94
 21: KEY_Y                  15		--->	 95
 22: KEY_U                  16		--->	 96
 23: KEY_I                  17		--->	 97
 24: KEY_O                  18		--->	 98
 25: KEY_P                  19		--->	 99
 26: KEY_LEFTBRACE          1a		--->	 9a
 27: KEY_RIGHTBRACE         1b		--->	 9b
 28: KEY_ENTER              1c		--->	 9c
 29: KEY_LEFTCTRL           1d		--->	 9d
 30: KEY_A                  1e		--->	 9e
 31: KEY_S                  1f		--->	 9f
 32: KEY_D                  20		--->	 a0
 33: KEY_F                  21		--->	 a1
 34: KEY_G                  22		--->	 a2
 35: KEY_H                  23		--->	 a3
 36: KEY_J                  24		--->	 a4
 37: KEY_K                  25		--->	 a5
 38: KEY_L                  26		--->	 a6
 39: KEY_SEMICOLON          27		--->	 a7
 40: KEY_APOSTROPHE         28		--->	 a8
 41: KEY_GRAVE              29		--->	 a9
 42: KEY_LEFTSHIFT          2a		--->	 aa
 43: KEY_BACKSLASH          2b		--->	 ab
 44: KEY_Z                  2c		--->	 ac
 45: KEY_X                  2d		--->	 ad
 46: KEY_C                  2e		--->	 ae
 47: KEY_V                  2f		--->	 af
 48: KEY_B                  30		--->	 b0
 49: KEY_N                  31		--->	 b1
 50: KEY_M                  32		--->	 b2
 51: KEY_COMMA              33		--->	 b3
 52: KEY_DOT                34		--->	 b4
 53: KEY_SLASH              35		--->	 b5
 54: KEY_RIGHTSHIFT         36		--->	 b6
 55: KEY_KPASTERISK         37		--->	 b7
 56: KEY_LEFTALT            38		--->	 b8
 57: KEY_SPACE              39		--->	 b9
 58: KEY_CAPSLOCK           3a		--->	 ba
 59: KEY_F1                 3b		--->	 bb
 60: KEY_F2                 3c		--->	 bc
 61: KEY_F3                 3d		--->	 bd
 62: KEY_F4                 3e		--->	 be
 63: KEY_F5                 3f		--->	 bf
 64: KEY_F6                 40		--->	 c0
 65: KEY_F7                 41		--->	 c1
 66: KEY_F8                 42		--->	 c2
 67: KEY_F9                 43		--->	 c3
 68: KEY_F10                44		--->	 c4
 69: KEY_NUMLOCK            45		--->	 c5
 70: KEY_SCROLLLOCK         46		--->	 c6
 71: KEY_KP7                47		--->	 c7
 72: KEY_KP8                48		--->	 c8
 73: KEY_KP9                49		--->	 c9
 74: KEY_KPMINUS            4a		--->	 ca
 75: KEY_KP4                4b		--->	 cb
 76: KEY_KP5                4c		--->	 cc
 77: KEY_KP6                4d		--->	 cd
 78: KEY_KPPLUS             4e		--->	 ce
 79: KEY_KP1                4f		--->	 cf
 80: KEY_KP2                50		--->	 d0
 81: KEY_KP3                51		--->	 d1
 82: KEY_KP0                52		--->	 d2
 83: KEY_KPDOT              53		--->	 d3
 85: KEY_ZENKAKUHANKAKU     76		--->	 f6
 86: KEY_102ND              56		--->	 d6
 87: KEY_F11                57		--->	 d7
 88: KEY_F12                58		--->	 d8
 89: KEY_RO                 73		--->	 f3
 90: KEY_KATAKANA           78		--->	 f8
 91: KEY_HIRAGANA           77		--->	 f7
 92: KEY_HENKAN             79		--->	 f9
 93: KEY_KATAKANAHIRAGANA   70		--->	 f0
 94: KEY_MUHENKAN           7b		--->	 fb
 95: KEY_KPJPCOMMA          5c		--->	 dc
 96: KEY_KPENTER            e0 1c	--->	 e0 9c
 97: KEY_RIGHTCTRL          e0 1d	--->	 e0 9d
 98: KEY_KPSLASH            e0 35	--->	 e0 b5
 99: KEY_SYSRQ              e0 2a e0 37	--->	 e0 aa e0 b7
100: KEY_RIGHTALT           e0 38	--->	 e0 b8
101: KEY_LINEFEED           5b		--->	 db
102: KEY_HOME               e0 47	--->	 e0 c7
103: KEY_UP                 e0 48	--->	 e0 c8
104: KEY_PAGEUP             e0 49	--->	 e0 c9
105: KEY_LEFT               e0 4b	--->	 e0 cb
106: KEY_RIGHT              e0 4d	--->	 e0 cd
107: KEY_END                e0 4f	--->	 e0 cf
108: KEY_DOWN               e0 50	--->	 e0 d0
109: KEY_PAGEDOWN           e0 51	--->	 e0 d1
110: KEY_INSERT             e0 52	--->	 e0 d2
111: KEY_DELETE             e0 53	--->	 e0 d3
112: KEY_MACRO              e0 6f	--->	 e0 ef
113: KEY_MUTE               e0 20	--->	 e0 a0
114: KEY_VOLUMEDOWN         e0 2e	--->	 e0 ae
115: KEY_VOLUMEUP           e0 30	--->	 e0 b0
116: KEY_POWER              e0 5e	--->	 e0 de
117: KEY_KPEQUAL            59		--->	 d9
118: KEY_KPPLUSMINUS        e0 4e	--->	 e0 ce
119: KEY_PAUSE              e1 1d 45	--->	 e1 9d c5
121: KEY_KPCOMMA            7e		--->	 fe
122: KEY_HANGUEL            f1		--->	
123: KEY_HANJA              f2		--->	
124: KEY_YEN                7d		--->	 fd
125: KEY_LEFTMETA           e0 5b	--->	 e0 db
126: KEY_RIGHTMETA          e0 5c	--->	 e0 dc
127: KEY_COMPOSE            e0 5d	--->	 e0 dd
128: KEY_STOP               e0 68	--->	 e0 e8
129: KEY_AGAIN              e0 05	--->	 e0 85
130: KEY_PROPS              e0 06	--->	 e0 86
131: KEY_UNDO               e0 07	--->	 e0 87
132: KEY_FRONT              e0 0c	--->	 e0 8c
133: KEY_COPY               e0 78	--->	 e0 f8
134: KEY_OPEN               64		--->	 e4
135: KEY_PASTE              65		--->	 e5
136: KEY_FIND               e0 41	--->	 e0 c1
137: KEY_CUT                e0 3c	--->	 e0 bc
138: KEY_HELP               e0 75	--->	 e0 f5
139: KEY_MENU               e0 1e	--->	 e0 9e
140: KEY_CALC               e0 21	--->	 e0 a1
141: KEY_SETUP              66		--->	 e6
142: KEY_SLEEP              e0 5f	--->	 e0 df
143: KEY_WAKEUP             e0 63	--->	 e0 e3
144: KEY_FILE               67		--->	 e7
145: KEY_SENDFILE           68		--->	 e8
146: KEY_DELETEFILE         69		--->	 e9
147: KEY_XFER               e0 13	--->	 e0 93
148: KEY_PROG1              e0 1f	--->	 e0 9f
149: KEY_PROG2              e0 17	--->	 e0 97
150: KEY_WWW                e0 32	--->	 e0 b2
151: KEY_MSDOS              6a		--->	 ea
152: KEY_COFFEE             e0 12	--->	 e0 92
153: KEY_DIRECTION          6b		--->	 eb
154: KEY_CYCLEWINDOWS       e0 26	--->	 e0 a6
155: KEY_MAIL               e0 6c	--->	 e0 ec
156: KEY_BOOKMARKS          e0 66	--->	 e0 e6
157: KEY_COMPUTER           e0 6b	--->	 e0 eb
158: KEY_BACK               e0 6a	--->	 e0 ea
159: KEY_FORWARD            e0 69	--->	 e0 e9
160: KEY_CLOSECD            e0 23	--->	 e0 a3
161: KEY_EJECTCD            6c		--->	 ec
162: KEY_EJECTCLOSECD       e0 7d	--->	 e0 fd
163: KEY_NEXTSONG           e0 19	--->	 e0 99
164: KEY_PLAYPAUSE          e0 22	--->	 e0 a2
165: KEY_PREVIOUSSONG       e0 10	--->	 e0 90
166: KEY_STOPCD             e0 24	--->	 e0 a4
167: KEY_RECORD             e0 31	--->	 e0 b1
168: KEY_REWIND             e0 18	--->	 e0 98
169: KEY_PHONE              63		--->	 e3
170: KEY_ISO                70		--->	 f0
171: KEY_CONFIG             e0 01	--->	 e0 81
172: KEY_HOMEPAGE           e0 02	--->	 e0 82
173: KEY_REFRESH            e0 67	--->	 e0 e7
174: KEY_EXIT               71		--->	 f1
175: KEY_MOVE               72		--->	 f2
176: KEY_EDIT               e0 08	--->	 e0 88
177: KEY_SCROLLUP           75		--->	 f5
178: KEY_SCROLLDOWN         e0 0f	--->	 e0 8f
179: KEY_KPLEFTPAREN        e0 76	--->	 e0 f6
180: KEY_KPRIGHTPAREN       e0 7b	--->	 e0 fb
183: KEY_F13                5d		--->	 dd
184: KEY_F14                5e		--->	 de
185: KEY_F15                5f		--->	 df
186: KEY_F16                55		--->	 d5
187: KEY_F17                e0 03	--->	 e0 83
188: KEY_F18                e0 77	--->	 e0 f7
189: KEY_F19                e0 04	--->	 e0 84
190: KEY_F20                5a		--->	 da
191: KEY_F21                74		--->	 f4
192: KEY_F22                e0 79	--->	 e0 f9
193: KEY_F23                6d		--->	 ed
194: KEY_F24                6f		--->	 ef
200: KEY_PLAYCD             e0 28	--->	 e0 a8
201: KEY_PAUSECD            e0 29	--->	 e0 a9
202: KEY_PROG3              e0 2b	--->	 e0 ab
203: KEY_PROG4              e0 2c	--->	 e0 ac
205: KEY_SUSPEND            e0 25	--->	 e0 a5
206: KEY_CLOSE              e0 2f	--->	 e0 af
207: KEY_PLAY               e0 33	--->	 e0 b3
208: KEY_FASTFORWARD        e0 34	--->	 e0 b4
209: KEY_BASSBOOST          e0 36	--->	 e0 b6
210: KEY_PRINT              e0 39	--->	 e0 b9
211: KEY_HP                 e0 3a	--->	 e0 ba
212: KEY_CAMERA             e0 3b	--->	 e0 bb
213: KEY_SOUND              e0 3d	--->	 e0 bd
214: KEY_QUESTION           e0 3e	--->	 e0 be
215: KEY_EMAIL              e0 3f	--->	 e0 bf
216: KEY_CHAT               e0 40	--->	 e0 c0
217: KEY_SEARCH             e0 65	--->	 e0 e5
218: KEY_CONNECT            e0 42	--->	 e0 c2
219: KEY_FINANCE            e0 43	--->	 e0 c3
220: KEY_SPORT              e0 44	--->	 e0 c4
221: KEY_SHOP               e0 45	--->	 e0 c5
222: KEY_ALTERASE           e0 14	--->	 e0 94
223: KEY_CANCEL             e0 4a	--->	 e0 ca
224: KEY_BRIGHTNESSDOWN     e0 4c	--->	 e0 cc
225: KEY_BRIGHTNESSUP       e0 54	--->	 e0 d4
226: KEY_MEDIA              e0 6d	--->	 e0 ed

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Fw: Re: keyboard problem with 2.6.6

[Dmitry Torokhov]

On Saturday 29 May 2004 08:37 am, Vojtech Pavlik wrote:
> > > One more thought: The emulated PS/2 mouse so many people are complaining
> > > about is there only because applications like X cannot use the native
> > > event interface. It was intended to be removed after that support is
> > > added, but with X development being as slow as it is, it didn't ever
> > > happen.
> > 
> > WRT this, would it be possible to create a GPM driver for the 
> > event interface?
> 
> Yes. Even better, it exists. And I though it's been integrated into GPM
> as well, but I might be wrong on this one.

Unfortunately evdev support in stock GPM is pretty much non-existant. It does
not use EV_SYNC and only works for relative devices. I have set of patches
that I consider proper implementation of user side of evdev interface, but I
am not sure if it is going to be included in GPM proper. For what it worth it
is in Fedora Code 2.

Now if I only had time to finish hotplug support for GPM...

-- 
Dmitry

http://www.geocities.com/dt_or/gpm/gpm.html

Re: Fw: Re: keyboard problem with 2.6.6

[Andries Brouwer]

On Sat, May 29, 2004 at 09:09:53AM +0200, Vojtech Pavlik wrote:

> One more thought: The emulated PS/2 mouse so many people are complaining
> about is there only because applications like X cannot use the native
> event interface. It was intended to be removed after that support is
> added, but with X development being as slow as it is, it didn't ever
> happen.

A mistake.

You add new functionality. That is good. At the same time you want
to force people to use this new stuff by throwing out the old. Bad.

It is almost impossible to remove features from the kernel.
People have a great variety of user space setups, and can have
lots of reasons why it is undesirable or impossible to change
their software, while a new kernel may be required to support
new hardware or for security reasons.

One should always (i) go in a long series of tiny steps,
(ii) attempt to be 100% backwards compatible.
Obsoleting old stuff is done over a period of more than
five years, if at all.

Andries

Re: Fw: Re: keyboard problem with 2.6.6

[Vojtech Pavlik]

On Sat, May 29, 2004 at 04:07:36PM +0200, Andries Brouwer wrote:
> On Sat, May 29, 2004 at 09:09:53AM +0200, Vojtech Pavlik wrote:
> 
> > One more thought: The emulated PS/2 mouse so many people are complaining
> > about is there only because applications like X cannot use the native
> > event interface. It was intended to be removed after that support is
> > added, but with X development being as slow as it is, it didn't ever
> > happen.
> 
> A mistake.

Well, yes. It's just 99% compatible, and it wasn't removed yet. But I
still hope it eventually will.

> You add new functionality. That is good. At the same time you want
> to force people to use this new stuff by throwing out the old. Bad.
> 
> It is almost impossible to remove features from the kernel.

I had hoped with so few programs using it (basically only X), it
shouldn't be so impossible.

> People have a great variety of user space setups, and can have
> lots of reasons why it is undesirable or impossible to change
> their software, while a new kernel may be required to support
> new hardware or for security reasons.
> 
> One should always (i) go in a long series of tiny steps,
> (ii) attempt to be 100% backwards compatible.
> Obsoleting old stuff is done over a period of more than
> five years, if at all.
> 
> Andries
> 

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR