-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: scheduling while atomic #6
Comments
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. |
Yeah, @berarma is right. From the dmesg log it seems like 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. |
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. The wheel is a variant T300 Ferrari Alcantara Edition. |
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. |
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). |
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. |
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 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 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 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. |
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. I can provide more data if needed. |
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. |
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. |
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. |
You mentioned packet 506 earlier. Is this the right number? In my file I see:
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. |
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. |
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.
|
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 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. |
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. |
Take a look at packet 52, what it seems to be the model number it's different from yours pcap (packet 3750). You had 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 |
@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 At some point I'm really going to have to clean up my code. Testing for long periods isn't pretty :D |
If you watch the request 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" |
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.
Thanks to everybody for participating in this. |
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 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. |
Yes, that was the latest commit. Here are the packets from FEdit: wheel3.zip |
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. |
If the packets are the same maybe the timings could have an influence. I've seen Also,
|
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? |
@berarma I'll try with ffbtools. |
@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'. 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 |
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. |
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. |
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.
It still works just the same.
I'll try that later and report.
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:
|
Using stopwatch to measure the duration when replaying I get about 6 seconds. :) |
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 If you want to test out changing the max number of supported effects, just change T300RS_MAX_EFFECTS in |
I recorded the exact output from
One would think this resolves the issue. Alas, there is a complication. This only works if I send it with the script directly to EDIT: When I say outputs match exactly I mean USB Interrupt OUT messages, their content, ordering and approximate timing. |
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? |
I am not sure what constitutes wheel 'response'. I am attaching wireshark recording from my session (unfortunately I had In the capture at packet 4 I manually send Looking at |
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. |
Testing f635e5d... Can you recommend any games that should be good for testing force feedback? |
Not to be a party breaker, but while effects work now, I don't get any movement and button pushes registered in oversteer. :) |
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. |
Right, test the newest commit. You might have to unplug your wheel and reboot, I at least had to. |
Aren't you skipping the first byte here? Line 102 in 4621e44
I've also noticed you're using The whole block at Line 1692 in 4621e44
|
First byte, sort of. I don't know how
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. |
I don't know the details of I might just be confused, but it seems like |
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 |
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:
Maybe some other fixes that you did along the way? |
It would be great to see if this also fixes issue #5. |
Right:
The 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. |
I find that in Another thing I noticed - but not specific to this commit as it goes back at least to f635e5d - is that running |
Line 3 in 4621e44
Edit: nevermind I was not reading the last commit, sorry |
@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 |
Sure, let's close it. Thanks. |
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:
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
The text was updated successfully, but these errors were encountered: