BUG: scheduling while atomic

[dafteran4]

First, thanks for your work on this. It's much appreciated.

I am on arch linux, kernel Linux 5.9.1-arch1-1 #1 SMP PREEMPT.

I haven't managed to get force feedback working. Attached is the dmesg log when plugging in the wheel. There are some errors:

[   12.988878] BUG: scheduling while atomic: systemd-udevd/757/0x00000002
...
[   12.988968] Preemption disabled at:
[   12.988974] [<0000000000000000>] 0x0
...
[   12.988986] Call Trace:
[   12.988999]  dump_stack+0x6b/0x88

After plugging in, the wheel does its calibration thing and after that force feedback works to keep the wheel centered.

Oversteer shows working axes and buttons, but the force feedback setting seem to have no effect. fftest reports OK for all effects, but nothing happens when actually running an effect.

It may be of significance that wheel's firmware has been last updated a couple of years ago. I haven't had access to Windows machine since, but I'll try to find one to update to recent firmware to see if that helps.

Otherwise, I 'd appreciate any pointers on what to try to make this work. Thanks.

dmesg.txt

[berarma]

I've just taken a quick look to the code and it seems there's function calls to kernel code inside spinlock blocks.

The code inside a spinlock should be very simple and fast without a chance to sleep. Normally just setting variables that need to be protected from being changed simultaneously by different threads.

[Kimplul]

Yeah, @berarma is right. From the dmesg log it seems like hid_hw_start inside a big spinlock is the main point of interest here. I could always take out the spinlock surrounding it, I mainly wrote it as a quick and dirty way to make sure that all data is initialized before any program attempts to communicate with the wheel.

I created a new branch for testing out spinlocks and possibly other locking mechanisms if they're necessary, try this out for a start and tell me if the dmesg logs change at all.
https://github.com/Kimplul/hid-tmff2/tree/spinlocks

[dafteran4]

Yup, that took care of the errors, dmesg now looks fine. However, force feedback still doesn't work, everything seems the same as I described previously, buttons and axes showing, but no force except autocentering.

Now it seems somewhat similar to issue #5. I am attaching rdesc as suggested in that issue.
rdesc.txt

The wheel is a variant T300 Ferrari Alcantara Edition.

[Kimplul]

Well, I've been looking through the pcaps found over at https://gitlab.com/her0/tmdrv/-/issues/4 and while I can't really tell for sure, but it seems that different T300RS wheels have slightly different init procedures, which is odd. Maybe Thrustmaster has changed the controllers for the wheels over the years? Don't know, but it sure is annoying.

Anycase, I would probably need some more information of your specific wheel. Is it at all possible for you to capture some packets with Wireshark? You would need a Windows virtual machine to begin with.

[dafteran4]

I'll need some time to setup the necessary, but I am glad to provide more data. What kind of virtual machine would do - qemu?

[berarma]

I'll need some time to setup the necessary, but I am glad to provide more data. What kind of virtual machine would do - qemu?

It's very easy to setup VMs with Gnome Boxes or even libvirt (the backend to Boxes).

[dafteran4]

Indeed, it was surprisingly pleasant and hassle free. I have now a win10 installation inside a Gnome Box. Not sure how to add USB devices and what to do next with Wireshark.

[Kimplul]

I personally use virt-manager as a frontend, but https://help.gnome.org/users/gnome-boxes/stable/usb-redirection.html.en should (hopefully) work.

For the most part I would need the packets from the initialization of the wheel, so you'll probably have to delete the hid-tmt300rs.ko and hid-tminit.ko files from /lib/modules/$(uname -r)/extra. This essentially is removing my driver from your system, so now when you plug in your wheel it should show up as 'Generic Thrustmaster FFB Wheel' or just 'Thrustmaster, Inc.'.

With the generic wheel, connect it to your virtual machine, and install the Thrustmaster drivers and firmware. The wheel will probably reconnect itself under a new name, and you will probably have to connect the wheel again to the virtual machine to get the driver/firmware installation to finish properly.

With everything up to date, we can start capturing packets with Wireshark. To run Wireshark, you'll need to load the usbmon module. sudo modprobe usbmon should work. You'll probably also have to start Wireshark with root privileges.

With Wireshark running, open up usbmon0. It should be pretty much in the centre of the Wireshark window. From there, we should add a display filter so that we can focus on the wheel's traffic. Open up a teminal on your linux machine, and run lsusb. Inside Wireshark, write usb.bus_id == X && usb.device_address == Y, where X and Y come from lsusb: Bus 00X Device 00Y: ID 044f:065d Thrustmaster, Inc.

