Linux Support (Beta)

Ask here if you experience technical problems with X4: Foundations.

Moderator: Moderators for English X Forum

fridl
Posts: 85
Joined: Sun, 22. Mar 09, 22:39
x4

Re: Linux Support (Beta)

Post by fridl » Sun, 20. Oct 19, 21:26

Ok, thats right, the Output from ldd tells as well:

Code: Select all

> ldd X4
./X4: /usr/lib64/liblber-2.4.so.2: no version information available (required by ./X4)
./X4: /usr/lib64/libldap_r-2.4.so.2: no version information available (required by ./X4)
./X4: /usr/lib64/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found (required by ./X4)
I think I have the right versions of liblder and libldap, but the wrong of libssl. Perhaps therefore there is a issue with the other two libs as well. So I also hope for a change on egosofts side, because I can't find a place providing the "proper" libssl for my system... And I'm not that deep in the topic :wink:

steve_v
Posts: 164
Joined: Sun, 12. Jun 16, 08:39
x4

Re: Linux Support (Beta)

Post by steve_v » Mon, 21. Oct 19, 10:47

I've not spun up 2.60 yet, but you guys might try grabbing some libs from steam-runtime as an interim solution while we wait for Egosoft to link against some non-ancient ssl libraries.
It's got libssl.so.1.0.0, but you'll probably need to cherry-pick it as the libav libraries it includes are a mite old.

Readelf says:

Code: Select all

  0x0060:   Name: OPENSSL_1.0.1  Flags: none  Version: 6
  0x0070:   Name: OPENSSL_1.0.0  Flags: none  Version: 4
so It looks like the version you need.

Just a suggestion, it's saved my bacon in the past. I'll get around to actually testing it (gentoo here too) soon if nobody else is game. Good luck.

andrewpc
Posts: 23
Joined: Sun, 27. Jan 19, 19:11
x4

Re: Linux Support (Beta)

Post by andrewpc » Mon, 21. Oct 19, 21:51

I run X4 (including the new 2.6 version) on my openSUSE Tumbleweed install without issue. Here are my library versions
andrew@host:/mnt/sdb3/home/andrew/SteamLibrary/steamapps/common/X4 Foundations> ldd X4
./X4: /usr/lib64/liblber-2.4.so.2: no version information available (required by ./X4)
./X4: /usr/lib64/libldap_r-2.4.so.2: no version information available (required by ./X4)
linux-vdso.so.1 (0x00007fffe17cb000)
libsteam_api.so => lib/libsteam_api.so (0x00007f29e52b8000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f29e5090000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f29e5068000)
libluajit-5.1.so.2 => lib/libluajit-5.1.so.2 (0x00007f29e4df0000)
libavformat.so.55 => lib/libavformat.so.55 (0x00007f29e4ad8000)
libavcodec.so.55 => lib/libavcodec.so.55 (0x00007f29e3e20000)
libswscale.so.2 => lib/libswscale.so.2 (0x00007f29e3bb8000)
libswresample.so.0 => lib/libswresample.so.0 (0x00007f29e39a0000)
libavutil.so.52 => lib/libavutil.so.52 (0x00007f29e3758000)
libboost_filesystem.so.1.63.0 => lib/libboost_filesystem.so.1.63.0 (0x00007f29e3538000)
libboost_regex.so.1.63.0 => lib/libboost_regex.so.1.63.0 (0x00007f29e3240000)
libboost_system.so.1.63.0 => lib/libboost_system.so.1.63.0 (0x00007f29e3038000)
libxml2.so.2 => lib/libxml2.so.2 (0x00007f29e2cd8000)
libopenal.so.1 => lib/libopenal.so.1 (0x00007f29e29f0000)
libvorbisfile.so.3 => lib/libvorbisfile.so.3 (0x00007f29e27e0000)
libSDL2-2.0.so.0 => lib/libSDL2-2.0.so.0 (0x00007f29e24c0000)
libvulkan.so.1 => lib/libvulkan.so.1 (0x00007f29e2278000)
libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00007f29e2270000)
libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007f29e2260000)
libm.so.6 => /lib64/libm.so.6 (0x00007f29e2118000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f29e2110000)
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f29e20f8000)
libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007f29e20a0000)
libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007f29e2028000)
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f29e1db0000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f29e1d90000)
libc.so.6 => /lib64/libc.so.6 (0x00007f29e1bc8000)
librt.so.1 => /lib64/librt.so.1 (0x00007f29e1bb8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f29e5518000)
libz.so.1 => lib/libz.so.1 (0x00007f29e1998000)
libvorbis.so.0 => lib/libvorbis.so.0 (0x00007f29e1758000)
libogg.so.0 => lib/libogg.so.0 (0x00007f29e1550000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f29e1538000)
libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007f29e1518000)
libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007f29e1480000)
libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007f29e11b0000)

