Arduino Leonardo as FFB

[Rohrtech]

Somewhat unconventional, but I am setting up a DIY sim package using an Arduino Leonardo and this library (https://github.com/YukMingLaw/ArduinoJoystickWithFFBLibrary) and it does not seem to be recognized by oversteer or speed dreams. It does work with fftest. The device takes the name "usb-Arduino_LLC_Arduino_Leonardo_HIDHC-if02-event-joystick". When I start oversteer it tells me no device available. Are only specific wheels supported? Or am I missing a driver.

[berarma]

Only specific devices, and specifically wheels.

I don't understand your setup. If you think Oversteer would be useful we can try to make it work but I'd need more info about what you're doing.

[berarma]

So you're building your own FFB wheel. It could be supported by Oversteer, I just need the vendor/product ids. If possible it shouldn't be used for other devices. We don't want to detect every Arduino as a DIY wheel. I'm using an Arduino for head tracking, that's a very different purpose.

How does it handle FFB? Does it use the HID++ protocol?

Linux apps can have some trouble detecting wheels because there's no interface to find them. There's just devices with axes and buttons. SDL has some logic to help with this.

If you can provide the information we could start but making it work with Oversteer then see which other pieces are missing in the Linux input stack.

[Rohrtech]

I honestly do not know what protocol it uses. It does work with fftest and your ffbplay software. So I am assuming it is HID++? To elaborate the ffb works on those when I specify the device. So I agree with it being an issue with the linux input stack. I am a mechanical engineer by trade, but work with linux and programming (mostly robotics related) on a frequent basis. This is my first experience with HID devices.

So I did a bit more digging. It is possible to change the vid/pid of the device in the boards.txt file of the compiler. Currently I have it set to this:
Bus 001 Device 034: ID 2341:ffff Arduino SA

So the vendor id is still Arduino but the PID does not correspond to any current Arduino. If you have any better suggestions for vid/pid that could work as a dummy for a different device maybe that may be preferable. I should explain my end goal is to make this a full open source solution on the hardware side and software side. From everything I found everyone precompiled every example so if you want to change anything (pinouts etc.) it's useless. I will post the source code for the device once I clean it up a bit.
The full CAD model can be found here:
https://cad.onshape.com/documents/068f1d56e2863a6844f53e26/w/92abdf46caf779daa25927bc/e/cea759b830cba30c1f860b0c?configuration=default&renderMode=0&uiState=62cb1686e2d3835cb9f0e2f5
The main reason for all of this is a different rotation sensor, it does not use a rotary encoder but rather a magnetometer and a magnet that rotates with the steering column. Centering the wheel should be a thing of the past. Initial testing is very promising.

[berarma]

I honestly do not know what protocol it uses. It does work with fftest and your ffbplay software. So I am assuming it is HID++?

Well, it could be using the HID PID extension. It's not that relevant, I was just curious how the kernel was interfacing with it. That is, which kernel module handled the FFB.

So I did a bit more digging. It is possible to change the vid/pid of the device in the boards.txt file of the compiler. Currently I have it set to this: Bus 001 Device 034: ID 2341:ffff Arduino SA

So the vendor id is still Arduino but the PID does not correspond to any current Arduino. If you have any better suggestions for vid/pid that could work as a dummy for a different device maybe that may be preferable. I should explain my end goal is to make this a full open source solution on the hardware side and software side.

My experience with USB devices is limited but this page seems like good advice to get a VID/PID for your project.

From everything I found everyone precompiled every example so if you want to change anything (pinouts etc.) it's useless. I will post the source code for the device once I clean it up a bit. The full CAD model can be found here: https://cad.onshape.com/documents/068f1d56e2863a6844f53e26/w/92abdf46caf779daa25927bc/e/cea759b830cba30c1f860b0c?configuration=default&renderMode=0&uiState=62cb1686e2d3835cb9f0e2f5 The main reason for all of this is a different rotation sensor, it does not use a rotary encoder but rather a magnetometer and a magnet that rotates with the steering column. Centering the wheel should be a thing of the past. Initial testing is very promising.

It's a very interesting project. I'm looking forward to see it finished.

Here's another related opensource project that has been doing good progress: https://hackaday.io/project/163904-open-ffboard

I'm very interested on supporting these kind of projects in any way I can. I think SDL should implement some way to know which devices are wheels and let applications know about them. Maybe using VID/PID lists or heuristics.

[berarma]

One more thing. We could just use any VID/PID that is not likely to clash with other devices. There's no need to ask for a official VID/PID at this early stage of the project. I could add a parameter to Oversteer that enables these VID/PIDs for experimental devices. We can do as we want. Just tell me on which VID/PID you decide and I'll add it.

[Rohrtech]

Here's another related opensource project that has been doing good progress: https://hackaday.io/project/163904-open-ffboard

I saw the open ffb board and it is a very nicely developed controller which I would have gladly bought and saved myself a lot of headache. Unfortunately he seems to be completely out of stock since March 2021 due to supply shortages. The Leonardo (at least in the US) is readily available. The current version uses a standard DC motor to keep expense down and simplicity up, but in the future may use a brushless motor arrangement or just support openFFB. Since open ffb supports can bus communication a high end ffb could use this (https://store.tmotor.com/goods.php?id=1201) which is a commercial version of (https://build-its-inprogress.blogspot.com/search/label/HobbyKing%20Cheetah).

My experience with USB devices is limited but this page seems like good advice to get a VID/PID for your project.

I agree this may be a nice clean final solution.

One more thing. We could just use any VID/PID that is not likely to clash with other devices. There's no need to ask for a official VID/PID at this early stage of the project. I could add a parameter to Oversteer that enables these VID/PIDs for experimental devices. We can do as we want. Just tell me on which VID/PID you decide and I'll add it.

For now that VID/PID combo will work but an experimental arrangement may be a good idea to add. For my arrangement and openFFB etc.

When open FFB becomes available again I may switch driver boards but considering the VID/PID issue I am guessing it would have the same problems interfacing with the Linux kernel unless it emulates a comercial wheel.

Do games in linux function the same way that Oversteer does with device management? Basically having a list of accepted wheels (VID/PID) combinations?