Switch from floating point math to fixed-point math? #14
Assignees
Labels
Comments
|
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). |
systemofapwne
added
bug
This was referenced May 20, 2022
Open
|
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. |
|
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 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 |
|
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 just added a PR for my modifications for the linux kernel module support to libfixmath: PetteriAimonen/libfixmath#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. Edit: My PR to libfixmath has been already merged, woohoo. That was fast. |
|
Been testing a build from fixedpoint branch 3a4b398 and so far it's been working well on Ubuntu 22.04. One hiccup I ran into is that the removal of |
|
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. |
|
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. accel.cExample config.hThere 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. Kernel logs since mounting the Windows partitionEdit: My Windows partition survived with no damage. There were a few file entries in the Apex directory for files that didn't exist. |
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 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. |
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: