Easy shift / ctrl / AltGr / etc hack on xf86-input-evdev

[teika]

Hi. This hack provides for example "space/shift 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. Any pairs of keys are possible. This means your hands stay almost always at their home postion. Now I can't type comfortably without it.

It's a fork of Xorg "evdev" driver (= xf86-input-evdev, or in debian/ubuntu xserver-xorg-input-evdev).

* Readme tells the detail.
* homepage. You can get the source tarball and git access instruction.

FAQ
Q: Can I input Shift+Space if my Space is Space/Shift dual-role key?
A: Turn both of your Space and Shift into Space/Shift keys.

News for 2.8.0 (Jun 2013)
Merges the upstream 2.8.0, and has no changes in ahm itself since 2.7.3. For full changes, read README, "News" section:

Installation
I'm not a debian-ish distro user! Fortunately, there's an Ubuntu PPA for this hack contributed by Yuri Khan. (Thanks!) I don't give general instruction and caution on PPA here. Use it at your own risk, but the source package may be nice; at least looking into debian/ directory will help.

Alternatives
* xcape. See the homepage for how to compile. It's a userland software, so you don't have to catch up the upgrade of xf86-input-evdev.
* Obsolete alternatives are Space2Ctrl in C++ and keydouble in C, which is a fork of Space2Ctrl.

Notice
Probably I don't develop any more this hack as a fork of xf86-input-evdev. It's better to do all in user space, rather than as an X driver.

If you want some progress, improve xcape. I'm also interested in a rewrite in Python, which will be easier to allow flexible configuration. It'd be great if it'd be integrated into AutoKey, but its development seems to have stopped.

With best regards.

[teika]

Hi. at-home-modifier-2.6.3 is released. Changes since the last post (2.6.0) are:

* Fast type fix
Users of this hack often have “tongue-twister of finger”: Suppose you want “ x”. If you press space/shift, press x, and release space/shift (before releasing x), you’ll get an upper-case X instead.
Fixes of this kind are attempted with new “AhmDelay” and “AhmFreezeTT” options.

* Cancellation by timeout
Suppose you were about to input shift + A and pressed space/shift, but you changed your mind. If you release the space/shift key, you’ll receive one space, but it’s not what you want!
This can be fixed by long enough press now.

* Reset
When something is wrong, leave the keyboard untouched for 10 secs. Then all are reset to the initial state.

* Gtk widget double press issue.
To push a gtk button, sometimes you had to press space/shift key twice, but this is fixed. If it doesn’t work out-of-box, set “AhmPaddingInterval” option. (This “bug” is not the author’s fault, but what’s bad for users are bugs.=)

For full changes, read README, "News" section:
http://gitorious.org/at-home-modifie.../master/README

With best regards.

Homepage: http://gitorious.org/at-home-modifier/pages/Home

[teika]

I've added installation instruction. See the first post.

[kindahero]

this sounds cooool.. will say after using for few days.

[teika]

Hi. at-home-modifier-2.6.4 is released. It has one minor fix, "mouse support":
When you press space/shift and a mouse button, the result used to be shift + click, ok, but also followed by an extra, unwanted space, as if the click hadn't happened. It's because each device ignored others. Now it's fixed, as long as the mouse is also handled by evdev driver. (Notebook touchpads are dealt by synaptics driver, so it's not fixed, and won't be fixed. Use AhmTimeout option as a workaround.)

For building, read the first message in the debian thread.

@kindahero:
Thank you for checking. Good luck!

If you find the news or README difficult to understand, then feel free to ask.
<quote>"What's inconvenient is a bug." - Teika kazura</unquote>

[Yuri Khan]

I have built xserver-xorg-input-evdev with your patch and posted it in my PPA: ppa:yurivkhan/ahm. Had to resolve a merge conflict with an Ubuntu-specific patch but had no problem otherwise.

The concept is quite nice. I mapped my home row to [Hyper Super Alt Ctrl | Ctrl Alt Super Hyper] and bound some compiz actions to Super- and Hyper- combinations. It works as expected, though I seem to suffer from a variation of “finger tongue-twister” that AhmDelay does not fix — maybe I’m releasing the second key a little bit earlier than the first one, which then counts as a modifier.

