Life without windows

[Aginor]

Ok, a few things have happened:

I played Minecraft with my wife and kids, and it was fun. Four people on the RaspberryPi4 server, total chaos 10/10.

I also downloaded and installed MSFS2024.
It runs great at everything on high settings it seems, using Proton10 beta I have 200+ FPS over Karlsruhe in a C172.
And @smokinhole wasn’t exaggerating, the visual quality IS mindblowing.

Sadly I could not enjoy it much, since apparently ultra settings don’t work for me yet because lack of Internet bandwith/stability (will retry that though) and because I had to use a PS4 controller since MSFS failed to see my TM16000 although it is plugged in and recognized by the system. (I see it in antimicrox and when using evtest). Seems like the TM16000 needs a custom driver to work with MSFS and that doesn’t exist in Linux. I am looking for a workaround there.

Today I tried my other stuff. The Saitek Yoke works fine out of the box.
However my Saitek Combat Rudder Pedals are not recognized ingame, and neither are my Saitek Radio Panel and Saitek Multi Panel.
Those are recognized by the system though, so I am researching this.
Seems like this article might help me, because without sudo evtest doesn’t see the devices, with sudo it does. So I probably need an udev rule.
https://forums.x-plane.org/forums/topic/143655-saitek-rudder-pedals-stopped-working/#comment-2524340

So we will see soon, I’ll test that tonight I think.

[Aginor]

I applied the following udev rules:

#06a3:0764 Saitek Pro Flight Combat Rudder Pedals (the normal ones are 0763)
KERNEL==“event*”, SUBSYSTEMS==“input”, ATTRS{id/product}==“0764”, ATTRS{id/vendor}==“06a3”, MODE=“0666”, TAG+=“uaccess”

#06a3:0d05 Saitek PLC Pro Flight Radio Panel
KERNEL==“event*”, SUBSYSTEMS==“input”, ATTRS{id/product}==“0d05”, ATTRS{id/vendor}==“06a3”, MODE=“0666”, TAG+=“uaccess”

#06a3:0d06 Saitek PLC Flight Pro Multi Panel
KERNEL==“event*”, SUBSYSTEMS==“input”, ATTRS{id/product}==“0d06”, ATTRS{id/vendor}==“06a3”, MODE=“0666”, TAG+=“uaccess”

#044f:b10a ThrustMaster, Inc. T.16000M Joystick
KERNEL==“event*”, SUBSYSTEMS==“input”, ATTRS{id/product}==“b10a”, ATTRS{id/vendor}==“044f”, MODE=“0666”, TAG+=“uaccess”

and restarted the service via
sudo systemctl restart systemd-udevd.service

That did fix the pedals, and I could assign them in MSFS2024.
It also did something for the panels, they are now visible in evtest without sudo.
They still don’t show up in MSFS though.
For good measure I added a rule for the TM16000 but it seems it didn’t help for it either, as was expected.

[Aginor]

More tinkering!

I tried to get the panels working.
No success yet, but I learned a few things.

For some reason they are recognized as mice by the OS, which - as you can imagine - leads to some problems. They keep clicking on things.

I searched the web and found a few people from the past that ran into the same problem. One of them was almost there. I managed to piece the info together with the xorg documentation, and got this:

You need to put some files into /etc/X11/xorg.conf.d/

Content (in my case, YMMV because those panels have been produced with different names. You can figure out those names with the command xinput list):

50-saitekmultipanel.conf content:

Section "InputClass"
    Identifier "Saitek multi"
    MatchProduct "Logitech Logitech Flight Multi Panel"
    Option "ButtonMapping" "0 0 0 0 0 0 0 0"
EndSection

50-saitekradiopanel.conf content:

Section "InputClass"
    Identifier "Saitek radio"
        MatchProduct "Logitech Logitech Flight Radio Panel"
    Option "ButtonMapping" "0 0 0 0 0 0 0 0"
EndSection

EDIT: So now we have regular input devices. Now I need some software to read those inputs, then I can at least use the buttons. The displays will probably stay empty, but working buttons would at least be something that the panels can still do.

[Aginor]

Talking about something means that you need names for things.

