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

Salkay · 2017-01-15 04:15:45

Ah okay. I actually already had that in my xorg.conf, as per the recommendations in the README linked in the first post of this thread. Anyway, glad you got it sorted!

teika · 2017-01-17 08:23:41

Hi, I'm Teika. Thank you for a valuable report.

Accroding to "Libinput" page of Gentoo Wiki, libinput is to replace the "evdev" and "synaptics" drivers. And from xorg-server-1.19 on, libinput is threaded. See this phoronix post and Peter Hutterer's blog post. (PH is the main developer of X's input driver.)

That does not mean libinput is the Xorg's default input driver, but it's Arch's decision. (The threaded libinput seems still experimental.) For Fedora, it already happened in 2015.

Currently at-home-modifier nor xcape do not run under Wayland. Emergence of libinput means porting ahm to libinput may suffice for both X and Wayland, but it's not easy. :P

Best regards.

acegallagher · 2018-02-08 11:31:57

I'm also on a search for this, since moving to Wayland is inevitable. I need a space2ctrl type replacement. There's been another discussion I've seen that covers this here:

https://github.com/swaywm/sway/issues/719

Which led me to software written by an Arch user here:

https://gitlab.com/interception/linux/tools

The hard part is done and I think the only thing left to do is to write an interface of some sort to his extensions? Either an extension that is customizable easily via GUI or a better way than needing to write your own code for your usecase similar to xmodmap?

I've opened a ticket here:

https://gitlab.com/interception/linux/tools/issues/8

Last edited by acegallagher (2018-02-08 11:36:09)

teika · 2018-03-01 12:55:00

Thanks a lot. (Sorry, still dunno what Wayland is at all, though it's already y 2018. ;-)

The upstream development of the evdev input driver seems to have almost stopped. It does not mean it's unusable. Keyboard is a mature device, so I think my hack remains to work for a coming few years. Of course earlier transition to the libinput driver makes the life less risky.

# BTW the "Wayland" article in the Debian wiki says the Arch wiki page is "as usual, excellent resource" Yeah, as a Gentoo user, I should say the Arch community is nice.)

Regards

Salkay · 2020-03-07 00:01:30

Hi teika, hope you are well.

I've noticed recently that AhmTimeout doesn't seem to work any more. That is, I hold my key, wait >10 seconds then release, but the keystroke is still sent. I previously had Option "AhmTimeout" "400" commented out in /etc/X11/xorg.conf.d/11-TECK-keymap.conf, which I understand should default to 600 ms anyway. Just in case, I removed the comment # and made this declaration explicit, but the timeout still didn't work.

I also tried reverting some other related packages, specifically

libevdev 1.9.0-1 -> 1.6.0-1 (i.e. how it was before 2019-06-10)
mtdev 1.1.5-1 -> 1.1.6-1 (i.e. how it was before 2018-06-05)

Neither made any difference. Presumably it's a related regression in some other package?

teika · 2020-03-07 01:14:27

In fact, it was just a few days ago that I noticed this, too. :) Wait for a while. Ha-ha.

I know the specs of TimeoutHandler and BlockHandler have changed. (If you know git, do "git show bb8bde7456def418".) I tried a fix, but it doesn't work.

Thank you very much, again this time, for your feedback. Yep, ahm is very convenient, and we can't live without it!

Last edited by teika (2020-03-07 01:14:49)

Salkay · 2020-03-07 04:57:36

Thanks again teika! I appreciate the support!

Yes, I definitely can't live without this. With my current TECK keyboard, this AHM is essential. I was even looking up other keyboards after I realised AHM was slightly broken! Thanks again!

teika · 2020-03-11 08:02:26

'Kay I finally got it. Seems like it's not my driver, but the kernel (since 5.5?) has changed.

I'll release a bumped version, but you can use the following patch: (@Salkay: You want it ASAP, right? :])

diff --git a/src/evdev.c b/src/evdev.c
index 650be6b..d53cef3 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -323,8 +323,14 @@ static int ahmTimedOutP(long int lastSec, long int lastUsec, struct input_event
     return 0;
   }
 
