Mouse movements/hooks work, but mouse clicks do not. (kubuntu cosmic 18.10, KDE/Plasma)

[c-to-the-l]

Title.

The test case is as simple as:

~/mouse (master|✔) $ sudo python3
Python 3.6.7 (default, Oct 22 2018, 11:32:17) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mouse
>>> mouse.move(50, 50) ## works
>>> mouse.click() ## nothing happens?
>>> ## no error

(alongside this, mouse.wait() and mouse.record() work, but mouse.replay() will replay movements but not clicks)

(the mouse directory is a fresh clone of this repository)

I'm not intimately familiar with how mouse interacts with linux on an i/o level, so i'm going to attempt to provide as much useful information as possible. Let me know what specific information you'd need about my environment.

This is a relatively vanilla installation of kubuntu:

~ $ apt list --installed | grep input

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

inputattach/cosmic,now 1:1.6.0-2 amd64 [installed,automatic]
libinput-bin/cosmic,now 1.12.1-1 amd64 [installed,automatic]
libinput10/cosmic,now 1.12.1-1 amd64 [installed,automatic]
libwinpr-input0.1/cosmic,now 1.1.0~git20140921.1.440916e+dfsg1-15ubuntu1 amd64 [installed,automatic]
xinput/cosmic,now 1.6.2-1build1 amd64 [installed,automatic]
xserver-xorg-input-all/cosmic,now 1:7.7+19ubuntu8 amd64 [installed,automatic]
xserver-xorg-input-libinput/cosmic,now 0.28.1-1 amd64 [installed,automatic]
~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.10
Release:        18.10
Codename:       cosmic
~ $

With the standard KDE window manager.

Nothing appears in dmesg except for the input: Virtual Keyboard as /devices/virtual/input/input## messages.

[robinpaulson]

Yep, I'm getting a similar problem. I also tried mouse.press and mouse.release, neither of those worked either. Ubuntu 20.04 though, with python 3.8

[ebbit1q]

I am also experiencing this issue, on Pop!_Os (Ubuntu 20.10). As a workaround I reverted to using xdotools: subprocess.run(["xdotool", "click", "1"]).

[vincens2005]

I have this issue on manjaro with python 3.9
I'll use the subprocess thing for now ig

[EliRibble]

I reproduced this as well. I tracked it down by reading the code and seeing that on POSIX systems the library is using the uinput module. After creating a sample program based on this blog post I was able to figure out that the issue comes down to this call:

# From _nixcommon.py lines 34 - 39
UI_SET_KEYBIT = 0x40045565
for i in range(256):
    fcntl.ioctl(uinput, UI_SET_KEYBIT, i)

I'm not sure why this is necessary. In my sample C program the analagous call is:

ioctl(fd, UI_SET_KEYBIT, BTN_LEFT);

Where BTN_LEFT on my system is defined as 0x00000110. This means I can replace the Python code with:

fcntl.ioctl(uinput, UI_SET_KEYBIT, 0x00000110)

...and button clicks work again.

I'd submit a PR if I knew this was stable on other systems, but I don't know that for sure.

[ebbit1q]

there is no cost to making a pr, it'd facilitate testing on other systems as well

[ebbit1q]

I can confirm this problem is fixed by #58 now two years ago...

@boppreh would it be possible to release a new version that includes this change?

[MasterChenSensei]

I reproduced this as well. I tracked it down by reading the code and seeing that on POSIX systems the library is using the uinput module. After creating a sample program based on this blog post I was able to figure out that the issue comes down to this call:

# From _nixcommon.py lines 34 - 39
UI_SET_KEYBIT = 0x40045565
for i in range(256):
    fcntl.ioctl(uinput, UI_SET_KEYBIT, i)

I'm not sure why this is necessary. In my sample C program the analagous call is:

ioctl(fd, UI_SET_KEYBIT, BTN_LEFT);

Where BTN_LEFT on my system is defined as 0x00000110. This means I can replace the Python code with:

fcntl.ioctl(uinput, UI_SET_KEYBIT, 0x00000110)

...and button clicks work again.

I'd submit a PR if I knew this was stable on other systems, but I don't know that for sure.

Can confirm this fixes the issue (Linux Manjaro user here), thanks for your investigation and help! :)

[FM1337]

I reproduced this as well. I tracked it down by reading the code and seeing that on POSIX systems the library is using the uinput module. After creating a sample program based on this blog post I was able to figure out that the issue comes down to this call:

# From _nixcommon.py lines 34 - 39
UI_SET_KEYBIT = 0x40045565
for i in range(256):
    fcntl.ioctl(uinput, UI_SET_KEYBIT, i)

I'm not sure why this is necessary. In my sample C program the analagous call is:

ioctl(fd, UI_SET_KEYBIT, BTN_LEFT);

Where BTN_LEFT on my system is defined as 0x00000110. This means I can replace the Python code with:

fcntl.ioctl(uinput, UI_SET_KEYBIT, 0x00000110)

...and button clicks work again.
I'd submit a PR if I knew this was stable on other systems, but I don't know that for sure.

Can confirm this fixes the issue (Linux Manjaro user here), thanks for your investigation and help! :)

Unfortunately this didn't work for me, so I went with @ebbit1q 's solution for the time being

[icezyclon]

I reproduced this as well. I tracked it down by reading the code and seeing that on POSIX systems the library is using the uinput module. After creating a sample program based on this blog post I was able to figure out that the issue comes down to this call:

# From _nixcommon.py lines 34 - 39
UI_SET_KEYBIT = 0x40045565
for i in range(256):
    fcntl.ioctl(uinput, UI_SET_KEYBIT, i)

I'm not sure why this is necessary. In my sample C program the analagous call is:

ioctl(fd, UI_SET_KEYBIT, BTN_LEFT);

Where BTN_LEFT on my system is defined as 0x00000110. This means I can replace the Python code with:

fcntl.ioctl(uinput, UI_SET_KEYBIT, 0x00000110)

...and button clicks work again.

I'd submit a PR if I knew this was stable on other systems, but I don't know that for sure.

While it is true that using this command enables BTN_LEFT (0x110) it does nothing for the other buttons, such as BTN_RIGHT, BTN_MIDDLE, BTN_SIDE and BTN_EXTRA.
Rather, the problem seems to be that the loop stops before enabling these inputs as 0x110 = 272, which is not enabled by the loop running only until 256.
Therefore, increasing the number in the loop to include these extra buttons will allow them to be controlled with click, press and release:

# _nixcommon.py - Line 32 - 33
for i in range(0x115):
    fcntl.ioctl(uinput, UI_SET_KEYBIT, i)

The button with the highest number seems to be BTN_EXTRA (0x114), which can be seen in _nixmouse.py, so running the loop until 0x115 = 277 enables all of them.

[ebbit1q]

this is exactly what #58 fixed, this issue has already been solved and could be closed. except there hasn't been a new release of mouse since 6 months before this change in 2020.

@boppreh please release a new version.