Wireshark should start recording packets automatically, but if you want to restart the recording, press the triangle in the upper-left corner of the window. The packets we want to record will be sent when you connect the 'generic' wheel to the virtual machine, and when you connect the 'proper' wheel again, after the generic wheel has initialized itself.

I would also like to see some packets from the force feedback tests in Thrustmaster's control panel, if possible.

To save the packets, stop the recording with the red square, and open File > Export Specified Packets. This will export the packets caught by the filter.

If you have any questions, just ask.

[dafteran4]

Here is Wireshark output. First event is the wheel plugged-in. Then at 56secs I redirected usb to windows machine. At that point the wheel reconfigured its usb bus/address to 2.5 so I had to adjust the filters. Then I opened up TS panel and ran a all the FF effects and moved the wheel around a bit.

usbmon.zip

I can provide more data if needed.

[Kimplul]

Wonderful, thanks.

I've had a quick look at the packets and to be honest, couldn't find anything too obviously different. That being said, packet 506 in your pcaps is slighlty different from the one I got when testing my own wheel. I can't really tell why on earth it would be, since as far as I have so far seen, all preceding packets are pretty much identical. Anycase, this packet is sent when the wheel is opened for reading/writing by a program, such as the TS panel. Sort of interesting, when I modified my driver to send out the version of the packet your logs have, I didn't get any force feedback. However, not sending it out at all, does give me FF. Why? No clue. Thrustmaster, fucking explain, please.

Anycase, I pushed a dirty fix to https://github.com/Kimplul/hid-tmff2/tree/spinlocks , which (temporarily) removes the packet. This has the side-effect of disabling autocentering when the wheel is unused, but doesn't seem to affect any effects when in games. Try it out, but I suspect more testing and digging will be needed.

EDIT: For clarity, I disabled sending packets on open/close, for testing the wheel will always stay in an "open" configuration, and the autocentering comes on when the device is "closed". The packet itself doesn't have anything to do with autocentering, as far as I'm aware.

[dafteran4]

Trying latest spinlocks brach, things look somewhat different now. In oversteer, sliders "Force feedback gain" and "Autocenter strength" both work and have the expected effect on wheel behavior. Other sliders (Spring, Damper and Friction) are disabled and cannot be moved. fftest, however, still has no effect on the wheel.

[dafteran4]

I'll try to get some wine games up to do more testing, though I guess if fftest isn't working, the games wouldn't also.

[dafteran4]

You mentioned packet 506 earlier. Is this the right number? In my file I see:

506 154.915888 host 2.5.1 USB 128 URB_INTERRUPT out

It doesn't seem relevant. Also this is pretty late in the process, I am quite sure at that time I was in the middle of clicking on various example effects.

[Kimplul]

With the leftover capture data "6012bf04000003c32000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"?

Well, you're free to be skeptical, but the packets at 504, 506 and 520 are ones that are typically sent out when a program opens the wheel. Sort of interesting, is that 506 isn't always sent out, whereas 504 and 520 are. I don't really know what it's for, but it seems like it has something to do with autocentering. That being said, there is a second method that sets autocentering, which is what my driver uses. That's also the method that you see in effect when using oversteer.

Well, interesting that we have some progress. I'll continue looking into it, but this is puzzling.

[dafteran4]

You're right. I tried again and such a packet appeared when I opened the panel. For clarity, I did another capture and noting what I was doing.

0s   - wheel plugged-in
43s  - usd redirect to win machine
95s  - another usb redirect since device address has changed
140s - opened wheel panel and moved the wheel a bit
175s - started running FF effects

wheel.zip

[Kimplul]

That's interesting. Now there isn't anything like packets 504 or 506, instead there's just one, at 634, that's like a weird combination of both 504 and 506? But 648 in wheel.zip is still the same packet as 520 in usbmon.zip.

That being said I'm starting to think that this is a red herring. I tried not sending out anything, no 504, 506, or 520, and I still get FF.

So, what I've now done is essentially try to replicate the messages I see in your logs as closely as possible. hid-tminit seems to already be pretty much identical, so I'm focusing on the hid-tmt300rs module. The newest commit in https://github.com/Kimplul/hid-tmff2/tree/spinlocks still gives me FF, and I included some interrupts that I previously thought to be unnecessary. Maybe they still are, and I'm way off the actual source of the problem, but give the newest commit a try and if that fails, I'll at least know to look elsewhere.

