GNOME 42 To Finally Allow Input Events To Happen Full-Rate

[microcode]

I think the original behaviour actually is the right choice to some extent, but the synchronization method is too primitive. I would appreciate input devices being capable of polling at an integer multiple of the display refresh rate.

I guess it's still better, given the way input devices work right now, to implement your own input vs. display filtering at the application level.

[brent]

I wonder if there is some way to limit the update frequency still. 60 Hz is clearly a bit low for many use cases, but on the other hand, nobody *really* needs 1 kHz or beyond and will just consume additional cpu cycles and power. 250 Hz or something along those lines would be plenty already, it would be cool if you could enforce such a middle-ground update rate with mice.

[Vistaus]

You remind me of 144Hz, btw what happened to him?

Konqi disliked his GNOME trolling, so he ate him for breakfast.

[ac130kz]

nobody *really* needs 1 kHz or beyond and will just consume additional cpu cycles and power. 250 Hz or something along those lines would be plenty already, it would be cool if you could enforce such a middle-ground update rate with mice.

There is a significant measured improvement in input latency with higher polling rates, you can look it up. Forcing some arbitrary value just to save a tiny number cpu cycles of modern beast machines by default, which are more than capable of doing it, is really what "nobody really needs". In addition, there are already 390Hz monitors in the wild, so 250 Hz mouse input will be jittery.

[Scellow]

this is why people who defend gnome are full of shit
they been full of shit for 42 versions already

and people wonder why linux on steam stagnates and no game dev take this paltform seriously

bunch of clueless people working on gnome and linux desktop in general

[pal666]

this is why people who defend gnome are full of shit
they been full of shit for 42 versions already

maybe those people just have faster monitors?

and people wonder why linux on steam stagnates and no game dev take this paltform seriously

so you are saying that linux is just half as good as macos?

[RedEyed]

How is KDE Plasma handling this? Is it possible to use a mouse like the Razer Viper 8khz with 8.000 Hz on KDE?

I wonder how kernel handles it. Not sure it handles it at 8KHz rate, I mean, maybe there is some sort of timer, which grabs mouse input at constant frequency

[Sami]

I wonder how kernel handles it. Not sure it handles it at 8KHz rate, I mean, maybe there is some sort of timer, which grabs mouse input at constant frequency

usbhid parameters mousepoll jspoll kbpoll specify the polling interval.
from include/linux/usb.h:

@interval: Specifies the polling interval for interrupt or isochronous
  transfers. The units are frames (milliseconds) for full and low
  speed devices, and microframes (1/8 millisecond) for highspeed
  and SuperSpeed devices.

So kernel parameter usbhid.mousepoll=1 gives 1/8ms polling interval for highspeed and SuperSpeed mice.

also, include/linux/usb.h:

 Note that High Speed and SuperSpeed(+) interrupt endpoints use a logarithmic
 encoding of the endpoint interval, and express polling intervals in
 microframes (eight per millisecond) rather than in frames (one per
 millisecond).

 Wireless USB also uses the logarithmic encoding, but specifies it in units of
 128us instead of 125us. For Wireless USB devices, the interval is passed
 through to the host controller, rather than being translated into microframe
 units.

[RedEyed]

usbhid parameters mousepoll jspoll kbpoll specify the polling interval.
from include/linux/usb.h:

@interval: Specifies the polling interval for interrupt or isochronous
transfers. The units are frames (milliseconds) for full and low
speed devices, and microframes (1/8 millisecond) for highspeed
and SuperSpeed devices.

So kernel parameter usbhid.mousepoll=1 gives 1/8ms polling interval for highspeed and SuperSpeed mice.

also, include/linux/usb.h:

Note that High Speed and SuperSpeed(+) interrupt endpoints use a logarithmic
encoding of the endpoint interval, and express polling intervals in
microframes (eight per millisecond) rather than in frames (one per
millisecond).

Wireless USB also uses the logarithmic encoding, but specifies it in units of
128us instead of 125us. For Wireless USB devices, the interval is passed
through to the host controller, rather than being translated into microframe
units.

Thank you for detailed response!

So, it means, that the highest refresh rate is 1 / 125us = 8 kHz
Which some razor mouse provide (I remember there was article about that here)
Now I see that it's possible, I just had doubts that kernel input handles 8 kHz