-
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
Pedal recognized as button #79
Comments
Hello, unfortunately this driver doesn't actually support the T500 (there's an open issue about it over in #18) meaning you won't be able to get force feedback effects working. That being said:
Yeah, Thrustmaster has this weird thing where pretty much all wheels start off in the
So, in short, the 'solution' is to use the |
Thank you for your Answer. So Is the driver you developed for force feedback? When I deleted the driver module installed through sudo make install and checked again, as you said, it came out as b65d and came out as b65e after rebooting, and the pedal was recognized as an axis event, not a button event. Then, in order to always be recognized as b65e rather than b65d, can I understand that I use the init driver mentioned above? Thank you |
Yep.
That's right. Installing this driver automatically installs the init driver as well, I can imagine it seeming like this driver would make the T500 work but unfortunately that's just misleading. |
After you gave me an answer, I reinstalled the driver and tested it. I'm aware of t500 rs as b65d until the time I post this, maybe I was lucky earlier. Of course, the extra product is normally recognized as b65e. However, the product that has been modified for testing is still recognized as b65d as mentioned above. I also updated the firmware to the latest version, and I set the id as b65d in the hij-tminit of the driver you uploaded, but the problem still occurred. When running Ubuntu, before entering the login screen "usb 1-7: device descriptor read/all, error -71" "hid-thrustmaster 0003:044F:B65D.0004: Unknown wheel's model id 0x0 unable to proceed further with wheel init" "Error: Driver 'hid-thrustmaster' is already registered, absorting" The above three error statements are output. What's the problem? Is it a problem with the product itself? The Linux environment is currently in Ubuntu 20.04 use. Thank you |
This would mean that the wheel is responding to driver queries in an unexpected manner. What exactly do you mean by "product that has been modified for testing", modified in what way? Apparently the modifications cause the wheel to require initialization in a manner that
There's a built-in kernel driver |
product that has been modified for testing you can try blacklisting the kernel module as mentioned in the README. |
After solving the problem situation, a new problem occurred. After setting up the Rotation Range through the Control Panel on Windows, I checked the Linux joy data. Regardless of the deadzone set in the process, the larger the Rotation Range setting value, the larger the minimum rotation angle at which the data begins to enter. To explain the above problem additionally, the maximum specification of rotation of the product (1080 degrees) is set so that the handle can be turned like a real car, but the data starts to come in when the handle is turned more than when set to 360 degrees. I set up the deadzone as described in README, but what is the reason for the above phenomenon? Is there a separate solution for this problem as well? Thank you. |
A couple things spring to mind. First, just to check, you replaced Second, the stuff in the README relates to evdev, but some legacy applications might still use joydev, in which case something like #42 might fix it. Third, the application itself might be adding deadzones (many games tend to do this) so check each application's settings. |
I am a SW Developer Using ROS at Linux Ubuntu 20.04
The pedal is recognized normally in a Windows environment, and the data is recognized as a button when operating the pedal only in a Linux environment, is there a way to solve that problem?
The problematic product is T500RS, but when running lsusb it comes out as 044f:065d.
When tested with the same different product, the pedal operates normally, but at lsusb it comes out as 044f:065e.
Is it a difference in perception on the driver? For products that come in 065d, it is not recognized by oversteer, and it is recognized by the Linux joy program, but the pedal data is coming out wrong.
I posted this question because I wanted to ask the opinion of the expert who developed the Linux driver.
Thank you.
The text was updated successfully, but these errors were encountered: