Bloody J90s Software

0 views

Skip to first unread message

Bazara Benavides

unread,

Aug 3, 2024, 12:40:55 PM8/3/24

to pornotity

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?

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

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:

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.

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.

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.

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:

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.

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.