-  if( (ev->time.tv_sec - lastSec) * 1000
-      + (ev->time.tv_usec - lastUsec) / 1000
+  /* Seems like in newer kernels (>= 5.5), the timestamp of a key release
+     is that of the press event */
+
+  struct timeval tv;
+  gettimeofday(&tv, NULL);
+
+  if( (tv.tv_sec - lastSec) * 1000
+      + (tv.tv_usec - lastUsec) / 1000
       > timeOut){
     return 1;
   }else{

Ah but *of course* it's your duty to report it if this patch is wrong. ;-)

Best regards

EDIT: I'll fix the following warning soon:
---
warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
329 | struct timeval tv;

Last edited by teika (2020-03-11 08:05:23)

Salkay · 2020-03-11 09:42:57

Brilliant! Yes, this fixes it for me too. I've updated the AUR package with the two patches for now, but I'll update it again whenever you are ready. Thank you again for sorting this out so quickly!

teika · 2020-03-11 13:10:43

Updated AUR? Heck, you're devilishly fast!! Oh I love the arch community again. (But I remain a Gentoo user. Don't blaymee.)

Salkay · 2020-03-11 21:04:55

Haha thanks! It didn't take too long, and I had to do it for myself anyway, so I figured I might as well upload the package. Thanks again for the fast update though!

teika · 2020-03-12 22:15:10

Can anyone confirm this? The former code is ok with kernels <= 5.3, but not with >= 5.4. (If so, it started to annoy me back in last December, but I realized it finally a week ago!!)

I can't spot the change in the kernel that caused this problem. Though it's not necessary, and simply documentation-maniac...

Salkay · 2020-03-14 05:27:36

I can confirm the version numbers. linux-5.4.arch1-1 is broken, but linux-5.3.13.1-1 was fine.

teika · 2020-03-24 01:07:42

I here release ahm-2.10.6, which is essentially the same as the latest AUR. (2.10.6-2, but *not* 2.10.6-1) If you already use it, you don't have to update.

Suggested PKGBUILD change:
* This single patch suffices.

This version now includes a sample xorg.conf.d file. Most readers must already have their own one; it's for newcomers.

@Salkay:
Thanks for your last reply. I was able to find the kernel commit that triggered this change, which was between 5.3 and 5.4. I filed a bug report.

Life and the world is full of diffculty, agony, and hardship. But that has always been so.
All the best.

EDIT:
ahm-2.10.6 provides a workaround for the kernel bug 206929, which was fixed in the kernels 5.6, 5.5.14 and 5.4.29.

Last edited by teika (2020-04-04 07:26:00)

Salkay · 2020-03-24 10:36:25

Thanks @teika. Do you have a suggestion on where to place the example file and the README in the Linux filesystem? I actually just realised that these weren't packaged previously. In /usr/share/xf86-input-evdev-ahm perhaps? I'm not sure if there is a standard place for these files.

Also, with our new "work from home" regime, I'm more frequently sharing a computer now with alt-ctrl-2. I've noticed that sometimes the alt or ctrl key will act as if it's held down permanently. My understanding is that the following line in xorg.conf is relevant.

# Option "AhmResetTime" "10"

So if this is commented, by default I'd just need to wait 10 seconds for it to reset, right? However, this doesn't seem to work. I end up having to crawl under the table and pull out and reset the USB cord! ? Do I understand this correctly?

teika · 2020-03-24 13:23:31

For now let me answer the latter half of your question.

> I'd just need to wait 10 seconds for it to reset,
In 10 seconds after your last keyboard touch, it will be reset. (I set it to 7 secs. 10 is too long for me.)

> So if this is commented,
Make sure: it has to be uncommented, right? If it's commented out, reset never happens.

Yep, for VT switching, this option too is indispensable.

# BTW2, there's a revelation: the kernel >= 5.4 problem happens only in USB keyboards, but not with AT Translated! We both use USB keyboards. ;-)

Salkay · 2020-03-24 22:14:12

Thanks @teika. I misunderstood. I thought the commented options were just the defaults. I wonder if that's worth mentioning in the new config file? That if not explicitly mentioned, there is no delay. A lot of config files comment out default values, so I thought it was the same here.

Also, while looking at your new example file, I realised that upstream's example file is installed at /usr/share/X11/xorg.conf.d/10-evdev.conf, so I can put 80-ahm.conf in the same directory. I can also put the README there as well if there's no better place.

teika · 2020-03-30 06:48:12

1. Gentoo puts READMEs and other docs into /usr/share/doc/<pkgname>-<version>/. For example, $ ls /usr/share/doc/zip-3.0-r3 looks like this:

BUGS.bz2       TODO.bz2          extrafld.txt.bz2  ziplimit.txt.bz2
CHANGES.bz2    WHATSNEW.bz2      ntsd.txt.bz2
README.CR.bz2  WHERE.bz2         timezone.txt.bz2
README.bz2     algorith.txt.bz2  txtvsbin.txt.bz2

$ ls /usr/share/doc/doctuils-0.13.1/:

BUGS.txt.bz2     FAQ.txt.bz2      README.txt.bz2         THANKS.txt.bz2  txt/
COPYING.txt.bz2  HISTORY.txt.bz2  RELEASE-NOTES.txt.bz2  html/

In this case usage manuals are there. But it's not FHS. I'm not sure what's good for Arch. Please decide, but take it easy.

2. After the release of ahm-2.10.6, I renamed README to README.adoc. (It's better in GitLab, the hosting site.) Maybe you want to put a future reminder in PKGBUILD.

3. For 80-ahm.conf, you can modify the following line in Makefile.am:

dist_xorgconf_DATA = 10-evdev.conf

Then it will go to /usr/share/X11/xorg.conf.d

4. Your comment "Hey, write the default" is reasonable. I don't feel like making another official release (as 2.10.6.1), but I fixed it in my HDD repo.

I discovered that the default value of AhmResetTime is 10, not "never happen", so it should work as-is.

Thanks!

Salkay · 2020-03-30 11:12:03

teika wrote:

Gentoo puts READMEs and other docs into /usr/share/doc/<pkgname>-<version>/.

Thank you! That's perfect. Arch doesn't use the version number, but apart from that this looks like a great spot for the README.

teika wrote:

For 80-ahm.conf, you can modify the following line in Makefile.am:
dist_xorgconf_DATA = 10-evdev.conf
Then it will go to /usr/share/X11/xorg.conf.d

Happy to do this, but what is the purpose of that line?

[EDIT: Actually, this line is already present in that file??]
[EDIT2: Also, my understanding is that files in /usr/share/X11/xorg.conf.d are for default configs that don't need further editing, but since 80-ahm.conf is contains commented suggestions, I think perhaps /etc/X11/xorg.conf.d is a better location? Then I can also use Arch Linux's backup array to track this file.]

teika wrote:

Your comment "Hey, write the default" is reasonable. I don't feel like making another official release (as 2.10.6.1), but I fixed it in my HDD repo.

Thank you again!

teika wrote:

I discovered that the default value of AhmResetTime is 10, not "never happen", so it should work as-is.

Hmmm… this means that it might not have worked earlier. I've explicitly set it to seven seconds now anyway, so I'll report back if it doesn't work again.

Last edited by Salkay (2020-05-19 10:30:21)

Salkay · 2020-08-16 01:16:33

Salkay wrote:

teika wrote:
I discovered that the default value of AhmResetTime is 10, not "never happen", so it should work as-is.
Hmmm… this means that it might not have worked earlier. I've explicitly set it to seven seconds now anyway, so I'll report back if it doesn't work again.

I've been having this problem again. Sometimes I'll swap TTYs, and the Ctrl or Alt key is stuck down after I swap. I tried waiting >10 seconds, but it doesn't reset for me.

teika · 2020-08-16 07:55:16

Sir, Teika is at your service. I'm not your servant, but I reckon it will eventually help myself. ;-)

1. Please try this patch

2. What's your current and the previous kernel versions? (If you can, try the former one, and see if ahm-2.10.6 is ok with it.)

3. # Why I didn't notice this last time? This seems to be due to the same kernel bug. Both AhmReset and AhmTimeout rely on the event timestamp.
# But what's irritating is that the kernel is hit by the same regression again, if my guess is correct. (BTW kernel developers are often great by being kind, not to mention their professional coding skills.) FYI: The former kernel bug 206929 was fixed in the kernels 5.6, 5.5.14 and 5.4.29.

Hope everyone is fine.

"When we are in the greatest distress" - BWV 641

Regards.

Salkay · 2020-08-16 09:42:24

Thank you again, Teika!

I have applied the patch and will report back! I'm currently using the latest Arch kernel, which is 5.8.1. I'll try the patch first, and if that doesn't work, I'll try an older kernel.

Hope you are going well too!

teika · 2020-08-31 12:33:11

On second thought, my patch is unlikely to fix the problem.

In fact I'm clueless. A reset happens when you press down a key after a while. OTOH the last kernel bug was related to the key release timestamp.

In a few days I'll try a new kernel(s). Let's wait and see.

Last edited by teika (2020-08-31 12:35:58)

Salkay · 2020-08-31 12:41:20

Ah okay. Thanks for the update.

I hadn't reported back yet because I hadn't hit the bug yet! I was going to wait until I had the problem, and see if waiting reset it, but I haven't had the initial problem yet.

Salkay · 2020-10-08 09:17:06

teika wrote:

On second thought, my patch is unlikely to fix the problem.

FWIW I ran into the "stuck modifier key" problem a few times recently, but as you predicted, waiting (with the patched ahm) doesn't fix it. I tried pressing the modifier key a few times, and sometimes that releases it, and sometimes it doesn't.

Arch Linux

#51 2017-01-15 04:15:45

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

#52 2017-01-17 08:23:41

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

#53 2018-02-08 11:31:57

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

#54 2018-03-01 12:55:00

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

#55 2020-03-07 00:01:30

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

#56 2020-03-07 01:14:27

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

#57 2020-03-07 04:57:36

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

#58 2020-03-11 08:02:26

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

#59 2020-03-11 09:42:57

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

#60 2020-03-11 13:10:43

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

#61 2020-03-11 21:04:55

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

#62 2020-03-12 22:15:10

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

#63 2020-03-14 05:27:36

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

#64 2020-03-24 01:07:42

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

#65 2020-03-24 10:36:25

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

#66 2020-03-24 13:23:31

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

#67 2020-03-24 22:14:12

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

#68 2020-03-30 06:48:12

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

#69 2020-03-30 11:12:03

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

#70 2020-08-16 01:16:33

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

#71 2020-08-16 07:55:16

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

#72 2020-08-16 09:42:24

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

#73 2020-08-31 12:33:11

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

#74 2020-08-31 12:41:20

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

#75 2020-10-08 09:17:06

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

Board footer