Mouse unresponsive when directly attached

[74k1]

Regarding #3 (comment)

Thanks a lot for the device selection. 👍
I do want to apologize for the mess on comments on PRs when it's only an Issue of mine.

To sum it up:

My Mouse (WL Mouse Beast X) is unresponsive in my environment when attached directly with the USB-C Port on the Mouse itself.
When using the dongle and using the mouse wirelessly, it works as expected again.
Replugging it or changing the ports does not help either.

I do think the issue was related to a0a28b1 as this issue has only appeared since then.

Thank you both for all the troubleshooting so far tho. 👍

[74k1]

Additional Note:
Since 489bf1e it feels like the same as before. (Mouse not working while directly plugged in) (even if its "unbinded" in yeetmouse)

[AndyFilter]

Thanks for opening this issue, so we can pin down the cause of it. I've looked up the mouse you've mentioned and I saw one interesting thing about it (beside the looks), and it was it's pooling rate of 8KHz. This should not cause problems tho, but we'll see. I'd like you to test a couple of things, as I'm physically unable to reproduce this issue on my end without the mouse. (I'm going to assume the issue has nothing to do with the OS you're using, since my knowledge is minimal on that topic.)

From my couple of tests I found that when NUM_USAGES is too low it can cause the effects you described on mice that have something special (even just a LED or DPI buttons).

1. The most obvious thing that comes to my mind is just changing the value of NUM_USAGES to something like 128, and seeing if it solves the issue (after reinstalling the driver). You can find it here. If this solves the issue I'll quickly change the value to something greater, and start working on Port input handler replacing HID driver #2 due to it likely solving the issue and not just patching it.

You don't have to do the steps below, if the issue was solved after that

2. After recompiling and running the driver, please post the logs (using sudo dmesg | grep -i "leetmouse"), and I'll see what's up. If the issue is with NUM_USAGES, then you should see something like in this error print:

   YeetMouse/driver/util.c

   Lines 68 to 71 in 489bf1e

   	if (r_count > NUM_USAGES){
   	printk("LEETMOUSE: parse_report_desc r_count > NUM_USAGES (%d). Should only happen on first probe.", NUM_USAGES);
   	return -1;
   	}

3. Does the mouse work without the LeetMouse driver installed? (I know, an obvious question, but you said it wasn't working in the unbound state (also, after unbinding, try refreshing, as some mice take quite a long time to register the change and actually go back to leetmouse driver after like 2 seconds)).

4. Can you change the pooling-rate of your mouse? If so, does it work with pooling rates of about 1000 and below?

[kitten]

wrote a small update here of what I'll be looking into next: #2 (comment)

@74k1: There's a chance that NUM_USAGES helps with some devices (as per a random comment in the leetmouse repo). Looking at the spec, I think the parser could be rewritten not to need a buffer relying on that fixed size though. You can always modify the flake with the change you linked as @AndyFilter says, and try that out.

fwiw, I'm currently on a ULX (and still have to test the rest of my mice collection 😅) and the wireless dongle also doesn't work. However, plugged in, like for you, the device works. I've got a HID descriptor dump and it doesn't look weird. High-polling shouldn't (in theory?) matter since it doesn't affect the HID descriptor dump if I'm not wrong about the spec and instead is represented by a single interval variable.

Anyway, there's also the possibility that dongles (not knowing how any of HID works) require some kind of output to be sent to the device before they provide the usual inputs.

[AndyFilter]

Thanks for Your input @kitten, into this issue, and this repo as a whole, Your work is awesome!

As of my experience with different mice, I've tested 6, two of which were wireless, and both of these worked out of the box with no issues. I only had problems with one mouse that was so old and "modded", that I just had the board with buttons on it. It still worked, but it required manual binding through the GUI (or by the binding script), just like my Arduino Pro Micro (which is fair).

Though, through some quite synthetic tests, I've managed to achieve the same kind of symptoms, as described in the original post. What I've done was just set the value of NUM_USAGES to something low, like 4, and connect some fancy mouse to the PC. As it turns out, it didn't work, all other mice worked, but this one just didn't. What's surprising, is that it still didn't work after unbinding it from the leetmouse and binding back to usbhid, which has to be an issue with the original HID related code:

YeetMouse/driver/usbmouse.c

Lines 156 to 164 in 489bf1e

	// ##########################################################################
	// This code extracts the report descriptor from the mouse. Might not be safe though (see https://github.com/torvalds/linux/blob/2a1d7946fa53cea2083e5981ff55a8176ab2be6b/drivers/hid/usbhid/hid-core.c#L1001)
	// I know, this is a total hack! The cleanest way would be to write a real HID
	// driver, with the HID subsystem taking care for probing the device.
	// This is (probably) planned. Due to my limited knowledge about the HID
	// subsystem, I have chosen to go this hacky route of merging usbmouse.c and hid-core.c
	// code for now.
	// Expect this to (probably) change in the future!
	// ##########################################################################

The only way to get the mouse to work after that was uninstalling the LeetMouse driver, and reconnecting it.

But if the issue really is caused by the NUM_USAGES, then the issue is not that hard to solve, as the size of this array is known pretty much from the beginning.

YeetMouse/driver/util.c

Lines 65 to 72 in 489bf1e

	if(ctl == D_REPORT_COUNT){
	r_count = (int) data[0];
	if (r_count > NUM_USAGES){
	printk("LEETMOUSE: parse_report_desc r_count > NUM_USAGES (%d). Should only happen on first probe.", NUM_USAGES);
	return -1;
	}
	}

What we could do is simply make the r_usage a dynamic array that allocates space when the ctl of D_REPORT_COUNT is encountered. As by then we already know what size it should be. This idea might sound simple, so I'll try to play around with it, and see if it actually works, and if so I'll make a push with these changes.

[kitten]

just to leave a small note here, I admittedly now spent more time on #5 (which basically now adds no virtual input device, so it's a better replacement than what I had before)

Regarding the USB HID descriptor parser though, my mouse has a bit of a weird behaviour in that (I think at least) the dongle never actually turns down its DPI (and other parameters?) in its boot mode. Something similar might be happening for @74k1's dongle. I've got this suspicion because the dongle also makes the mouse input hard to handle in the EFI boot menu (which is not a problem for the mouse in wired mode)

I'll leave a data dump here for now. I haven't actually compared this to my other mice's HID descriptors just yet. I suspect that maybe this comment is relevant:

YeetMouse/driver/util.c

Lines 109 to 111 in 489bf1e

	//case 4:
	//Sure, we could also now check 4 bytes, as it is written down in the HID specs...
	//However, my extract_at function does not support 4-byte numbers and I don't see, why I should implement it. A mouse should never need to send 4-bytes long messages IMHO.

Or potentially Report Size (16) in general 🤔

I really am not sure, but this might also imply that we're not getting mice out of boot mode?
or maybe once we're binding to the device the usbhid driver has written some outputs to it?

HID Descriptor Data

[ 2261.886676] usb 5-1.3.2.1: USB disconnect, device number 12
[ 2274.118140] usb 5-1.3.2.1: new high-speed USB device number 14 using xhci_hcd
[ 2274.221692] usb 5-1.3.2.1: New USB device found, idVendor=361d, idProduct=0100, bcdDevice= 3.03
[ 2274.221695] usb 5-1.3.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2274.221696] usb 5-1.3.2.1: Product: UltralightX dongle
[ 2274.221697] usb 5-1.3.2.1: Manufacturer: Finalmouse
[ 2274.221698] usb 5-1.3.2.1: SerialNumber: 65E2D5BB06682A5E
[ 2274.302296] input: Finalmouse UltralightX dongle Mouse as /devices/pci0000:00/0000:00:08.1/0000:0f:00.3/usb5/5-1/5-1.3/5-1.3.2/5-1.3.2.1/5-1.3.2.1:1.0/0003:361D:0100.000E/input/input24

Bus 005 Device 014: ID 361d:0100 Finalmouse UltralightX dongle
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x361d Finalmouse
  idProduct          0x0100 UltralightX dongle
  bcdDevice            3.03
  iManufacturer           1 Finalmouse
  iProduct                2 UltralightX dongle
  iSerial                 3 65E2D5BB06682A5E
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0029
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     142
          Report Descriptors:
            ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1

005:014:000:DESCRIPTOR         1728396118.527722
 05 01 09 02 A1 01 09 01 A1 00 85 01 05 09 19 01
 29 05 15 00 25 01 75 01 95 05 81 02 75 03 95 01
 81 01 05 01 09 30 09 31 16 00 80 26 FF 7F 75 10
 95 02 81 06 09 38 15 81 25 7F 75 08 95 01 81 06
 C0 C0 06 00 FF 09 01 A1 01 85 02 19 01 29 01 15
 00 26 FF 00 75 08 95 3F 91 02 85 03 19 01 29 01
 15 00 26 FF 00 75 08 95 3F 81 02 85 04 19 01 29
 01 15 00 26 FF 00 75 08 95 3F 91 02 85 05 19 01
 29 01 15 00 26 FF 00 75 08 95 3F 81 02 C0

