Open Cloudperry opened 2 years ago
This sounds very interesting. TBH, I always hated the FPU in the kernel workarounds I had to figure out the hard way here (messing up my BTRFS volumes multiple times).
To elaborate a bit regarding the float traps:
So I really should consider migrating to fixed point arithmetic. Thank you for also providing a C library here. This really might speed up things. I will give it a look, if I find some time this weekend (I just recently moved and didn't check github).
Thanks for the reply and for seriously considering this change. I have had 2 ethernet disconnects after creating this issue (it goes completely down and I have to restart). I have github email notifications on and I can do some testing, if there is something to test about a fixed-point version of Leetmouse.
There is a wiki page on the old repository of that library, which might be helpful. If report counts multiplied by acceleration get too high for Q16.16 numbers, there are also libraries that implement Q32.32 fixed point like fixedptc. I reckon that shouldn't happen though, because Q16.16 numbers go from -32768,999985 to 32767,999985.
libfixmath sounds absolutely fine for me right now. It is also well documented and the addressable number range should be sufficiently big. Most of the times, the single events received from a mouse movement are on the order of one to two digits long. Acceleration might boost this up though. Yet I doubt, that anyone would prefer a setting, where one movement-tick/event is scaled up to 32768 (5 digits). And if someone tries that anyway, I will simply implement a hard-cap here within the precision of Q16.16. Right now I just quickly integrated the build process of libfixmath for this project locally on my machine. Once this works reliable across all build targets (manual compile & dkms basically), I will start migrating the codebase to libfixmath. That will be the least amount of work I guess.
Little update here: I integrated libfixmath into the build-process. However I just discovered, that libfixmath seems to utilize cstd headers. Thats a big no-no for kernel-space (there is no cstd). However it seems like, that this is only about data-type definitions (so far I can see it). So libfixmath probably just needs a patch to use the kernel-header's typedefs. Or maybe it does not matter at all, since libfixmath is statically compiled and might not depend on libc at all. Lets see. I might continue with that somewhere around next week, after I'm back home.
I have no idea why, but it seems that I don't get any of the float trap errors anymore. I have changed to a kernel package compiled with x86-64-v3, changed some leetmouse settings and updated a bunch of packages.
Also I was googling a bit after seeing your last comment and I saw a version of fixedptc which had some useful changes for Linux kernel use. The last commit in that repo might be very close to what you need to change about libfixmath.
Edit: Nevermind, I am still getting float trap errors. I guess I just didn't get them for a few hours while gaming yesterday.
I have no idea why, but it seems that I don't get any of the float trap errors anymore. I have changed to a kernel package compiled with x86-64-v3, changed some leetmouse settings and updated a bunch of packages.
Also I was googling a bit after seeing your last comment and I saw a version of fixedptc which had some useful changes for Linux kernel use. The last commit in that repo might be very close to what you need to change about libfixmath.
Edit: Nevermind, I am still getting float trap errors. I guess I just didn't get them for a few hours while gaming yesterday.
My plan was forking libfixmath, apply similar ifedefs as here https://github.com/cxw42/fixedptc-fork/blob/60e5d3a4ea81be72684a03b5563ee455060bf979/fixedptc.h#L135 and apply for a PR. Until then, this repo here will use my forked libfixmath. ETA on this and the next migration steps towards integration: Probably the next few days or so. I am still a bit busy to get things together in my new flat.
just wanna trowe something in
iam using a hefty jumpcurve (jump to ~5000dpi after offset) and noticed i get those float traps mostly if not only when i hit my jump curve) so i suspected to many inputs
raising the buffers to 512 fixed the issue for me
for reference. mouse set to 6400, prescaler to 1360, jumpcurve via cap to 3.5f, acceleration 100 (lel)
That is an interesting observation. So far, the floattraps have been triggered, when a certain usermode process used the FPU in some special way (some videos triggered that for me a lot) while this kernel module also wanted to use it, even though it was marked "free to use for the kernel". I already made some tests and tinkering around with the fixedfloat variant, so "float traps" will not be necessary anymore in the future.
I have no idea why, but it seems that I don't get any of the float trap errors anymore. I have changed to a kernel package compiled with x86-64-v3, changed some leetmouse settings and updated a bunch of packages. Also I was googling a bit after seeing your last comment and I saw a version of fixedptc which had some useful changes for Linux kernel use. The last commit in that repo might be very close to what you need to change about libfixmath. Edit: Nevermind, I am still getting float trap errors. I guess I just didn't get them for a few hours while gaming yesterday.
My plan was forking libfixmath, apply similar ifedefs as here https://github.com/cxw42/fixedptc-fork/blob/60e5d3a4ea81be72684a03b5563ee455060bf979/fixedptc.h#L135 and apply for a PR. Until then, this repo here will use my forked libfixmath. ETA on this and the next migration steps towards integration: Probably the next few days or so. I am still a bit busy to get things together in my new flat.
I just added a PR for my modifications for the linux kernel module support to libfixmath: https://github.com/PetteriAimonen/libfixmath/pull/37. Latest changes for the build process of leetmouse with this library are in the fixedpoint branch. I think I almost got everything now together. This was kind of painfull, but anyhow worth the weight. Up next: Rewriting the accel.c file to use libfixmath. That should be quite easy now.
Edit: My PR to libfixmath has been already merged, woohoo. That was fast.
Been testing a build from fixedpoint branch 3a4b3989bb2596985ec71517caf82d8265eaac47 and so far it's been working well on Ubuntu 22.04. ~Mouse lag & float-traps no longer an issue while watching Youtube videos for example.~ Edit: Nevermind, didn't realise accel.c wasn't using libfixmath yet. Regardless rest of the driver works fine, ignoring float-traps with some videos.
One hiccup I ran into is that the removal of ccflags-y += -mhard-float
from /driver/Makefile
in commits df93b17482a7b9d7faa34036993011603a96c4e9 & 94ef8355038137f21eaeaa24d332102405a1ef77 breaks make for me:
:: Compiling leetmouse kernel module
========================================
cp -n /var/lib/dkms/leetmouse-driver/0.9.1/build/driver/config.sample.h /var/lib/dkms/leetmouse-driver/0.9.1/build/driver/config.h
cd /var/lib/dkms/leetmouse-driver/0.9.1/build/driver && make depend
make[1]: Entering directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver'
mkdir -p libfixmath/build
cd libfixmath/build && cmake -DCMAKE_C_FLAGS="-DFIXMATH_NO_CTYPE" .. && make libfixmath
-- The CXX compiler identification is GNU 11.2.0
-- The C compiler identification is GNU 11.2.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /var/lib/dkms/leetmouse-driver/0.9.1/build/driver/libfixmath/build
make[2]: Entering directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/libfixmath/build'
make[3]: Entering directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/libfixmath/build'
make[4]: Entering directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/libfixmath/build'
make[5]: Entering directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/libfixmath/build'
make[5]: Leaving directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/libfixmath/build'
make[5]: Entering directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/libfixmath/build'
[ 0%] Building C object CMakeFiles/libfixmath.dir/libfixmath/fix16.c.o
[ 25%] Building C object CMakeFiles/libfixmath.dir/libfixmath/fix16_exp.c.o
[ 25%] Building C object CMakeFiles/libfixmath.dir/libfixmath/fix16_fft.c.o
[ 50%] Building C object CMakeFiles/libfixmath.dir/libfixmath/fix16_sqrt.c.o
[ 50%] Building C object CMakeFiles/libfixmath.dir/libfixmath/fix16_str.c.o
[ 75%] Building C object CMakeFiles/libfixmath.dir/libfixmath/fix16_trig.c.o
[ 75%] Building C object CMakeFiles/libfixmath.dir/libfixmath/fract32.c.o
[100%] Building C object CMakeFiles/libfixmath.dir/libfixmath/uint32.c.o
[100%] Linking C static library liblibfixmath.a
make[5]: Leaving directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/libfixmath/build'
[100%] Built target libfixmath
make[4]: Leaving directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/libfixmath/build'
make[3]: Leaving directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/libfixmath/build'
make[2]: Leaving directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/libfixmath/build'
cd libfixmath/build && ar x liblibfixmath.a
cd libfixmath/build && ld -r *.c.o -o libfixmath.o_shipped
touch libfixmath/build/.libfixmath.o.cmd
make[1]: Leaving directory '/var/lib/dkms/leetmouse-driver/0.9.1/build/driver'
make -C /lib/modules/5.15.0-48-generic/build M=/var/lib/dkms/leetmouse-driver/0.9.1/build/driver modules
make[1]: Entering directory '/usr/src/linux-headers-5.15.0-48-generic'
CC [M] /var/lib/dkms/leetmouse-driver/0.9.1/build/driver/usbmouse.o
CC [M] /var/lib/dkms/leetmouse-driver/0.9.1/build/driver/accel.o
In file included from /var/lib/dkms/leetmouse-driver/0.9.1/build/driver/accel.c:5:
/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/float.h: In function ‘updata_params’:
/var/lib/dkms/leetmouse-driver/0.9.1/build/driver/float.h:40:46: error: SSE register return with SSE disabled
40 | for(j = 1; j < pos; j++) *result *= 10.0f;
| ^~
make[2]: *** [scripts/Makefile.build:297: /var/lib/dkms/leetmouse-driver/0.9.1/build/driver/accel.o] Error 1
make[1]: *** [Makefile:1884: /var/lib/dkms/leetmouse-driver/0.9.1/build/driver] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-48-generic'
make: *** [Makefile:29: driver] Error 2
Hey, I was extremely "busy" the past months with holidays, conferences and work. Yes, the current libfixmath branch does not implement any libfixmath to leetmouse yet. It is currently just integrating compilation of the lib to the project and needs some more fine-tuning for linking against it. I hope, I find some time in the near future.
For me, this feature is a fundamental important change. Especially where you mention YouTube videos here: I thought, I fixed most video playback issues with the float-traps, but apparently I did not. Especially this makes this feature so fundamental important.
I tried making a port of Leetmouse to fixed-point math and it works and sort of feels like the acceleration is done correctly. However its a very hacky version and I think I wouldn't be able to fix the remaining issues with it (with my currently non existent C skills). It doesn't update the parameters at runtime and worst of all crashes the kernel after about 10 minutes of usage with no useful logs. Also the mouse wheel scaling is not implemented, but that I could have added back easily.
I thought I should still post this version, if it helps when starting to implement the change to fixed-point. I made the changes on top of the fixed point branch and changed accel.c and config.h.
There seem to be some parts of libfixmath that are not usable in the kernel. For example I tried using fix16_to_string for debug prints, but using that always made the kernel insta crash. I think I used it correctly, because I checked libfixmath tests and it used that function the same way. Also I didn't know if I could just compare fixed-point numbers with the normal operators, but the acceleration code seems to work with normal comparisons. The change to add a string representation of the params in config.h was to make the params look correct in sysfs for example. However that was just a hack, because I don't know how to convert fixed-point to string while keeping the string const.
Edit: Changed code to use spaces instead of tabs everywhere.
Thank you. I surely should finally invest some more time into leetmouse again :/ I feel sorry for letting so many people let down, just because "it simply works for me 99%" so I tended to switch to other projects.
If you ever find a 100% working method, feel free to file a PR. If not, I should be constantly nagged by people like you, to work on this project again, until I really do :)
Not sure if its caused by Leetmouse or not, but I was just moving Apex Legends to my Windows partition and then my desktop basically froze. Couldn't even switch to a different tty. I was going to check if I was hit by this Apex banwave that has been affecting Linux users.
Edit: My Windows partition survived with no damage. There were a few file entries in the Apex directory for files that didn't exist.
Thank you. I surely should finally invest some more time into leetmouse again :/ I feel sorry for letting so many people let down, just because "it simply works for me 99%" so I tended to switch to other projects.
It works for me 99% of the time as well. I just get weird problems like once a month or every 2 months and I have posted basically all of them here.
If you ever find a 100% working method, feel free to file a PR. If not, I should be constantly nagged by people like you, to work on this project again, until I really do :)
If you start working on it, my code should actually be a decent starting point. Its almost a 1 to 1 conversion of every line in the original version with the biggest difference being that I completely removed the buffer (kept the carry). It doesn't make sense with fixed-point because there isn't a need to wait for math operations to be available. I'm not 100% sure, but the crash I mentioned earlier happens only with a GCC compiled kernel (not with LLVM).
Thanks. In fact, I already played on it (libfixmath) some months ago but shifted it aside, after other, more urgent projects emerged and some unclear situations arised in Leetmouse (E.g. how to properly link a binary-lib, compiled in usermode, against a kernel module and making it 100% libc free with no side-effects such as "destroying a partition" for example ;).
Not sure if its caused by Leetmouse or not, but I was just moving Apex Legends to my Windows partition and then my desktop basically froze. Couldn't even switch to a different tty. I was going to check if I was hit by this Apex banwave that has been affecting Linux users.
Kernel logs since mounting the Windows partition Edit: My Windows partition survived with no damage. There were a few file entries in the Apex directory for files that didn't exist.
This really suggestes that the ntfs-driver you used (the "new" ntfs3 enhanced version from paragon I guess) is heavily relying on the FPU.
I have had one annoying mouse slowdown bug for a month. It only happens with Apex legends. Today I realized that its probably caused by Leetmouse and I wanted to finally get it fixed.
I now have a version of Leetmouse that works without crashing the kernel and all the current features are there except for updating parameters at runtime. Unfortunately I had to switch from Libfixmath to this single header library. Libfixmath was full of footguns (e.g. functions that would crash the kernel) and I had problems with numbers overflowing with it.
I have created a PR of this port here. I will write a description for the PR probably tomorrow. Basically all thats left for a proper port is to handle updating the parameters at runtime and converting the default parameters (from config.h) to string. Also Libfixmath needs to be removed from the build system. Fixedptc.h should be about as good as Libfixmath for the future. It has sin, cos, tan and probably everything that Leetmouse will need for adding features. Only disadvantage that I know of compared to Libfixmath is that it doesn't use lookup tables for trig functions. Also from what I read of its code I saw some comments about the trig functions having very rough precision.
I am interested to see your modifications, even though I am still in favor of libfixmath for its modularity, self-tests and more math function.
What were your specific problems with libfixmath, that made your kernel hang? Which functions specifically? I guess those relying on libc behavior, that are not in the kernel? Or str to float conversions? I thought, my PR some time ago fixed these issues. Seems like, I was wrong. I would be interested to see specific code, that generates these issues, if you still have this laying around somewhere :)
Btw: Right now, many of my recent side-projects come close to finish (hopefully), so this might be a good point to find some time for leetmouse again. I know, I said this a lot already in the past...
When testing the last accel.c version I posted here, it would crash GCC compiled kernels, but not LLVM compiled ones. It didn't happen instantly, but within a few minutes of normal use. That version of accel.c doesn't even use much of libfixmath. Just basic add, subtract, divide and multiply. Also when I tried adding debug prints to it, it would crash instantly when trying to print. The debug prints used libfixmath's fix16 to string conversion functions exactly the same way as in libfixmath tests.
My new PR is exactly the same as the previous version in terms of fixed point usage. I just replaced libfixmath functions with fixedptc. Still it is 100% stable and the accel feels exactly the same as the old float based version. Also with my previous libfixmath based port the mouse would sometimes jump 32767 units from arithmetic overflow, but that is gone in the fixedptc based version. I tried to fix that overflow in my libfixmath version by setting FIXMATH_NO_OVERFLOW, but that made it even crashier.
I have been using this driver for a couple of days and it has worked great most of the time. However yesterday my ethernet connection went down and I saw these messages in dmesg:
After that I haven't seen these float traps getting triggered much, but I'm not fully confident in this driver not breaking shit randomly. It seems that there have been many attempts at fixing problems caused by using the FPU in a kernel module, but there are still some problems.
Maybe this driver could change the math operations to fixed-point arithmetic to get rid of all the problems that come with using the FPU in kernel code. An alternative driver that uses fixed-point would be fine too. Replacing floats with Q16.16 fixed point numbers (16-bits integer part inc. sign bit, 16-bits decimal part) would probably have enough precision for the purposes of this driver. There are good C libraries for this like libfixmath. That library should be suitable for kernel code as it is made for use on embedded systems. I might look into porting this driver to fixed-point math, when I have the time for it (my only C experience is customising a qmk keyboard).
If you are interested in the precision of fixed-point numbers I did play a bit with them and here are the results (using fpn):
Update: It seems that playing CS:GO triggers the float traps much more often than playing Overwatch. I haven't gotten any more ethernet disconnects for now.