Asetek LaPrima Wheelbase support

[uweeby]

Rotation is detected on a gamepad tester and seems to show 99% range as intended from -1 to +1 (I have a bump stop enabled in the firmware).

iRacing calibration tool detected it as going from 50%-100% rotation which is odd. Gives error that the wheel does not support force feedback.

Windows raw values go from 0 to 65535

[JacKeTUs]

Can you please give kernel logs when you connect the wheelbase to the PC?
Also, please, install Wireshark + USBMon and create .pcap file from Linux, when you connect the wheelbase to the PC. That's how we can look into the descriptor

[uweeby]

Having a hard time figuring out how to do the pcap but here are the kernel logs.

[ 133.129908] usb 1-6.2: new high-speed USB device number 9 using xhci_hcd
[ 133.264040] usb 1-6.2: New USB device found, idVendor=2433, idProduct=fa00, bcdDevice= 1.38
[ 133.264047] usb 1-6.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 133.264050] usb 1-6.2: Product: Gaming HUB
[ 133.264052] usb 1-6.2: Manufacturer: Asetek SimSports
[ 133.274088] hub 1-6.2:1.0: USB hub found
[ 133.276933] hub 1-6.2:1.0: 7 ports detected
[ 134.183260] usb 1-6.2.1: new full-speed USB device number 10 using xhci_hcd
[ 134.524436] usb 1-6.2.1: New USB device found, idVendor=2433, idProduct=f303, bcdDevice= 2.00
[ 134.524443] usb 1-6.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 134.524446] usb 1-6.2.1: Product: LaPrima Wheelbase
[ 134.524448] usb 1-6.2.1: Manufacturer: Asetek SimSports
[ 134.524450] usb 1-6.2.1: SerialNumber: 365134633131
[ 134.614975] Asetek SimSports LaPrima Wheelbase: Invalid code 768 type 1
[ 134.614980] Asetek SimSports LaPrima Wheelbase: Invalid code 769 type 1
[ 134.614982] Asetek SimSports LaPrima Wheelbase: Invalid code 770 type 1
[ 134.614983] Asetek SimSports LaPrima Wheelbase: Invalid code 771 type 1
[ 134.614985] Asetek SimSports LaPrima Wheelbase: Invalid code 772 type 1
[ 134.614986] Asetek SimSports LaPrima Wheelbase: Invalid code 773 type 1
[ 134.614988] Asetek SimSports LaPrima Wheelbase: Invalid code 774 type 1
[ 134.614989] Asetek SimSports LaPrima Wheelbase: Invalid code 775 type 1
[ 134.614991] Asetek SimSports LaPrima Wheelbase: Invalid code 776 type 1
[ 134.614992] Asetek SimSports LaPrima Wheelbase: Invalid code 777 type 1
[ 134.615063] input: Asetek SimSports LaPrima Wheelbase as /devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-6/1-6.2/1-6.2.1/1-6.2.1:1.0/0003:2433:F303.0007/input/input25
[ 134.615259] hid-generic 0003:2433:F303.0007: unknown set_effect report layout
[ 134.615264] hid-generic 0003:2433:F303.0007: input,hiddev99,hidraw6: USB HID v1.11 Joystick [Asetek SimSports LaPrima Wheelbase] on usb-0000:02:00.0-6.2.1/input0

[JacKeTUs]

Usbmon is what you need

Looks like PIDFF again, i think it should work just fine with our patches to pidff, but first we need to see the descriptor :D

[moonrail]

Hey,
from my experience, this Wheelbase "just works" under Proton without any additional driver (so hid-pidff?).
Seems to be pretty similiar to Simucube: https://granitedevices.com/wiki/Using_Simucube_wheel_base_in_Linux
This should be the same for all other Asetek Wheelbases (Forte, Invicta) as well.

What does not work (or at least I cannot get to work) is RaceHub - so no configuration from Linux possible other than mimicking USB commands sniffed while using RaceHub in Windows.
I've "reverse engineered" some commands such as unlocking High Torque and am able to send them via pyusb Python Scripts, but this approach is highly fragile and may break with any firmware update.

Asetek has a lot of vendor specific USB HID reports in its descriptor (both La Prima wheelbase and wheel) and my dmesg also shows USB HID errors about unsupported effects. I've attached the descriptor:
asetek_la_prima_wheelbase_hid_report.txt

I have have used this Wheelbase successfully with:

