Easy shift / ctrl / AltGr... hack.

[teika]

EDIT (2023-06-29): You may want to switch to "interception", and its plug-in "Dual Function Keys". Fetch their ebuilds from [bug=813843]bug #813843[/bug]. For how to use, see the homepage. Notice they work independent of X. I here thank "hoelbezier" for sumbitting an ebuild of "interception". Without it, I would be left clueless.

Original post
Hi. This hack, at-home-modifier (or ahm for short) 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 positions.

It's a fork of Xorg "evdev" driver (= x11-drivers/xf86-input-evdev). See README for the detail.

* ebuild: xf86-input-evdev-2.11.0-r1.ebuild
* For source .tar.bz2 / git access and so on, visit the homepage.

Installation
The latest release is 2.11.0. (2024-12)
Save the ebuild in your overlay, and emerge as usual. Maybe you want the following lines in your /etc/portage/package.mask to prevent upgrading to the original one:

Code: Select all

# at-home-modifier fork is used. Prevent automatic upgrading from the official portage tree::
x11-drivers/xf86-input-evdev::gentoo

News for 2.11.0
* Merges the upstream 2.11.0, which fixes several bugs.

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.

EDIT (2024-12): Obviously Benjamin Netaniyahu is a new Adolf Hitler. See his inhumane atrocity since 2009.

With best regards.

[NeddySeagoon]

Moved from Desktop Environments to Unsupported Software.


teika,

Gentoo won't support this unless it gets merged upstream. Don't fork the driver yourself.
Pass your patch upstream.

[Satoshi]

I'm also interested in a patch I can easily modify an ebuild to use.

And I wonder how no one ever thought of that! (could complicate gaming, though).

[teika]

> Moved from Desktop Environments to Unsupported Software.
Sorry & thanks.

NeddySeagoon, thank you for your comment. You're right. However...[1]

[1] However, it'll be quite a task to merge it into X. I had a talk a while ago at Xorg ML, and they say my fork can't be merged as long as it's implemented in evdev driver, and they're right. In fact, it should be part of xkb2, which is a long-waited-but-unlikely-to-come-soon part of Xorg server. :/
Anyway it'll be a long way. So my strategy is first make it popular. Then a way to go may appear.

Satoshi, if you like it, please tell it to your friends. I've got little time to advertise it. Thank you for trying. :)

[Satoshi]

teika, a good way to make it popular is to provide us with a patch we can easily apply to the source.

[teika]

Thanks, Satoshi. You're right. It seems I have to be serious on that kind of things as well, in addition to coding.

[Ant P.]