[berarma]

I hope I'm correctly following the conversation. The packets you're talking about might be configuration commands. You could try changing the settings in the panel, quit then open again and see how settings are being sent when changed and when starting the panel. There might be groups or individual bits dedicated to different settings.

[scarburato]

Take a look at packet 52, what it seems to be the model number it's different from yours pcap (packet 3750). You had 0x0206 meanwhile he has 0x0204 and also the others unknown fields are different.

Either my assumption on the field meaning was wrong or @dafteran4 wheel is another hardware revision

EDIT: link to recapitulatory table I wrote some time ago

[Kimplul]

@scarburato Heyo, thanks for joining. I wouldn't be surprised if it's a hardware revision. The problem is that the data leaving the computer is still, as far as I can tell, pretty much identical. At least all leftover capture data is, so if the latest commit doesn't work I'm trying to look at control urbs, and maybe interrupts. Something that would set my T300RS apart from @dafteran4 's, besides that one number.

@berarma You're most probably right, but even just copying the packets I can see from @dafteran4 's logs doesn't seem to work, which makes me really confused. I'd like to figure out what configuration works first, but if that isn't happening I suppose I might as well do as you suggested.

EDIT: Still haven't found anything that would differentiate the wheels, but I did notice a rather interesting control out. In wheel.zip, packet 224. Apparently my own pcaps feature it, I just haven't sent it out in my own driver. I doubt it's the solution to our problems, but it's a bit where I haven't managed to imitate the Windows driver. Anycase, I pushed it to Github.

At some point I'm really going to have to clean up my code. Testing for long periods isn't pretty :D

[scarburato]

If you watch the request 73 (used to ask the wheel what is seems to be the model information) is made by the Windows driver multiple time even after the init procedure, for example after packet 190 and after packet 608 it's spammed 35+ times

Maybe you driver could make this request once one during the probe and keep something to discriminate the hardware revisions

Anyway I'll add this new value to the hid-tminit as "T300 Ferrari Alcantara Edition"
EDIT: done

[dafteran4]

Tried latest spinlocks branch. Unfortunately, fftest still doesn't work. I tried another capture that might be helpful by using the module from this latest update.

• First I attached the wheel, kernel module loads,
• then I try fftest, doesn't work - wheel not moving,
• then, with the wheel still connected, I redirect usb to windows (usb address now remains the same), try effects in windows, works as expected,
• then turning off redirect, try again fftest, doesn't work,
• then turning on redirect, try again in windows, works.

wheel2.zip

Thanks to everybody for participating in this.

[Kimplul]

Hmmmm. I'm assuming by latest you mean the 'Added mysterious control out'-commit? Anycase, could you download https://gimx.fr/download/b882e209a0ac023d03abbf560dfc3f25fe6367ca/fedit.zip to your Windows machine? It's a force feedback editor, I just want to make sure that the commands that produce the wanted effects aren't different between the two wheels.

With FEdit open, add in a ConstantForce, and move it up to the beginning of the line, like so:

Doubleclick on the added force, and go to 'Direction'. Type in 9000 in the text box, and press 'Play'. Capture the packets that this produces.

Thanks for your patience with this whole ordeal.

[dafteran4]

Hmmmm. I'm assuming by latest you mean the 'Added mysterious control out'-commit?

Yes, that was the latest commit.

Here are the packets from FEdit: wheel3.zip

[Kimplul]

Welp, good news and bad news, The good news is that the packets are the same, so I probably won't have to write a whole new set of instructions for your wheel specifically. Bad news, I still don't know what the core issue is.

[berarma]

If the packets are the same maybe the timings could have an influence. I've seen t300rs_init_interrupts is sending a batch of unknown commands as fast as possible. Would inserting short waits (some tens of ms) between calls to t300rs_send_int make a difference?

Also, fftest might be doing too much and triggering multiple issues. It might be a bit too indeterministic for testing at this stage. You could try https://github.com/berarma/ffbtools. After building, you can play the effect files in the tests directory using this command:

bin/ffbplay -d /dev/input/your_device tests/constant.ffb

[dafteran4]

I'm trying to get a sense on how the read these captures, I am still a bit in the dark. Can you perhapse help me get a better understanding of the elements?

I figure "URB INTERRUPT out" are the packets where host send FFB command to the wheel. By monitoring fftest I see that it sends 60 00 ID 89 01. This corresponds to 'starting to play' in the documentation. ID is the number of the effect selected. This is pretty much everything that it sends. How does the wheel know what these IDs mean?

