hid-tmff2
hid-tmff2 copied to clipboard
Kimplul
Correctly identify/label T2PA pedals
Follow up to https://github.com/berarma/oversteer/issues/73, sorry for the delay @Kimplul.
I managed to get a packed capture of the initial USB communication with Linux, I can see that it does include things like the vendor id so the connected pedals might be in there as well: t300rs_t2pa_linux.pcap
I'm having trouble capturing the equivalent communication with Windows on VirtualBox (never done this), I can connect the wheel to the VM but the wheel doesn't reinitialize, even though I can see all the buttons and axis functional on the driver software inside Windows.
I'm following this guide, I can't do step 4 which is probably what is causing the wheel to not reinitialize, but none of the USB interfaces show up on ifconfig -a like they do on wireshark.
If I remember correctly the name of the device changes after the initial init so you need to attach it, let it initialise then attach it again inside the VM.
I'm following this guide, I can't do step 4 which is probably what is causing the wheel to not reinitialize, but none of the USB interfaces show up on
ifconfig -alike they do on wireshark.
I don't think you need that step. I guess it's for network devices, in the example the device is a network dongle.
Enabling it in VirtualBox should disconnect it from Linux. But I haven't had much success testing my Logitech on a Virtualbox VM, it only works partially.
Hi, thanks for taking the time to help out with this project.
As @Raboebie mentioned, the initialization essentially disconnects the wheel, kickstarts it into the 'real' configuration and reconnects it with the updated configuration, due to which the wheel's USB PID and name changes. This, as far as I'm aware, is pretty rare and you will have to connect the device again, with the new PID/name to the virtual machine.
The pedal info could be in the packets you already captured, but I'm hoping that the info can also be fished out after initialisation, as that would probably make it easier to implement pedal switching. The T300-stage driver is completely unaware of the Init-stage driver, and I'm not sure if any data can be transferred between them.
Completely different functionality, mainly. The init driver is responsible for initializing the wheel, whereas the main driver is responsible for handling the actual FFB commands. It turns out that essentially all Thrustmaster wheels behave completely differently, and share essentially no common components besides the init. Me and @scarburato had a discussion about whether we should try to combine all Thrustmaster drivers (at least the main ones, T150/T300/possibly others) into one, but I suppose it would've been too messy and we decided to keep them separated.
Completely different functionality, mainly. The init driver is responsible for initializing the wheel, whereas the main driver is responsible for handling the actual FFB commands. It turns out that essentially all Thrustmaster wheels behave completely differently, and share essentially no common components besides the init. Me and @scarburato had a discussion about whether we should try to combine all Thrustmaster drivers (at least the main ones, T150/T300/possibly others) into one, but I suppose it would've been too messy and we decided to keep them separated.
I was referring to the the init and ffb driver. Those could be together, maybe not in the same files but compiled into the same module. The logitech module is actually composed of several parts, a common one to all Logitech input devices and the particular implementations, then all get compiled into a module. That would make it possible to share information. Just saying in case you want to see an example.
Right, yes, I meant that each driver would need the same init code, and to avoid duplicating it into each driver (T150/T300/etc) we kept the init as a separate driver. Your suggestion would also work, I'm sure.
@Raboebie After I connect the wheel to the Windows VM the device id in lsusb doesn't change and it doesn't do the usual calibration routine (rotating to both sides) when I physically plug in the USB cable. But it is connected to Windows, if I open the official driver's app it does detect the wheel rotation, buttons being pressed, etc. And it does indeed disconnect from Linux, Oversteer no longer detects it until I disconnect the wheel from Windows again.
I tried physically disconnecting and re-connecting the pedals to the wheel while Wireshark was running and I didn't see any messages, but my filtering might be wrong because I also don't see messages when pressing buttons on the wheel (Unless Oversteer is also running, but even then I see nothing when reconnecting the pedals.). My filter is usb.src == "1.<lsusb device id>.0" or usb.dst == "1.<lsusb device id>.0".
Anyway, here's a capture of the messages exchanged when I tell VirtualBox to connect the wheel to Windows: t300rs_t2pa_windows.zip
Is there an quick way of diffing my capture from yours? I don't mind going through them manually but I might miss something relevant.
But now that I think about it the wheel itself doesn't identify the pedals, right? It has the mode button on the left and the instructions explain how to set it for different pedal sets:
https://ts.thrustmaster.com/download/accessories/manuals/t300rs/t300_rs_manual.pdf (page 15) https://ts.thrustmaster.com/download/accessories/Manuals/T_LCM/T-LCM_RJ12-pedal_set_mode_detection.pdf
But hopefully it does at least report the selected mode.
My filter is usb.src == "1.
.0" or usb.dst == "1. .0"
This might be too restrictive. The last number, which you've set to zero here, is the USB endpoint number. The wheel uses endpoints 0 through 2. Endpoint 1 is for FFB, but I'm not sure about configuration and/or button IO.
Is there an quick way of diffing my capture from yours?
At least not any particularly quick ways that I'm aware of. It might be possible to fiddle around with pcapdump, but I'm not too familiar with it to be honest. You should be able to get some of my captures from the pcaps branch, they're a bit messy but t300rs_kimplu.pcapng should be the packets after the wheel has initialized. There has apparently been a firmware update after I captured the packets, so I should probably try to get a new capture in case something's changed.
It has the mode button on the left and the instructions explain how to set it for different pedal sets
It never occurred to me that you'd have to manually set the pedal set, interesting. Does fiddling with the mode fix the original issue, #24?
Ok, I'll try to get a more complete capture and figure out how to diff them, thank you :)
edit: Made a new capture with the filter usb.addr matches "1\.19\..*", it definitly catches more messages, including ones that mention the axis/button states:
t300rs_t2pa_windows_all_endpoints.zip
It includes: X Axis, Y Axis, Rz Axis and Slider Axis (along with the buttons)
Does fiddling with the mode fix the original issue, #24?
It does not, I did try it at the time, it's mentioned there:
I've also tried to select the green pedal mode but it didn't make a difference."
I also remember trying the load cell mode but as expected that just didn't work.
It does not, I did try it at the time, it's mentioned there:
Right, sorry, should've read your issue more thoroughly.
Anycase, I added a couple captures with the newer firmware to the pcaps branch. t300rs_fw33_init.pcapng is the init in Windows, and t300rs_fw33_main.pcapng is the second stage. I couldn't see anything too obvious at a cursory glance, but I'll dive deeper into the captures in a couple days, I have some coursework deadlines coming up.
Hi, sorry for the delay. Here's where I'm at at the moment:
Ignoring endpoint 2, which is used for button input etc. I couldn't really find any info in the HID data of the USB packets. I did notice that the long litany of 49000301010006021300000005050000/48400000000000 pairs is interrupted at slightly different times, but I don't know if this has any meaning. I've scratched my head about the pairs for a while, they seem to always be 27 (assuming I counted them right) with one interruption somewhere approximately in the middle. My driver doesn't send these out anymore, although I did try that at one point but couldn't find any change in the wheel behaviour. Could be some calibration data, calculating the time difference between packets or something. Anycase, I don't really think this contains any pedal info.
I also checked if there were maybe some non-hid raw USB data to go through, with some wIndex or wValue info but couldn't find any. Wireshark seems to want to interpret all packets with HID Data. I'm not familiar enough with the USB spec to know for certain if this is a bug or if the HID spec overwrites wIndex etc and that's why Wireshark refuses to show the raw values. Don't know, will still need to research this a bit further but it's not looking too promising at the moment.