Troubleshooting Help - Unable to Change Settings Again

[gyvess]

For months now I haven't been able to change my settings for this driver. Every reinstall feels the same regardless of how much I increase values. Also, it feels the same regardless of which kernel version I've tested it on, including kernels I have yet to run the installer on. I've upgraded my kernel and installation dependencies since the initial installation so I'm unsure which of those, if any, are causing issues.

I finally sat down today to try to figure out why, so far the only thing I can see wrong is the installation is no longer creating /sys/bus/usb/drivers/leetmouse, /sys/module/leetmouse, nor the files within. However, other folders are still created/modified when reinstalling such as /usr/src/leetmouse-driver-0.9.0 or /lib/modules/$KERNEL/kernel/drivers/hid/leetmouse.ko.

Distro: Gentoo
Kernel: 5.15.11

Day 2 of messing with this thing. So now I've found I have to manually invoke doas insmod /lib/modules/$KERNEL/kernel/drivers/hid/leetmouse.ko which creates the previous missing folders and files. Then I tried echo -n "1-2:1.1" > /sys/bus/usb/drivers/leetmouse/bind but it returns a No such device error. echo -n "1-2:1.1" > /sys/bus/usb/drivers/usbhid/bind and echo -n "1-2:1.1" > /sys/bus/usb/drivers/usbhid/unbind do work though, so this seems to be a problem specific to what's in the leetmouse directory.

Oh and my settings feel the same despite this. Unbinding and rebinding the usbhid driver I can feel a change, but running the same commands I use prior to it breaking makes it feel the same. Despite putting in extremely different values in drivers/config..

[systemofapwne]

When /sys/module/leetmouse/parameters/ does not exist, then the kernel module is not loaded. Try uninstalling and reinstalling the module.

[gyvess]

Right, when using either modprobe or insmod the module is then loaded. /sys/module/leetmouse/parameters/ is created and the parameters match the newest config.h changes. However, the output of lsmod states that leetmouse is used by 0 and no changes are felt an input movement.

My uninstall and install commands are virtually the same as the readme's with the exception that I use doas instead of sudo. Here are the commands I use.

And here is the shell output of those commands just in case it'd be helpful.

[systemofapwne]

It all sounds pretty weird, that you need to manually load the module. In principle, that is the job of udev.
Can you please check your udev logs? It looks like that your mouse is not covered by the rules I wrote.

[gyvess]

I checked udevdebug.log, reinstalling leetmouse only adds two repeating lines of Received udev control message (RELOAD). Also, neither dmesg -w or udevadm monitor --environment print anything when I reinstall. udev log level is set to info as well.

When I use insmod,modprobe, or rmmod commands udevadm monitor --environment does show leetmouse being added or removed and dmesg prints messages like usbcore: registered new interface driver leetmouse and leetmouse: loading out-of-tree module taints kernel.

Unsure of where to go from here. I'll post the output I get when unplugging and replugging my mouse in hopes that you can spot why the rules you wrote no longer cover my device.

udevadm monitor output
dmesg output

[systemofapwne]

Try also unplug/replug your mouse. What is shown in dmesg and udevadm monitor output then? Can you post an of your mouse as mentioned in this debug readme https://github.com/systemofapwne/leetmouse/blob/master/debug/Readme.org?

Also: What mouse do you use? I guess it is due to some USB attributes of your mouse (PloopyCo Trackball) being different to most other mices such that the udev-rules dont kick in. That would be a very easy fix.

[gyvess]

Oh, I missed this debug readme or else I'd have done this sooner.

lsusb -vd output

In the above you can see that "Report Descriptors" are unavailable just like the example in the readme.

usbhid-dump -d output

USB Descriptor Parser for the first hex block

[systemofapwne]

Ok, the issue clearly is that your trackball identifies itself as a "keyboard" instead of as a mouse, so the udev rule ignores it.
There is basically one thing that one can do now: Adding a quirk just for this device to the udev rules.
But this comes with some issues