Is it possible somehow for me to issue these commands manually so I could try replaying the ones I see in windows?

[dafteran4]

@berarma I'll try with ffbtools.

[Kimplul]

@berarma Excellent idea, I added some short sleeps in between the interrupts. Newest commit in spinlocks as usual.

@dafteran4 Sure, you're correct about the starting of effect. The ID is given by the upload command, so for constant force it would be 60 00 NEW_ID 6a ..., in my documentation under 'Initialisation'.
A new ID can be given once an effect is stopped, with 60 00 ID 89 00 .... For some reason this command works both as a "stop the effect" and "unload the effect and free this ID".

To be honest, I don't think there is any way to send out individual commands. At least I haven't found any tool like that, but you're free to modify my code however you wish.

EDIT: Oh, and you've probably noticed that the TS force test thing doesn't really follow the documentation I have, that is because I've collected the information from FEdit. FEdit has the advantage that I can more freely test out the different effects and modify different aspects of the effects, but it seems like the Windows driver supports some sort of combining of effects, which results in different and more complex packets being sent out, such as with the effects in the TS panel. I unfortunately haven't managed to figure out how it works. Nor have I figured out how to make the wheel work at all, apparently, so I guess it balances itself out :D

[berarma]

Is it possible somehow for me to issue these commands manually so I could try replaying the ones I see in windows?

I wrote a deceptively simple command to do this for the Logitech wheels. I may try to modify it so it can work on any device and add it to ffbtools.

[dafteran4]

Commit 4356921 breaks oversteer which I previously reported had functioning Force and Autocenter sliders. With this commit oversteer opens at 40 deg angle and the wheel goes berserk :), also Force/Autocenter sliders don't work anymore. Reverting prior to this commit fixes that and sliders work again.

[dafteran4]

How exactly did you test out fftest/ffbplay? Did you open up fftest/ffbplay, then send those signals? Or signals first, then open up something?

After. First I run the imitation sequence (cf or engine), then after that I try running fftest and ffbplay. The both seem to behave weirdly, not doing their own thing, but running the effect from previous imitation sequence or nothing at all.

Also, what happens if you leave out the second command at 7 secs, 60 02 bf 00 ... ? It should just be setting the gain, just weird that it shows up there of all places.

It still works just the same.

EDIT: One more question, have you tried downloading multiple effects to the device at the same time? In FEdit, you can just add in another effect and imitate that. My thinking is that so far the tests have been with just one effect at a time, maybe the wheel behaves weird if we try to upload more than it can handle? What if the cap is something like four, fftest uploads five efffects I believe, which could mess the wheel up.

I'll try that later and report.

EDIT EDIT: Oh, I just noticed. What duration does FEdit give you? For some reason the packet has a different duration than mine.
And what happens if you set Duration to INFINITE?
I haven't looked at the timings tab then and didn't save to disk to check now. Default seems to be 4160000, though.

These are the INFINITE duration commands to start CF effect that I get from FEdit win session. I can replay on host and it works just as fine:

6000016afd3f0000fc7f0000fc7f004fffff0000200800ffff000000000000000000000000000000000000000000000000000000000000000000000000000000
600001c9004400000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

[dafteran4]

EDIT EDIT: Oh, I just noticed. What duration does FEdit give you? For some reason the packet has a different duration than mine.
And what happens if you set Duration to INFINITE?
I haven't looked at the timings tab then and didn't save to disk to check now. Default seems to be 4160000, though.

Using stopwatch to measure the duration when replaying I get about 6 seconds. :)

[Kimplul]

Thanks, seems fine. Sort of odd that your default is different from mine in FEdit, but hey, it's whatever.

I'll just quickly point out that you should remember to unload/free/stop the effects before opening up fftest/ffbplay, as uploading an effect before stopping the one in the ID slot is pretty much undefined behaviour. Seems like you did it with the constant force and FEdit, but just a reminder to be on the safe side.

Could you also try only sending out 60 01 05 ..., and see if that has any effect? My assumption is that all 0a ...and 42 01 ... packets are unnecessary. And an effect to test with, of course.

If you want to test out changing the max number of supported effects, just change T300RS_MAX_EFFECTS in hid-tmt300rs.h to something else. You could also test changing DEFAULT_TIMER_PERIOD in the same file, but I'm somewhat doubtful it would do anything. It's used to change how often effects are updated/played/sent to the device, but your wheel isn't showing any symptoms of receiving more packets than it can handle.

