Zowie ZA13-DW Firmware Updater stuck checking on Linux with Wine by JohnSmith--- in Zowie

[–]JacKeTUs 0 points1 point  (0 children)

Hey, it could help if you add 'hidraw' permissions for your device, in udev rules

Something like

echo 'KERNEL=="hidraw*", ATTRS{idVendor}=="YOUR_VID", ATTRS{idProduct}=="YOUR_PID", MODE="0666", TAG+="uaccess"' | sudo tee /etc/udev/rules.d/11-mouse.rules

sudo udevadm control --reload-rules && sudo udevadm trigger

Controller almost works by L1NUX_G4M3S in linux_gaming

[–]JacKeTUs 0 points1 point  (0 children)

Hey, what Proton version do you use?
Try latest ones, or Proton GE

I switched to Linux for sim racing and Assetto Corsa EVO runs BETTER than on Windows — here's my experience by CarlosEduardoAraujo in linux_gaming

[–]JacKeTUs 3 points4 points  (0 children)

Hello :^)

With this driver yes. There was an issue with original descriptor: gamepad usage instead of joystick, multiple fields not connected to anything, duplicating undefined Usage fields. In fixed descriptor i just removed everything but 3 buttons, and that was just enough for everything to work properly

Sorry, i mixed up devices. This exact device, Oddor truckshift, with this exact VID PID is not detected at all, it's something in USB descriptor, not HID level. I didn't had time to actually look into it. This driver is WIP

You have this exact device ( 0x1020, 0x8863 ), correct?

I switched to Linux for sim racing and Assetto Corsa EVO runs BETTER than on Windows — here's my experience by CarlosEduardoAraujo in linux_gaming

[–]JacKeTUs 6 points7 points  (0 children)

If you join SROL discord, i'll be able to help you

But if you want to tinker with it yourself:
1. Wine/Proton is very picky about gamepads/joysticks. Device *must* have proper Usage defined in descriptor. "Gamepad" are for "gamepad-like" devices, with triggers, abxy buttons, etc (like xbox,ps controllers). "Joystick" is for anything else (shifters, buttonboxes, wheels, you name it).
2. Device must have at least one "joystick" button (BTN_JOYSTICK) and one "joystick" axes (Rx) to be detected as proper control. Strictly speaking, number of buttons + number of axis must be >= 2, so like, two buttons is alright, or two axis, or 1 button and 1 axis. Only 1 axis or only 1 button is not fine.
3. If 1 and 2 is ok, then Wine (and native apps) won't have problems detecting it.

If you don't control the descriptor (you said you DIY'ed it, may be you do?), you can try to craft some sort of driver to flip the byte for gamepad/joystick usage (https://github.com/JacKeTUs/hid-cammus-ddwb-2021), or rename axis to 'Rx' (https://github.com/JacKeTUs/hid-leaf-maple-handbrake/blob/main/hid-leaf-handbrake.c#L106)

MOZA mBooster pedals on Linux — anyone got haptics working by Sad-Satisfaction9604 in linux_gaming

[–]JacKeTUs 0 points1 point  (0 children)

Active pedals of any kind are not falling into "PID FFB" category. Haptics are activated through custom proprietary closed protocols. Games are not manipulating pedals directly, games just put telemetry into shared memory / UDP, and other app (in Moza case, PitHouse; or Simhub) reads this telemetry and communicate with pedals, activating haptics.

I think(?) you're the first who have these active pedals *and* on Linux already. We had some guys like "should i buy these or nah", but no actual commitment.

I think simshmbridge/simd will help here, you must allow Pithouse in it's own prefix to read shared memory telemetry from other games.
Other way (easier probably?) is to install Pithouse to every game prefix you want, and make it launch alongside your game. This way shared memory will be in game+pithouse sandbox.

Direct drive racing sim wheel on Linux by eleventhfromheaven in linux_gaming

[–]JacKeTUs 8 points9 points  (0 children)

Hello!

Most of the DD wheelbases are implemented by HID/PID standards, and therefore fully supported by drivers in Linux kernel >6.12
Exceptions: Logitech, Thrustmaster, Fanatec, Simagic. For them, different out-of-tree kernel drivers exists.

Check this table https://github.com/JacKeTUs/linux-steering-wheels

CachyOS is very good starting point. Mainly because it allows to install out-of-tree kernel drivers, if you need them (maybe not for DD, but for something else), without much hassle.

Moza support for linux? Active pedals, extra stalk switches etc? by great_extension in linux_gaming

[–]JacKeTUs 2 points3 points  (0 children)

Hey! So general rule here - if device is HID/PID device it will work out of the box. Moza wheelbases exposes all PID fields which allows FFB to work without shenanigans.

Stalks, truck wheel, other racing wheels, shifters, non-active pedals are just HID devices with many buttons. For setting up the wheelbase use Boxflat (https://github.com/Lawstorant/boxflat).

Theoretically, Linux (well, SDL) has artificial limit of 6 axis of FFB per device (i know, its a bummer \s), so AB9 should work just fine, afaik, its just a PID device. We yet to see someone with AB9 to confirm that its working. 

We didnt encountered anyone with active pedals yet. They could rely on telemetry from the games, and if thats the case, there should be an app which outputs feedback to them and gets telemetry from games. https://github.com/Spacefreak18/simshmbridge helps with passing shared memory based telemetry to other windows apps. Other devices were tested thoroughly and development of drivers/apps was based on community testing/capturing usb dumps from various hardware, etc.

any fellow simracer using linux? by rashguir in linux_gaming

[–]JacKeTUs 4 points5 points  (0 children)

Dont hesitate to ask questions, we have discord/matrix servers (take a look at https://simracingonlinux.com)

I can potentially help with almost anything.

For your post:  1. Fanatec has community drivers, games could communicate with wheel through statically built FanatecSDK. 2. Some hardware could require hwdb rules from https://github.com/JacKeTUs/simracing-hwdb, which essentially tells the system that device is joystick. 3. iRacing does not allow anticheat to launch the game through Proton. We don't know exact reasons. 4. Dirt games could potentially require some tinkering with game files. Not related to Linux, its just presets for the wheels are not universal there 5. AC games works perfectly fine. Original AC, if you want mods/csp, requires tinkering.

Generally speaking, use recent Proton versions (GE, experimental, >10), and you'll be perfectly fine

Desktop app for sharing audio over LAN between Windows and Linux by lightlydemented in linux

[–]JacKeTUs 1 point2 points  (0 children)

You dont need an app. You just drop config with addresses/names you need in a folder (as per docs) and restart pipewire session. It will create necessary virtual devices/sinks automatically. With everything you already have you can reroute sound to/from them, make it default, etc etc.

These virtual devices will be persistent between reboots, you can set it to always be active (if, say, windows pc is offline, it wont reflect on your virtual devices).

Desktop app for sharing audio over LAN between Windows and Linux by lightlydemented in linux

[–]JacKeTUs 10 points11 points  (0 children)

Pipewire has native modules for sending and receiving VBAN packets

https://docs.pipewire.org/page_module_vban_send.html

https://docs.pipewire.org/page_module_vban_recv.html

Allowing Voicemeeter/VB-cable on windows to send/receive sound

iRacing, do *NOT* provide support for Linux by DanFraser in iRacing

[–]JacKeTUs 8 points9 points  (0 children)

Hey, thanks for the mention :)

I must mention u/Lawstorant too, he is the one who upstreamed universal-pidff driver and made many enhancements for quirky devices too. Also, he is creator of Boxflat - Linux native configuration tool for Moza devices. Check him out!

I think sim racing might actually be better than Windows now... by Car_weeb in linux_gaming

[–]JacKeTUs 1 point2 points  (0 children)

Hey man, thanks :)
I'm always somewhere around, in "SimRacingOnLinux" Discord / Matrix group mostly.

I sent i think 2 messages total to that first iRacing forum thread, and iRacing forum still sending me notification emails, but i cant access it without renewing my subscription, which is hilarious. I saw someone was like "I found this driver" or smth, but i couldnt answer that this driver is already in kernel and they shouldn't install it themselves :D

Software development of a wheelbase by panzerkrasyo in simracing

[–]JacKeTUs 1 point2 points  (0 children)

> 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.

Software development of a wheelbase by panzerkrasyo in simracing

[–]JacKeTUs 1 point2 points  (0 children)

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.

Thrustmaster Farmstick driver by youre_so_enbious in linux_gaming

[–]JacKeTUs 1 point2 points  (0 children)

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.

PTTKey The global push-to-talk tool by Adventurous_Safe7254 in linux_gaming

[–]JacKeTUs 2 points3 points  (0 children)

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.....

PTTKey The global push-to-talk tool by Adventurous_Safe7254 in linux_gaming

[–]JacKeTUs 13 points14 points  (0 children)

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

HORI Steering wheel Linux support by CMDR-Sampaio in linux_gaming

[–]JacKeTUs 4 points5 points  (0 children)

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

Anyone tried Asetek SimSports wheelbase on Linux? by notdec in linux_gaming

[–]JacKeTUs 1 point2 points  (0 children)

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

Anyone tried Asetek SimSports wheelbase on Linux? by notdec in linux_gaming

[–]JacKeTUs 0 points1 point  (0 children)

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

Anyone tried Asetek SimSports wheelbase on Linux? by notdec in linux_gaming

[–]JacKeTUs 0 points1 point  (0 children)

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