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)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/