Your trackballs report descriptor has this type of data transmitted to your PC. I commented and separated the relevant parts in the following codeblock

0x05, 0x01,        // Usage Page (Generic Desktop Ctrls)

// The now following bytes are describing a mouse report descriptor. Almost everything from it can be parsed and used by LEETMOUSE
0x09, 0x02,        // Usage (Mouse)
0xA1, 0x01,        // Collection (Application)
0x85, 0x02,        //   Report ID (2)
0x09, 0x01,        //   Usage (Pointer)
0xA1, 0x00,        //   Collection (Physical)
0x05, 0x09,        //     Usage Page (Button)
0x19, 0x01,        //     Usage Minimum (0x01)
0x29, 0x08,        //     Usage Maximum (0x08)
0x15, 0x00,        //     Logical Minimum (0)
0x25, 0x01,        //     Logical Maximum (1)
0x95, 0x08,        //     Report Count (8)
0x75, 0x01,        //     Report Size (1)
0x81, 0x02,        //     Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x95, 0x02,        //     Report Count (2)
0x75, 0x08,        //     Report Size (8)
0x81, 0x01,        //     Input (Const,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x01,        //     Usage Page (Generic Desktop Ctrls)
0x09, 0x30,        //     Usage (X)
0x09, 0x31,        //     Usage (Y)
0x16, 0x01, 0x80,  //     Logical Minimum (-32767)
0x26, 0xFF, 0x7F,  //     Logical Maximum (32767)
0x95, 0x02,        //     Report Count (2)
0x75, 0x10,        //     Report Size (16)
0x81, 0x06,        //     Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0x09, 0x38,        //     Usage (Wheel)
0x15, 0x81,        //     Logical Minimum (-127)
0x25, 0x7F,        //     Logical Maximum (127)
0x95, 0x01,        //     Report Count (1)
0x75, 0x08,        //     Report Size (8)
0x81, 0x06,        //     Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x0C,        //     Usage Page (Consumer)
0x0A, 0x38, 0x02,  //     Usage (AC Pan)
0x15, 0x81,        //     Logical Minimum (-127)
0x25, 0x7F,        //     Logical Maximum (127)
0x95, 0x01,        //     Report Count (1)
0x75, 0x08,        //     Report Size (8)
0x81, 0x06,        //     Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0xC0,              //   End Collection
0xC0,              // End Collection

//Here are coming some additional information. Everything in here will be ignored by LEETMOUSE. E.g. special buttons will not work
0x05, 0x01,        // Usage Page (Generic Desktop Ctrls)
0x09, 0x80,        // Usage (Sys Control)
0xA1, 0x01,        // Collection (Application)
0x85, 0x03,        //   Report ID (3)
0x19, 0x01,        //   Usage Minimum (Pointer)
0x2A, 0xB7, 0x00,  //   Usage Maximum (Sys Display LCD Autoscale)
0x15, 0x01,        //   Logical Minimum (1)
0x26, 0xB7, 0x00,  //   Logical Maximum (183)
0x95, 0x01,        //   Report Count (1)
0x75, 0x10,        //   Report Size (16)
0x81, 0x00,        //   Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
0xC0,              // End Collection
0x05, 0x0C,        // Usage Page (Consumer)
0x09, 0x01,        // Usage (Consumer Control)
0xA1, 0x01,        // Collection (Application)
0x85, 0x04,        //   Report ID (4)
0x19, 0x01,        //   Usage Minimum (Consumer Control)
0x2A, 0xA0, 0x02,  //   Usage Maximum (0x02A0)
0x15, 0x01,        //   Logical Minimum (1)
0x26, 0xA0, 0x02,  //   Logical Maximum (672)
0x95, 0x01,        //   Report Count (1)
0x75, 0x10,        //   Report Size (16)
0x81, 0x00,        //   Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position)
0xC0,              // End Collection

// 131 bytes

To be honest, I don't see any big issues here by adding your mouse via a quick to the udev-rules. But IMHO the issue is the actual firmware (FW) of your mouse, that incorrectly identifies itself as a keyboard. The reason is, it uses https://github.com/qmk/qmk_firmware as a firmware, which by definition is meant for keyboards.
It would have been way more cleverer for the firmware to separate the "keyboard" sub-device from the "mouse" sub-device, rather putting both together into a "keyboard" subdevice.

[systemofapwne]

Can you please replace the contents of

/usr/lib/udev/rules.d/99-leetmouse.rules

with the following content

ACTION=="remove", GOTO="leetmouse_end"
SUBSYSTEMS=="usb|input|hid", ATTRS{bInterfaceClass}=="03", ATTRS{bInterfaceSubClass}=="01", ATTRS{bInterfaceProtocol}=="02", RUN+="leetmouse_bind leetmouse $kernel"

#Quirk for PloopyCo devices using QMK Firmware (https://github.com/systemofapwne/leetmouse/issues/20#issuecomment-1237448456)
SUBSYSTEMS=="usb|input|hid", ATTRS{idVendor}=="5043", ATTRS{idProduct}=="5442", RUN+="leetmouse_bind leetmouse $kernel"

LABEL="leetmouse_end"

and then run sudo udevadm control --reload-rules && sudo udevadm trigger? This should bind your trackpad to leetmouse. If not, unplug + replug it. If it still did not work, I messed up the udev-rules above.

TODO: Reminder for myself, to also fix leetmouse_manage regarding

[gyvess]

Did not work unfortunately. Same results as before. Just in case I replaced /install_files/udev/99-leetmouse.rules too, then reinstalled and nothing changed.

Now at some point the leetmouse driver worked with this device no problem. I attempted to change the rules and config to see if that might be a problem. Nope. Then I flashed to the default keymapping and nothing changed either. So this is definitely a change in the QMK firmware itself.

For the record it seems like xinput may be able to discern the difference between pointer and keyboard.

┏ Virtual core pointer                    	id=2	[master pointer  (3)]
┃   └ PloopyCo Trackball Consumer Control     	id=10	[slave  pointer  (2)]
┃   └ PloopyCo Trackball Mouse                	id=12	[slave  pointer  (2)]
┗ Virtual core keyboard                   	id=3	[master keyboard (2)]
    └ PloopyCo Trackball System Control       	id=9	[slave  keyboard (3)]
    └ PloopyCo Trackball Consumer Control     	id=11	[slave  keyboard (3)]
    └ PloopyCo Trackball                      	id=21	[slave  keyboard (3)]

[systemofapwne]

So even modprobe leetmouse + echo -n "1-2:1.1" > /sys/bus/usb/drivers/leetmouse/bind
did not work anymore?

[gyvess]

It still gives write error: No such device when I execute echo -n "1-2:1.1" > /sys/bus/usb/drivers/leetmouse/bind.

echo -n "1-2:1.1" > /sys/bus/usb/drivers/usbhid/bind and echo -n "1-2:1.1" > /sys/bus/usb/drivers/usbhid/unbind work though. Unbind makes my cursor disappear and device not functional, binding of course makes it operational again. I tried unbinding from usbhid and then binding to leetmouse to see if it was somehow blocking, but again no dice.

[systemofapwne]

Have you made sure, that you execute both commands as root?

[gyvess]

Yup. I'm executing everything as root. I tried in multiple different ways even. First echo -n "1-2:1.1" | doas tee /sys/bus/usb/drivers/leetmouse/bind because shell symbols like > don't inherit super user. Then to double check I logged directly into root send the commands without doas. The "No such device" error is given in both circumstances.

I tried both modprobe and insmod prior to the echo to see if that'd make a diffence as well. Also, I tried changing the echo to printf '%s' to see if the mattered too.

[systemofapwne]

Does /sys/bus/usb/drivers/leetmouse/bind even exist? (I guess so. It should after modprobing)
Which shell are you using? Did you also try bash?

[gyvess]

Yeah /sys/bus/usb/drivers/leetmouse/bind exists. I'm using zsh normally but bash when I log in as root so I've tried both.

[systemofapwne]