[dafteran4]

I recorded the exact output from ffbplay tests/constant.ffb and started testing by replaying the usb interrupt out packets with a script which sends raw data to hidraw device. The packet 60 01 05 is a must - it has to be sent after initializing the wheel, otherwise there are no effects. Everything else is unnecessary. So I would send the following with the script and get the expected behavior:

# mystery line - necessary to call the first time after plugging-in the wheel,
# otherwise nothing is played. It can be ommited on subsequent runs.
60010500000000000000000000000000000000000000000000

# exact usb interrupt OUT from ffbplay tests/constant.ffb
6002ff00000000000000000000000000000000000000000000 # set gain
6000016ad8dc0000000000000000004fffff0000000000ffff # upload effect
60000189010000000000000000000000000000000000000000 # start playing
6000010a282300000000000000000000000000000000000000 # change to next effect 
6000010a589e00000000000000000000000000000000000000 # change to next effect
6000010aa86100000000000000000000000000000000000000 # change to next effect
60000189000000000000000000000000000000000000000000 # stop playing
# note that we wait 5 secs before changing and stopping effects

One would think this resolves the issue. Alas, there is a complication. This only works if I send it with the script directly to hidraw. If I use ffbplay, it simply repeats the last played effect and doesn't switch between effects every 5s. This is true even if I send 60 01 05 immediately before running ffbplay. The bizarre thing being, if I record all this in Wireshark, the outputs from ffbplay and the script match exactly.

EDIT: When I say outputs match exactly I mean USB Interrupt OUT messages, their content, ordering and approximate timing.

[Kimplul]

I wonder if the packets that get sent out by my driver are sent out too fast?

When you send out the packets manually, does the wheel respond to them as they arrive, or does it receive some amount of packets and then sends a bunch of responses back?

[dafteran4]

I am not sure what constitutes wheel 'response'. I am attaching wireshark recording from my session (unfortunately I had usb.src == "host" enabled, so it only half of the packets, but I guess it should be enough for the purpose).

ffbplay_vs_manual.zip

In the capture at packet 4 I manually send 60 01 05 then at 6 ffbplay starts. Then at 4693 I run the whole sequence manually.

Looking at ffbplay and manual sequence, interrupt OUTs match exactly, but with manual sequence there are INs after every OUT and there are larger time gaps between OUTS.

[Kimplul]

Right, sorry, I should've been more clear.

What I meant was that when a 60 00 01 ... is sent out manually is the [Response in: NUMBER] part in wireshark immediately after the packet? So, if 60 00 01 ... is packet no. 4, is the response packet number 5?

Here's a picture that shows where to find the section I'm talking about.

In the pcaps you provided that information is unfortunately lost because of the filtering.

[Kimplul]

Heyo, sort of interesting, I looked at new-lg4ff and noticed that berarma used hid_hw_request, so I thought "well heck, I might as well" and now I'm having similar symptoms. Autocentering and changing it in oversteer works just fine, but otherwise I don't get any effects. It'd be pretty funny if this method worked for you, so try it out.

Newest commit in spinlocks. Don't mind the previous commits, I sort of messed around with mutexes and as it turns out, using them in an interrupt context crashes your machine.

EDIT: If you tried 62a2738, it probably didn't work. I had to adjust the rdesc of the device for it to function in my vm. But now I'm skeptical that this was the issue. Anyway, try it out.

[dafteran4]

Testing f635e5d... ffbplay with all examples in tests dir works great and correctly as far as I can tell. That's out of the box, no need to send any manual commands. fftest also works 0-3, Mayber number 0 (periodic sine) seems a bit weird, vibrates and moves erratically, it is not like in ffbplay, but other seems fine. All in all, this looks great.

Can you recommend any games that should be good for testing force feedback?

[dafteran4]

Not to be a party breaker, but while effects work now, I don't get any movement and button pushes registered in oversteer. :)

[Kimplul]

Holy fucking shit what a weird experience this has been. Well, heck yeah dude, we dun did it.

Personally I'd recommend Wreckfest, Dirt Rally, Dirt Rally 2 and I guess rFactor 2. The F1 series works but feels somewhat 'floaty', but from what I've read on the internet that might be intentional? Don't know.

Dirt Rally one and two are the only two games that I have experience on windows with, and they're fairly close on Linux as well, in my opinion.

Buttons, yeah, hold on, I've had something similar before. Let me check if the solution is still the same.

[Kimplul]

Right, test the newest commit. You might have to unplug your wheel and reboot, I at least had to.

