An evdev feature proposal; shift/space dual role key

[Peter Hutterer]

> On Tue, 21 Dec 2010 14:43:36 +0900 (JST), Teika Kazura <teika at lavabit.com> wrote:
> 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.

it'd be better to fix the shortcuts in the application than to put hacks
in the driver to mess with keyboards.

> This feature is completely optional, so it never harms.  

[citation needed]

the code is there. if no-one uses it, it shouldn't be there. if someone
uses it, it needs debugging, maintainer time, integration with other
features, etc.

this patch introduces no less than 7 options for modifier handling (from
StickyShift to OneShotAlt), in what is essentially a reimplementation of
xkb functionality (or functionality that should be in xkb). which means
we have configuration in the xorg.conf for some keyboard features and
elsewhere for other features, and will over time end up re-implementing
xkb in the driver, albeit without a client-side protocol to actually use
this (no, properties are not a good configuation UI here). IMO, this
will go nowhere but be a random headache generator.

Cheers,
  Peter


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