-
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
T500 RS support #18
Comments
Heyo, first of all, thanks bud. Second, I'm aware of tmdrv, and I actually posted a notice about my project on the project's gitlab page a while ago. @scarburato wrote a more generic init driver based on the information found by the tmdrv project. That being said, device detection is just a part of The easiest way to figure out if the T500 works the same as the T300 might be to just change Line 1599 in cf31a8e
to whichever product ID the T500 RS has, and see if the driver still works. If it does, great, if it doesn't, more drastic measure must be taken. If you decide to try this out, I recommend doing it in a virtual machine to make sure nothing of value is lost if the driver decides to crash on you. Shouldn't, but you never know. Getting the correct value to place instead of If the simple change I presented doesn't work, which I sort of doubt, you'll probably have to do a lot of reverse engineering. I did it by installing If this doesn't sound too appealing, I don't blame you. I've been looking into getting a T500 myself and trying to get it to work, but haven't actually gone through with anything yet. And it's not as if this driver is perfect either, see other open issues. About the shifter, not really sure what to point you towards, as it's somewhat out of my expertise. For a start I guess I would check if it works just by playing around with settings in games. I think I remember figuring out that shifters more or less work by just sending out a button pressed signal when the lever is put in gear, and sending a release event when put out of gear. This might not need a lot of driver logic to do, but if it turns out that the shifter does need a driver, it might be doable with a userland driver. Don't quote me on anything at this point, though. Feel free to contact me if you have any questions or suggestions, I'll try to address them as soon as possible. |
Thank you very much for the detailed walk through. I didn't tested the wheel itself in game yet but I can feel force being applied to the wheel already while steady, probably center position force... |
Wonderful, good luck. |
I've tried the modified driver from @cazzoo. The wheel seems to be initialized correctly as far as I can tell.
dmesg output:
Trying the native Dirt Rally version on Steam the wheel and the pedals seems to work as far as it reacts to steering the wheel, pressing the pedals, buttons, etc. However the wheels is stuck in the center position and FF doesn't seem to work so it's not playable/usable right now since the steering wheel is constantly pushing into the center position. Trying the same on Windows the "lock" to the center position is released as soon as the level loads. oversteer is segfaulting on my system but I guess that's unrelated as it also does when the wheel is not plugged in. Trying https://github.com/berarma/ffbtools I also couldn't apply any FF to the wheel.
seems to report no FF capabilities(?). fftest (https://sourceforge.net/projects/linuxconsole/) as mentioned at https://www.kernel.org/doc/html/v5.12/input/ff.html also does nothing:
Please let me know if there's anything I can do to help, looks things are nearly there but not quite yet. Additional note: I've also submitted a PR to add the wheel under the initialized ID to SDL: libsdl-org/SDL#4404 |
Heyo, thanks for taking an interest in this/@cazzooo's project.
Anycase, to figure out what the API differences are, you would probably have to do the process I outlined earlier in this thread. I don't know how far @cazzoo has gotten with his work, but you could always try to communicate with him about what needs to be done. You can do it in this thread if you'd like, but if you come up with some better platform that's fine as well. Other than that, just using and testing the driver is of great help. For example, #6 shows some issues I probably would've never found out about on my own, since apparently different T300 wheels work slightly differently, and I wouldn't be surprised if it's the same story with the T500. Thanks for opening the SDL PR, I still haven't confirmed if it fixes FF in some games but I can't hurt. |
I hope @cazzoo is more competent than me to figure this out, I gave it a quick spin on Windows by installing wireshark which supports usb capture nowadays as well, but after having it installed fedit didn't work anymore at all, no matter what command I sent, the wheel didn't do anything anymore. And even then I would have probably have failed on how to isolate the correct USB traffic since fedit seems to provide many options/values for the individual commands and even switching active windows between wireshark and fedit made some usb traffic being logged. So I would probably need help by explaining everything step-by-step for starters. Though I'm very interested to get things working as Linux is my main OS also for gaming and the wheel has been sitting there unused for years already but it would be nice to not also have it working for hardcore fast racing games, but for rather slow ones like e.g. the new snow runner and the truck simulators whiich would probably better fit my gaming habits these days and probably also wouldn't require everything to run 100% accurate. |
Hi @tgurr, thank you for interest in this project. Help will be greatly appreciated. |
@tgurr I've added some hex dumps for convenience but I didn't succeed getting this parsed in the driver yet. |
Hi both, |
Sure, if you already set up a Discord server send me a link, I'd be happy to join in. I took a cursory glance at the data you've put up on your repo, and seems like you might unfortunately have to modify a bit more code than maybe initially though. I got lucky enough that the T300RS uses HID requests, so each packet is the same size. The T500RS, form the looks of it, has different length packets, but |
Hi @Kimplul, |
Hi folks, also a Linux using t500rs owner here. I'm glad to see some efforts are undertaken to get this device working on Linux and I'd be happy to help with testing anything that comes up. All the best, Uwe |
I am interested also, and would be happy if I can provide anything useful :) |
Hello again, the T500 effort's been pretty quiet for a while. This bump is to call for volunteers to help reverse engineer the T500 RS USB api. The current state of the T500 effort is over at https://github.com/cazzoo/hid-tmff2. There are some initial USB packet captures and If you own a T500 and would be interested in helping us out, please have look through the wiki for how to capture packets and go about reverse-engineering them. Feel free to ask for help, I'll try to assist as well as I can. |
Hi, I'm glad to hear that you're working on reverse engineering the USB API of the T500 RS. I have a T500 and I have a dual boot with Windows and Debian on my machine. Additionally, I have the ability to run Windows within a QEMU virtual machine. I would be happy to assist you in your efforts, but I would need some explanations on how I can contribute. Could you please explain to me how I can help? Thank you very much! |
Hello @MonsorP4py, thanks for showing interest. A short overview of what has to be done can be found in the wiki: https://github.com/Kimplul/hid-tmff2/wiki#how-to-add-in-support-for-a-new-t-series-wheel TL;DR: We're mainly interested in the USB packet format, i.e. when a user requests a force feedback effect, what would the corresponding USB packet look like. You don't necessarily have to know how to program in C or Linux internals, I'll try and help with that as much as possible. A fairly good first milestone would maybe be figuring out the constant force. It's arguably the simplest and most widely used, so even with just it implemented we might already have a decently usable driver. Note that uploading an effect is done in one packet where all parameters are passed at the same time, but modifying effects is done with one parameter per packet. What's so far been uncovered can be found over in https://github.com/cazzoo/hid-tmff2 Please feel free to ask about details and specifics. |
Hello @Kimplul I have tried to make a wireshark capture for constant force. I got 4 packages I have uploaded them to https://github.com/silverlore/hid-tmff2/blob/const_force/captures/device_const_force_pos.pcapng. Can you help me prepare the capture for merge with cazzoo's branch? |
Hello, looks like you've successfully captured starting and stopping an effect. The leftover capture data looks to be identical to
Sure, what would you need help with? Note, I'm not sure how useful one capture on its own is. There's a list of some already made hex dumps in |
The help I need was if something were missing or to many data. I will try to reproduce some of the T500 hex dump. This is my first time capturing data like this so I am a little unsure if I am doing it right. |
Right, gotcha. You could argue that there's sort of both too little and too much. As previously stated, half of the packets are kind of unnecessary, but they don't really hurt anything and in these kinds of things it's usually better to add in a bit too much extra stuff than to leave out some bit that turns out to be important. Conversely, starting and stopping is largely already figured out, and we'd really need the packets that handle constant force feedback specifically, but at least we have confirmation that you're capturing more signal than noise. Keep in mind that the packet that uploads the force to the wheel is sent out when you add the effect, not when you start playing the effect. Also, you can edit an effect while it's playing to get the modification packets.
First time for everything. Don't worry, looks like you're on the right track. Play around with the captures a bit, I'm sure you'll get the hang of it. |
Hi there,
Good work so far to get T300 RS support to linux; Kudos!
I wonder if you can bring T500 RS support to your project.
I know there are some other alternatives that started to make the device detection working (https://github.com/her001/tmdrv) so maybe there something to combine with you two projects.
Personally owner of T500 RS + shifter, I'd be glad to give some help if I can anyhow, but I don't know from where to start...
The text was updated successfully, but these errors were encountered: