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) _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: [email protected]
