Open uweeby opened 1 month ago
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
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
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
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:
Steps are simple:
/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"
sudo udevadm control --reload-rules && sudo udevadm trigger
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.
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
@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
@JacKeTUs
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.
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.
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
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.
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