0x05, 0x01,        // Usage Page (Generic Desktop Ctrls)
0x09, 0x02,        // Usage (Mouse)
0xA1, 0x01,        // Collection (Application)
0x09, 0x01,        //   Usage (Pointer)
0xA1, 0x00,        //   Collection (Physical)
0x85, 0x01,        //     Report ID (1)
0x05, 0x09,        //     Usage Page (Button)
0x19, 0x01,        //     Usage Minimum (0x01)
0x29, 0x05,        //     Usage Maximum (0x05)
0x15, 0x00,        //     Logical Minimum (0)
0x25, 0x01,        //     Logical Maximum (1)
0x75, 0x01,        //     Report Size (1)
0x95, 0x05,        //     Report Count (5)
0x81, 0x02,        //     Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x75, 0x03,        //     Report Size (3)
0x95, 0x01,        //     Report Count (1)
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, 0x00, 0x80,  //     Logical Minimum (-32768)
0x26, 0xFF, 0x7F,  //     Logical Maximum (32767)
0x75, 0x10,        //     Report Size (16)
0x95, 0x02,        //     Report Count (2)
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)
0x75, 0x08,        //     Report Size (8)
0x95, 0x01,        //     Report Count (1)
0x81, 0x06,        //     Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0xC0,              //   End Collection
0xC0,              // End Collection
0x06, 0x00, 0xFF,  // Usage Page (Vendor Defined 0xFF00)
0x09, 0x01,        // Usage (0x01)
0xA1, 0x01,        // Collection (Application)
0x85, 0x02,        //   Report ID (2)
0x19, 0x01,        //   Usage Minimum (0x01)
0x29, 0x01,        //   Usage Maximum (0x01)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xFF, 0x00,  //   Logical Maximum (255)
0x75, 0x08,        //   Report Size (8)
0x95, 0x3F,        //   Report Count (63)
0x91, 0x02,        //   Output (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x85, 0x03,        //   Report ID (3)
0x19, 0x01,        //   Usage Minimum (0x01)
0x29, 0x01,        //   Usage Maximum (0x01)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xFF, 0x00,  //   Logical Maximum (255)
0x75, 0x08,        //   Report Size (8)
0x95, 0x3F,        //   Report Count (63)
0x81, 0x02,        //   Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x85, 0x04,        //   Report ID (4)
0x19, 0x01,        //   Usage Minimum (0x01)
0x29, 0x01,        //   Usage Maximum (0x01)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xFF, 0x00,  //   Logical Maximum (255)
0x75, 0x08,        //   Report Size (8)
0x95, 0x3F,        //   Report Count (63)
0x91, 0x02,        //   Output (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x85, 0x05,        //   Report ID (5)
0x19, 0x01,        //   Usage Minimum (0x01)
0x29, 0x01,        //   Usage Maximum (0x01)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xFF, 0x00,  //   Logical Maximum (255)
0x75, 0x08,        //   Report Size (8)
0x95, 0x3F,        //   Report Count (63)
0x81, 0x02,        //   Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0xC0,              // End Collection

// 142 bytes

[AndyFilter]

Yea, if the dongle works this makes sense, in terms of the NUM_USAGES problem, because dongle could limit the "number of usages" (which can be pretty much anything, but mostly stuff like LEDs, DPI control, etc.), and it would explain why the mouse worked with a dongle, and didn't work without it. But it might also work the other way around, it might add usages as a wireless protocol, or some other more complex thing.

Either way, raising the NUM_USAGES, or making it dynamic should solve some issues. And so the last commit (ba430f6) does that. I've tested it like 20 times, to make sure I didn't mess something up in the kernel, but it should work (I somehow managed to not kernel panic even once 😎).

When it comes to the Boot Mode, I remember leetmouse refused to work with my Arduino that wasn't disguised as a Boot Mouse, so I had to change the library to one that supported it. So this might be the case, though, I also think it would work just fine with manual binding.

Also, the #5 looks really nice, I'll look into it a bit more, and probably dive a bit deeper into the HID descriptors, to be able to help with that.

[74k1]

Hey @AndyFilter

