High polling rate mouse support

[DoctorRainer]

I have VAXEE XE-S Wireless (4K) and it works perfectly with polling rate up to 1000. When I switch it higher, to 2K or 4K, it starts feeling laggy and tools for detecting polling rate all report it doesn't go higher than 1000. Is it a hard limitation or it can be configured properly? It works fine on macOS and Windows

 

[Jake0162]

Do you know what mouse driver you're using and your USB hub info?

I know the mice I use don't have any issues when I switch around my DPI settings on FreeBSD 15.0-RELEASE.

If you can toss out some information on your system setup, all your connected hardware and how/where your mouse is connected.

Also what tools you're using for evaluating this.

I would first check that it's showing up with the correct description under usb HID devices like so:

sudo usbconfig
sudo usbconfig -d <mouse ugen number here> dump_all_desc | less

That should give you an idea of it's USB connection details such as the speed, which could be an issue if you're running it on say a USB1.0 connection or through a hub that has some issues.

On my mouse I can see the 'bRefresh' and 'bInterval' fields that should indicate the polling rate I think.

 

[sko]

Usually usb communication for such devices is interrupt based (see usb(4)). polling(4) is only supported for network interfaces.

Check the output of usbconfig -v and the bmAttributes value for the endpoint of your mouse.

ugen0.2: <USB Device CHERRY> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
ugen0.2.0: usbhid0: <vendor 0x046a USB Device, class 0/0, rev 1.10/1.10, addr 1>
[...]
     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0081  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0007 
        bInterval = 0x0008 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000

 

[Jake0162]

sko Yes, the communication is interrupt based for this because most the time it's not active and this makes sense; but the mouse itself has a polling rate most the time.

As in the firmware on the mouse itself is likely a super loop that's constantly polling the optical sensor of the mouse.

The mouse they are talking about itself has a higher polling rate, but it sounds like they are being bottle-necked somewhere along the line.

 

[Jake0162]

Okay I started to wonder a bit more on it and using under the <sys/mous.h> header there's a typedef for the mouse mode structure. One of the fields is the report rate of the mouse.

typedef mousemode {
int protocol;
int rate;
int resolution;
// -- SNIP --
} mousemode_t;

From what I can see it has both setter and getter functions so assuming the mouse itself supports it it shouldn't be to bad to change it I think.

 

[Espionage724]

With a 8K mouse, a website mouse polling checker iirc would cap around 2K-4K. A program would show low current rate until "Show" was unchecked (might run with Wine):

Above 1K that mouse needed a wireless dongle (USB-C wired capped 1K), and had some difference if Motion Sync was enabled (manufacturer recommends it above 1K to reduce USB controller load). I wonder if evdev vs libinput would affect anything.