[SOLVED] a4tech bloody sticky mouse problem because 2 event files

dedligma37 · 2023-06-12 12:18:32

Hello everyone!

I use a4tech bloody j90s mouse. A4tech mice have a problem on linux, in the form of strange cursor behavior. It behaves like I'm using a gamepad or something. That is, if I move the mouse a little bit, the cursor doesn't move. It's like the computer thinks it's a gamepad dead zone. What is happening is that the mouse is getting two event files. The solution to this problem is to merge the two event files using evsieve as shown here.

Now let's move on to the problem on arch linux. The event file numbers change after every arch linux reboot (the kernel kind of changes them but that is not the point). And the solution described above does not work because the event file numbers change.

Actually, the question is as follows. Is there any solution to this problem so that the mouse doesn't behave like a gamepad stick? Save the event file numbers so that evsieve merges them when running the .service file or something else?

Upd: the solution - a4tech-bloody-strange-mouse-fix

Last edited by dedligma37 (2023-06-15 11:44:42)

seth · 2023-06-12 13:31:00

ls /dev/input/by-id/

dedligma37 · 2023-06-12 14:31:31

seth wrote:

ls /dev/input/by-id/

usb-C-Media_Electronics_Inc._USB_Audio_Device-event-if03  usb-COMPANY_USB_Device-if01-mouse
usb-COMPANY_USB_Device-event-if02                         usb-COMPANY_USB_Device-if02-event-kbd
usb-COMPANY_USB_Device-event-kbd                          usb-USB_USB_Keyboard-event-if01
usb-COMPANY_USB_Device-if01-event-mouse                   usb-USB_USB_Keyboard-event-kbd

seth · 2023-06-12 14:38:21

Nice…
… but the point was to show you where to get stable event handles, those are symlinks to /dev/input/event*

dedligma37 · 2023-06-12 14:47:23

Yes, I understand. But the problem is that when I look at the link target of these files, one of the event files that I "merge" with evsieve is always missing there. That is, if I have event files with numbers 17 and 19, the link target of those files will not have an event19 file

seth · 2023-06-12 14:53:31

Figure which one that is and add a udev rule to add the symlink.
https://wiki.archlinux.org/title/Udev#udev_rule_example

dedligma37 · 2023-06-13 00:33:16

Phew, it took a bit of work, but the problem was solved. Perhaps not the most elegant solution, but still.

So, since I couldn't get the path to the second event file using udevadm (or maybe I just couldn't find the solution), I wrote a little bash script. The script takes the path to the first event file, and since the difference in numbers is always 2, the script adds 2 to the number of the detected event file and then runs evsieve. Code:

#!/bin/bash
eventFileFirst=`udevadm info --query=property --property=DEVNAME --value /dev/input/by-id/usb-COMPANY_USB_Device-if01-event-mouse`
eventNumber=`echo "$eventFileFirst" | sed 's/\/dev\/input\/event//'`
eventNumber=$(($eventNumber+2))
eventFileSecond="/dev/input/event$eventNumber"
sudo evsieve --input $eventFileFirst grab --input $eventFileSecond grab --output

The rest of the problem - I should not touch the mouse until I'm not in the system, otherwise I'll have to run the fix manually using systemctl. But for now it's fine for me, I mark the topic as solved.
If someone is interested or need complete solution to the problem - here's the full code. I'll finalize it there.

Thanks for the help, Seth!

Last edited by dedligma37 (2023-06-13 06:26:52)

seth · 2023-06-13 06:57:41

