Mixing vendors

[hodasemi]

Hi,

my current setup is a G29 wheel with the Thrustmaster T-LCM pedals. Both are correctly recognized by the system. The problem is that Oversteer and the games I've tested (F1 2021, KartKraft, DRAG) don't take input from the thrustmaster pedals. Using the default G29 pedals does work as intended.

(Screenshot is taken from jstest-gtk. Input is also verified via this tool.)

It could be cool if there is a way to mix both devices. I don't know if that can even be done with oversteer. I also tried Input Remapper, but it doesn't list the thrustmaster pedals as device.

[berarma]

It's currently not possible, the app is designed around one selected device only. You can use Oversteer for the wheel and jstest for the pedals. There's little we can do with the pedals besides testing and that is possible with jstest too.

In the future I might add support for multiple devices in case it will bring some benefit.

[hodasemi]

I think that it would be an awesome features to not be vendor locked, when possible. I will take a look in the next couple days if I get something working.

[irseny]

I am working on the same issue and have come up with a partial solution up to this point. My test applications are the following

• SpeedDreams (native linux)
• Wreckfest (steam proton)
• Assetto Corsa Competizione (steam proton)

Since your pedals are properly registered they should work fine in native linux games. <- not too sure about this since you mentioned input remapper

---

Someone found out that Proton/SDL changed parameters for recognizing pedals, specifically with Proton 5.13. With Proton 5.0 Wreckfest can "see" my standalone pedal set but with 5.13 it does not show up as a detected controller. They suggested https://github.com/sambazley/virtjs which creates a virtual controller that can mimic your Thrustmaster pedal set. The magic is that it adds a button to satisfy the updated controller detection in SDL.

---

Maybe you can confirm that native linux games detect your pedal set or that virtjs is sufficient for your needs. The latter does partially work for Wreckfest but not for Assetto Corsa Competizione with my pedal set. Thats what I am currently working on.

[hodasemi]

I have done quite a bit of research. I tested like all tools I could find on the internet (Input-Mapper, uinput-mapper, MoltenGamepad). Just before your comment I also came across virtjs. Native apps also don't get any input from the pedals. I guess it is due to SDL not recognizing it as an joystick (only native game tested was DRAG).

The only thing that got the pedals working was virtjs indeed. Sadly the calibration is a bit off.

[irseny]

True, if native apps use the problematic SDL, they will also not see the pedals. What is your output of ls -l /dev/input/event/by-id ? Do your pedals also show up as /dev/input/event/by-id/***-event-joystick? Then you can calibrate them with evdev-joystick When virtjs starts it sets up the new device with the calibration of the original device.

Another way is to calibrate with jscal-gtk directly, but the results look off with my pedals too.

[hodasemi]

Output of ls -l /dev/input/event/by-id

...
lrwxrwxrwx 1 root root  9 16. Jan 10:52 usb-Thrustmaster_Sim_Pedals-event-if00 -> ../event2
...

They are not shown as *-event-joystick, there is only one entry. I will try to calibrate them correctly. Thank you for some hints ;).

[irseny]

Sorry, no idea what that means Ok, I found out the easier way is to check with the tool itself evdev-joystick --list BTW which axes does your virtual device have? It looks like this for me:

---

Edit: Can no longer get the calibration to work with the original code of virjs. puzzled

[hodasemi]

$ evdev-joystick --list
/dev/input/by-id/usb-Logitech_G29_Driving_Force_Racing_Wheel-event-joystick

Only the G29 is shown there. The mapping of the virtual joystick looks quite similar.

[berarma]

I think I've found a method so that SDL sees any choosen device as a joystick.

This page has instructions to write a udev rule that tags the device as a joystick for SDL: https://github.com/libsdl-org/SDL/blob/d4f2f01580454deef8ac43d8939ebc907d4ad759/README-linux.txt

Please try it, and if it works send me the udev rule so I can add them to the udev rules that Oversteer installs so others can fix it easily.

[hodasemi]

There is some progress. DRAG does recognize my pedals now, but I can't mix inputs of multiple devices inside it. F1 2021 still doesn't recognize it.

My udev rule is:

# Thrustmaster T-LCM Pedals (USB)
SUBSYSTEM=="input", KERNELS=="0003:044F:B371.????", MODE="0666", ENV{ID_INPUT_JOYSTICK}="1"

I tried to mimic your device listing. Now I can see the pedals in there:

import pyudev

LG_G29 = '046d:c24f'
T_LCM = '044f:b371'

supported_devices = {
    LG_G29,
    T_LCM
}

context = pyudev.Context()
devices = {}

for udevice in context.list_devices(subsystem='input', ID_INPUT_JOYSTICK=1):
    usb_id = str(udevice.get('ID_VENDOR_ID')) + \
        ':' + str(udevice.get('ID_MODEL_ID'))

    if usb_id in supported_devices:
        seat_id = udevice.get('ID_FOR_SEAT')

        devices[seat_id] = {
            'vendor_id': udevice.get('ID_VENDOR_ID'),
            'product_id': udevice.get('ID_MODEL_ID'),
            'usb_id': usb_id,
            'dev_name': udevice.get('DEVNAME'),
            'input_joystick': udevice.get('ID_INPUT_JOYSTICK'),
            'seat_id': seat_id,
        }

[berarma]

DRAG does recognize my pedals now, but I can't mix inputs of multiple devices inside it.

It's most probably a limitation in the game itself.

F1 2021 still doesn't recognize it.

Wine/Proton may check for accelerometers too and maybe doesn't check for the udev tag, or some other issue.

Related Proton issues: https://github.com/ValveSoftware/Proton/issues/5126 https://github.com/ValveSoftware/Proton/issues/5194

I don't lock vendors, but since there isn't a way to ask what kind of device we've found I resort to a list of vendor/product ids.

The way the application is designed makes sense only for wheels/pedals/shifters all in one. Anyway, this wouldn't help games recognize the pedals. The only way Oversteer would be useful for pedals is testing they're working, like you would with jstest.

[hodasemi]

Yea, probably the only way to solve this issue is to select wheel, pedals, shifters, etc .. inside oversteer and setup a new virtual device with everything wired up.

[berarma]

I would consider redesigning Oversteer to be able to test and create profiles with different devices selected but it's already more work than it's probably worth doing at this point when there are better things to do, probably. Maybe in the future.

For games that are limited to only inputs from one device, I think that's a flaw in the game and the developer should be asked to remove that limitation.

It would be nice that Oversteer could mix several devices into a virtual one which could be recognized by games as some device we chose but that would be a lot of work to fix a flaw in the games, and would probably be more useful as a generic application for joysticks and related devices anyway.

[irseny]

Besides SDL the core issue of the titles I am interested in are the reported pedal axes (RX, RY and RZ in my case). Modifying virtjs a little revealed that I could get ACC to pick up input if at least X and Y were also present. To come up with a more general solution that I use permanently as well as to fiddle around I created a separate project protopedal. It could be worth trying F1 again with different axis and button counts if it is still a priority.

[berarma]

Besides SDL the core issue of the titles I am interested in are the reported pedal axes (RX, RY and RZ in my case). Modifying virtjs a little revealed that I could get ACC to pick up input if at least X and Y were also present. To come up with a more general solution that I use permanently as well as to fiddle around I created a separate project protopedal. It could be worth trying F1 again with different axis and button counts if it is still a priority.

That's great. I hope this ends up reaching to Wine/Proton as patches that improve compatibility out of the box.