Pedal recognized as button about hid-tmff2

[Kimplul]

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:

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.

Yeah, Thrustmaster has this weird thing where pretty much all wheels start off in the 065d mode you've identified, from where they have to be told by an init driver to jump into their 'actual' mode, and that's where this driver (or some equivalent) takes control and handles FFB and so on. The init driver is hosted over in https://github.com/scarburato/hid-tminit/tree/master. The 065d mode is not supported by Oversteer, probably because the wheel isn't really supposed to be used in that mode. The mode does have some button/pedal input capabilities, but I'm not surprised it doesn't work as expected.

When tested with the same different product, the pedal operates normally, but at lsusb it comes out as 044f:065e.

065e is the wheel in its 'actual' state, and is the state you should be trying to use. Even though there's no FFB driver for the T500, at least yet, the hid-generic driver built into Linux should be able to correctly handle the pedals and at least allow the wheel to work as an input device in the correct state.

So, in short, the 'solution' is to use the 065e mode.

[NeighborDva]

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

[Kimplul]

So Is the driver you developed for force feedback?

Yep.

Then, in order to always be recognized as b65e rather than b65d, can I understand that I use the init driver mentioned above?

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.

[NeighborDva]

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

[Kimplul]

"hid-thrustmaster 0003:044F:B65D.0004: Unknown wheel's model id 0x0 unable to proceed further with wheel init"

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 hid-tminit is not able to provide.

"Error: Driver 'hid-thrustmaster' is already registered, absorting"

There's a built-in kernel driver hid-thrustmaster which is more or less just hid-tminit but an older version of it, either version should still be able to at least initialize the T500. The error message can be ignored, or you can try blacklisting the kernel module as mentioned in the README.

[NeighborDva]

product that has been modified for testing
--> Modifications for simulator driving (change to actual car Steering wheels and rotating shafts)

you can try blacklisting the kernel module as mentioned in the README.
I will do it tomorrow. Thank you

[NeighborDva]

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.

[Kimplul]

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?

A couple things spring to mind.

First, just to check, you replaced WHEEL_ID with 065e, right?

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.