Stops working on logout/login, or sometimes randomly

[spikespaz]

Describe the bug

Occasionally I go to use a gesture and notice that it doesn't work. Then I try all of them, and nothing works. Sometimes this happens randomly, but it is guaranteed to happen after a logout/login.

Stopping and starting the systemd service does not seem to do much of anything.

Logs

$ touchegg --debug
...

When I do this, touchegg starts working normally, printing correct results to the terminal.

• Version of Touchégg: Touchégg v2.0.12.

██████████████████  ████████   jacob@jacob-thinkpad 
██████████████████  ████████   -------------------- 
██████████████████  ████████   OS: Manjaro Linux x86_64 
██████████████████  ████████   Host: 20Y1S00C00 ThinkPad P14s Gen 1 
████████            ████████   Kernel: 5.15.7-1-MANJARO 
████████  ████████  ████████   Uptime: 7 hours, 43 mins 
████████  ████████  ████████   Packages: 1387 (pacman), 17 (snap) 
████████  ████████  ████████   Shell: zsh 5.8 
████████  ████████  ████████   Resolution: 1920x1080 
████████  ████████  ████████   DE: Cinnamon 5.0.7 
████████  ████████  ████████   WM: Mutter (Muffin) 
████████  ████████  ████████   WM Theme: Mint-Y-Dark-Aqua (Adapta-Maia) 
████████  ████████  ████████   Theme: Mint-Y-Dark-Aqua [GTK2/3] 
████████  ████████  ████████   Icons: Papirus-Dark-Maia [GTK2/3] 
                               Terminal: gnome-terminal 
                               CPU: AMD Ryzen 7 PRO 4750U with Radeon Graphics (16) @ 1.700GHz 
                               GPU: AMD ATI 07:00.0 Renoir 
                               Memory: 5767MiB / 21809MiB 

[mazen-mardini]

I've been experiencing exactly the same issue. I'm running Ubuntu 21.10. Restarting the service hasn't worked for me either, only logging out and logging in again. Randomly however, touchegg stops working.

Edit: Restarting the service seems to work. I did change the systemd service-file to run touchegg --debug --daemon rather than touchegg --daemon. Maybe that has something to do with it.

[JoseExposito]

It looks like the client (the touchegg command) is crashing, not the daemon.

If not installed already, could you install systemd-coredump and after a crash run sudo coredumpctl debug /usr/bin/touchegg and attach the output, please?

That should hopefully include a stack trace of the crash.

[spikespaz]