Note that I have libraries for libssl.so.1.0 and 1.1 and also liblber and libldap

Code: Select all

 
> zypper search --provides -s libssl.so
S  | Name                  | Type    | Version      | Arch   | Repository             
---+-----------------------+---------+--------------+--------+------------------------
   | boringssl-devel       | package | 20190916-1.1 | x86_64 | openSUSE-Tumbleweed-Oss
   | boringssl-devel       | package | 20190916-1.1 | i586   | openSUSE-Tumbleweed-Oss
   | libboringssl1         | package | 20190916-1.1 | x86_64 | openSUSE-Tumbleweed-Oss
   | libboringssl1         | package | 20190916-1.1 | i586   | openSUSE-Tumbleweed-Oss
i+ | libopenssl1_0_0       | package | 1.0.2t-1.1   | x86_64 | openSUSE-Tumbleweed-Oss
v  | libopenssl1_0_0       | package | 1.0.2t-1.1   | i586   | openSUSE-Tumbleweed-Oss
   | libopenssl1_0_0-32bit | package | 1.0.2t-1.1   | x86_64 | openSUSE-Tumbleweed-Oss
i+ | libopenssl1_1         | package | 1.1.1c-1.4   | x86_64 | openSUSE-Tumbleweed-Oss
v  | libopenssl1_1         | package | 1.1.1c-1.4   | i586   | openSUSE-Tumbleweed-Oss
i+ | libopenssl1_1-32bit   | package | 1.1.1c-1.4   | x86_64 | openSUSE-Tumbleweed-Oss
   | libssl47              | package | 2.9.2-1.2    | x86_64 | openSUSE-Tumbleweed-Oss
   | libssl47              | package | 2.9.2-1.2    | i586   | openSUSE-Tumbleweed-Oss
   | libssl47-32bit        | package | 2.9.2-1.2    | x86_64 | openSUSE-Tumbleweed-Oss

>

and for liblber

Code: Select all

S  | Name                | Type    | Version     | Arch   | Repository             
---+---------------------+---------+-------------+--------+------------------------
i+ | libldap-2_4-2       | package | 2.4.48-48.2 | x86_64 | openSUSE-Tumbleweed-Oss
v  | libldap-2_4-2       | package | 2.4.48-48.2 | i586   | openSUSE-Tumbleweed-Oss
i+ | libldap-2_4-2-32bit | package | 2.4.48-48.2 | x86_64 | openSUSE-Tumbleweed-Oss

Sorry I gave up the static versions and moved to the rolling distribution but that may help

User avatar
Lander1979
Posts: 1017
Joined: Mon, 4. Aug 14, 05:18
x4

Re: Linux Support (Beta)

Post by Lander1979 » Tue, 5. Nov 19, 08:34

I can no longer launch X4. Instead a box opens that says;

X4 - Fatal Error
A fatal error has occurred and X cannot recover:
Vulkan::CreateMemoryHeaps() Couldn't allocate heap 9
Version: 2.60 - Code revision: 370595

Please inform EGOSOFT GmbH technical support.

OS: Arch Linux Rolling Stable.
Launcher: STEAM Runtime.
GFX: Nvidia 1050 2GB

EDIT: After a clean reboot X4 launches ok so the problem seems to be intermittent. I will update if I can narrow down the cause of the error.
0101...0011...0011...0101...2!

Rastuasi
Posts: 459
Joined: Mon, 1. Oct 18, 16:28
x4

Re: Linux Support (Beta)

Post by Rastuasi » Tue, 5. Nov 19, 15:31

I'm running a custom version of the arch kernel, I've not had this, but I do get menu artifacts, where lines occasionally stick while scrolling.

