[Discussion] Kernel Upstreaming

[pastaq]

Greetings! This is a bit long winded but bear with me.

Background

I'm here to start a discussion regarding starting the process of upstreaming the work that has been done here and in the t150 driver. As many of us ThrustMaster owners are aware, there are quite a few out of tree drivers floating around that provide basic functionality for these wheels. It would be nice to have a unified kernel driver so that DKMS and/or userspace daemons are no longer required. This is likely to be a long process that will take a large community effort.

Current Scope

Here are all the projects I'm aware of that deal with modern ThrustMaster wheels.

• Xpad in-tree kernel driver: Basic support for a few xb360 & xone wheels. These will probably remain untouched, I'm not sure if they are even FFB capable (some of them are gamepads).
• hid-thustmaster in-tree kernel driver: Initialization support for T150RS, T300, T300RS (+ accessories), T500RS.
• hid-tmff2: Provides HID subsystem FFB feature support for T300RS, T248, TX, T128, T-GT II and TS-XW
• TMX-driver: Initialization support for TMX wheels only.
• tmdrv: Initialization support for T500RS, TX, TMX, TS-XW (doesn't appear to be maintained anymore).
• t150_driver: Provides HID subsystem FFB feature support for T150 and TMX.
• hid-tminit: Precursor to hid-thrustmaster, no longer maintained but provides support for kernels pre-5.13 for the same wheels.

There may be others, but these are the main ones.

There have been issues related to combining some of these dkms modules/features over the years, or improving support in the kernel, that haven't really come to fruition yet:
#48
#78
scarburato/t150_driver#2

Why Upstream?

Owning a ThrustMaster FFB wheel at this point in time means tinkering with your system, at least a little, to get support. There is no "out of the box" solution that works now, and the current ones are not guaranteed to continue working through kernel updates. API/ABI's change and out of tree drivers need to be maintained separately as kernel maintainers have no obligation to out of tree functionality. Luckily the input subsystem is fairly stable so this doesn't appear to have been a huge issue, but it will always be a moving target. It is also difficult for users to find the right combination of initialization and functionality drivers, depending on the wheel, due to the fracturing of the ecosystem.

Proposed Solutions

Problem Statement

All modern ThrustMaster wheels start in some kind of basic state. hid-thrustmaster handles the "GIP" hid_device state of these wheels which detects the model, then submits a change request to cycle it into a second hid mode where this or the t150 drivers take over. The TM and TMX devices start as a USB HID device and have a two stage initialization where the first mode change is expected to hand off to hid-thrustmaster when it switches to the hid subsystem. Through happy circumstance I found that the first state doesn't appear to be strictly necessary. Through testing I found that the TMX wheel in GIP mode doesn't support the command to get the model number, it will error out with a bad URB. As a fluke I tried sending the stage 2 change bit that GIP mode would take to the USB HID init mode and it actualy switched to the final state without problems. I'm still waiting for a tester for the TX wheel, but if this works for both then the "xbox" style wheel is solved for init and the TMX-Driver/tmdrv projects can be dropped from the above list as necessary.

What Next

The driver I'm currently writing for upstreaming to init the TMX/TX wheels is a USB HID driver. Once/while that is merged I plan to start work upstreaming the TMX/T150 family functionality currently provided by t150. The final state for both the t150 driver and the tmff2 driver bind to the hid subsystem, just like hid-thrustmaster. My plan then is to refactor hid-thrustmaster into its own mini-subsytem. The basic structure would look like this:

- /drivers/hid/hid-thrustmaster.c: Current driver
+ /drivers/hid/thrustmaster-ffw-hid/..
+  ./thrustmaster-ffw-hid-core.c/h: Contains driver entry-point for all wheels and type enumeration, common structs and callback function definitions
+  ./thrustmaster-ffw-hid-init.c/h: Contains the current functionality of hid-thrustmaster for devices that start in the hid subsystem
+  ./thrustmaster-ffw-hid-t248.c/h: Contains the current functionality of hid-tmff2 for t248 and similar wheels
+  ./thrustmaster-ffw-hid-t300.c/h: Contains the current functionality of hid-tmff2 for t300rs and similar wheels
+  ./thrustmaster-ffw-hid-tmx.c: Contains the current functionality of t150_driver for TMX and T150 family
+  ./thrustmaster-ffw-hid-tsxw.c/h: Contains the current functionality of hid-tmff2 for tsxw and similar wheels
+  ./thrustmaster-ffw-hid-tx.c/h: Contains the current functionality of hid-tmff2 for TX wheels

This won't all happen at once. I plan to submit a patch series to refactor the current hid-thrustmaster first, then add one driver family at a time until everything is covered, starting with my own wheel. At least one driver implementation is probably a prerequisite for fully implementing, but once we have a solid/coordinated plan I'll submit the refactor alone as an RFC and see if they will take it without.

What I need help with

First and foremost, I want to make sure the original authors for each driver/subdriver are credited for their efforts. There isn't a lot of copywrite notice in the source code so I'll need information on that. I'm not here to take credit for the hard work that has been done previous to me. I'm merely offering to coordinate the effort so we can all benefit from it.

Secondly, I only own one wheel, the TMX. I'll need folks to test their wheel against the driver, provide insight for the functionality they wrote, provide kernel review/tested by tags, etc.

Thirdly, feedback and experience.

Who am I and why should you trust me to follow through

I've been in the ThrustMaster Linux family for a while at this point and have slowly worked towards this goal. I'm also fairly comfortable with the LKML at this point and work on input systems quite frequently these days. I'm certainly not going to promise inclusion in a specific kver, but I think I have a decent plan and the experience necessary to lead a sustained effort towards getting proper kernel level support for our racing wheels.

[Kimplul]

I'm all for it. I've toyed around with the idea of upstreaming for about as long as this thing has existed, but there's always been something. Someone asked for a new feature, some new wheel is about to start working, etc. Combined with my glacially slow development pace, the 'ecosystem' is admittedly in a bit of a rough spot. Especially lately a lot of the issues have been about installing on gaming-focused systems that don't really make it easy to work with external modules (boo, but whatever, I guess it's what kids these days want :) so someone kicking things into gear is fantastic.

A couple things jumped to mind reading through the problem statement:

1. At least the T128X shows up as a regular USB device instead of a HID device, so I've been using a second init driver,usb-tminit, as a dependency lately. Doesn't seem that you can use a HID driver for a raw USB device, unfortunately.
2. At least some devices (in certain modes (?)) don't go through the GIP. T248 in PS4 mode, IIRC (although the PS4 mode has some other issues and I've been telling people to use the PC mode instead).
3. Some devices share USB IDs. There was recently a request to get some T-GT II buttons working, where the issue was that the T-GT II shows up as a T248, and this driver tells the kernel to use the T248 rdesc, which is missing a few inputs. I'm currently waiting on some feedback before I do anything else, but I'm planning on adding some kind of more generic system that 'multiplexes' (if that's the right word) these devices by asking the wheel directly what model/attachment it thinks it is instead of relying on the USB VID/PID, but that's as of yet unimplemented.
4. There's been some debate regarding (minor?) details of the FFB API and how different drivers implement it. There's some discussion in Effect corrections part2 #107 (bit of a long one, sorry) that might become relevant while upstreaming.

I'd be happy to test/help with my wheels, I own a T300 and a T248.

I had a quick look and I've had contributions from @gou4shi1, @MmAaXx500, @davidedmundson and @yassineimounachen. Hope I'm not missing anyone. IIUC the GPL allows copying the code as is (since the kernel is GPLv2) but if someone would like to put their name on things, now would be a good time. IANAL etc.

[pastaq]

1. At least the T128X shows up as a regular USB device instead of a HID device, so I've been using a second init driver,`usb-tminit`, as a dependency lately. Doesn't seem that you can use a HID driver for a raw USB device, unfortunately.

Do you have a link? This sounds similar to the TMX/TX devices. If it is and it's not upstreamed I can throw it into usb-thrustmaster.

2. At least some devices (in certain modes (?)) don't go through the GIP. T248 in PS4 mode, IIRC (although the PS4 mode has some other issues and I've been telling people to use the PC mode instead).

Interesting. I think for now we can support known working implementations and work on filling out new features/modes later.

3. Some devices share USB IDs. There was recently a [request](https://github.com/Kimplul/hid-tmff2/issues/151) to get some T-GT II buttons working, where the issue was that the T-GT II shows up as a T248, and this driver tells the kernel to use the T248 `rdesc`, which is missing a few inputs. I'm currently waiting on some feedback before I do anything else, but I'm planning on adding some kind of more generic system that 'multiplexes' (if that's the right word) these devices by asking the wheel directly what model/attachment it thinks it is instead of relying on the USB VID/PID, but that's as of yet unimplemented.

If there is a ready available command then that will be simple. A less elegant way might be to use the T-GT II rdesc for both and have those buttons "missing" on the T248.

4. There's been some debate regarding (minor?) details of the FFB API and how different drivers implement it. There's some discussion in [Effect corrections part2 #107](https://github.com/Kimplul/hid-tmff2/pull/107) (bit of a long one, sorry) that might become relevant while upstreaming.

I'll take a look, thanks. Should be useful.

I'd be happy to test/help with my wheels, I own a T300 and a T248.

Sweet. Might be a while for those specifically since I'll be focusing on my wheel first, but once I have the new pattern down for the core/init stuff feel free to treat my kernel fork as the working tree and we can submit co-developed by.

I had a quick look and I've had contributions from @gou4shi1, @MmAaXx500, @davidedmundson and @yassineimounachen. Hope I'm not missing anyone. IIUC the GPL allows copying the code as is (since the kernel is GPLv2) but if someone would like to put their name on things, now would be a good time. IANAL etc.

That's a great starting list. I'd certainly prefer that original attribution is maintained.

[pastaq]

I found your usb_tminit and updated my branch to add the PID and wValue for the T128X. If someone can build that kernel and test it that would be swell.

https://github.com/pastaq/linux/blob/pastaq/tmx/drivers/input/joystick/usb-thrustmaster.c

[pastaq]

@Kimplul how many "families" of device would you say there are? Based on my cursory look there seems to be
TMX
TM
T248? (128, T-G PII)
T300RS (T248 ish?)
T500? Can't find a driver.
TS_XW

[Kimplul]

All wheels that this driver supports use the same USB command set as the T300, plus the TS-PC which ATM lives in its own branch (see #65) and possibly the T818 (see #97, #58).

There's been some digging into the T500 and it appeared to not share the T300 command set, though it might use the T150? Not sure, see #18 (my, that's an old issue) and https://github.com/cazzoo/hid-tmff2.

Don't know about the TM, but presumably it falls into either the T300 or T150/TMX camp? Or are you using some other definition of 'family'?

[pastaq]

I'm somewhat done with the "Surgery" portion for the driver reorg. Would be good to get some testing done on other devices to make sure they still init properly and the core driver detects the final wheel type.

This is the branch:
https://github.com/pastaq/linux/tree/pastaq/tmx

Summary of changes:

• hid-thrustmaster.c was moved to thustmaster-ffw-hid/ and broken up into -core.c/h, -init.c/h
• hid-tmff.c had the Kconfig option from hid-thrustmaster as a depends on, so I needed to incorporate it as well. That is now thustmaster-ffw-hid-tmff.c/h and will be bundled into thrustmaster-ffw-hid.mod.o
• While moving those drivers, I modernized them to use devm allocated memory so kfree isn;t a thing now and I don't attach the URB to the driver data anymore, it will just be freed/added when needed. I also had to change how the ff_effect was applied to the tmff devices as it was using .driver_data, which I need to use for the actual drvdata struct.
• I added all known "ready" wheel ID's to the module. They should trigger a print statement with the wheel type they detect as now.
• I moved my WIP usb-thrustmaster into the same subfolder and called it thrustmaster-ffw-usb.c, it needs it own module. I added (hopefully working) support for TS_XW and T128X as well.

Here is the folder:
https://github.com/pastaq/linux/tree/pastaq/tmx/drivers/hid/thrustmaster-ffw-hid

If I can get a couple devices tested that were initialized by hid-thrustmaster, that would give me good piece of mind that I'm on the right track. I'm especially concerned about the urb for model discovery since that doesn't seem to work on my wheel (but it might not be supported, TMX-Driver and tmdrv didn't need to do that step).

[pastaq]

All wheels that this driver supports use the same USB command set as the T300, plus the TS-PC which ATM lives in its own branch (see #65) and possibly the T818 (see #97, #58).

To clarify, is TS-PC/T818 the same command set?

There's been some digging into the T500 and it appeared to not share the T300 command set, though it might use the T150? Not sure, see #18 (my, that's an old issue) and https://github.com/cazzoo/hid-tmff2.

I'll take a look and see.

Don't know about the TM, but presumably it falls into either the T300 or T150/TMX camp? Or are you using some other definition of 'family'?

Its in this driver, so I assume T300

So we seem to have 2-3 "families" of modern wheel:

T150/TMX
T300 et al.
Maybe T500

• Legacy wheels

[pastaq]

Comparing the T500 dumps to the ones I posted in #78, I don't think its a T150 wheel

[Kimplul]

To clarify, is TS-PC/T818 the same command set?

As far as I'm aware, yes, but those wheels just aren't 'officially' supported at the moment.

Don't know about the TM [...]

Its in this driver, so I assume T300

Hang on, I'm a bit confused. I had a look through Thrustmaster's wheel models on their support page and I can't see a base by that name, just TMX. There are wheel attachments that have a TM prefix which screw into a T300 base, is that what we're talking about here? I don't recall adding support for just a TM base.

Comparing the T500 dumps to the ones I posted in #78, I don't think its a T150 wheel

Unfortunate, looked superficially very similar. Maybe the T500 is in a class of its own then? Kind of odd, but Thrustmaster devices are kind of weird anyway.

[pastaq]

To clarify, is TS-PC/T818 the same command set?

As far as I'm aware, yes, but those wheels just aren't 'officially' supported at the moment.

Don't know about the TM [...]

Its in this driver, so I assume T300

Hang on, I'm a bit confused. I had a look through Thrustmaster's wheel models on their support page and I can't see a base by that name, just TMX. There are wheel attachments that have a TM prefix which screw into a T300 base, is that what we're talking about here? I don't recall adding support for just a TM base.

Uh, typo and sore eyes, I meant TX sorry.

Comparing the T500 dumps to the ones I posted in #78, I don't think its a T150 wheel

Unfortunate, looked superficially very similar. Maybe the T500 is in a class of its own then? Kind of odd, but Thrustmaster devices are kind of weird anyway.

I could be wrong, but the start/stop messages for effects seem to be a different length than the T500 stuff. I'm not an expert when it comes to interpreting USB packets though.

[rcardenes]

Hi @pastaq. I've just got a brand new T128X GIP (044f:b69c) + T2PM + TH8S combo, and I'm willing to do some heavy testing if needed. I just downloaded your tmx branch and gave it a try.

So far I'm focusing only on the wheel and pedals though, to make it simpler.

When connecting the wheel I see:

[ 5820.155651] usb 5-1: new full-speed USB device number 9 using xhci_hcd
[ 5820.316854] usb 5-1: New USB device found, idVendor=044f, idProduct=b69c, bcdDevice= 1.01
[ 5820.316862] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5820.316866] usb 5-1: Product: Thrustmaster T128X GIP Racing Wheel
[ 5820.316869] usb 5-1: Manufacturer: Thrustmaster
[ 5820.316872] usb 5-1: SerialNumber: 0000B8DCA51975C9
[ 5820.341228] input: Generic X-Box pad as /devices/pci0000:00/0000:00:08.3/0000:e5:00.0/usb5/5-1/5-1:1.0/input/input44
[ 5820.341319] usbcore: registered new interface driver xpad
[ 5820.343239] usb-thrustmaster 6-0:1.0: device product to match: xHCI Host Controller
[ 5820.343242] usb-thrustmaster 6-0:1.0: xHCI Host Controller not a match
[ 5820.343244] usb-thrustmaster 6-0:1.0: device product to match: xHCI Host Controller
[ 5820.343245] usb-thrustmaster 6-0:1.0: xHCI Host Controller not a match
[ 5820.343246] usb-thrustmaster 6-0:1.0: device product to match: xHCI Host Controller
[ 5820.343247] usb-thrustmaster 6-0:1.0: xHCI Host Controller not a match
[ 5820.343249] usb-thrustmaster 6-0:1.0: device product to match: xHCI Host Controller
[ 5820.343250] usb-thrustmaster 6-0:1.0: xHCI Host Controller not a match
[ 5820.343278] usbcore: registered new interface driver usb-thrustmaster

and end up with these modules loaded:

thrustmaster_ffw_usb    12288  0
xpad                   49152  0
ff_memless             16384  1 xpad

So at least the usb-thrustmaster module seems to be picking up the wheel. Not quite sure why the xHCI messages though, the wheel is connected to a different hub:

$ lsusb
...
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 011: ID 044f:b69c ThrustMaster, Inc. Thrustmaster T128X GIP Racing Wheel
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
...

jscal reports...

Joystick has 8 axes and 11 buttons.
Correction for axis 0 is broken line, precision is 16.
Coeficients are: -128, 128, 16513, 16513
Correction for axis 1 is broken line, precision is 16.
Coeficients are: -128, 128, 16513, 16513
Correction for axis 2 is broken line, precision is 0.
Coeficients are: 511, 511, 1050628, 1050628
Correction for axis 3 is broken line, precision is 16.
Coeficients are: -128, 128, 16513, 16513
Correction for axis 4 is broken line, precision is 16.
Coeficients are: -128, 128, 16513, 16513
Correction for axis 5 is broken line, precision is 0.
Coeficients are: 511, 511, 1050628, 1050628
Correction for axis 6 is broken line, precision is 0.
Coeficients are: 0, 0, 536870912, 536870912
Correction for axis 7 is broken line, precision is 0.
Coeficients are: 0, 0, 536870912, 536870912

At any rate, so far the other software only seem to find the wheel as a generic X-Box pad. I've got ETS2 to try it on, but only the gas pedal seems to have any effect. Oversteer won't detect it either.

Please let me know if you want me to do any specific tests/setup

[pastaq]

Hi @pastaq. I've just got a brand new T128X GIP (044f:b69c) + T2PM + TH8S combo, and I'm willing to do some heavy testing if needed. I just downloaded your tmx branch and gave it a try.

So far I'm focusing only on the wheel and pedals though, to make it simpler.

Awesome, any support is welcome.

When connecting the wheel I see:

[ 5820.155651] usb 5-1: new full-speed USB device number 9 using xhci_hcd
[ 5820.316854] usb 5-1: New USB device found, idVendor=044f, idProduct=b69c, bcdDevice= 1.01
[ 5820.316862] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5820.316866] usb 5-1: Product: Thrustmaster T128X GIP Racing Wheel
[ 5820.316869] usb 5-1: Manufacturer: Thrustmaster
[ 5820.316872] usb 5-1: SerialNumber: 0000B8DCA51975C9
[ 5820.341228] input: Generic X-Box pad as /devices/pci0000:00/0000:00:08.3/0000:e5:00.0/usb5/5-1/5-1:1.0/input/input44
[ 5820.341319] usbcore: registered new interface driver xpad

Seems xpad picked it up first. Let me adjust the name of the wheel and see if we can pick it up with this driver. Xpad grabs everything thrustmaster USB, which is pretty obnoxious. If it's grabbed by this driver it should, in theory, disconnect the GIP device and load into the hid module.

[ 5820.343239] usb-thrustmaster 6-0:1.0: device product to match: xHCI Host Controller
[ 5820.343242] usb-thrustmaster 6-0:1.0: xHCI Host Controller not a match
[ 5820.343244] usb-thrustmaster 6-0:1.0: device product to match: xHCI Host Controller
[ 5820.343245] usb-thrustmaster 6-0:1.0: xHCI Host Controller not a match
[ 5820.343246] usb-thrustmaster 6-0:1.0: device product to match: xHCI Host Controller
[ 5820.343247] usb-thrustmaster 6-0:1.0: xHCI Host Controller not a match
[ 5820.343249] usb-thrustmaster 6-0:1.0: device product to match: xHCI Host Controller
[ 5820.343250] usb-thrustmaster 6-0:1.0: xHCI Host Controller not a match
[ 5820.343278] usbcore: registered new interface driver usb-thrustmaster

and end up with these modules loaded:

thrustmaster_ffw_usb 12288 0
xpad 49152 0
ff_memless 16384 1 xpad

