| Age | Commit message (Collapse) | Author |
|---|
|
|
|
+ HID derives fuzz and flat from the logical axis range. On the tested T300
this gives steering fuzz=255 and flat=4095. It filters small corrections
and adds a large centered deadzone before applications apply their own
steering model.
+ Flat is also centered for pedal axes, while their rest position is an
endpoint. Fuzz without an endpoint deadzone can retain a small nonzero
value after the hardware has returned to rest. Both behaviours are
inappropriate for wheel and pedal input, and applications already provide
the required steering and endpoint deadzones.
+ Override fuzz and flat for every available wheel and pedal axis in
input_configured on devices handled by hid-tmff2, following the existing
hid-universal-pidff precedent for high-resolution racing devices. Skip
absent axes through the input device's absbit mask.
|
|
+ FF_GAIN and the driver gain both use the full 16-bit range. Their product
can exceed INT_MAX. Signed overflow is undefined and happens for common
settings such as 75 percent times 75 percent. Use a u32 intermediate for
the scaling operation.
+ Pass the configured gain directly when initializing or updating the
hardware. This also removes two redundant multiply-divide expressions
which could overflow before cancelling out.
|
|
+ Gain is documented and sent to the hardware as a value in the range 0 to
65535, but the module parameter and sysfs attribute accept wider integer
values. Store gain as a u16 and parse sysfs writes with kstrtou16 so
out-of-range values are rejected instead of being silently changed.
+ This constrains only the configured value. Calculations combining gain
values still require a wider intermediate to cover the product of two
full-range 16-bit values.
|
|
This reverts commit c26573d77369c042dc2b9a881a7f2ff88ddc0dd9.
+ `on_hid_hw_open` is apparently new enough that common distros don't
have it yet, so let's wait a few years and try again. The old method
works well enough and if not, just set `open_mode=0`.
|
|
+ Seems some applications can mess with input_dev->open, still unclear
how but on_hid_hw_open seems to be a bit more reliable so use it for
now at least
|
|
+ Courtesy of @BDave95
|
|
+ Effects handlers were being called in a locked context,
which in this case happened to work due to how `hid_hw_request`
is implemented. Now, only the selected state is updated and the heavy
lifting of making the wheel aware of the requested changes is done
after the critical section.
|
|
|
|
"HID: change return type of report_fixup() to const" fe73965
|
|
|
|
|
|
+ This avoids a slight stutter when an effect is restarted. I also had a
bug in the original code that effectively stopped the playing of some
effects, whoops
|
|
|
|
|
|
|
|
|
|
|