radcapricorn
Moderator (English)
Moderator (English)
Posts: 3230
Joined: Mon, 14. Jul 08, 13:07
x4

Re: Linux Support (Beta)

Post by radcapricorn » Tue, 5. Nov 19, 16:52

Rastuasi wrote:
Tue, 5. Nov 19, 15:31
I'm running a custom version of the arch kernel, I've not had this, but I do get menu artifacts, where lines occasionally stick while scrolling.
That's a known issue and isn't Linux-specific.

@Lander1979 I have been getting that beautiful red window crash occasionally in recent builds as well.

radcapricorn
Moderator (English)
Moderator (English)
Posts: 3230
Joined: Mon, 14. Jul 08, 13:07
x4

Re: Linux Support (Beta)

Post by radcapricorn » Fri, 15. Nov 19, 14:22

Yay, mouse pointer finally got some love with 3.0 beta!

User avatar
Lander1979
Posts: 1017
Joined: Mon, 4. Aug 14, 05:18
x4

Re: Linux Support (Beta)

Post by Lander1979 » Sat, 16. Nov 19, 03:41

I have a small issue that I've been trying to fix since moving from Win10 to Arch Linux, In Win10 both of my Thrustmaster T.16000M flightsticks work out of the box, however in Linux only one of the two flightsticks is detected by X4.
In Arch Linux both joysticks are detected on dev/input/js0 and dev/input/js1, but with identical names in jstest-gtk . In Steam both joysticks are detected but also with identical names, but in the game only the first stick (or dev/input/js0) is detected and mappable. Is there any way to get X4 to detect Both sticks and make them mappable?

EDIT: Just tested X-Rebirth on Arch Linux and both controllers are detected and working fine there so this is definitely an X4 issue and not a me\OS issue.

EDIT: I think the problem is the name of the flightstick, if I swap out either stick for a different brand both are detected. This seems to be the case with X-Rebirth as well, however I didn't notice as it initially detects both sticks and places them on a slot, however if that is changed one of the sticks speaks for both and clears the slot of the other stick, very annoying. X4 unfortunately isn't even listing the second flightstick or giving it an initial slot as Rebirth did.

Now, the question is, how do I change the name of the sticks so the game sees them as unique and doesnt confuse them and ignore the existence of the second stick?

Here is the output of $ udevadm info /dev/input/js0

Code: Select all

P: /devices/pci0000:00/0000:00:12.0/usb6/6-1/6-1:1.0/0003:044F:B10A.0003/input/input3/js0
N: input/js0
L: 0
S: input/by-path/pci-0000:00:12.0-usb-0:1:1.0-joystick
S: input/by-id/usb-Thrustmaster_T.16000M-joystick
E: DEVPATH=/devices/pci0000:00/0000:00:12.0/usb6/6-1/6-1:1.0/0003:044F:B10A.0003/input/input3/js0
E: DEVNAME=/dev/input/js0
E: MAJOR=13
E: MINOR=0
E: SUBSYSTEM=input
E: USEC_INITIALIZED=14653899
E: ID_INPUT=1
E: ID_INPUT_JOYSTICK=1
E: ID_VENDOR=Thrustmaster
E: ID_VENDOR_ENC=Thrustmaster
E: ID_VENDOR_ID=044f
E: ID_MODEL=T.16000M
E: ID_MODEL_ENC=T.16000M
E: ID_MODEL_ID=b10a
E: ID_REVISION=0500
E: ID_SERIAL=Thrustmaster_T.16000M
E: ID_TYPE=hid
E: ID_BUS=usb
E: ID_USB_INTERFACES=:030000:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=usbhid
E: ID_PATH=pci-0000:00:12.0-usb-0:1:1.0
E: ID_PATH_TAG=pci-0000_00_12_0-usb-0_1_1_0
E: ID_FOR_SEAT=input-pci-0000_00_12_0-usb-0_1_1_0
E: DEVLINKS=/dev/input/by-path/pci-0000:00:12.0-usb-0:1:1.0-joystick /dev/input/by-id/usb-Thrustmaster_T.16000M-joystick
E: TAGS=:uaccess:seat:
Also the output of $ udevadm info /dev/input/js1

Code: Select all