[berarma]

Aren't you skipping the first byte here?

hid-tmff2/hid-tmt300rs.c

Line 102 in 4621e44

value[i] = send_buffer[i + 1];

I've also noticed you're using greport but have t300rs_device_entry->report that isn't used, same with `t300rs_device_entry->ff_field'.

The whole block at

hid-tmff2/hid-tmt300rs.c

Line 1692 in 4621e44

list_for_each_entry(report, report_list, list){

makes little sense to me but it could be my ignorance.

[Kimplul]

First byte, sort of. I don't know how hid_hw_request works exactly, but the first byte is taken from the output field in the rdesc, which I had to modify to get the output identical to the Windows commands in Wireshark. I'll have to look into it at some point.

greport is just me being lazy, I'll have to clean up the code once we get confirmation that the issue was in fact the way I sent out the packets.

That part's ripped from the Thrustmaster driver in the kernel that I somewhat based this driver on, something of a remnant I suppose. Good thing that you brought it up though, I'll experiment with it and see if it's really necessary.

[berarma]

First byte, sort of. I don't know how hid_hw_request works exactly, but the first byte is taken from the output field in the rdesc, which I had to modify to get the output identical to the Windows commands in Wireshark. I'll have to look into it at some point.

I don't know the details of hid_hw_request either, but when working on new-lg4ff I had to pass the same bytes that would work with rawcmd.

I might just be confused, but it seems like t300rs_send_int is not sending send_buffer[0]. So if you're calling t300rs_send_int with a buffer containing [0x60, 0x00, 0x01, 0x89, 0x01, 0x00,...], it would send [0x00, 0x01, 0x89, 0x01, 0x00,...] to the device.

[Kimplul]

Don't know what to tell you, but the Wireshark packets are identical. I don't know if Wireshark maybe interprets the packets wrong and shows them as the same when they're not, but my wheel works either way.

EDIT: Found this: https://elixir.bootlin.com/linux/latest/source/drivers/hid/hid-core.c#L1616
Seems like if the report id is larger than zero, it's pushed to the front of the data buffer. Don't know why it's done like that, but I guess that's the explanation for why I had to omit the first byte of my send_buffer.

[dafteran4]

With 4621e44 everything works: inputs, effects. Briefly tried Dirt Rally, seemed fine, I can't really remember what it was in windows. I'll try to get Assetto Corsa running to see if I can keep my drifts - if I can, then it's good. :)

If we summarize, what was part of the solution anyway? By my count:

• removing spinlocks,
• 60 01 05 packet,
• using hid_hw_request

Maybe some other fixes that you did along the way?

[dafteran4]

It would be great to see if this also fixes issue #5.

[Kimplul]

Right:

• Removing spinlocks from t300rs_probe and the procedures it calls fixed the initial dmesg error
• Using hid_hw_request

The 60 01 05 packet was already present, but hid_hw_request affected it too. Still not exactly sure why hid_hw_request turned out to work, but I suppose it fills out the urb in a slightly different way than usb_fill_int_urb that then didn't show up in Wireshark.

Could I still ask for one favor? Could you quickly test out ddaa7db, I cleaned up the code and want to make sure it still works on your machine. After that I suppose we can close this issue and I'll merge the changes into main.

If you find anything wrong with the force effects, such as they feel off or you know that some game should feel different than it does, just open up a new issue.

[dafteran4]

Could I still ask for one favor? Could you quickly test out ddaa7db, I cleaned up the code and want to make sure it still works on your machine. After that I suppose we can close this issue and I'll merge the changes into main.

I find that in oversteer the rotation range setting has no effect. If I go one commit back to 9b3a6c1, it works again. Otherwise all seems fine.

Another thing I noticed - but not specific to this commit as it goes back at least to f635e5d - is that running ffbplay tests/conditional.ffb works well on its own, but if you precede it by running ffbplay tests/sine.ffb, then its second stage (damper) still exhibits spring behavior.

[scarburato]

hid-tmff2/hid-tmt300rs.c

Line 3 in 4621e44

struct hid_report *greport;

Is it correct that the hid_report is shared between all the wheels connected to the host?

Edit: nevermind I was not reading the last commit, sorry

[Kimplul]

@daftera that's odd, I'll look into it. Could you open up a new issue for it? I'm pretty sure we can close this issue as I fixed the rangesetting on my machine, and I'm almost convinced it should work on yours too.

@scarburato no worries bud

[dafteran4]

Sure, let's close it. Thanks.