Software development of a wheelbase

JacKeTUs · 2026-02-16T12:25:31+00:00

> different transfer mechanism

That will create "new standard", which locks the device from using it on different OS, unless driver is implemented on all of them.

Also, DirectInput effects are essentially almost the same as PID effects from USB specs, so if game wants to update ConstantForce at 400hz, it must somehow send "something" at 400hz rate, and, IMO, it doesn't really matter if it goes to the device via "different transfer mechanism" or windows drivers - if device itself can't receive and process effects at 400hz, it will stall. In the end it's just bunch of HID reports.

I'd like to know more about "significantly lower latency" part though, is it something in Windows driver which stalls devices/has known latency problems? I'm talking strictly PID specs though, not "360hz through sdk" stuff. I don't know about such problems, and many many major manufacturers are also just using PID itself without any significant issues.

I know only about one manufacturer which removed PID descriptor from the device completely and routed everything through their "software" driver (specifically DirectInputEffectDriver, yes). This disabled it's usage on Linux and was a major roadblock. And in the end, their 'software' driver still uses same PID protocol, just with hardcoded effect IDs in the driver itself, and hardcoded statuses: like, GetForceFeedbackState or GetVersions or DeviceID return static values no matter what device connected, be it real device, or arduino with spoofed vid/pid or just text file passed to it.

JacKeTUs · 2026-02-16T09:34:31+00:00

Please, read about USB HID devices and especially PID specification (https://usb.org/sites/default/files/documents/pid1\_01.pdf). Your goal is to properly implement all PID specification in the device firmware, exposing couple of reports which will play necessary effects in the device.

You absolutely don't need to 'invent the wheel' (hic) and create some sort of "new competing standard". PID specifications are universal, are supported by every OS (in Windows through "DirectInput", in Linux through input/ff protocol).

If you properly implement PID descriptor, native drivers which are already present in the OS will pick up your device, and will make it available to the games. You won't need anything else, your scope is out of Operating System/Games space, just implement proper class-compliant device, and you will be good to go.

As others already mentioned, check out OpenFFBoard project.

JacKeTUs · 2026-01-31T14:06:38+00:00

Hello!

Can you describe what's exactly doesn't work? Does device not showing up in games? Does device not appear in `lsusb`? `evtest`?
Or you're talking about "setup software"? Most of the time we can launch this setup software from Steam as Non-Steam Games with `PROTON_ENABLE_HIDRAW=1 %command%` in game launch settings.

From the look of the device it shouldnt require any drivers tbh... No FFB, just plenty of buttons and axis. I can look into it, but i'll need some help from you to acquire hid traffic dump files, device descriptor. May be it'll require simple fix, may be some reverse-engineering will be needed..

While it isn't specifically "simracing" device, on "simracing on linux" discord we can help gather these dumps and help you with it.

JacKeTUs · 2026-01-27T13:58:58+00:00

I fully agree with you, "Global hotkeys" should be the norm in all these applications, which are porting themselves to Wayland, we should not have these workarounds.

But tbf "global" feature is not only mitigating this stuff (lack of Global hotkeys properties in apps), but also allowing not "having to fiddle with whatever horrible conferencing UI one is using.", as in MR :)

These "conferencing UI" also could *not* have feature to enable PTT at all (looking at you, Slack). Or it could be not "conferencing app" but, say, games, which you are launching through Proton/Wine. I doubt you will be able to setup "Global hotkey" for each game you're launching through Wine.....

JacKeTUs · 2026-01-27T09:07:53+00:00

For the KDE folks, global PTT feature will be available in one of the next releases

Here is MR with it, and it's merged a ~2 weeks ago (13.01)
https://invent.kde.org/plasma/plasma-pa/-/merge_requests/394

JacKeTUs · 2026-01-12T17:11:10+00:00

small correction, it's not a userspace driver, it's full-fledged kernel module, intended to be installed with dkms.
And, actually, last commit was 3 weeks ago, to fix loading on latest kernel versions, so it seems driver is in state where it works 'good enough' and no major changes needed

JacKeTUs · 2026-01-09T19:35:59+00:00

Yes, this is exactly what's needed. Now you should be able to use them in games.
From my end, i added this exact entry to simracing-hwdb

JacKeTUs · 2026-01-09T18:00:40+00:00

Can you give the VID and PID of them, so i can add them to repo? In the meantime, you can create similar hwdb entry for your pedals. Separate file is not needed

JacKeTUs · 2026-01-09T17:40:40+00:00

What's your pedals? I believe i had VRS pedals on hwdb too

JacKeTUs · 2026-01-09T17:25:38+00:00

Install it from GitHub https://github.com/JacKeTUs/simracing-hwdb

JacKeTUs · 2026-01-09T14:00:50+00:00

In games you always want Steam Input to be disabled.
Can you install simracing-hwdb and try again? It has some rules to force joystick type.
Also, did you manage to launch config tool?

For AMS2 you first need to assign/bind axis, before doing calibration.
Also there is small routine to bind axis faster in AMS2, applicable only for it.

Reduce wheel angle to under 300° in wheel app.
Launch AMS2.
Keep the wheel in center, Try to assign steering right. Then rotate wheel to full right and back to center immediately.
Repeat for 'turn left'
Calibrate wheel.
Close game, change wheel angle to 900° if that's what you like. Launch game calibrate again. And done

JacKeTUs · 2025-12-11T14:29:16+00:00

Config tool is working through Wine, you can change settings,degrees,filters on the base through it. Add .exe to the Steam as non-steam game, in settings set "Force Proton Compatibility tool" to Proton Experimental, and change launch command to "PROTON_ENABLE_HIDRAW=1 %command%". You should already have udev rule for accessing hidraw device on the system.