• Assetto Corsa Competizione
• AMS2
• Beamng.drive
• Dirt Rally 2.0 (requires adding the wheelbase device configuration file, just as with EA WRC: https://www.overtake.gg/news/ea-sports-wrc-ffb-guide-moza-asetek-fix.1456/) - this is required for Windows as well, nothing Linux specific, its just how the developer decided to implement device support

Steps are simple:

One time setup

1. Create an udev rule allowing unprivileged users access to wheelbase and wheel via hidraw
   e.g. a file /etc/udev/rules.d/60-steam.rules with content:

# Asetek La Prima Wheelbase
KERNEL=="hidraw*", ATTRS{idVendor}=="2433", ATTRS{idProduct}=="f303", MODE="0660", TAG+="uaccess"
# Asetek La Prima Steering Wheel
KERNEL=="hidraw*", ATTRS{idVendor}=="2433", ATTRS{idProduct}=="f203", MODE="0660", TAG+="uaccess"

3. Reload udev rules: sudo udevadm control --reload-rules && sudo udevadm trigger

Per game setup

Add Proton setting PROTON_ENABLE_HIDRAW=0x2433/0xf303,0x2433/0xf203 to your environment. This can be done via Steam via Game Properties > General > Launch Options, so e.g.:
PROTON_ENABLE_HIDRAW=0x2433/0xf303,0x2433/0xf203 %command%

Forte and Invicta have different PID values, so adjust accordingly.

Alternative: Per Proton environment setup

Alternatively to per-game one can set this setting once for each Proton installation via user_settings.py: https://github.com/ValveSoftware/Proton/wiki/Proton-FAQ

[JacKeTUs]

@moonrail, thank you!
Did you encounter original error from the first message, with odd rotation range detection?
Did you try to launch RaceHub with similar fixes as in GraniteDevices guide? (DisableInput, Enable SDL, etc...)
If it won't work, then we maybe could bring these reverse engineered commands to the Oversteer or Boxflat. And no custom driver needed at all, that's good :D

[moonrail]

@JacKeTUs

OPs issue

I am not sure I completely understand OPs issue. Even without udev rules (hence without hidraw) I can use the full range in jstest:

However I could manufacture a seemingly similiar behaviour (range only from 50 to 100%) if I unset all calibration (Button "Raw Events" in jstest). Once I've done that, Wheel-center was reported in jstest as 100% (as if fully turned to the right) and Wheel-left until bumpstop was reported as 50% (as if wheel was centered). Maybe OP is struggling with uncalibrated events?

I would assume OPs issue could be solved by configuring permissive hidraw udev rules and (if using Proton) defining hidraw usage for the Wheelbase as described in my initial comment.

RaceHub

As for RaceHub: Yes, I've tried all documented Simucube methods and tried all seemingly related Wine settings - no luck yet.
I've used Wine 8 & 9, setup manually as in Simucube docs as well as with bottles.
Of course I also tested with udev rules, even some that would allow any and all USB access, but it made no difference.
RaceHub logs the following:
240819_213952 - RaceHub Log.log
I mean - "Skipped USB check" sounds very much like the issue, but it may be a result of the previous Exception where a value is null but is not expected to be while discovering installed games.
Therefore I've asked Asetek via Email for any clue to go further or maybe even support, but the polite answer was simply, that they do not support Linux and they have to resources to look into it.

Oversteer & Boxflat

Regarding Oversteer & Boxflat - I am not content with my current lack of understanding - as I said, its only mimicking seen USB traffic, not really understanding its contents. Setting High Torque for example is possible this way exactly once. If its disabled again (by own commands) the same payload does not enable it again.

The following enables it once:
Report endpoint to send to: 0x6b
Report endpoint to wait for answers on: 0x6c

1. Sending HID data: 97006bb71700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2. Wheelbase does not answer
3. Sending HID data: 97006bb71700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
4. Wheelbase answers, but I do not know what - maybe a simple confirmation?
5. Sending HID data: 96006bb71700000000000000000000000000000000e28a63090000000000000000000000000000000000000000000000000000000000000000000000
6. Wheelbase does not answer, but plays its "High Torque enabled" sound and is now in High Torque mode

Disabling High Torque is an unanswered send of HID data: 96006bb71700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Profiles can be switched with HID data: 26{profile_id:02x}00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Current configuration can be requested via HID data: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
And wheelbases answer has selected profile at byte 19 and high torque state at byte 55, where 00 means disabled and 04 enabled.

And so on. I do not think that this is nearly enough for Oversteer or Boxflat.

[Sluring]

@moonrail

When you say that it just works, does that include the force feedback?

If it does work with force feedback, maybe it would deserve at least a bronze rating? That the settings program doesn't work could count as a major bug.

I'm thinking about getting a La Prima bundle which should be a nice upgrade over the K800 keyboard I'm using to play AC now, but seeing that Asetek was unrated in the list made me a bit disheartened. So if it does actually work I suggest that it gets a bronze rating and a link to this thread.

[moonrail]

@Sluring

When you say that it just works, does that include the force feedback?

Yes :) When I still had a Windows installation I could not notice any differences in FFB in ACC or AMS2. As it should be, given that this Wheelbase and these games use the regular Windows DirectInput protocol for FFB.