So at least the usb-thrustmaster module seems to be picking up the wheel. Not quite sure why the xHCI messages though, the wheel is connected to a different hub:

I've seen this on my end as well. Not sure why as the vid/PID match table is very specific. I'll try to troubleshoot this so it doesn't grab anything else.

$ lsusb
...
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 011: ID 044f:b69c ThrustMaster, Inc. Thrustmaster T128X GIP Racing Wheel
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
...

jscal reports...

Joystick has 8 axes and 11 buttons.
Correction for axis 0 is broken line, precision is 16.
Coeficients are: -128, 128, 16513, 16513
Correction for axis 1 is broken line, precision is 16.
Coeficients are: -128, 128, 16513, 16513
Correction for axis 2 is broken line, precision is 0.
Coeficients are: 511, 511, 1050628, 1050628
Correction for axis 3 is broken line, precision is 16.
Coeficients are: -128, 128, 16513, 16513
Correction for axis 4 is broken line, precision is 16.
Coeficients are: -128, 128, 16513, 16513
Correction for axis 5 is broken line, precision is 0.
Coeficients are: 511, 511, 1050628, 1050628
Correction for axis 6 is broken line, precision is 0.
Coeficients are: 0, 0, 536870912, 536870912
Correction for axis 7 is broken line, precision is 0.
Coeficients are: 0, 0, 536870912, 536870912