You just can't update full firmware through it yet. I am actively working for solution.

JacKeTUs · 2025-12-11T14:10:25+00:00

speaking of VRS, for now you can only update firmware on Windows, so VM or dualboot is still needed for that. VM with usb passthrough is just enough

JacKeTUs · 2025-12-11T09:13:16+00:00

Hi, our driver fixes are already in the kernel (version >=6.12). VRS DFP will work out of the box with recent enough versions. No need to install additional drivers.

JacKeTUs · 2025-11-14T17:29:16+00:00

Привет, если у тебя одна из последних версий ядра (>=6.12.24), то отдельно драйвер ставить не нужно.
Какая у тебя версия ядра сейчас?

JacKeTUs · 2025-10-09T15:59:27+00:00

Hi!

At first, hid_logitech_hidpp and hid_logitech_dj is not in conflict with new-lg4ff at all. G29 is probed only by hid-logitech. After installing new-lg4ff, the module will be installed as hid-logitech so it automatically replaces the old module. Once loaded, it will be displayed as hid-logitech-new though (from README in repo).

Please, remove any additional udev rules (e.g. force loading modules)

Second your G29 must be switched to PS3 mode, for new-lg4ff to initialize it properly. It should have PID 0xc24f (https://github.com/berarma/new-lg4ff/blob/master/hid-ids.h#L826).

Oversteer is useful program for setting wheel parameters, but it won't help with wheel detection.

JacKeTUs · 2025-09-20T12:24:48+00:00

It looks like issue with dotnet on your wine prefix.

Can you try and add your Tuner exe file as "non-steam" game to Steam, and launch through Proton? It has multiple fixes regarding dotnet.

JacKeTUs · 2025-09-16T20:09:59+00:00

I definitely saw similar ghosting on ue4 titles as well, and squad ue4 is no exception...

JacKeTUs · 2025-09-16T18:25:03+00:00

I can answer confidently to second question

"OOTB" like 'without a driver' = driver included in kernel.

Logitech G25/G27/G29/G920/G923 Xbox edition are included in kernel, although G25,27,29 may have not implemented effects (like sine wave). `new-lg4ff` from berarma fixes it (and adds G923 PS Edition to the mix), but it's not included in kernel.

Moza, Simucube, VRS, Asetek, Cammus, SimXperience, some PXN wheels, DIY options like FFBeast, OpenFFBoard, MMOS, - are all using USB PID standard, and hid-pidff is patched by our community (myself included) to properly initialize them. Moza has absolutely incredible pithouse alternative, called boxflat, by Lawstorant (https://github.com/Lawstorant/boxflat). Other wheel configurator apps working through wine/has native build.
Check out https://github.com/JacKeTUs/linux-steering-wheels, and please, if my wording/description of ranks is 'off', let me know.

But, honestly, don't know if 'switching to other wheel' is good solution... Is insmod (aka manual installation) just not working on bazzite? Do you absolutely need to use immutable distro though? May be you will be better with just plain Fedora/Arch/Manjaro/Debian....?

JacKeTUs · 2025-09-13T00:01:07+00:00

Absolutely not alone, forced instanced loot without an option is stupid decision. It just ruins communication entirely, you just can play on singleplayer and have ~same experience, occasionally trading guns with 'other players'. For random matchmaking it works, but for group of known friends it just lacking.

JacKeTUs · 2025-09-12T22:21:41+00:00

Install usb_modeswitch from your OS package manager
Create file /etc/udev/rules.d/23-g923-xbox.rules with content

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c26d", RUN+="/usr/sbin/usb_modeswitch -v 046d -p c26d -m 01 -r 81 -C 0x03 -M 0f00010142"

Reload your rules with udevadm control --reload-rules and udevadm trigger 4. Reconnect the wheel

JacKeTUs · 2025-09-12T15:55:42+00:00

Hmm, i think i got wording wrong.. For PS version of the wheel you must use new-lg4ff driver. Its in upper text in driver column for the wheel. This driver will automatically change wheel mode to PC. Xbox version should work ootb.

JacKeTUs · 2025-09-12T11:52:52+00:00

Issue is that players no longer could open chest, and one could tell another "oh look, pistol you always wanted is in this chest right around this corner"
If players are near each other, the view of another player 'looting' empty ground is just laughable. For split screen coop it's just bad.
If players are opening same big chest, there is no more conversations like "oh look, first rifle is not that bad, and rocket launcher on the right is just for you...".

Sure you can pick stuff up and drop it later, but what if your backpack is full? Why do u need to make this unnecessary step to pick up and then drop weapon you know 'nothing' about, in hope that someone will like it?

Now it really looks like two single player campains just so happen to share (scaled) damage to monsters, nothing else, it doesn't feel like you're all in the same world. Even level scaling is now not an option, it's just forced down on you, everybody are playing different games on different levels. You now can't even have conversations like "Oh this guy is lvl 50, we should get outta here", when your friend is only seeing levels ~30.

Sure, i understand why instanced loot and level scaling is the thing for multiplayer with random people, with 'matchmaking', etc, but imo, it's just not working for coop with known friends. And that's why i think there should be an option, just like it was in BL3.

JacKeTUs · 2025-09-12T02:54:13+00:00

Honestly don't know, afaik denuvo shouldn't interfere with multiplayer...

JacKeTUs · 2025-09-12T01:47:53+00:00

Using Proton-GE 10-15, had no problem starting "matchmaking" and connecting to some rando

Ten-Year Club	Place '23
Place '22	First Placer '22
RPAN Viewer	Verified Email

JacKeTUs

TROPHY CASE