What does sudo /usr/lib/udev/leetmouse_bind "1-2:1.1" sudo /usr/lib/udev/leetmouse_bind "leetmouse" "1-2:1.1" print out?
That is exactly what the UDev rules would call. It checks, if the driver is present and if not, modprobe it. After that, it is supposed to unbind your trackball from usbhid and then rebind it to leetmouse. Maybe the error you get comes from not having it initially unbound from usbhid.

[gyvess]

It prints

Device_ID (Driver) -  (1-2:1.1)
Modprobing 1-2:1.1

And it sits there without exiting, similar to dmesg -w. If I manually unbind from usbhid and then run that command, the same thing occurs.

[systemofapwne]

Error from my side. The command should have been this (fixed in original post):

sudo /usr/lib/udev/leetmouse_bind "leetmouse" "1-2:1.1"

[gyvess]

Ok now it prints

Device_ID (Driver) - 1-2:1.1 (leetmouse)
Unbinding 1-2:1.1 from hid-generic
Binding 1-2:1.1 to leetmouse
/usr/lib/udev/leetmouse_bind: line 72: printf: write error: No such device
Finished binding 1-2:1.1

[systemofapwne]

I really don't get the "No such device" error :/

[systemofapwne]

I have another suspicion about the USB address being not ok. Does 1-2:1.0 work?

And what is the output of lsusb -t?

[systemofapwne]

If this does not work, I might give this a try with real hardware in about 2 weeks: I just ordered a $12 ATMega32u4 Development board, similar to the one in the PloopyCo Trackball. Flashing the official Ploopy FW to it and testing it on my machine should give me a better idea for debugging it.

[gyvess]

lsusb -t

/:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 3: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 3: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 10000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M
    |__ Port 5: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 6: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M
    |__ Port 1: Dev 16, If 3, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 1: Dev 16, If 1, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 1: Dev 16, If 2, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 1: Dev 16, If 0, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 2: Dev 15, If 0, Class=Human Interface Device, Driver=, 12M
    |__ Port 2: Dev 15, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 4: Dev 4, If 1, Class=Wireless, Driver=, 12M
    |__ Port 4: Dev 4, If 0, Class=Wireless, Driver=, 12M
    |__ Port 5: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 5: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 6: Dev 6, If 2, Class=Vendor Specific Class, Driver=, 12M
    |__ Port 6: Dev 6, If 0, Class=Vendor Specific Class, Driver=xpad, 12M
    |__ Port 6: Dev 6, If 3, Class=Vendor Specific Class, Driver=, 12M
    |__ Port 6: Dev 6, If 1, Class=Vendor Specific Class, Driver=, 12M

doas /usr/lib/udev/leetmouse_bind "leetmouse" "1-2:1.0"

Device_ID (Driver) - 1-2:1.0 (leetmouse)
Unbinding 1-2:1.0 from hid-generic
Binding 1-2:1.0 to leetmouse
/usr/lib/udev/leetmouse_bind: line 72: printf: write error: No such device
Finished binding 1-2:1.0

Sending this command does sort of break my mouse though. The pointer works but certain key combinations weren't working or were garbled in a strange way where it sends different keys simultaneously. I only noticed because I was actually playing a game at the time. The strange thing is, running xev to see what keys are being pressed while this happens shows no output when I press the same button.

[systemofapwne]

According to your lsusb -toutput, 1-2:1.1 seems to be the right device, since it is bound to usbhid already. My guess of 1-2:1.0 was a dead end.

It also seems like people have similar errors @ the OpenRazer driver, where I "inspired" leetmouse_bind from here: openrazer/openrazer#830

Yet, there was no solution.

[gyvess]

I used git fetch to go back to QMK commit 971d36b from late August of 2021. Then tried to install the module again. Same error, so I no longer believe this is necessarily a change/problem with the firmware.

Other things I've tried today is updating my kernel, plugging into different USB ports and binding to the new Bus-Port, and removing old kernel entries from /lib/modules/. Nothing changed.

