bulletmark / libinput-gestures

Actions gestures on your touchpad using libinput
3.93k stars 241 forks source link

Gesture performs action even if screen is locked #293

Closed mrr0b0t-0x1 closed 3 years ago

mrr0b0t-0x1 commented 3 years ago

Hey, I recently noticed this weird issue when the screen is locked. I have setup left swipe to switch to the previous workspace and right swipe to switch to the next workspace. FYI, I am on Manjaro KDE and use Latte dock.

Issue

So when the screen is locked, and if I swipe left or right, the workspace switches and some parts of the screen are visible through the lockscreen such as the panel and dock of Latte Dock is visible, which should not be the case, if the screen is locked no command should execute without unlocking it.

To give you a better idea, I have recorded a small video of the issue, https://imgur.com/a/QKJhNl5

What I have tried so far -

  1. Remove the custom config and try with default config
  2. Purge and reinstall the package

The issue persists after performing each of the above steps.

Debug commands -

> libinput-gestures-setup status

libinput-gestures is installed.
libinput-gestures is set up as a desktop application.
libinput-gestures is currently running as a desktop application.
libinput-gestures is set to autostart as a desktop application.
libinput-gestures is using custom configuration.
> libinput-gestures -d

libinput-gestures: session KDE+x11 on Linux-5.4.100-1-MANJARO-x86_64-with-glibc2.33, python 3.9.1, libinput 1.17.0
/usr/sbin/libinput-gestures: hash 9442a11c0fda2c0ea67cef65a7eb4472
Gestures configured in ~/.config/libinput-gestures.conf:
swipe up         4 xdotool key super+alt+End
swipe down       4 xdotool key super+alt+Home
swipe left       4 _internal ws_up -w
swipe right      4 _internal ws_down -w
swipe up         3 xdotool key ctrl+F9
swipe down       3 xdotool key ctrl+F10
swipe left       3 xdotool key alt+Tab
swipe right      3 xdotool key alt+shift+Tab
pinch in           xdotool key ctrl+F9
pinch out          xdotool key ctrl+F9
swipe_threshold 10
libinput-gestures: device /dev/input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-event-mouse(event18): SYNA2393:00 06CB:7A13 Touchpad
libinput-gestures: SWIPE right 4 [307.57000000000005, -10.66]
   _internal ws_down -w
libinput-gestures: SWIPE left 4 [-365.02000000000004, 136.11999999999998]
   _internal ws_up -w
libinput-gestures: SWIPE right 4 [484.7299999999999, 22.14]
   _internal ws_down -w
libinput-gestures: SWIPE left 4 [-691.4099999999999, 139.39999999999995]
   _internal ws_up -w
libinput-gestures: SWIPE up 4 [205.82, -923.5300000000003]
   xdotool key super+alt+End
libinput-gestures: SWIPE down 4 [-4.1000000000000005, 843.9799999999999]
   xdotool key super+alt+Home
libinput-gestures: SWIPE right 4 [825.1, 81.17999999999995]
   _internal ws_down -w
libinput-gestures: SWIPE left 4 [-958.8099999999998, 210.73999999999992]
   _internal ws_up -w
libinput-gestures: SWIPE right 4 [875.9900000000001, -20.5]
   _internal ws_down -w
libinput-gestures: SWIPE left 4 [-961.2699999999999, 218.12999999999997]
   _internal ws_up -w
^CTraceback (most recent call last):
  File "/usr/sbin/libinput-gestures", line 766, in <module>
    main()
  File "/usr/sbin/libinput-gestures", line 723, in main
    for line in cmd.stdout:
KeyboardInterrupt

Interestingly enough, this only happens with the gestures that are setup with the _internal command. I have only two gestures that use this command, swipe left and swipe right. This doesn't happen on any of the gestures that use other key combinations such as swipe down and swipe up. All the gestures work just fine when screen is unlocked.

So I am suspecting that the issue is with the _internal command, it is somehow getting executed bypassing the lockscreen restrictions, hence performing the gesture action.

Please take a look at the issue, meanwhile I will try reproducing the issue by booting from a live USB stick to see if it exists on a fresh system too.

bulletmark commented 3 years ago

I wouldn't say it was weird. I'd expect this would happen now you mention it but nobody else has ever noticed it. I created a branch called "session" which adds logic to check if the user session is locked and inhibit actions until it becomes unlocked. Please try that branch and see if it works for you.

bulletmark commented 3 years ago

BTW, I should comment on your remarks at the end of your post. Note it has nothing to do with the _internal command specifically. All gestures are always being executed by libinput-gestures, regardless of whether your session is locked or not. I suspect that your DE is simply ignoring keyboard shortcuts sent by xdotool when the DE session is locked because they are just like a user executed those shortcuts directly. However _internal works differently. Ii invokes wmctrl to send commands to the DE via an alternate path and it seems that path is still respected by the DE even when the session is locked. I guess that could be argued to be a bug in the DE.

There are plenty of commands users can configure which have nothing to do with any DE so libinput-gestures probably should not execute anything when locked, hence my change here.

mrr0b0t-0x1 commented 3 years ago

I created a branch called "session" which adds logic to check if the user session is locked and inhibit actions until it becomes unlocked.

This fixes the issue, now it works as expected. Thanks!

I guess that could be argued to be a bug in the DE.

I am thinking of filing a bug report since this could be a major issue, I'll do some more testing to confirm that I am able to reproduce the issue regardless of my system config before filing the report.

bulletmark commented 3 years ago

I merged this change to master and made a new release 2.61.