P: /devices/pci0000:00/0000:00:12.0/usb6/6-2/6-2:1.0/0003:044F:B10A.0007/input/input23/js1
N: input/js1
L: 0
S: input/by-path/pci-0000:00:12.0-usb-0:2:1.0-joystick
S: input/by-id/usb-Thrustmaster_T.16000M-joystick
E: DEVPATH=/devices/pci0000:00/0000:00:12.0/usb6/6-2/6-2:1.0/0003:044F:B10A.0007/input/input23/js1
E: DEVNAME=/dev/input/js1
E: MAJOR=13
E: MINOR=1
E: SUBSYSTEM=input
E: USEC_INITIALIZED=6194827722
E: ID_INPUT=1
E: ID_INPUT_JOYSTICK=1
E: ID_VENDOR=Thrustmaster
E: ID_VENDOR_ENC=Thrustmaster
E: ID_VENDOR_ID=044f
E: ID_MODEL=T.16000M
E: ID_MODEL_ENC=T.16000M
E: ID_MODEL_ID=b10a
E: ID_REVISION=0500
E: ID_SERIAL=Thrustmaster_T.16000M
E: ID_TYPE=hid
E: ID_BUS=usb
E: ID_USB_INTERFACES=:030000:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=usbhid
E: ID_PATH=pci-0000:00:12.0-usb-0:2:1.0
E: ID_PATH_TAG=pci-0000_00_12_0-usb-0_2_1_0
E: ID_FOR_SEAT=input-pci-0000_00_12_0-usb-0_2_1_0
E: DEVLINKS=/dev/input/by-path/pci-0000:00:12.0-usb-0:2:1.0-joystick /dev/input/by-id/usb-Thrustmaster_T.16000M-joystick
E: TAGS=:seat:uaccess:
0101...0011...0011...0101...2!

steve_v
Posts: 164
Joined: Sun, 12. Jun 16, 08:39
x4

Re: Linux Support (Beta)

Post by steve_v » Sat, 16. Nov 19, 09:22

Lander1979 wrote:
Sat, 16. Nov 19, 03:41
how do I change the name of the sticks so the game sees them as unique and doesnt confuse them
The real question is: How does X4 query available devices? It's linked against SDL2, so presumably that's how it's handling input?

If it is using SDL2, a quick rummage around in the SDL code suggests that SDL_JoystickName is just going to report whatever the input driver gives it... and the input driver (usbhid) is going to report whatever the USB device identifies itself as.
If your joysticks both report "Thrustmaster T.16000M flightstick" over the USB bus, that's what SDL will tell X4, and X4 will get confused because it probably doesn't have any code to handle this corner-case.
It's a limitation of the SDL joystick API, and no more useful identifier than name and index will you get.

Until SDL2's new GameController API is production ready (i.e. supports real joysticks properly), the only way I can see to work around this is for X4 to query the OS for more information directly - device serial numbers are available via sysfs, lsusb or libudev. The latter is probably the way to go.

adamto99 wrote:
Tue, 12. Nov 19, 14:24
Ahem ... why is the Linux version linked against kerberos and libssh2 libs?
Ahem, please stop hiding random links in your quotes. Reported for spam.
As for ssh and kerberos, it's probably using some of the crypto functions for the whole "let's screw over people who like mods" online stuff.

User avatar
Lander1979
Posts: 1017
Joined: Mon, 4. Aug 14, 05:18
x4

Re: Linux Support (Beta)

Post by Lander1979 » Sat, 16. Nov 19, 09:33

I was looking at trying to change something in udev by applying a rule maybe? My line of thought was to change the device by name to be specific as I noticed I have 2 devices by path but only 1 device by id. Though I am an absolute Linux newb having just come from Windows so I really don't know how these things work. At this stage I'm blindly fumbling my way along poorly documented udev tutorials hoping to find an answer...
Last edited by Lander1979 on Sat, 16. Nov 19, 09:41, edited 1 time in total.
0101...0011...0011...0101...2!

steve_v
Posts: 164
Joined: Sun, 12. Jun 16, 08:39
x4

Re: Linux Support (Beta)

Post by steve_v » Sat, 16. Nov 19, 09:40