Reminder: With "It just works" I did not mean you can just plug and play. It means you do not require any additional software like drivers.

You do only require manual configuration, as stated below "Steps are simple" in my first comment:
#6 (comment)

When you give your game via Proton hidraw access to the Wheelbase, the game has native access to it and will use DirectInput as it would under native Windows.

If it does work with force feedback, maybe it would deserve at least a bronze rating? That the settings program doesn't work could count as a major bug.

Agreed - base functionality is there.

A remaining caveat, even if unlikely for an already released product: A firmware update can change the behaviour of the Wheelbase, so that it does not start up in a DirectInput usable mode and a command of a software/driver is required for it to be usable.
Thrustmaster did this with their Wheelbases (my old T500 RS had this). The Wheelbase would connect as a dummy and require an activation command from the driver, only then it would connect as a DirectInput device.

The Asetek Wheelbases currently seem to incorporate this behaviour only for the "High Torque Mode".

I'm thinking about getting a La Prima bundle

Just keep in mind that you'll only be able to use 8NM instead of "High Torque" 12NM of the La Prima Wheelbase, until the command required to enable it is available to you/us in a fitting software or a script.

[JacKeTUs]

Hmm, can you elaborate on "High Torque" mode? Can you ELI5 this for me?
Do you need additional software on Windows to enable that mode? And without software, even on Windows, wheelbase will be limited at 8Nm?

If so, could you please record some USB dumps with Wireshark on Windows you enabling and disabling this mode?

I see no reason for them changing the whole protocol to enable "High Torque", i think it's easy fix with something like usb_modeswitch, but we need full command sequence

Edit: in their FAQ (https://www.asetek.com/simsports/knowledge-base/wheelbase-troubleshooting/) there is statement about "torque button is not connected correctly to the wheelbase." on the wheelbase itself. Does this apply to La Prima? I thought that button exists only on higher level wheelbases (Forte, Invicta)

[moonrail]

@JacKeTUs
At least on the La Prima Wheelbase you currently need the Asetek software "RaceHub" to enable "High Torque Mode". If you connect the Wheelbase, it will never activate this mode automatically. On the La Prima Wheelbase this means that the default torque is limited (and set) to 8nm. Via RaceHub you then can enable "High Torque Mode", which means 12nm for the La Prima Wheelbase. There is no physical button for this.

To enable/disable High Torque Mode, the RaceHub software sends USB HID data to the Wheelbase, see "RaceHub" and "Oversteer & Boxflat" in this comment: #6 (comment)

in their FAQ (https://www.asetek.com/simsports/knowledge-base/wheelbase-troubleshooting/) there is statement about "torque button is not connected correctly to the wheelbase." on the wheelbase itself. Does this apply to La Prima? I thought that button exists only on higher level wheelbases (Forte, Invicta)

Yes, this Torque-Cutoff-Button does not exist on the La Prima Wheelbase, only Forte and Invicta. So this FAQ statement does not apply for La Prima.

[JacKeTUs]

Thank you!
Can you send Wireshark USB dumps (pcap files) with you enabling and disabling that High Torque Mode multiple times (from Windows)? May be fresh pair of eyes will help decode this thing :D

usb_modeswitch can send only one command, i don't know about sequence. I also don't think device driver should do such work... May be adding additional device file to control that mode...

[moonrail]

I currently do not have a Windows install available to capture traffic with (and do not plan to ever return to Windows :D) - but I'll have a look later if I still have a Wireshark USBPcap capture from earlier this year.

[Sluring]

@moonrail

Reminder: With "It just works" I did not mean you can just plug and play. It means you do not require any additional software like drivers.

Yes, I saw your earlier post. Compared to getting AC to work it seems pretty straightforward. :)
Thanks for your detailed reply!

@JacKeTUs Would it be useful for you to have access to a La Prima for a week or two?

[moonrail]

@JacKeTUs
Here the promised Wireshark USBPcap packet capture. It was captured while these steps were done:

1. opened racehub
2. started capture
3. powered on wheelbase
4. racehub recognized wheelbase
5. activated high torque via racehub
6. closed racehub
7. stopped capture

rh_connect_high_torque_20240317.zip

Recommended Viewfilter: (usb.src == "2.5.0") || (usb.dst == "2.5.0") || (usb.src == "2.5.1") || (usb.dst == "2.5.1")

Observations (in order of Requests):

1. RaceHub asks for 3 Descriptors: 2, 1, 3
2. 232 Wheelbase suddenly answers identical HID report request to interface 03 with report 6c vendor data instead of 04 HID data
3. 230 RaceHub sends zeroed report to 6b
4. 240 Wheelbase answers with report 6c vendor data
5. 238 RaceHub sends data to 6b
6. 252 Wheelbase answers with report 6c vendor data
7. 248 RaceHub sends data to 6b
8. 262 RaceHub sends data to 6b
9. 268 Wheelbase answers with report 6c vendor data
10. 270 RaceHub sends data to 6b
    ...
11. 712 - 5618 Wheelbase answers now with the same report 6c vendor data
12. 710 - 5630 RaceHub sends zeroed report to 6b
    ...
13. 5626 RaceHub sends "High Torque" vendor data to 6b
14. 5632 Wheelbase answers with different report 6c vendor data
    (15. 5634 RaceHub sends "High Torque" vendor data to 6b)
15. 5632 Wheelbase answers with different report 6c vendor data
16. 5642 - ... Wheelbase answers now with the same report 6c vendor data as before, but with one exception: Byte 55 is now "04" instead of "00"

[JacKeTUs]

@JacKeTUs Would it be useful for you to have access to a La Prima for a week or two?

@Sluring I appreciate the offer, but i think shipping to me (and back to you) will be quite expensive (what is it, 10kg including wheel?)

@moonrail thank you so much for detailed info. Quite interesting that they need some interactive app to enable "High torque"...
But even if we copy these exact values to some userspace app (or even the driver itself), it could break with fw update? Did you know it for sure that they changing their protocols in different versions of fw, or its just speculation and we can use some python+udev rules? :D

[protoz]

RaceHub is built on Unity, which I found out after it was eating 4gb of memory due to a memory leak, so I would wager there might be a way to get it to work under proton.

I don't have the wheelbase yet, but I do have Forte pedals. I can hook my rig up to my steam deck to see if it works with my G920 wheelbase as is or should pedals just work?

Edit: I got RaceHub to start but it's not detecting the pedals, I need to add the permissions mentioned above to see if that changes tonight.

[JacKeTUs]

If for "working pedals" you mean game will detect them and input will be readable - yes, it will work
If you meant RaceHub detects them and will be able to change some things around - don't know for sure, please test :D

[Sluring]

@JacKeTUs I send some packages at work for reasonable prices, but you're right. I just checked and sending as a not-company is silly. Might as well buy you an Invicta setup to keep for the same money as sending a La Prima back and forth. Sending as a company would probably cost about 100€ each way which could be worth it to have a fully functioning driver.

@protoz Fingers crossed! :)

