keyboard problem with 2.6.6
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Andrew Morton
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.
Quoted 1 line
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.
Quoted 45 lines
Begin forwarded message:
Date: Fri, 28 May 2004 15:33:21 +0200
From: Giuseppe Bilotta <[email protected]>
To: [email protected]
Subject: Re: keyboard problem with 2.6.6Quoted 6 lines · Sau Dan Lee
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?)
Signature · 13 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 8 lines · Vojtech Pavlik
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.
Quoted 18 lines
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.
Quoted 5 lines
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?
Signature · 7 lines
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)Quoted 8 lines · Giuseppe Bilotta
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.
Quoted 8 lines
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.
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 4 lines
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.
Quoted 2 lines
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
Quoted 2 lines
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).
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 16 lines · Vojtech Pavlik
Quoted 8 lines · Giuseppe Bilotta
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.
Quoted 7 lines
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.
Quoted 4 lines
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?'
Quoted 2 lines
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.
Quoted 10 lines
Quoted 6 lines
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?
Quoted 5 lines
Quoted 2 lines
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.
Quoted 10 lines
Quoted 4 lines
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.
Quoted 2 lines
stream, which IIRC should work even with X, since X can read the gpm socket ...
Quoted 7 lines
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?)
Quoted 5 lines
Quoted 2 lines
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.
Signature · 7 lines
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)Quoted 8 lines · Giuseppe Bilotta
Quoted 3 lines
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.
Quoted 10 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 1 line
2. the applications still don't comply with it
Unfortunately, yes.
Quoted 3 lines
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.
Quoted 11 lines
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. ;)
Quoted 30 lines
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?Quoted 5 lines
Quoted 2 lines
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.
Quoted 13 lines
Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
It's then
kernel ---- gpm
`--- X -- appAny 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.
Quoted 4 lines
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.
Quoted 7 lines
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.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 7 lines · Vojtech Pavlik
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.
Signature · 1 line
Dmitry
Quoted 11 lines · Dmitry Torokhov
Quoted 7 lines
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. ;)
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
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.
Quoted 6 lines · Vojtech Pavlik
Quoted 5 lines · Giuseppe Bilotta
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]
Quoted 2 lines
The support is present in the kernel. You can use setkeycode to load that table. Only X won't use it.
[snip]
Quoted 4 lines
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.
Quoted 9 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 9 lines
Quoted 5 lines
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?
Quoted 9 lines
Quoted 3 lines
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 :)
Quoted 7 lines
Quoted 3 lines
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 :)
Signature · 7 lines
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)Quoted 11 lines · Giuseppe Bilotta
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.
Quoted 8 lines
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.
Quoted 3 lines
* 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.
Quoted 3 lines
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.
Quoted 8 lines
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.cdirectly to have it work with my keyboard.
It was written for 2.4 unfortunately, and 2.6's emulated rawmode confuses it no end.
Quoted 4 lines
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.
Quoted 11 lines
Quoted 9 lines
Quoted 3 lines
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.
Quoted 5 lines
Quoted 3 lines
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 :)
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 11 lines · Vojtech Pavlik
Quoted 6 lines · Giuseppe Bilotta
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.
Quoted 11 lines
The event interface of course doesn't have this limitation.
Quoted 8 lines
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.)
Quoted 8 lines
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.
Quoted 6 lines
Quoted 3 lines
* 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.hhas 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 :)
Quoted 11 lines
Quoted 8 lines
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.cdirectly 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.
Quoted 2 lines
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.
Signature · 7 lines
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)Quoted 11 lines · Giuseppe Bilotta
Quoted 8 lines
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.
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
* 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.hhas the documented set of keycodes. It's largely based on what 2.4 uses for keycodes - sanitized PS/2 codes.
Quoted 6 lines
Ah good. I was looking at the wrong headers :)
Quoted 2 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 11 lines · Vojtech Pavlik
Quoted 9 lines · Giuseppe Bilotta
Quoted 8 lines
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.
Quoted 5 lines
Quoted 2 lines
Sorry but this is untrue. My Win keys are configured as super, for example.
The Linux kernel reports them as
KEY_LEFTMETA,KEY_RIGHTMETAandKEY_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 ] };
};Quoted 10 lines
Quoted 5 lines
Quoted 2 lines
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.
Signature · 7 lines
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)Quoted 20 lines · Giuseppe Bilotta
Quoted 2 lines
The Linux kernel reports them as
KEY_LEFTMETA,KEY_RIGHTMETAandKEY_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 }; };
Quoted 7 lines
// 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.
Quoted 5 lines
Quoted 4 lines
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.
Quoted 8 lines
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.
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 7 lines · Vojtech Pavlik
Quoted 5 lines · Giuseppe Bilotta
Quoted 2 lines
The Linux kernel reports them as
KEY_LEFTMETA,KEY_RIGHTMETAandKEY_COMPOSE.In X standard keyboards Meta is mapped as the second symbol for Alt.
[snip]
Quoted 2 lines
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.
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 5 lines
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.
Signature · 7 lines
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)Quoted 8 lines · Giuseppe Bilotta
Quoted 2 lines
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
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 25 lines · Vojtech Pavlik
Quoted 8 lines · Giuseppe Bilotta
Quoted 2 lines
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>
Quoted 8 lines
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_SHIFT9
Point fully taken. I retreat in a corner with a big 'A' cone cap on my head.
Signature · 7 lines
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
In reply to Giuseppe BilottaQuoted 5 lines · Giuseppe Bilotta
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
Quoted 11 lines · Andries Brouwer
Quoted 5 lines · Giuseppe Bilotta
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 ...
Signature · 7 lines
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)Quoted 14 lines · Giuseppe Bilotta
Quoted 14 lines
Quoted 13 lines
Quoted 4 lines
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.
Quoted 3 lines
Quoted 1 line
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
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR
Quoted 11 lines · Vojtech Pavlik
Quoted 8 lines
Quoted 5 lines
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...
Signature · 3 lines
Dmitry http://www.geocities.com/dt_or/gpm/gpm.html
Quoted 5 lines · Vojtech Pavlik
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
Quoted 9 lines · Andries Brouwer
Quoted 5 lines · Vojtech Pavlik
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.
Quoted 4 lines
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.
Quoted 12 lines
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
Signature · 2 lines
Vojtech Pavlik SuSE Labs, SuSE CR