Lander1979 wrote:
Sat, 16. Nov 19, 09:33
I was wondering if maybe trying to change something in udev by applying a rule maybe? My line of thought was to maybe change the device by name to be specific as I noticed I have 2 devices by path but only 1 device by id.
Those symlinks (by-id, by-name, by-path etc.) are created by udev, so you should be able to modify them with an appropriate udev rule. Some reading here and here might be a place to start. I suspect it won't fix your problem, but it can't hurt to try it.

I'd whip you up a rule myself, but I don't actually run udev... or have two identical joysticks.

Ed. Out of interest, can someone with XR installed do a quick ldd on the binary? I'm curious as to if it's linked to libsdl2, libudev, or both.
I own it for sure, but I played about 10 minutes before dumping it and it's kinda a big DL...

User avatar
Lander1979
Posts: 1017
Joined: Mon, 4. Aug 14, 05:18
x4

Re: Linux Support (Beta)

Post by Lander1979 » Sat, 16. Nov 19, 10:46

Ok Im jumping waay waay into the deep end of the pool here, as in I have literally no idea how to do this, but so far;

$ udevadm info --attribute-walk --path=$(udevadm info --query=path --name=/dev/input/js0)

outputs;

Code: Select all

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '//devices/pci0000:00/0000:00:12.0/usb6/6-1/6-1:1.0/0003:044F:B10A.0003/input/input3/js0':
    KERNEL=="js0"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '//devices/pci0000:00/0000:00:12.0/usb6/6-1/6-1:1.0/0003:044F:B10A.0003/input/input3':
    KERNELS=="input3"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{name}=="Thrustmaster T.16000M"
    ATTRS{phys}=="usb-0000:00:12.0-1/input0"
    ATTRS{properties}=="0"
    ATTRS{uniq}==""

  looking at parent device '//devices/pci0000:00/0000:00:12.0/usb6/6-1/6-1:1.0/0003:044F:B10A.0003':
    KERNELS=="0003:044F:B10A.0003"
    SUBSYSTEMS=="hid"
    DRIVERS=="hid-generic"
    ATTRS{country}=="00"

  looking at parent device '//devices/pci0000:00/0000:00:12.0/usb6/6-1/6-1:1.0':
    KERNELS=="6-1:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="usbhid"
    ATTRS{bInterfaceProtocol}=="00"
    ATTRS{authorized}=="1"
    ATTRS{supports_autosuspend}=="1"
    ATTRS{bInterfaceNumber}=="00"
    ATTRS{bNumEndpoints}=="01"
    ATTRS{bInterfaceClass}=="03"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bInterfaceSubClass}=="00"

  looking at parent device '//devices/pci0000:00/0000:00:12.0/usb6/6-1':
    KERNELS=="6-1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{version}==" 1.10"
    ATTRS{quirks}=="0x0"
    ATTRS{devnum}=="2"
    ATTRS{idProduct}=="b10a"
    ATTRS{rx_lanes}=="1"
    ATTRS{speed}=="12"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{product}=="T.16000M"
    ATTRS{bDeviceClass}=="00"
    ATTRS{bcdDevice}=="0500"
    ATTRS{removable}=="unknown"
    ATTRS{tx_lanes}=="1"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{manufacturer}=="Thrustmaster"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{idVendor}=="044f"
    ATTRS{devpath}=="1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{devspec}=="(null)"
    ATTRS{bMaxPower}=="100mA"
    ATTRS{configuration}==""
    ATTRS{authorized}=="1"
    ATTRS{busnum}=="6"
    ATTRS{ltm_capable}=="no"
    ATTRS{maxchild}=="0"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bmAttributes}=="80"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{urbnum}=="24"

  looking at parent device '//devices/pci0000:00/0000:00:12.0/usb6':
    KERNELS=="usb6"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{manufacturer}=="Linux 5.3.11-arch1-1 ohci_hcd"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{idProduct}=="0001"
    ATTRS{bcdDevice}=="0503"
    ATTRS{authorized}=="1"
    ATTRS{serial}=="0000:00:12.0"
    ATTRS{quirks}=="0x0"
    ATTRS{ltm_capable}=="no"
    ATTRS{idVendor}=="1d6b"
    ATTRS{rx_lanes}=="1"
    ATTRS{busnum}=="6"
    ATTRS{product}=="OHCI PCI host controller"
    ATTRS{devpath}=="0"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{tx_lanes}=="1"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{removable}=="unknown"
    ATTRS{urbnum}=="81"
    ATTRS{maxchild}=="5"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{configuration}==""
    ATTRS{authorized_default}=="1"
    ATTRS{bMaxPower}=="0mA"
    ATTRS{version}==" 1.10"
    ATTRS{devspec}=="(null)"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{interface_authorized_default}=="1"
    ATTRS{speed}=="12"
    ATTRS{devnum}=="1"

  looking at parent device '//devices/pci0000:00/0000:00:12.0':
    KERNELS=="0000:00:12.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="ohci-pci"
    ATTRS{local_cpulist}=="0-3"
    ATTRS{irq}=="18"
    ATTRS{broken_parity_status}=="0"
    ATTRS{enable}=="1"
    ATTRS{subsystem_device}=="0x4397"
    ATTRS{revision}=="0x00"
    ATTRS{vendor}=="0x1002"
    ATTRS{numa_node}=="0"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{ari_enabled}=="0"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{subsystem_vendor}=="0x1849"
    ATTRS{class}=="0x0c0310"
    ATTRS{d3cold_allowed}=="0"
    ATTRS{device}=="0x4397"
    ATTRS{devspec}==""
    ATTRS{msi_bus}=="1"
    ATTRS{local_cpus}=="f"
    ATTRS{driver_override}=="(null)"

  looking at parent device '//devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""
