Re: problem with softraw and keycodes > 128

[Hans de Goede <j.w.r.degoede@hhs.nl>]

Vojtech Pavlik wrote:
> On Thu, Jun 07, 2007 at 10:21:33AM +0200, Hans de Goede wrote:
>
> Hans,
>
> > I've been experimenting with getting the internetkeys on several
> > keyboards to work. My biggest problem with this currently is the
> > following:
>
> > Step 1: press key, dmesg says:
> > 	atkbd.c: Unknown key released (translated set 2, code 0xa3 on  isa0060/serio0).
> > 	atkbd.c: Use 'setkeycodes e023 <keycode>' to make it known.
> > Step 2: map key: setkeycodes e023 163
> > Step 3: run xev, press key. X-keycode is: 153 instead of 163 ?
>
>
> > Doing:
> > 	echo -n 0 >/sys/devices/platform/i8042/serio1/softraw
> > However does make them identical.
>
> this is a well known problem. It's not easy to explain and next to
> impossible to fix within the scope of operation of your test case -
> otherwsie it'd be fixed ages ago.
>
> The explanation why this happen will be a little longer, and will follow
> the life of a keystroke as it passes through the different layers.
>
> 	1. First, the user presses a key. Since we're talking a 102-key
> 	PS/2-type keyboard here, the keyboard scans its matrix and figures out
> 	the position of the key. Then, since the connection to the PC is running
> 	in AT mode, it translates the key to a string (one to eight bytes) of
> 	AT-compatible scancodes.
>
> 	2. The i8042 in the computer receives the scancodes, translates them to
> 	XT-compatible scancodes and makes them available to the OS.
>
> 	3. In OS the i8042.c gets the scancodes and forwards them to atkbd.c
>
> 	4. atkbd.c decodes the string of scancodes and turns them into a single
> 	Linux input event, and forwards it to the input core.
>
> 	5. The Linux input core dispatches the events to char/keyboard.c.
>
> 	6. keyboard.c, a part of the VT driver, sees that X told the VT that it
> 	wants the "raw mode", which means that the VT should give the keystrokes
> 	as the original string of XT scancodes. Hence (when softraw is 1), it
> 	consults a table and synthesizes what it thinks the original string of
> 	bytes could have been and gives that to X. For all keys that atkbd.c
> 	knows by default, this string is IDENTICAL to what atkbd.c has received.
>
> 	7. X takes the string, and using an algorithm similar to, but DIFFERENT
> 	from the algoithm that atkbd.c uses, it converts them to an X scancode.
> 	The X scancodes are similar to, but different from the Linux event
> 	keycodes, for historical reasons going back to the 90's.
>
> 	8. Using an xmodmap table compiled from xkb sources, X converts the X
> 	scancode to an X keysym.
>
> In the softraw == 0 case, the original string of XT scancodes is passed
> all along the path to X, so that X really gets what the keyboard sent.
>
> Since the table mapping Linux event keycodes to the synthesized XT
> scancodes in step 6. is constant and shared for all (even USB and other)
> keyboards, this means that the Linux kernel always presents a virtual
> "Linux keyboard" to X.
>
> The "Linux keyboard" always sends the same scancodes for keys with the
> same meaning, regardless of what the real hardware does.

But doesn't it only know the meaning after doing a setkeycodes for easy-access 
keys? I find it somewhat counter inituitive that doing "setkeycodes e023 163" 
will give me a keycode 163 on the console (as reported by showkeys), but will 
send a scancode of 153 to the X-server.

> And this is why X sees a different code in softraw==1 mode than in
> softraw==0 mode: In the first it gets the virtual "Linux keyboard", in
> the other it gets access to the real hardware.
>
> > Problem, as the xkb files for these keyboards expect the X-keycode to
> > be 163, as just it is under the console. Now I know that X-keycodes !=
> > console-keycodes, for example the A key is 30 on the console and 38 in
> > X, but in the case of this special keys, both the xkb files for these
> > internet keyboards (written by suse) and config files for special
> > daemons like lineak, expect them to be identical.
>
> This is wrong. Someone simply needs to write a xkb/lineak description
> for the "Linux keyboard", and then all these problems will go away.

Well to be honest I'm looking for a somewhat more quick fix then that. Let me 
try to explain. Xorg comes with keyboard descriptions for many special-access 
keys having keyboards. These descriptions can be easily selected by the end 
user from the kde / gnome keyboard properties applets.

This however only works with softraw=0 for 2 reasons:
1) without softraw=0 the key presses never reach the server when there hasn't
   been an setkeycodes command for the easy access key
2) even if a setkeycodes command was given, then the keycode given to
   setkeycodes doesn't match the scancode seen by xorg, messing things up.
   (unless one uses setkeycodes with a reverse mapping of the mapping done in
    the kernel)

There are 3 ways out of this:
1) write special loadkey maps for all the easy access keyboards, since unlike X
   loadkeys AFAIK doesn't support inheriting keys from a global layout, the
   number of language-layout <-> keyboard model variants would become quite
   frightening.

   When loadkeys has been thought to map the special keys according to the
   linuxkeyboard codes, then X needs to be tought how to handle a linux
   keyboard and default to this

   Also configuration utils need to be written to properly set things up for
   loadkeys, as autodetecting this is impossible

2) Somehow fix things so that selecting the right model in gnome/kde
   keyboard-preferences will make the keys work. Like it does now with
   softraw=0. Which leads me to asking what are the downsides of using
   softraw=0?
   What about be default defining keycodes for all the 128+ scancodes not yet
   defined, and defining these in such a way that the actual scancodes is what
   gets send to X?
   Or maybe it would be an option to send the raw scancode just like is done
   with softraw=0 when there is no mapping (instead of ignoring the key as is
   done now).

   Since the xkb discriptions for most of the easy access keyboards have been
   written by Suse, I assume the tested them and it works for them. Does anyone
   know how suse does this?

3) Forget about all this and leave things as is, this one clearly does not have
   my preference.

Regards,

Hans

-
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/