At any rate, so far the other software only seem to find the wheel as a generic X-Box pad. I've got ETS2 to try it on, but only the gas pedal seems to have any effect. Oversteer won't detect it either.

Please let me know if you want me to do any specific tests/setup

[rcardenes]

@pastaq Ok, I've blacklisted xpad and we get further:

[ 8133.084925] usb 5-1: new full-speed USB device number 14 using xhci_hcd
[ 8133.251191] usb 5-1: New USB device found, idVendor=044f, idProduct=b69c, bcdDevice= 1.01
[ 8133.251201] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8133.251205] usb 5-1: Product: Thrustmaster T128X GIP Racing Wheel
[ 8133.251209] usb 5-1: Manufacturer: Thrustmaster
[ 8133.251212] usb 5-1: SerialNumber: 0000B8DCA51975C9
[ 8133.263234] usb-thrustmaster 5-1:1.0: device product to match: Thrustmaster T128X GIP Racing Wheel
[ 8133.263246] usb-thrustmaster 5-1:1.0: Match, Thrustmaster T128X GIP Racing Wheel
[ 8133.263252] usb-thrustmaster 5-1:1.0: PID b664 switch_value: b
[ 8133.264885] usb-thrustmaster 5-1:1.0: Initialized Thrustmaster Wheel mode change
[ 8133.362429] usb 5-1: USB disconnect, device number 14
[ 8133.362503] usb-thrustmaster 5-1:1.0: Device Removed
[ 8133.993205] usb 5-1: new full-speed USB device number 15 using xhci_hcd
[ 8134.155355] usb 5-1: New USB device found, idVendor=044f, idProduct=b696, bcdDevice= 1.00
[ 8134.155361] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 8134.155363] usb 5-1: Product: Thrustmaster Advance Racer
[ 8134.155365] usb 5-1: Manufacturer: Thrustmaster
[ 8134.173053] input: Thrustmaster Thrustmaster Advance Racer as /devices/pci0000:00/0000:00:08.3/0000:e5:00.0/usb5/5-1/5-1:1.0/0003:044F:B696.0007/input/input49
[ 8134.173255] thustmaster-ffw-hid 0003:044F:B696.0007: input,hidraw5: USB HID v1.00 Joystick [Thrustmaster Thrustmaster Advance Racer] on usb-0000:e5:00.0-1/input0
[ 8134.173259] thustmaster-ffw-hid 0003:044F:B696.0007: PID b696 is a FFW_T300 family device