and
$ udevadm info --attribute-walk --path=$(udevadm info --query=path --name=/dev/input/js1)

Code: Select all

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '//devices/pci0000:00/0000:00:12.0/usb6/6-2/6-2:1.0/0003:044F:B10A.0007/input/input23/js1':
    KERNEL=="js1"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '//devices/pci0000:00/0000:00:12.0/usb6/6-2/6-2:1.0/0003:044F:B10A.0007/input/input23':
    KERNELS=="input23"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{phys}=="usb-0000:00:12.0-2/input0"
    ATTRS{name}=="Thrustmaster T.16000M"
    ATTRS{properties}=="0"
    ATTRS{uniq}==""

  looking at parent device '//devices/pci0000:00/0000:00:12.0/usb6/6-2/6-2:1.0/0003:044F:B10A.0007':
    KERNELS=="0003:044F:B10A.0007"
    SUBSYSTEMS=="hid"
    DRIVERS=="hid-generic"
    ATTRS{country}=="00"

  looking at parent device '//devices/pci0000:00/0000:00:12.0/usb6/6-2/6-2:1.0':
    KERNELS=="6-2:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="usbhid"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{supports_autosuspend}=="1"
    ATTRS{bNumEndpoints}=="01"
    ATTRS{bInterfaceNumber}=="00"
    ATTRS{bInterfaceClass}=="03"
    ATTRS{authorized}=="1"
    ATTRS{bInterfaceSubClass}=="00"
    ATTRS{bInterfaceProtocol}=="00"

  looking at parent device '//devices/pci0000:00/0000:00:12.0/usb6/6-2':
    KERNELS=="6-2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{quirks}=="0x0"
    ATTRS{removable}=="unknown"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{idProduct}=="b10a"
    ATTRS{configuration}==""
    ATTRS{urbnum}=="13"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{rx_lanes}=="1"
    ATTRS{ltm_capable}=="no"
    ATTRS{busnum}=="6"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{tx_lanes}=="1"
    ATTRS{maxchild}=="0"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{speed}=="12"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{idVendor}=="044f"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{product}=="T.16000M"
    ATTRS{bDeviceClass}=="00"
    ATTRS{manufacturer}=="Thrustmaster"
    ATTRS{devspec}=="(null)"
    ATTRS{version}==" 1.10"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bmAttributes}=="80"
    ATTRS{devnum}=="4"
    ATTRS{bMaxPower}=="100mA"
    ATTRS{authorized}=="1"
    ATTRS{devpath}=="2"
    ATTRS{bcdDevice}=="0500"

  looking at parent device '//devices/pci0000:00/0000:00:12.0/usb6':
    KERNELS=="usb6"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{devpath}=="0"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{maxchild}=="5"
    ATTRS{urbnum}=="81"
    ATTRS{bMaxPower}=="0mA"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{devnum}=="1"
    ATTRS{interface_authorized_default}=="1"
    ATTRS{removable}=="unknown"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{configuration}==""
    ATTRS{bDeviceClass}=="09"
    ATTRS{busnum}=="6"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bmAttributes}=="e0"
    ATTRS{devspec}=="(null)"
    ATTRS{authorized}=="1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{manufacturer}=="Linux 5.3.11-arch1-1 ohci_hcd"
    ATTRS{rx_lanes}=="1"
    ATTRS{serial}=="0000:00:12.0"
    ATTRS{speed}=="12"
    ATTRS{quirks}=="0x0"
    ATTRS{ltm_capable}=="no"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{product}=="OHCI PCI host controller"
    ATTRS{version}==" 1.10"
    ATTRS{idProduct}=="0001"
    ATTRS{idVendor}=="1d6b"
    ATTRS{bcdDevice}=="0503"
    ATTRS{authorized_default}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{tx_lanes}=="1"

  looking at parent device '//devices/pci0000:00/0000:00:12.0':
    KERNELS=="0000:00:12.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="ohci-pci"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{irq}=="18"
    ATTRS{enable}=="1"
    ATTRS{driver_override}=="(null)"
    ATTRS{class}=="0x0c0310"
    ATTRS{broken_parity_status}=="0"
    ATTRS{numa_node}=="0"
    ATTRS{msi_bus}=="1"
    ATTRS{ari_enabled}=="0"
    ATTRS{subsystem_device}=="0x4397"
    ATTRS{revision}=="0x00"
    ATTRS{local_cpus}=="f"
    ATTRS{subsystem_vendor}=="0x1849"
    ATTRS{devspec}==""
    ATTRS{device}=="0x4397"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{vendor}=="0x1002"
    ATTRS{d3cold_allowed}=="0"
    ATTRS{local_cpulist}=="0-3"

  looking at parent device '//devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""
    