It seems that the reason why Linux (and thus MSFS) cannot hear anything from those devices is that there might be a problem between evdev (as testable working with evtest) and SDL (or was it joydev? I don’t know), which seems to be the API the system is using?

I don’t think I understand that properly yet. But I am getting dangerously close to driver programming it seems, and that sounds like trouble.

There has to be a simple tool that does the trick. I can see that all the buttons do buttons-stuff, I just need a software that puts that input into some shape that the programs can use.

[Aginor]

I found a way, but it has a few downsides:

There is a tool named xboxdrv that can be used to turn eventdev inputs into those of an Xbox360 controller. MSFS knows how to handle those.

So you have to build a config file which takes the button names from evtest and maps them to button names of the Xbox360 controller, then run the tool in the background. You can then launch MSFS and assign the buttons of your weird Xbox controller.

Sadly MSFS is too much built for that controller. You cannot turn off the menu navigation it seems. So you have to be a bit careful with the assignments.

I also haven’t tried yet if the game can handle more than one Xbox360 controller at the same time. I think it cannot, so I have to find a way to make my two panels work at the same time.

But maybe I’ll find another tool, now that I know that I am searching for.

And I will definitely check if I can turn my TM16000 into an Xbox360 controller to make it work. That should be easier than the panels.

So much to try, so little time…

[Aginor]

Hmpf. Today wasn’t a good day.

I tried to get OpenTrack working with MSFS and failed. Tried all modes, and even the Windows binary via Steam Proton. Just no reaction from MSFS2024, no clue why. And I know no way to debug either.

I also couldn’t quite find a good way to get the controller to work. I can do some basic stuff but I need to plan a good layout to get as much functionality as possible. Today wasn’t a good day for planning, work got into my head too much.

So I decided to go watch some TV instead, and that’s when I noticed that my TV has died. Grrr…

[Poneybirds]

@Aginor

TV has died

Lucky for you, June is a good month to get a TV for half the price. Got my LG OLED for 1000€ and still love the picture every time I watch something. They usually sell for 2000€.

[Freak]

@Aginor you inspired me.

Seriously though, I was very unsure if the upgrade will be worth it, but there will be no benchmarks:

I already sold the RTX 3080

[Aginor]

Small progress today.

I have now tried around 60 or 70 configurations of Opentrack. Native, via wine, via half a dozen proton versions. All work internally, none works for MSFS2024.
The only thing I might get to work is 3DOF via joystick emulation. Better than nothing but not what I wanted. We will see.

As for the panels:
I once again adjusted my udev rules (after some light documentation reading).
I added the “ENV” part, which forces the system to see those things as joysticks.

That makes them appear in antimicrox, which in turn means that I can assign their buttons to keyboard keypresses. I can work with that, so I will try to get the panels working in MSFS2024 that way.

#06a3:0764 Saitek Pro Flight Combat Rudder Pedals (the normal ones are 0763)
KERNEL=="event*", SUBSYSTEMS=="input", ATTRS{id/product}=="0764", ATTRS{id/vendor}=="06a3", ENV{ID_INPUT_JOYSTICK}="1", MODE="0666", TAG+="uaccess"

#06a3:0d05 Saitek PLC Pro Flight Radio Panel
KERNEL=="event*", SUBSYSTEMS=="input", ATTRS{id/product}=="0d05", ATTRS{id/vendor}=="06a3", ENV{ID_INPUT_JOYSTICK}="1", MODE="0666", TAG+="uaccess"

#06a3:0d06 Saitek PLC Flight Pro Multi Panel
KERNEL=="event*", SUBSYSTEMS=="input", ATTRS{id/product}=="0d06", ATTRS{id/vendor}=="06a3", ENV{ID_INPUT_JOYSTICK}="1", MODE="0666", TAG+="uaccess"

#044f:b10a ThrustMaster, Inc. T.16000M Joystick
KERNEL=="event*", SUBSYSTEMS=="input", ATTRS{id/product}=="b10a", ATTRS{id/vendor}=="044f", ENV{ID_INPUT_JOYSTICK}="1", MODE="0666", TAG+="uaccess"

Still haven’t played a lot, but I am slowly getting there.