#!/bin/bash
eventFile=$(udevadm info --query=property --property=DEVNAME --value /dev/input/by-id/usb-COMPANY_USB_Device-if01-event-mouse)
# eventFile=$(realpath /dev/input/by-id/usb-COMPANY_USB_Device-if01-event-mouse) # alternatively
sudo evsieve --input $eventFile grab --input /dev/input/eventt$((${eventFile##*event}+2)) grab --output

But that's fragile; the device does not show up in "udevadm monitor"??

I should not touch the mouse until I'm not in the system, otherwise I'll have to run the fix manually using systemctl.

Can you elaborate on that?

dedligma37 · 2023-06-13 10:21:54

#!/bin/bash
eventFile=$(udevadm info --query=property --property=DEVNAME --value /dev/input/by-id/usb-COMPANY_USB_Device-if01-event-mouse)
# eventFile=$(realpath /dev/input/by-id/usb-COMPANY_USB_Device-if01-event-mouse) # alternatively
sudo evsieve --input $eventFile grab --input /dev/input/eventt$((${eventFile##*event}+2)) grab --output

But that's fragile; the device does not show up in "udevadm monitor"??

Yeah, I know. udevadm event19 (which I do with eventNumber+2) has shows in the propertys the file that creates 3 event files. And if I look at the properties of that file through udevadm info or monitor, it only outputs mouse0 link. I could never get event19 or the links list.

I should not touch the mouse until I'm not in the system, otherwise I'll have to run the fix manually using systemctl.
Can you elaborate on that?

When I boot, I have to select the user and enter the password. If I make a mouse move before doing this, (from what I understand) there will be an error in systemctl status and I have to use systemctl start mouseFix. I am not quite sure how the Linux event files are created and systemd units are called to say exactly what the problem is.

seth · 2023-06-13 14:35:13

"an error in systemctl status" means some service failed - likely the "mouseFix" one.
Check its status to see why it fails.
Do you run that as user service w/ sudo???

dedligma37 · 2023-06-13 17:36:13

Do you run that as user service w/ sudo???

Yes. I know it's not very good, but without sudo the script almost always refused to start.

"an error in systemctl status" means some service failed - likely the "mouseFix" one.

Yes, I meant that the error is related to mouseFix. An error, which can be seen with systemctl status mouseFix

After several reboots, I noticed the following pattern:
If I turn off and then turn on the system, making mouse movements before selecting a user and entering a password - the script doesn't work, and the systemctl status mouseFix gives the following:

pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
Jun 13 19:46:51 archlinux sudo[356]: pam_unix(sudo:session): session closed for user root
Jun 13 19:46:51 archlinux systemd[1]: mouseFix.service: Control process exited, code=exited, status=1/FAILURE

But if I don't make any mouse movements - the script works fine.

If I RESTART the system, the script works fine whether I select the user and enter the password or not.

seth · 2023-06-13 19:39:51

Yes. I know it's not very good, but without sudo the script almost always refused to start.

Why don't you just use a system service?

dedligma37 · 2023-06-13 20:57:57

I use. The .service file calls this bash script. As I understand it, describing all the logic in a .service would be problematic. So I do everything necessary in the bash script and the .service file calls it.

seth · 2023-06-13 21:11:24

System services are executed as root- it's pointless to sudo anything there (that's why I asked whether this is a user service)

I suspect the problem is rather that the system service is executed too early, you could (or rather "should") condition it on the existence of the event file.
https://superuser.com/questions/1469766 … enerically

Or you trigger the unit from a udev rule for the device, https://wiki.archlinux.org/title/Udev#S … _processes

The lazy variant is to just add a timer-based delay (eg. "sleep 5")

dedligma37 · 2023-06-15 09:59:05

So, I tweaked the systemd unit and now it is called after creating the .device file of the mouse. And just in case, I added a restart after on-failed (although I noticed the script never restarted after that time if it failed). And I also removed sudo from the bash script.

[Unit]
Description=Fix mouse movement issue
After=pci-0000:00:14.0-usb-0:3:1.1-event-mouse.device


[Service]
Restart=on-failure
RestartSec=8s

Type=forking
ExecStart=/home/dedligma/Documents/mouseFix/mouseFix
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes


[Install]
WantedBy=multi-user.target

Now everything works just perfect. No matter how I boot up, the script will merge the mouse files after a couple of seconds at most.

Thank you very much, seth!

I think it's time to make the repository on the githab look nice.

Arch Linux

#1 2023-06-12 12:18:32

[SOLVED] a4tech bloody sticky mouse problem because 2 event files

#2 2023-06-12 13:31:00

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#3 2023-06-12 14:31:31

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#4 2023-06-12 14:38:21

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#5 2023-06-12 14:47:23

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#6 2023-06-12 14:53:31

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#7 2023-06-13 00:33:16

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#8 2023-06-13 06:57:41

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#9 2023-06-13 10:21:54

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#10 2023-06-13 14:35:13

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#11 2023-06-13 17:36:13

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#12 2023-06-13 19:39:51

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#13 2023-06-13 20:57:57

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#14 2023-06-13 21:11:24

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

#15 2023-06-15 09:59:05

Re: [SOLVED] a4tech bloody sticky mouse problem because 2 event files

Board footer