So if I am to understand this correctly, I need to try to come up with a rule that looks at these attributes and can identify the difference between them, then use that to change the symlink somehow?
0101...0011...0011...0101...2!

steve_v
Posts: 164
Joined: Sun, 12. Jun 16, 08:39
x4

Re: Linux Support (Beta)

Post by steve_v » Sat, 16. Nov 19, 11:15

Lander1979 wrote:
Sat, 16. Nov 19, 10:46
So if I am to understand this correctly, I need to try to come up with a rule that looks at these attributes and can identify the difference between them, then use that to change the symlink somehow?
Pretty much. Find an attribute that can be used to tell the devices apart, and have udev make a symlink in /dev/ with an appropriate name when they are plugged in.

I haven't played with udev in a long time, but I'd expect something like:

Code: Select all

SUBSYSTEM=="input", ATTRS{idVendor}=="XXXX", ATTRS{idProduct}=="YYYY", ATTRS{serial}=="ZZZZ", SYMLINK+="joystick_foo"
is what you're after. As to whether X4 actually looks at symlink names in /dev/, dunno.

This is a good exercise in figuring out the arcane (and constantly changing) potteringware that is udev, but I honestly doubt X4 will notice even if you override the standard by-id links. It is after all a port from windows, and ports love cross-platform APIs like SDL, not looking in GNU/Linux specific places...

User avatar
Lander1979
Posts: 1017
Joined: Mon, 4. Aug 14, 05:18
x4

Re: Linux Support (Beta)

Post by Lander1979 » Sat, 16. Nov 19, 13:20

Every rule I've tried to make seems to have zero effect. I'm unable to change the symlink(though I think this is an issue with me not understanding what is actually going on here). It's sad to think that even if I did that it isn't even going to help with X4 disccovering the Joystick due to the SDL issue.

EDIT: Also these flight sticks are identical in almost every respect. Even down to the vendor id and serial #. The only way to distinguish them apart is by the USB port they are plugged in to.

EDIT: I was able to manually create the missing symlinks to the joystick and it's event, however you were right, it changes nothing. I think I am trying to treat symtoms of the problem here rather than the actual cause...
0101...0011...0011...0101...2!

User avatar
Lander1979
Posts: 1017
Joined: Mon, 4. Aug 14, 05:18
x4

Re: Linux Support (Beta)

Post by Lander1979 » Sun, 17. Nov 19, 04:36