Anything that can make X's keyboard handling suck less is a good thing, and they don't seem particularly interested in improving on their own. (I've been waiting years for it to support all the keys on mine - the kernel sees all the keycodes no problem...)

[teika]

I think all keys are supported. Run xev, and if it emits something when you press those keys, they're. If it's the case, it's simply keysyms are not bound, so you can use xmodmap or configure XKB files under /usr/share/X11/xkb.

X is an old dog, and we're all losers. (All OSes suck more or less. All Linux distros are wading through mud. All life, all government...)

Ok, now the patch against the upstream, xf86-input-evdev-2.5.0 is available, too from the website.

[Ant P.]

X11 does not support keycodes > 255. My keyboard has at least three.

[Satoshi]

Ebuilds, ebuilds, anyone?

(Got little time here to do one on my own right now)

[teika]

Ant_P, you may be able to have a workaround. Evdev driver seems to talk directly with linux input system, and evdev driver doesn't seem to limit it to 255.

First try my patch. It translates one keycode to another. Evdev's keycode is the keycode of linux input + 8. E.g, esc is 9 in X, 1 in linux input. Translate your key > 255 to some supported key.

If it basically works, then look at my patch to make it suit your need. It's short, so if you know C, it'll be easy.

Satoshi, you don't want to use git, right? Then:
1. Get the tarball, and save at <portage-dir>/distfiles/xf86-input-evdev.tar.bz2.
2. $ ebuild <path>/xf86-input-evdev-2.5.0.ebuild digest
3. emerge normally.
It suffices. Of course with an appropriate ebuild it's possible to skip the step1, but I'm busy, too.

[teika]

If you like this hack, please donate >= $1 for tsunami sufferers in Japan. Your local NGOs with good history or UNICEF is a good choice. Search e.g. "unicef <your country name>". Tell it to others when you're done. Please.

[teika]

Hi. Version-2.6.0 is released.

• Upstream xf86-input-evdev-2.6.0 is merged.
• "Double press bug" is fixed. Suppose both key a and b are translated to shift. Press a, b, and release b. Then it should be 'B', but it used to emit lower b. It's because the release of shift was sent before b key press.

You can download the ebuild from
https://gitorious.org/at-home-modifier/ ... 6.0.ebuild. (Sorry, the hosting site adds an annoying suffix "gentoo_" to the filename.) Add it to your overlay, and
$ ebuild <downloaded ebuild file name> digest
$ emerge x11-drivers/xf86-input-evdev
and you're done.

(I want to make the ebuild do "dodoc README*", but I don't know how to do. Please read the ebuild and send me a fix.)

The homepage is http://gitorious.org/at-home-modifier/pages/Home. See the readme for future plan. (I'm still not in good shape, and I can't guarantee it will happen.)

I thank the help to Japan from all over the world. And I'm sorry for our bullshit the government and the electic power supplier for their **** handling of nuclear power plant.

PS If you use it, please give us the feedback. Simply putting "+1" in this forum greatly helps. I've got no clue how many users are there.

[teika]

[This post is outdated. (8 oct)]

Some news:

Fast type fix

“Fast type fix” is attempted in the “fast-type” git branch:
http://gitorious.org/at-home-modifier/pages/Home

Suppose you have space / shift key. If you press the space key, and the next key too fast, you don’t get the desired output. That is, you wanted the sequence “space + a”, but this hack sends “shift + a”.

However, I haven’t succeeded. I've explained the details in README of the branch "fast-type"[1]. I'd be grateful for any help.

[1] http://gitorious.org/at-home-modifier/a ... ype/README


Multiple key press

It’s found that many cheap keyboards fail to report some combinations of key presses. For example, mine doesn’t Alt + Space (used as Ctrl) + down. See README[2] for more.

[2] http://gitorious.org/at-home-modifier/a ... ter/README

[teika]

Hi. Ahm-2.6.2 is released. Many new features, bugfixes, README improvements are done.

* 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.

* "Big keycode support" is introduced in this version, but it's deleted in 2.6.3, since loadkeys (1) command suffices. (Edit: 12 Nov 2011)

* 2.6.1 was never released.

For full changes, read README, "News" section:
http://gitorious.org/at-home-modifier/a ... ter/README

Forum / mailing list
Now there's a forum for this hack:
http://at-home-modifier.2300353.n4.nabble.com/

Please use it for general topics, and use this thread for distro specific things only.
(But I'd be glad if you could add a comment here to make it draw more attention. =)

For download & the details, visit the homepage: http://gitorious.org/at-home-modifier/pages/Home As usual, ebuild is provided there.

With best regards.

[teika]

Hi. at-home-modifier-2.6.3 is released. It's a bugfix release. Changes are:

* 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.=)

* Reset and Delayed key
“Delay” and “Reset” are features introduced in 2.6.2. If a delayed key is pressed after a long enough period is passed (i.e. a reset is done), the press was ignored. It’s fixed now.

* “Big keycode support” introduced in the previous release is deleted, since xloadkeys (1) command suffices.

For full changes, read README, "News" section:
http://gitorious.org/at-home-modifier/a ... ter/README

# By the way, I've never received any feedback. Please give me a short word of "Hi, I like this hack, please keep going on!" or so. I feel lonely. ;)

With best regards.

Ebuild: https://gitorious.org/at-home-modifier/ ... 6.3.ebuild (Sorry for annoying prefix in filename.)
Homepage: https://gitorious.org/at-home-modifier/pages/Home

[tclover]

yes, I wanted to leave my hands at [home] ease for while now and I noticed this thread a while back but was busy with other stuff. I've just merged your package today with a custom/modified ebuild posted here which uses xorg tarball and your patch.

[teika]

Hi. I've updated the ebuilds so that README is installed under /usr/share/doc, as it should be.

@tclover
Thanks. I've suspected that my versioning scheme be wrong, but I'm not sure of the correct way. Ebuild howto and "man 5 ebuild" say suffixes are limited to _alpha, _p, -r, etc. If _ahm were allowed, I might use it. Using a seperate package name, like xf86-input-evdev-ahm, may be better, but you have to delete "evdev" from INPUT_DEVICES in make.conf. Hmm...

[obsolete hereafter]
In your ebuild, I had to replace "https" to "http" in the SRC_URI to make a digest. Without it, it'll produce an error:

Connecting to gitorious.org|87.238.52.168|:443... connected.
ERROR: certificate common name `*.gitorious.org' doesn't match requested host name `gitorious.org'.
To connect to gitorious.org insecurely, use `--no-check-certificate'.
!!! Couldn't download 'ahm-2.6.3.patch'. Aborting.
!!! Fetch failed for ahm-2.6.3.patch, can't update Manifest

[tclover]

You could have used my Manifest if you did not need any/more changes aside from that. I've just thought that as those who will try your hack have probably xorg driver, it's sane to just make an ebuild with your provided patch. So I went ahead and make one.

No idea about that error, just a habit to put https instead of plain http. Your certificate package is up to date?

[teika]

The latest (testing) app-misc/ca-certificates doesn't help.

[tclover]

Is it possible to implement something like a time out which will make SPACE behave like a normal continuous SPACE press? Well, I'm used to hold SPACE when aligning some piece of codes/comments and it's really annoying to get nothing in that case and be forced to press/release SPACE for a dozen, a dozen and half, two dozen... of spaces to align some text.

Thanks!

[teika]

Yes, it IS possible, and I've thought of it before, too. (Fortunately the last release makes use of timers, so it's feasible, though a challenge.)

But I wonder what's the good way. Simple timeout can be annoying for some. For example I use ctrl (= space for me) so often in Emacs, and I often press ctrl, and stop there, thinking. If it turns to spaces too soon, it'll irritate. But if the timeout is too long, it's useless. So this method is not the best for me.

An alternative is to press space/modifier twice in row; if the second press lasts long enough, then make it as a normal space press. this implementation may be better, but if what I want is a space and ctrl+something, it's the same as the first one. Hmm...

Ok, wait a bit (= a month or so). Maybe I'll implement both. Thanks for your idea. Discussion is always welcome.

# BTW I recommend a macro or something in your editor for such formatting. Better use of editors improves your life. =)

[tclover]

# BTW I recommend a macro or something in your editor for such formatting. Better use of editors improves your life. =)

Very true. The thing is, with vim it does align codes/comments quite well but only for the third lines or so. Suppose, I write something like:

Code: Select all

#[first alignment]      * some sub title:     [second alignment] some text

so yes, the second line of text will have to be manually aligned and vim will take care of the rest. And that second alignment could be two dozen of spaces with a few tabs or something.

[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 ebuilds, read the [post=6584193]the first message in the thread[/post]

Support for autorepeat will require further deviation from the Xorg's original code, so I think it's better to make a release before autorepeat inclusion. Wait a bit. (TM)

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>

[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.