Something in the last six months changed, but I can't figure out what. Because, like I said, installing this module used to work fine.

[systemofapwne]

I agree. Only the UDEv rules were related to QMK. The "no such device" is related to something else though.

[systemofapwne]

Can you, one more time, send me a fresh lsusb -t right after you booted up your system? And how does
ls -l /sys/bus/usb/devices/1-2:1.1/driver and ls -l /sys/bus/usb/drivers/usbhid/ look like?

After that, unbind your mouse from usbhid with echo -n "1-2:1.1" > /sys/bus/usb/drivers/usbhid/unbind and one more time post the same three commands againg. At that point, your mouse should not work anymore. If it still works, then there is some issue that it does not properly unbind from (or instantly rebinds to) usbhid (and thus does not allow binding to leetmouse).

[gyvess]

Here you go. This is immediately after a fresh boot.

https://dpaste.com/9J42UEYGD

[systemofapwne]

This at least confirms my suspicion, that the both subdevices of the mouse (1-2:1.0 and 1-2:1.1) are both handled via usbhid. Generally, there is nothing that speaks against binding these subdevices to the same or even different drivers. In fact, it is a general practice to introduce different subdevices for different purposes and thus drivers (like an USB printer can simultaneously be a mass storage device to supply drivers or a webcam having a "camera" and a "audio" subdevice).

Please try to unbind the mouse completely from usbhid and then try to only bind the 1-2:1.1 to leetmouse:

echo -n "1-2:1.0" > /sys/bus/usb/drivers/usbhid/unbind
echo -n "1-2:1.1" > /sys/bus/usb/drivers/usbhid/unbind
echo -n "1-2:1.1" > /sys/bus/usb/drivers/leetmouse/bind

This might work now. If so, I need to figure out, what the reason for "no such device" is, when 1-2:1.0 is bound to usbhid and why it suddenly happened for you recently.

[gyvess]

Still the "No such device" message after unbinding both and then attempting to bind 1-2:1.1 to leetmouse. Then I tried binding 1-2:1.0 to leetmouse and also got the same error. Then I tried unbinding a generic Dell keyboard from usbhid and binding it to leetmouse, same "No such device" error.

I want to reiterate that I think acceleration from leetmouse is still being applied. I'm doubting myself after having done all of this but it has felt the same for months. I've tracked both fast and slow strafing targets, thrown flicks, tried out multiple websites that claim to test mouse accel. I'm fairly certain it's still on. I have rules on boot to disable mouse acceleration from libinput, and I run those commands manually when I reistall/install leetmouse.

Is it possible leetmouse is phantomly installed somehow? Maybe got mixed up with another driver? Just shooting in the dark here.

I uninstalled leetmouse and then ran fd on root (excluding home) to search for anything with "leetmouse" in the path/file name, this is what came up.

var/lib/dkms/leetmouse-driver
lib/modules/5.19.3-gentoo/kernel/drivers/hid/leetmouse.ko
lib/modules/5.15.11-xanmod1/kernel/drivers/hid/leetmouse.ko
var/lib/dkms/leetmouse-driver/0.9.0/5.15.13-xanmod1/x86_64/module/leetmouse.ko
var/lib/dkms/leetmouse-driver/0.9.0/5.19.3-gentoo/x86_64/module/leetmouse.ko
var/lib/dkms/leetmouse-driver/0.9.0/5.16.12-xanmod1/x86_64/module/leetmouse.ko
var/lib/dkms/leetmouse-driver/0.9.0/5.15.11-xanmod1/x86_64/module/leetmouse.ko
var/lib/dkms/leetmouse-driver/0.9.0/5.19.0-xanmod1/x86_64/module/leetmouse.ko

All installs on old kernels. I'll delete them and maybe reboot later to see what happens.

[gyvess]

Minor update. I pulled out my MTE and tried to bind leetmouse to it. It worked without the No such device error, however there were no observed changes to pointer speed despite trying multiple different values.

Also, sometime last year Gentoo switched from using eudev to using udev. I can only wonder if that has anything to do with my troubles.