libinput issueshttps://gitlab.freedesktop.org/libinput/libinput/-/issues2023-09-30T17:17:15Zhttps://gitlab.freedesktop.org/libinput/libinput/-/issues/800Enable spurious debouncing with Logitech G502 HERO Gaming Mouse?2023-09-30T17:17:15ZJakob HainEnable spurious debouncing with Logitech G502 HERO Gaming Mouse?<!--
Before your file a feature request, please read
https://wayland.freedesktop.org/libinput/doc/latest/what-is-libinput.html
The amount of developer time libinput has available is very small.
Requesting a feature is no guarantee tha...<!--
Before your file a feature request, please read
https://wayland.freedesktop.org/libinput/doc/latest/what-is-libinput.html
The amount of developer time libinput has available is very small.
Requesting a feature is no guarantee that it will get implemented. Someone
(you!) needs to step up to do the work.
-->
## Summary
Sorry to bother you. I have the same issue as https://gitlab.freedesktop.org/libinput/libinput/-/issues/441.
Dragging occasionally releases the mouse. The time it's released is definitely <100ms, and where the delay of letting go because of debounce check would not be an issue.
Is there a way to increase spurious debounce time?
<!-- Summarize the requested feature in a few sentences. -->
## Feature details
Either increase spurious debounce for Logitech G502 HERO Gaming Mouse in upstream, or provide a setting in local-overrides.quirks so I can do so locally.
<!-- A step-by-step list of what the feature should achieve (where applicable) -->
## Affected Hardware
<!-- Which hardware types would be affected by this -->
Logitech G502 HERO Gaming Mouse
As well as any other faulty mouse
## Implementation in Other Systems
<!-- Does this feature already exist elsewhere? How does it work there? Try
to provide as many details as possible -->https://gitlab.freedesktop.org/libinput/libinput/-/issues/350RFE: Mouse acceleration profile enhancements2023-01-29T18:03:33ZMatt MayfieldRFE: Mouse acceleration profile enhancements## Summary
Mouse acceleration that feels better subjectively than the existing profile, as agreed on by a reasonably large number of testers. Or, ability to choose between a small number of alternate acceleration profiles.
## Feature d...## Summary
Mouse acceleration that feels better subjectively than the existing profile, as agreed on by a reasonably large number of testers. Or, ability to choose between a small number of alternate acceleration profiles.
## Feature details
Compared to the current mouse acceleration profile, personally I find it desirable to have:
- A greater difference in speed between slow and fast movements
- Currently, at settings where slow movements are precise enough, fast movements aren't fast enough
- Likewise, at settings where fast movements are fast enough, slow movements are too fast and create muscle strain
- A smoother transition (continuous?) from less to more acceleration, over velocity
- Currently experimenting with quadratic curves instead of ramp/plateau/ramp
## Affected Hardware
All mice
## Implementation in Other Systems
Windows 10 with "Enhance pointer precision" on comes reasonably close to my preference on this. MacOS is slightly different subjectively, but fairly similar to Windows 10. AFAICT, current libinput differs from both of those more than they do from each other.
(@mdmayfield is currently working on a proof-of-concept for this)Matt MayfieldMatt Mayfieldhttps://gitlab.freedesktop.org/libinput/libinput/-/issues/282Initial velocity calculation uses the wrong indices2019-06-19T00:30:53ZPeter HuttererInitial velocity calculation uses the wrong indicesThis was pointed out by Simon Thum, introduced by commit 7d06ccc06125844ffc3e914ee8fa0a7b6e0a0df3. Discussion was in email, but this is my analysis:
Trackers are a set of deltas to the current point, including time and direction. `track...This was pointed out by Simon Thum, introduced by commit 7d06ccc06125844ffc3e914ee8fa0a7b6e0a0df3. Discussion was in email, but this is my analysis:
Trackers are a set of deltas to the current point, including time and direction. `trackers[0]` is `0/0`, `trackers[2]` is the delta to point 2 events ago. Velocity is simply that tracker's delta/time.
For up to `trackers[2]`, we use the velocity of that event as initial velocity. But that's wrong, after 6 events we would use event 4 as initial velocity after than actual event 2. I suspect my mistake was taking `offset[2]` as the second event rather than the event 2 events ago.
Before this patch, `initial_velocity` was always `velocity[tracker[1]]`. The fix to get the intended behaviour would be to use something like `(tracker->ntrackers - 2)` instead, but only for `result`, not `initial_velocity`.
Additional problem: we don't have a notion of "the first two events" as 7d06ccc wants it, the trackers are just a continuous buffer. No automatic reset after a timeout is present.https://gitlab.freedesktop.org/libinput/libinput/-/issues/281Configurable constant scale factor2019-06-19T00:30:49ZHactarConfigurable constant scale factor## Summary
There is currently no proper way to simply scale the pointer speed by a constant factor, something which seems quite basic and very useful. There are several workarounds, each of which has their drawbacks:
* `Accel Speed` wo...## Summary
There is currently no proper way to simply scale the pointer speed by a constant factor, something which seems quite basic and very useful. There are several workarounds, each of which has their drawbacks:
* `Accel Speed` works if the "flat" acceleration profile is used. Under any other profile, 'Accel Speed' does not simply scale the resulting pointer movement; it alters the shape of the acceleration curve [as shown here](https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html). I like my mouse _acceleration_ the way it is, but the _speed_ is too fast.
* `CoordinateTransformationMatrix` can be used to achieve the desired effect, but it is not meant for relative devices like mouse pointers and so causes [other problems](https://gitlab.freedesktop.org/xorg/xserver/issues/633). Additionally, it is my understanding that this would not be available under Wayland, where Libinput is the default (and only?) option.
## Feature details
This feature would introduce a new option, called something like `Constant Scale Factor`, which would be a floating point value ranging from `0` to positive infinity. The acceleration factor for each pointer movement, after all other acceleration calculations, would be multiplied by this value.
Alternatively, call the value `Constant Deceleration` and _divide_ each acceleration factor by this value. This provides equivalent capability.
## Affected Hardware
This would affect all relative pointing devices (mice, touchpads, and maybe [trackpoints](https://xkcd.com/243/)). The option would default to `1`, so existing configurations would remain the same.
## Implementation in Other Systems
Xorg has an option `Device Accel Constant Deceleration` which does exactly what I want. Xorg divides each component of the pointer movement delta by this configurable constant value, after all other acceleration calculations.
## Other relevant links
#224 would have brought this back, but Kim Kröger wanted to use the flat profile anyway, where `Accel Speed` does the job. (I want to use the `adaptive` profile, and so `Accel Speed` does not do what I want.)
[This forum thread](https://bbs.archlinux.org/viewtopic.php?id=244000) and [this StackExchange post](https://unix.stackexchange.com/questions/491531/) should serve to illustrate that I am not the only one who would benefit from this feature, and that the currently accepted workaround is to use Xorg's `CoordinateTransformationMatrix`.
Thank you very much.https://gitlab.freedesktop.org/libinput/libinput/-/issues/237Improve hardcoded delay value for button scrolling2021-12-21T04:51:33ZHenré BothaImprove hardcoded delay value for button scrolling## Summary
When using button scrolling, a hardcoded delay of 200 milliseconds between button down and scroll events being emitted makes fast scrolling gestures feel clunky and sometimes fail entirely. Let's discuss what this timeout val...## Summary
When using button scrolling, a hardcoded delay of 200 milliseconds between button down and scroll events being emitted makes fast scrolling gestures feel clunky and sometimes fail entirely. Let's discuss what this timeout value should be.
## Feature details
When using button scrolling (where holding a chosen button down translates pointer movement into scroll events), there is a hardcoded delay of 200 milliseconds (in src/evdev.c) during which the pointer is immobilised, but scroll events are not yet emitted. This delay forms part of the design allowing the chosen button to perform both its normal function and the button scroll function. It acts to prevent minor mouse movement during what is intended to be a normal click from swallowing the click event and instead emitting scroll events. (It is likely that a pointing device will experience minor movement during a normal button press; that is what this delay is attempting to work around.)
200 milliseconds is a long time. I have used dedicated utils in the past to provide this functionality on other operating systems, and those utils do not attempt to preserve the button's original function, and thereby have no need of a delay. Using those utils, it's easy to press the scroll button and immediately begin scrolling, which feels quite natural. Attempting this gesture with the 200 ms delay in place is much more clunky; the intended scrolling often does not happen at all (for quick "one page" scroll flicks, which for me take less than 200 ms).
I discussed this a bit with @whot over email, and he suggested we could discuss perhaps changing the timeout length, as the 200 ms value was chosen seemingly arbitrarily and has never changed.
I've compiled libinput with the delay reduced to 50 ms, which feels fairly natural for scrolling, but starts to lose the intended "anti-jitter" effect. I'm not sure whether a value exists which would both enable natural scrolling gestures and preserve the button's original function. Perhaps we need to concretely determine _how much_ anti-jitter is needed?
## Affected Hardware
Any pointing devices that use button scrolling are affected.
The feature in its current state benefits devices such as mice, but devices such as trackpads and trackballs actually see little benefit because it is easy to press a button with absolutely no pointer movement.
## Implementation in Other Systems
Other utils typically don't attempt to preserve the button's original function, and so don't have a delay in place.
<!-- original email
I've compiled libinput reducing that delay from 200 ms to 50 ms and it feels very responsive for scrolling. I think what was tripping me up before, being used to instantaneous move->scroll translation, was I had gotten used to being able to hit the button, "spin" the ball, and release the button over a very short (< 250 ms) period to scroll roughly one page up/down. With the long delay, that entire "gesture" got swallowed. With 50 ms, I can still do that quite easily.
However, from my testing, this does kill the previous desired behaviour of buffering against minor mouse movements while clicking.
-->