Hello,

This patch series adds support for the Thrustmaster, Inc. Ferrari 458 Spider Racing Wheel (USB ID 044f:b671) to the xpad driver. The implementation is inspired by the work in https://github.com/Capure/xpad.

The wheel reports steering and pedal data at non-standard offsets, so custom axis mapping is introduced via a new mapping flag.
I have tested the changes with the actual hardware on Fedora 42 (kernel 6.15.7-200.fc42.x86_64), and confirmed correct input reporting.

If you prefer a different name for the mapping flag, please let me know.

Please consider this for upstream inclusion.

Pär Eriksson (3):
  Input: xpad - Add MAP_FERRARI_458_CUSTOM_AXES mapping flag
  Input: xpad - Add Thrustmaster Ferrari 458 Spider (044f:b671) device
    entry
  Input: xpad - Implement custom axis mapping for Ferrari 458 Spider

 drivers/input/joystick/xpad.c | 35 ++++++++++++++++++++++++-----------
 1 file changed, 24 insertions(+), 11 deletions(-)

-- 
2.50.1

Hi Pär,

On 8/5/25 12:20 PM, Pär Eriksson wrote:
> Hello,
> 
> This patch series adds support for the Thrustmaster, Inc. Ferrari 458 Spider Racing Wheel (USB ID 044f:b671) to the xpad driver. The implementation is inspired by the work in https://github.com/Capure/xpad.
> 
> The wheel reports steering and pedal data at non-standard offsets, so custom axis mapping is introduced via a new mapping flag.
> I have tested the changes with the actual hardware on Fedora 42 (kernel 6.15.7-200.fc42.x86_64), and confirmed correct input reporting.
> 
> If you prefer a different name for the mapping flag, please let me know.
> 
> Please consider this for upstream inclusion.
> 
> Pär Eriksson (3):
>   Input: xpad - Add MAP_FERRARI_458_CUSTOM_AXES mapping flag
>   Input: xpad - Add Thrustmaster Ferrari 458 Spider (044f:b671) device
>     entry
>   Input: xpad - Implement custom axis mapping for Ferrari 458 Spider
> 
>  drivers/input/joystick/xpad.c | 35 ++++++++++++++++++++++++-----------
>  1 file changed, 24 insertions(+), 11 deletions(-)
> 

So I have several concerns with this series in general. First of all, it should be just one patch, but more importantly, the device *does* have standard offsets...just not standard *gamepad* offsets. GIP, the Xbox One controller protocol, uses GUIDs to specify the type of device in question. Most devices you're familiar with use the gamepad GUID, but the wheels use a different one which have a different set of mappings. So ideally, the name of the flag would be MAP_WHEEL.

However, the problem runs deeper. This is all easily detectable from the metadata. xpad *in general* does not support the metadata parsing, so we can't autodetect it without parsing it. Unfortunately, the metadata message is fragmented. xpad *in general* does not support fragmented messages. xpad is based on a very rudimentary understanding of the protocol, which is very obsolete at this point.

I have a new driver I've been working on for a few months that supports all of this stuff properly, including wheels, that I am hoping to support for the 6.17 merge window. I may be too late, but if I submit it soon you can at least pull it downstream while waiting for the 6.18 merge window. I'll see if I can get it ready before the end of the week.

Vicki

Hi Vicki,

On Tue, Aug 05, 2025 at 01:23:39PM -0700, Vicki Pfau wrote:

> I have a new driver I've been working on for a few months that
> supports all of this stuff properly, including wheels, that I am
> hoping to support for the 6.17 merge window.

6.17 merge window is closing this weekend so no new drivers can go into
it anymore, only what was in maintainer trees/linux-next.

6.18 is the earliest option.

Thanks.

-- 
Dmitry

Hi Dmitry

On 8/5/25 1:57 PM, Dmitry Torokhov wrote:
> Hi Vicki,
> 
> On Tue, Aug 05, 2025 at 01:23:39PM -0700, Vicki Pfau wrote:
> 
>> I have a new driver I've been working on for a few months that
>> supports all of this stuff properly, including wheels, that I am
>> hoping to support for the 6.17 merge window.
> 
> 6.17 merge window is closing this weekend so no new drivers can go into
> it anymore, only what was in maintainer trees/linux-next.

I see. I haven't been paying attention to how merge window timing works until now, so that's on me for not cleaning it up sooner for this cycle. My other concerns for this patchset still stand, though.

> 
> 6.18 is the earliest option.

That gives me more time to clean it up and generally get it working better, so I guess it's a trade-off here. It's still missing some features I'd like to get in so I don't have to do significant refactoring later.

> 
> Thanks.
> 

Thanks,
Vicki