Oversteer recognizes it as "Thrustmaster Advance Racer"

I've tested it with ETS2 and it picks it up straight away. It needs a bit of fiddling to assign the axes and buttons, but it seems to work. I'll see about the FFB

[pastaq]

@pastaq Ok, I've blacklisted xpad and we get further:

[ 8133.084925] usb 5-1: new full-speed USB device number 14 using xhci_hcd
[ 8133.251191] usb 5-1: New USB device found, idVendor=044f, idProduct=b69c, bcdDevice= 1.01
[ 8133.251201] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8133.251205] usb 5-1: Product: Thrustmaster T128X GIP Racing Wheel
[ 8133.251209] usb 5-1: Manufacturer: Thrustmaster
[ 8133.251212] usb 5-1: SerialNumber: 0000B8DCA51975C9
[ 8133.263234] usb-thrustmaster 5-1:1.0: device product to match: Thrustmaster T128X GIP Racing Wheel
[ 8133.263246] usb-thrustmaster 5-1:1.0: Match, Thrustmaster T128X GIP Racing Wheel
[ 8133.263252] usb-thrustmaster 5-1:1.0: PID b664 switch_value: b
[ 8133.264885] usb-thrustmaster 5-1:1.0: Initialized Thrustmaster Wheel mode change
[ 8133.362429] usb 5-1: USB disconnect, device number 14
[ 8133.362503] usb-thrustmaster 5-1:1.0: Device Removed
[ 8133.993205] usb 5-1: new full-speed USB device number 15 using xhci_hcd
[ 8134.155355] usb 5-1: New USB device found, idVendor=044f, idProduct=b696, bcdDevice= 1.00
[ 8134.155361] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 8134.155363] usb 5-1: Product: Thrustmaster Advance Racer
[ 8134.155365] usb 5-1: Manufacturer: Thrustmaster
[ 8134.173053] input: Thrustmaster Thrustmaster Advance Racer as /devices/pci0000:00/0000:00:08.3/0000:e5:00.0/usb5/5-1/5-1:1.0/0003:044F:B696.0007/input/input49
[ 8134.173255] thustmaster-ffw-hid 0003:044F:B696.0007: input,hidraw5: USB HID v1.00 Joystick [Thrustmaster Thrustmaster Advance Racer] on usb-0000:e5:00.0-1/input0
[ 8134.173259] thustmaster-ffw-hid 0003:044F:B696.0007: PID b696 is a FFW_T300 family device

Oversteer recognizes it as "Thrustmaster Advance Racer"

That's good, init seems to work properly. I need to figure out why xpad grabs these devices first though.

I've tested it with ETS2 and it picks it up straight away. It needs a bit of fiddling to assign the axes and buttons, but it seems to work. I'll see about the FFB

FFB won't work yet, it's just the init portion done. Report descriptor fixups also aren't happening yet so axes and buttons aren't all correct. You'll still need tmff2 DKMS for the FFB until that's added. It probably won't connect unless the PID is commented from the hid module.