Ok, todays topic will be a crash course on the Linux Kernel and how to manipulate Kernel Modules :sceptic:

Continuing my trip down the rabbit-hole today with the udev/SDL2 Dual T.16000M Conflict I began trawling through SDL2 Bugtrackers and bug posts, and I came across this similar use case that comes with a few work-arounds.

http://forums.libsdl.org/viewtopic.php?p=45762

So I am now going to attempt to find and disable the evdev Kernel module to see if there is any knock-on effect that lets X4 see the second flightstick...

EDIT: Results; Removing the 'evdev' Kernel module appears to brick the PC, requiring a rescue solution. It seems that all inputs are being handled by the evdev module and without it the system will still boot, but there is no keyboard or mouse. If I am to try the 'disable evdev' solution then I need to find another way to use kbd and mouse...

Setting SDL_JOYSTICK_DEVICE=/dev/input/js0 in /etc/environment did nothing either. I think I've exhausted all the options and it's safe to call this an X4 Bug. Not just an X4 bug either, but a udev bug and an SDL2 bug, as well as a Thrustmaster bug.
0101...0011...0011...0101...2!

steve_v
Posts: 164
Joined: Sun, 12. Jun 16, 08:39
x4

Re: Linux Support (Beta)

Post by steve_v » Sun, 17. Nov 19, 13:02

Lander1979 wrote:
Sun, 17. Nov 19, 04:36
Results; Removing the 'evdev' Kernel module appears to brick the PC, requiring a rescue solution.
I have a reply open in another tab, but I became distracted before hitting "submit"... It reads: Make sure you have a way to reverse this without use of your USB input devices, including the mouse and probably the keyboard too. Alternative drivers exist, so long as they're compiled into your kernel.
Uhh, sorry I guess. Oops. I blame Mayhem.

For recovery, either chroot into your install from a livecd or just SSH into your box from another device. This is one of the reasons we run ssh servers. ;)
Lander1979 wrote:
Sun, 17. Nov 19, 04:36
I think I've exhausted all the options and it's safe to call this an X4 Bug. Not just an X4 bug either, but a udev bug and an SDL2 bug, as well as a Thrustmaster bug.
Pretty much, though I'd be more inclined to say:
1) More an oversight, XR handles this fine, so time to port over that solution.
2) Not really udev's problem.
3) A bug if you can call missing features bugs, it's being worked on.
4) If they both report the same serial number (and they probably do), most certainly a bug. Never going to be fixed though, it works on Windoze and manufacturers are generally lazy sods.

User avatar
Lander1979
Posts: 1017
Joined: Mon, 4. Aug 14, 05:18
x4

Re: Linux Support (Beta)

Post by Lander1979 » Fri, 22. Nov 19, 07:18

I have a response from Thrustmaster... They don't support Linux. I suggested they take a queue from Microsoft and get onto it or be left behind.

So as far as X4 is concerned, should I consider this bug as reported? I'd love to know that it's at least on somebodys "to do" list...
0101...0011...0011...0101...2!

steve_v
Posts: 164
Joined: Sun, 12. Jun 16, 08:39
x4

Re: Linux Support (Beta)

Post by steve_v » Sat, 23. Nov 19, 15:56

Lander1979 wrote:
Fri, 22. Nov 19, 07:18
So as far as X4 is concerned, should I consider this bug as reported?
That's an excellent question, and AFAIK there is no public bugtracker or other facility specifically for reporting bugs.

As far as I can tell, the general approach seems to be opening a new thread in the tech support forum and waiting until someone from egosoft makes comment.

Cadbury
Posts: 7
Joined: Sun, 17. Nov 19, 21:57
x4

Re: Linux Support (Beta)

Post by Cadbury » Sun, 24. Nov 19, 19:23

Anyone tried a Saitek X52 pro? I can get all the buttons to map but any axes are completely unresponsive :(

I can see all the axes correctly responding in the Manjaro game controller setup window.

Rastuasi
Posts: 459
Joined: Mon, 1. Oct 18, 16:28
x4

Re: Linux Support (Beta)

Post by Rastuasi » Sun, 24. Nov 19, 20:18

I use the x56 warthog with no issues on Arch

Post Reply

Return to “X4: Foundations - Technical Support”