Thanks for the steps to debug my issue! (I've done / have comments on all the steps, just so it's documented on what's happening on my end)

To clarify some statements:

• My Mouse is not the 8k Hz version (it's an older version with 4k Hz)
• My Mouse + YeetMouse works only through the dongle
• My Mouse + YeetMouse do not work without the dongle (directly attached)
• My Mouse without YeetMouse work as expected (see answer 3.)

Now to answer the Questions:

1. It does work with a higher value. In my case, I've set it back to 90. (where @kitten had it at first) (7f4c34b)

2. see below (this was while NUM_USAGES was still at 32)

output of: sudo dmesg | grep -i "leetmouse"

[   37.850081] leetmouse: loading out-of-tree module taints kernel.
[   37.851629] usbcore: registered new interface driver leetmouse
[   37.922613] LEETMOUSE: parse_report_desc r_count > NUM_USAGES (32). Should only happen on first probe.
[   37.922617] leetmouse: probe of 1-5:1.0 failed with error -1
[ 5601.992701] LEETMOUSE: parse_report_desc r_count > NUM_USAGES (32). Should only happen on first probe.
[ 5601.992708] leetmouse: probe of 1-5:1.0 failed with error -1
[ 5617.560160] LEETMOUSE: parse_report_desc r_count > NUM_USAGES (32). Should only happen on first probe.
[ 5617.560165] leetmouse: probe of 1-5:1.1 failed with error -1
[ 5628.617178] LEETMOUSE: parse_report_desc r_count > NUM_USAGES (32). Should only happen on first probe.
[ 5628.617187] leetmouse: probe of 1-5:1.1 failed with error -1
[ 7738.414434] LEETMOUSE: parse_report_desc r_count > NUM_USAGES (32). Should only happen on first probe.
[ 7738.414446] leetmouse: probe of 1-5:1.0 failed with error -1
[ 7745.092294] LEETMOUSE: parse_report_desc r_count > NUM_USAGES (32). Should only happen on first probe.
[ 7745.092302] leetmouse: probe of 1-5:1.1 failed with error -1
[ 7752.252751] leetmouse: probe of 1-5:1.1 failed with error -71
[ 7752.285711] leetmouse: probe of 1-5:1.2 failed with error -71

3. Yes, the mouse works without leetmouse kernel mods

4. The DPI of the mouse can be changed. (allbeit only through their windows software). But that only works, while connected to the Dongle. If the mouse is directly attached (without the dongle), it's using a Polling Rate of 1k Hz.

[AndyFilter]

Alright, thanks for the comprehensive response, I think the latest commit (ba430f6) with the dynamic NUM_USAGES should solve your issue in that case (guessing from the dmesg output).

If it does, I don't think the issue is fully solved yet, as there still might be some edge cases, where the device is being rejected at the driver level, and becomes unusable, as it doesn't get rebound to the usbhid driver.

[74k1]

Unfortunately with the latest commit, I can't rebuild my system:

The last few lines of the build error being:

  CC [M]  /build/source/driver/usbmouse.o
  CC [M]  /build/source/driver/util.o
/build/source/driver/util.c: In function 'parse_report_desc':
/build/source/driver/util.c:45:15: error: implicit declaration of function 'kmalloc'; did you mean 'mm_alloc'? [-Werror=implicit-function-declaration]
   45 |     r_usage = kmalloc(r_count, GFP_KERNEL);
      |               ^~~~~~~
      |               mm_alloc
/build/source/driver/util.c:45:13: warning: assignment to 'int *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
   45 |     r_usage = kmalloc(r_count, GFP_KERNEL);
      |             ^
/build/source/driver/util.c:80:36: error: implicit declaration of function 'krealloc'; did you mean 'idr_alloc'? [-Werror=implicit-function-declaration]
   80 |                 int* new_r_usage = krealloc(r_usage, r_count, GFP_KERNEL);
      |                                    ^~~~~~~~
      |                                    idr_alloc
/build/source/driver/util.c:80:36: warning: initialization of 'int *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
/build/source/driver/util.c:83:21: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
   83 |                     kfree(r_usage);
      |                     ^~~~~
cc1: some warnings being treated as errors
make[2]: *** [/nix/store/kf4wg02vjcp5bbsp4z5slhr6gbd1m7v5-linux-6.6.56-dev/lib/modules/6.6.56/source/scripts/Makefile.build:243: /build/source/driver/util.o] Error 1
make[1]: *** [/nix/store/kf4wg02vjcp5bbsp4z5slhr6gbd1m7v5-linux-6.6.56-dev/lib/modules/6.6.56/source/Makefile:1921: /build/source/driver] Error 2
make: *** [/nix/store/kf4wg02vjcp5bbsp4z5slhr6gbd1m7v5-linux-6.6.56-dev/lib/modules/6.6.56/source/Makefile:234: __sub-make] Error 2
make: Leaving directory '/nix/store/kf4wg02vjcp5bbsp4z5slhr6gbd1m7v5-linux-6.6.56-dev/lib/modules/6.6.56/build'

[AndyFilter]

It looks like difference in the Kernel version, as I'm using 6.8, and you seem to be running on 6.6. The issue can most likely be solved by adding this header to the util.c file:

#include <linux/slab.h>

in here:

YeetMouse/driver/util.c

Lines 5 to 7 in ba430f6

	#include <linux/string.h> //memcpy
	// ########## Kernel module parameters

I can't really test this solution on my end though so I'd like to know if it does work for you, and if so I'll make a commit with this change.

[74k1]

Hey @AndyFilter
Thanks for the patch. I got to build it and discarded my changes (with the increased NUM_USAGES). https://github.com/74k1/YeetMouse/commit/c15da1237105afdffbac257453b34ce28062ebe0

It's very interesting now. I seem to be able to move my mouse only, horizontally.. (while directly attached.)

With the dongle I can fully move it, like previously.

Let me know if I can send over any details to help debug this behaviour.

[AndyFilter]

Thanks for the test. I didn't expect that result, haha. Not much is coming to my mind right now. I think I'm going to have to ask you for some debug details from the sudo dmesg | grep -i "leetmouse" like last time, to see what's going on. Also @kitten is making awesome progress on the #5, which might solve issues like this once and for all.

[74k1]

Can definitely do that. And it's great to hear progress being made! I'm excited 😄
Here's the output

[    7.292575] leetmouse: loading out-of-tree module taints kernel.
[    7.292728] usbcore: registered new interface driver leetmouse
[    7.348165] LEETMOUSE: New r_count (2) is bigger than the old r_count (1)
[    7.348169] LEETMOUSE: New r_count (64) is bigger than the old r_count (1)

[AndyFilter]

This looks very interesting. It looks like the NUM_USAGES starts at value of 1, which is not how it's defined (it's defined as 64 be default). I think this might be caused by some oddly placed D_REPORT_COUNT CTLs. To fix it, I'll ask you to change parse_report_desc function in util.c in 3 places, first on the top:

int r_count = max(NUM_USAGES, 1), r_max_count = r_count, r_size = 0, r_sgn = 0, len = 0;

This adds a new variable r_max_count, to keep track of the highest r_usage encountered.

Next, to use it, please change old_r_count to the new variable r_max_count here:

YeetMouse/driver/util.c

Line 75 in ba430f6

if(old_r_count < r_count) {

At the end of this if statement, update the r_max_count like so:

r_max_count = r_count;

The entire if statement should look something like this:

            // Check if the new count is greater
            if(r_max_count < r_count) {
                printk("LEETMOUSE: New r_count (%i) is bigger than the old r_count (%i)\n", r_count, old_r_count);

                // Try to reallocate more space if needed
                // (this should happen at most once, but we can handle more just in case)
                int* new_r_usage = krealloc(r_usage, r_count, GFP_KERNEL);
                if(!new_r_usage) {
                    printk("LEETMOUSE: Failed to allocate memory for r_usage");
                    kfree(r_usage);
                    return -ENOMEM;
                }
                else
                    r_usage = new_r_usage;

                // Zero only the new values of r_usage
                for(n = old_r_count; n < r_count; n++){
                    r_usage[n] = 0;
                }

                r_max_count = r_count;
            }

I forgot that device's CLTs can be out of order, this fix should keep the maximum usage size encountered.

Sorry for so much work, but I don't want to push changes that might be destructive to the main branch, and I don't know how (or even if) I can make like code change suggestions for a issue, like on a PR.

After that, please share your dmesg output (assuming it doesn't work).

[74k1]

Hey again

I've added the patches to my fork and tested it.
Same results where as the mouse only moves horizontally, not vertically.

Additionally, when plugging in my dongle, the entire system wants to crap itself.

I'll have this module disabled for now until #5 is implemented. 👍

[kitten]

@74k1: btw, if you want to test out the changes in #5, I've got a branch with all my changes which would also help us make that my input_handler is working across multiple kernel versions and machines ✌️ you can either try github:kitten/yeetmouse/next?dir=nix or github:kitten/feat/input-handler-overrides?dir=nix.

Doesn't of course fix the HID parsing for your mice 😞 but it at least helps us test the alternative approach

[AndyFilter]

@74k1 Alright, thanks for trying everything I suggested. You're right maybe it's better to just wait until #5 is done, as dealing with Kernel is critical, and my changes were a bit rushed. Even if that would fix your issue, the real problem would still not be solved, as there are more issues with the current descriptor parser and other parts of the code that deal with devices.