Messages in this thread | | | From | Giuseppe Bilotta <> | Subject | Re: Fw: Re: keyboard problem with 2.6.6 | Date | Sun, 30 May 2004 14:38:08 +0200 |
| |
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)
- 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/
| |