lxqt/lxqt-config

Mouse accel not working on touchpad.

J-Dunn opened this issue · 8 comments

Touchpad movement is very slow and it requires about 5 passages from left to right on the pad to traverse the screen with the mouse pointer. Pretty unusable in everyday sense. Changin "acceleration" param in Settings has no effect and is not retained.

Same failures of Settings dlg seen on desktop system with same distro etc. Fortunately zero accel works reasonably well here but the bug is the same.

Expected Behavior

Setting "acceleration" parameter in Mouse and keyboard settings should affect touchpad swipe speed. Param value should be retained.

Current Behavior

The spin edit can change the value between 0 and 1
Pressing "Apply" had no effect on user input.
Closing dlg and re-entering settings shows zero and previous setting has been lost.

Possible Solution
Steps to Reproduce (for bugs)
  1. Preferences | Keyboard and Mouse | Mouse and Touchpad
  2. see accel=0; set accel=1
  3. Press apply button
  4. Test touchpad behavious, no change
  5. Close
  6. Preferences | Keyboard and Mouse | Mouse and Touchpad
  7. see accel=0
Context

I need to paddle 4 or 5 times to get the mouse pointer from one side of screen to another.
This is barely usable in this state.

System Information
  • Distro Fedora 34
  • Kernel: 5.11.19
  • Qt Version: 4.8.7
  • liblxqt Version: 0.16.0
  • lxqt-build-tools Version: 0.8.0
  • Package version:

Not reproducible. I've set it to 0.4 and it works fine.

I don't start a long Q&A about xinput list and touchpad ID because 0.16.0 is outdated. If you see the issue with the latest release, please tell us to re-open this page or, preferably, open a Discussion at https://github.com/lxqt/lxqt/discussions/categories/q-a..

Comments can still be added.

Is this the regression which was fixed in 0.16.1 ?

The latest release is 0.17 and 1.0.0 will be released in less than a week.

That's great. However, it takes a while for distros to adopt each version because it implies an chain of testing.
Without talking about Ubuntu TLS, Fedora is unlikely to update other than next release unless there's a bug fix.

Can you tell me whether this issue is the one which is referred to in the change log for 0.16.1 ?

Not reproducible. I've set it to 0.4 and it works fine.

Did you test with 0.16.0 as I filed it, or are you saying "not reproducible on 0.17" ?

Can you tell me whether this issue is the one which is referred to in the change log for 0.16.1 ?

Most probably, the fix is 6dc047e. Apparently, the LXQt maintainers of Fedora 34 didn't care about point releases.

Did you test with 0.16.0 as I filed it.

Old versions are considered "dead". As a developer, I only have the latest git LXQt.

Yes, it was reported a year ago, in #676, and fixed quickly.

Apparently, the LXQt maintainers of Fedora 34 didn't care about point releases.

You cannot expect distros to test and integrate every minor release. IIRC my installation has something like 3000 packages and the entire distro tree probably has ten times that number.
Every update brings in the possibility of introducing new problems in other packages and means previous testing can no longer be counted on. That is why distros are reluctant to bring in every minor update which is released unless it addresses a major bug and why they try to keep a stable set of version within each release.
That does not mean they "don't care about point releases". It means it imposes a massive testing burden and risk of knock on problems which is only justified for major bug fixes.

That is why package developers need to do proper regression testing before releasing newer versions. This acceleration bug was not some peculiar corner case, it simply did not work and was apparently never tested before release.

It would be more productive to look at how your own project could improve regression testing, rather than just shrugging it off by claiming distros "don't care".

Thanks for your replies.

You cannot expect distros to test and integrate every minor release

I don't expect anything from package maintainers who don't care about their users. Users can always switch to ditros with better maintainers.