search

systemofapwne / leetmouse

A fork of the Linux mouse driver with acceleration
GNU General Public License v2.0
93 stars 10 forks source link

Mouse cursor stuck on the side of the screen #4

Closed Thomot512 closed 3 years ago

Thomot512 commented 3 years ago

On 5.12.1-arch1-1, I ran into an issue where the mouse cursor is stuck on the side of the screen until I reboot or uninstall (or re-install) leetmouse. Step to reproduce:

  1. Go to a streaming website such as Youtube;
  2. start a video (not all but most video have this issue, here's a link to one that has this issue);
  3. wait for 10 to 15s without moving the mouse;

Expected behaviour: The mouse cursor should become invisible to avoid disturbing while watching the video. Behaviour: The mouse cursor snaps to the left of the screen and can yet only be moved vertically. Behaviour continues until the computer is rebooted or the leetmouse driver is uninstalled.

Info System: OS: RebornOS Linux x86_64 Kernel: 5.12.1-arch1-1 DE: Plasma WM: KWin CPU: Intel i9-7920X (24) @ 4.300GHz GPU: NVIDIA TITAN X GPU: NVIDIA TITAN X Memory: 10556MiB / 31789MiB Mouse: Cooler Master MM710 ; Swiftpoint Tracer Internet Browser: Brave Version 1.24.82 Chromium: 90.0.4430.93 (Official Build) (64-bit)

Thomot512 commented 3 years ago

Issue is still present after updating to kernel: 5.12.2-arch1-1.

systemofapwne commented 3 years ago

I noticed this too some weeks ago. The fix should be in the testing-branch. Earlier, I was only able to trigger it via this video: https://sps-tutorial.com/was-ist-eine-sps/ . However, it started to happen, as you noticed, even with some youtube videos.

Please give the testing branch a try. If you do not have this issue anymore, I will merge testing into master.

Edit: This is the associated fix I added about 2 weeks ago https://github.com/systemofapwne/leetmouse/commit/234425fcdaf3a708b6da2f67ab6874dbed752b1c

Thomot512 commented 3 years ago

With the testing branch, the youtube video seems to not trigger the issue anymore, but the sps tutorial video still triggers the issue. (It is not happening if I play the video in full screen)

systemofapwne commented 3 years ago

Oh, that's a bummer. I need to check now, why this happens. Unfortunately, debugging this might not to be so straight forward, since triggering this seems to be system specific and depends on the situation (like playing a video). For me, it was solved with the latest code in testing :/

For now, I have seen this happening whenever a float is pushed to a call stack. That's why I rather use pass-by-pointer and inlining, where I can. However even then, floating point arithmetic seems to get screwed up sometimes, which then made me to add this ugly check/workaround. Apparently, it is not enough...

systemofapwne commented 3 years ago

Please give the latest commit in testing a try. I explicitly force code-inlining now, where it matters (read about more here, why this matters: https://yarchive.net/comp/linux/kernel_fp.html). I expect that "gcc has acted 'smart' on your end" by not inlining code (even though I added "inline" to functions) to be the reason for this bug. However, I also added an additional "is_valid" check, to test if a float is either NaN, positive infinity or negative infinity at the end of accelerate() in accel.c, just in case. Lets hope, that this bug is now fixed!

systemofapwne commented 3 years ago

~~When disassembling the module, I noticed, it still does not always inline all the code. It looks like, the always_inline attribute only is working during compilation, not when linking the different objects together. I am now looking for how to force it even here. Alternatively, it would need me to mege all c files and compile then, which I would like to avoid. I keep you updated.~~

Thomot512 commented 3 years ago

The issue is still present in the testing branch.

systemofapwne commented 3 years ago

Alright. I will quickly push another commit soon, where inlining definitely is working. Give me a few minutes. It would be nice if you then could give feedback on a short notice :)

systemofapwne commented 3 years ago

~~Latest commit is pushed to testing. All floating point operation is now properly inlined between kernel_fpu_begin() and kernel_fpu_end() -> No more function calls. I hope, this fixed the problems. I really would like to know, if this fixes your problems.~~

If not, please do the following:

run modinfo leetmouse to find the path to the module

It should return something like

filename:       /lib/modules/5.4.116-1-MANJARO/kernel/drivers/hid/leetmouse.ko.xz
license:        GPL
description:    USB HID mouse driver with acceleration (LEETMOUSE)
author:         Vojtech Pavlik <vojtech@ucw.cz>
author:         Klaus Zipfel <klaus (at) zipfel (dot) family>
author:         Christopher Williams <chilliams (at) gmail (dot) com>
srcversion:     5E3B65904A3D936A773B113
alias:          usb:v*p*d*dc*dsc*dp*ic03isc01ip02in*
depends:        hid
retpoline:      Y
name:           leetmouse
vermagic:       5.4.116-1-MANJARO SMP preempt mod_unload modversions 
parm:           debug:byte
parm:           no_bind:This will disable binding to this driver via 'leetmouse_bind' by udev. (byte)
parm:           update:Triggers an update of the acceleration parameters below (byte)
parm:           PreScaleX:Prescale X-Axis before applying acceleration. (charp)
parm:           PreScaleY:Prescale Y-Axis before applying acceleration. (charp)
parm:           SpeedCap:Limit the maximum pointer speed before applying acceleration. (charp)
parm:           Sensitivity:Mouse base sensitivity. (charp)
parm:           Acceleration:Mouse acceleration sensitivity. (charp)
parm:           SensitivityCap:Cap maximum sensitivity. (charp)
parm:           Offset:Mouse base sensitivity. (charp)
parm:           PostScaleX:Postscale X-Axis after applying acceleration. (charp)
parm:           PostScaleY:Postscale >-Axis after applying acceleration. (charp)
parm:           ScrollsPerTick:Amount of lines to scroll per scroll-wheel tick. (charp)

Please upload the kernel module at /lib/modules/<YourKernel>/kernel/drivers/hid/leetmouse.ko.xz then.

systemofapwne commented 3 years ago

While thinking the bug was fixed with inlining, I was browsing the web, until this video triggered the bug for me again.

While debugging the driver, I think I am now confident to have found the cause: This assignment is outside the kernel_fpu_begin() and kernel_fpu_end() statement. So it uses the FPU while it shouldn't and can therefore completely screw up the FPU state (or get its value screwed up by other code using the FPU at that time). I completely missed that...

This is now fixed and will be shortly available upstream. Please report back, once I have pushed the (supposed to be final) bugfix.

systemofapwne commented 3 years ago

Fix is now upstream in testing. Please check it out and report back :)

Thomot512 commented 3 years ago

I tested a few videos including the sps one, and the last one you posted, and I could not trigger this issue anymore. I will test further in the following days.

systemofapwne commented 3 years ago

I am pretty confident, that this is now fixed. Feel free to re-open anytime again. I also have merged testing into master.