[moonrail]

@JacKeTUs
I've pushed my trial-and-error unstable CLI, so that all my talk in here is more streamlined and easier to understand via code: https://github.com/moonrail/asetek_wheelbase_cli

Maybe someone finds it useful or can contribute knowledge.

Quite interesting that they need some interactive app to enable "High torque"...

I've seen this "High torque" logic in Simucube wheelbases as well. Maybe its for "safety" reasons, to limit torque until the consumer agrees to potential dangers coming with it.

The command to send to the wheelbase changes after the first time enabling and disabling this mode. So as of now the above logged command sequence is only useful once. It is always the same for the first time. Any subsequent toggles of this mode via RaceHub cause different payloads in response and request I did not understand the cause for this at the time, as I just do not know which byte means what - the datastructure is likely vendor specific without public documentation.

But even if we copy these exact values to some userspace app (or even the driver itself), it could break with fw update? Did you know it for sure that they changing their protocols in different versions of fw, or its just speculation and we can use some python+udev rules? :D

Speculation, just a possibility. It is possible that a future firmware update changes both - the initialization of the wheelbase (which currently is synchronous on connecting USB) as well as the "High torque"-mode stuff.

@protoz
Yes, definitely Unity and its logs show an exception regarding game discovery: 240819_213952 - RaceHub Log.log

[2024-03-20 23:37:07.218] Skipped USB check

So RaceHub skips the USB discovery - possibly due to the exception beforehand. Therefore no udev rule can fix this. I've contacted Asetek Simsports via email earlier this year for support with the issue and above logs, but they did reject politely, as they do not support Linux.

[protoz]

asetek_forte_S_pedals.zip

Here is my Windows Wireshark dump for my Forte S Pedals. I didn't see more packets generated when I calibrated the pedals and changed LED colors.

If I unplug and close Racehub, my settings aren't loaded when I plug it back in. With how stiff the brake pedal is, having custom thresholds is helpful.

428-451 was me plugging it back in with Racehub closed, then opening Racehub. I do have custom LEDs and calibrations set but don't know yet how it's being passed to the pedals once Racehub is running.

[seven-sam]

on archlinux and wine without doing anything special I installed racehub 4.0 then in the same way I did the proposed update to 4.0.1 and again after to 4.0.2, but I have not tried to connect the base yet
I put a video on the asetek discord

video for racehub and Asetek invicta et Pedals on Manjaro Linux https://www.youtube.com/watch?v=ysZixXJNc3U