An evdev feature proposal; shift/space dual role key

[Teika Kazura]

Hi. I propose a new feature of evdev driver.

* Overview
It enables for example a "shift/space dual role key." When you
press the space key alone, it's a space; but when you press it with
another key, it's a shift.

More precisely, you specify pairs of two keycodes, the "original", and
the "translated". The evdev driver records the last event in this patch.
After the press of one "original" key, the driver instead reports the
tranlated key press event. When an original key is released, it sends
the release of the tranlated key. And it sends the press and release
of the original key if necessary, judging from the last event.

The impact is tremendous, especially for those who avoid mouse, or say
Emacs users. For example, you can use "f" and "j" as shifts, "d" &
"k" ctrl, etc. Then you can press modifiers with fingers, without
moving your hand.

This feature is completely optional, so it never harms.  It is not
possible solely with xkb, so it's new. It doesn't collide with xkb
either; It's up to users which keysym is assigned to each keycode.

* Details
This proposal extends a patch on a blog.[1]

[1] 
The blog page (in Japanese):
http://d.hatena.ne.jp/jeneshicc/20100306/1267843799
The patch for evdev 2.5.0:
http://dl.dropbox.com/u/662567/xf86-input-evdev-2.5.0-mad-key.patch

Unfortunately the patch is not of the quality to be adopted
immediately to the evdev driver, with hardcoded keycode, too
complicated implementation, etc.

Essentially it works, but the current patch does not check other
devices. For example if you want "shift + left click", the patch
fails, producing an unwanted event of space key. I don't know if such
support is easy. If it complicates, perhaps we may simply drop it. The
precise explanation takes only a couple of lines, so users will
easily understand its limitation.

It's partially possible to achieve this with grabbing, but X grab is not
reliable enough, e.g. no race condition guarantee.

What do you think? Because it's difficult to change xkb, it should be
done in input drivers. Or is it better to push this idea to the kernel
developers? (I don't know where to propose.)

If it's done in the evdev driver, I'm not a good programmer for this,
and I don't understand some points in the patch. I may be able to send
a rewritement, but I think X experts can do it easily and far better
(and faster) than me. I don't know anything about kernel input.

* Backgrounds
This kind of thing seems possible in Mac and Windows. What was
proposed origially was called "SandS" - stands for "Space and Shift" -
which dates back to year 2001.[2][3]

Then in 2008 one person implemented it for X keyboard driver[4]. The
above patch is a port to evdev driver.

[2] (Japanese) http://hp.vector.co.jp/authors/VA002116/sands/ 
[3] Currently the name "SandS" is very bad, because you can't search
it. Poor google doesn't distinguish upper and lower cases.
[4] (Japanese)
http://dev.ariel-networks.com/Members/matsuyama/keyboard-customize

* Patch code explanation

Three kinds of options are offered. One is called "PseudoModSpace"
that is introduced in this email.

"OneShotModifier" tries to do it in the opposite way. (The patch
assumes the physical space key is bound to space keysym. ) In the
above language, "original" and "translated" are reversed. With xkb, 
one of them suffices. Though its code is simpler than
"PseudoModSpace", it's more common to give modifier power to plain
keys.

"StickyShift" makes the shift key behave as toggle type. This is
possible with xkb, so it's not necessary.

These options are remembered with a list, but a table which associates
"original" to "translated" will be enough. The list is not freed
anywhere.

Original keycodes are specified by those in linux/input.h, but the
translated keycodes, which are user options, seem to correspond to
numbers in xkb/keycodes/evdev. I don't know why.

Generalization to any keys is my idea.

With best regards,
Teika (Teika kazura)