It would be good to have run-time configurability e.g. via xinput set-prop. After all, such tweaks ought to be per-user only. As of now, I have them configured per-device.

I would also like to point you to a similar work by Michal Maruska, he seems to put some thought into deciding when to autorepeat a held key in cases when it is also a transmod, and into rollover detection (basically what you call “tongue-twisters”).

[teika]

Spasibo, Yurocheka, znaesh... No, I don't speak Russian. ;)

On xinput: it'd be nice if it were possible to use xinput, but it seems no. If you do:
$ xinput list-props <keyboard id>
it doesn't show any keyboard options, including those of non-ahm. I know on-the-fly setting of options is great, but it may need socket or something that I don't know at all.

I haven't studied notes by Michal Maruska yet. It looks well written, but I'm afraid any theories may fail, and it could only be solved by experiences. Perhaps autorepeat is not so much involved, and "tongue-twister" is the sole issue. Possibly should I write a key logger? (It has to be good enough, and also a good way to analyze the log is required. I'm not good at both.)

# Michal always go ahead of me. He's written a huge fork of Sawifsh WM.

One Gentoo user requested autorepeat, too. I've made a pointer:
http://at-home-modifier.2300353.n4.n...6p4294256.html

Thanks for helpful comments. I'm a bit busy now. :P

[Yuri Khan]

Spasibo, Yurocheka, znaesh... No, I don't speak Russian.

That’s very clear. The Japanese equivalent of using the diminutive name form would be addressing a total stranger as ちゃん. No offense though.

On xinput: it'd be nice if it were possible to use xinput, but it seems no. If you do:
$ xinput list-props <keyboard id>
it doesn't show any keyboard options, including those of non-ahm. I know on-the-fly setting of options is great, but it may need socket or something that I don't know at all.

Of course properties do not work “out of the box” for all xorg.conf settings. It will need some coding before it will work.

Other evdev keyboard-related settings are actually xkb options, and can be set via setxkbmap and/or xkbcomp. I don’t think that way is appropriate for ahm options though.

I haven't studied notes by Michal Maruska yet. It looks well written, but I'm afraid any theories may fail, and it could only be solved by experiences.

He seems to have an evdev fork of his own, though I was unable to get it to work on my machine.

Perhaps autorepeat is not so much involved, and "tongue-twister" is the sole issue.

Actually yes. Key rollovers seem to be essential for touch typing; autorepeat is only meaningful for the space and cursor movement keys. (Though you do use Space/shift as the motivating example.)

Possibly should I write a key logger? (It has to be good enough, and also a good way to analyze the log is required. I'm not good at both.)

That’s one of the few cases where a keylogger is a good thing
I’d suggest writing the log as lines of tab- or comma-separated keycodes and timestamps, and some elementary analysis can then be done in {Open|Libre}Office.

[teika]

I've found an alternative, Space2Ctrl, by Victor Moreira.

* s2c works in the user space, while ahm (=at-home-modifier) is the fork of an X input driver.
* s2c uses "X Record Extension" to detect events. I haven't given a try yet, but it probably stands between the X server and clients (or Xlib).
*** This (probably) means it can't coexist with other softwares which use Record Extension, e.g. AutoKey or xnee.
* s2c doesn't require much updates; ahm has to keep up with the upstream (= X).
* s2c is written in C++. (I don't understand C++. :P)
* The s2c code is slim; it's easier for users to hack.
*** Ahm is a fork, so the distinction of the genuine ahm part and the original X code is not clear.
* s2c is rudimentary. The sole keycode pair is hard-coded, and has no option. According to the author (in private correspondence), "more of a personal hack, very poorly tested and documented."

Read the git commit log to know the author's email address. He said he'd like more users, so sending patches may be welcome.

News: Ahm development hasn't seen any progress after the 2.6.4 release.

[teika]

An implementation in C, "keydouble" is developed by "baskerville" aka "bloom" in the ArchLinux forum. See the web site hosted at github. You may find the news at the Arch forum thread.