So, it just happened again for the first time since posting this. I ran the command, and tried to direct it to a file and now when I press ^C it just prints Quit. But the output doesn't look useful to you anyway. Touchegg didn't crash, and I noticed that four-finger gestures are still working (though it seems to behave weirdly and I can't put a finger on exactly what is different) but three-finger gestures are not. And now when writing this, just now, it starts working again as I habitually switched to the terminal to check on the misbehaving process.

[maranhaoBruno]

@JoseExposito, I just installed Touchegg on my RPi4 today, and am running into a similar issue. I created the desktop file you shared in another post, and touchegg does appear to be running on startup because when I try to launch another instance it complains its already running, but it does not work (gestures result in no behavior) until I run "sudo systemctl restart touchegg" in a terminal window, then it behaves as expected.

Below is the output of my coredump (I hope that helps, I'm not familiar with coredump). The only thing I can make out is an abort signal...

Thank,
B

PID: 1879 (touchegg)
UID: 1000 (pi)
GID: 1000 (pi)
Signal: 6 (ABRT)
Timestamp: Fri 2022-01-14 12:04:38 CST (1min 43s ago)
Command Line: touchegg
Executable: /usr/bin/touchegg
Control Group: /user.slice/user-1000.slice/session-1.scope
Unit: session-1.scope
Slice: user-1000.slice
Session: 1
Owner UID: 1000 (pi)
Boot ID: b2584a84a5784595a7adeb23ce09b786
Machine ID: 86e24053a87844d8a883148b7c0d4f2e
Hostname: raspberrypi
Storage: /var/lib/systemd/coredump/core.touchegg.1000.b2584a84a5784595a7adeb23ce09b786.1879.1642183478000000.zst
Message: Process 1879 (touchegg) of user 1000 dumped core.

            Stack trace of thread 1879:
            #0  0x00000000b5db58c0 __GI_raise (libc.so.6 + 0x318c0)
            #1  0x00000000b5d9e804 __GI_abort (libc.so.6 + 0x1a804)
            #2  0x00000000b5ff3f88 _ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6 + 0x7ff88)

GNU gdb (Raspbian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
https://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/touchegg...
(No debugging symbols found in /usr/bin/touchegg)
[New LWP 1879]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `touchegg'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) Quit
(gdb)

[JoseExposito]

@spikespaz

So, it just happened again for the first time since posting this. I ran the command, and tried to direct it to a file and now when I press ^C it just prints Quit

And it is my fault, because I forgot to mention than installing a debug version from source is required 🤦‍♂️
I'm so used to have the debug version installed to inspect crashes that I forgot the step, sorry :S

It can be done with the usual CMake steps, as described here, but using -DCMAKE_BUILD_TYPE=Debug instead of -DCMAKE_BUILD_TYPE=Release:
https://github.com/JoseExposito/touchegg/blob/master/HACKING.md#compilation

Touchegg didn't crash, and I noticed that four-finger gestures are still working (though it seems to behave weirdly and I can't put a finger on exactly what is different) but three-finger gestures are not. And now when writing this, just now, it starts working again as I habitually switched to the terminal to check on the misbehaving process.

It could be than the client process is running but the systemd daemon crashed.

The daemon restarts automatically after 5 seconds after a crash. That could explain why it's back to normal after a while... But no the 3 fingers issue. Without the daemon running you shouldn't be able to perform any gesture.

---

@maranhaoBruno

This could be a different issue, but let's see...

I created the desktop file you shared in another post

How did you install Touchégg? Did you use the .deb package? (assuming you are using Raspberry Pi OS, which is based on Debian)

The installer should create the desktop file for you. If not, there is a problem in the package.

it does not work (gestures result in no behavior) until I run "sudo systemctl restart touchegg" in a terminal window, then it behaves as expected.

This could also be a problem with the package. Maybe the service is not enabled.

You can check it by running this command after rebooting:

$ systemctl status touchegg

● touchegg.service - Touchégg Daemon
     Loaded: loaded (/lib/systemd/system/touchegg.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-01-14 19:11:17 CET; 37min ago
       Docs: https://github.com/JoseExposito/touchegg/tree/master/installation#readme
   Main PID: 1962 (touchegg)
      Tasks: 4 (limit: 76757)
     Memory: 2.5M
     CGroup: /system.slice/touchegg.service
             └─1962 /usr/bin/touchegg --daemon

If Active: active (running) is not present, as a workaround you can manually enable the service:

$ sudo systemctl enable touchegg.service

But the installer should do it for you.

[maranhaoBruno]

@JoseExposito

How did you install Touchégg? Did you use the .deb package? (assuming you are using Raspberry Pi OS, which is based on Debian)

I tried to install from the deb package, but it wouldn't work (I apologize, I don't recall what the issue was), so I downloaded the code and compiled it; that worked flawlessly. One a side note, I was unable to install Touché as it requires libgtk-4-dev and this is still experimental in Debian, and I figured it was just easier to manually edit the XML configuration file than to work around this.

This could also be a problem with the package. Maybe the service is not enabled.

You can check it by running this command after rebooting:

When I initially checked the status of touchegg it was indeed inactive. I ran the enable command and rebooted and now it is working. Thanks!

[JoseExposito]

I tried to install from the deb package, but it wouldn't work (I apologize, I don't recall what the issue was), so I downloaded the code and compiled it

Ok, that's why the service was not enabled, the package does it for you, but when installing from source it needs to be performed manually.

One a side note, I was unable to install Touché as it requires libgtk-4-dev and this is still experimental in Debian

You can install it from FlatHub and avoid the dependencies issue:

https://flatpak.org/setup/Raspberry%20Pi%20OS/

https://flathub.org/apps/details/com.github.joseexposito.touche

[niksingh710]

same happens on debian based distro installed via ppa (kubuntu 22.04) any way out?
For me it only stops working after log out login.

[cheerio-pixel]

@spikespaz
The solution is to set psmouse.synaptics_intertouch=1 in the kernel boot line, in my case it was in the line GRUB_CMDLINE_LINUX_DEFAULT of /etc/default/grub

For the reason see https://gitlab.freedesktop.org/libinput/libinput/-/issues/624#note_971747