Skip to content

Troubleshooting

mescon edited this page Jul 28, 2026 · 6 revisions

Troubleshooting

First move for anything at all, from a git checkout:

./tools/setup.sh doctor

It health-checks every layer (module built, loaded, bound, udev rule, permissions, tools) and names the exact fix for anything that fails.

Common symptoms

Symptom Fix
logi-dd is gone / where is the app? It is called logi-wheel (and logi-wheel-gui) since 0.20.0. Packages upgrade in place and the old names remain as symlinks, so nothing you already run should break; see Installation
No wheel_* files, no FFB (wheel grabbed by hid-generic) The module did not bind. Confirm it is loaded (lsmod | grep hid_logitech_dd), replug the wheel, check dmesg. From a checkout: sudo ./tools/rebind-wheel.sh
Settings writes return "permission denied" The udev rule that grants your desktop user access is missing or not applied. Run ./tools/setup.sh doctor, then replug the wheel; no group membership is needed
Force feedback pulls the wrong way A native game and a Wine/Proton game can want opposite signs: toggle Invert constant force in logi-wheel (the wheel_ffb_constant_sign attribute)
A game stops seeing the wheel after a driver reload Restart Steam completely; its device list goes stale across reloads
Rotation snaps to 90° at session start Some games reset it themselves; the driver restores your range automatically within about 20 seconds (dmesg shows rotation range changed externally then rotation range auto-restored). Re-apply the game's own steering-lock setting so it stops pushing 90°. If you ever end up stuck at 90, that is a bug worth reporting
Steering feels off-center Hold the rim physically straight, then echo 1 > "$H/wheel_calibrate_here" (or the Calibrate action in logi-wheel)
Rumble shakes the steering instead of buzzing the rim Check cat "$H/wheel_texture_route" says tf; texture belongs on the haptic channel
No FFB in a DirectInput game (Le Mans Ultimate etc.) Launch it with logi-ffb %command%, which sets up the force-feedback path; without the proxy these games need PROTON_ENABLE_HIDRAW=0. See Force Feedback in Games
Pedals read as fully pressed when released (in game) A side effect of PROTON_ENABLE_HIDRAW=1: the game is reading the wheel's raw HID reports, which use the opposite convention to the Linux input layer. Turn on the game's own "invert axis" for those pedals, or unset the variable if you do not need TrueForce. Nothing is wrong with the wheel.
TrueForce does not turn on in a game that supports it Check Logitech's TrueForce files are installed for that game (Setup page), PROTON_ENABLE_HIDRAW=1 is set, and Steam Input is disabled for the game
Wheel oscillates hard during a load screen Keep hands clear during AC EVO map loads; the driver damps game-uploaded springs (wheel_spring_damping, default 25) to keep the wheel's over-torque failsafe from tripping
G923: no force feedback in a game Remove PROTON_ENABLE_HIDRAW=1 from the game's launch options; that recipe is for the RS50 / G PRO and breaks the G923. No launch options, Steam Input off. See G923
G923: another driver grabbed the wheel The packaged udev rule reclaims c266/c267/c26e automatically; replug and check dmesg. If you run berarma's new-lg4ff, note this driver blacklists it (it races for the same PIDs)
G923: settings missing from the app (LIGHTSYNC, curves, profile slots, mode toggle) Not a fault: the apps hide what a wheel does not have, and those are direct-drive features. The G923's four settings, desktop profiles and the tests are all there. See G923
G923 Xbox edition: no input device at all The wheel is stuck in console mode (046d:c26d). Install usb_modeswitch and replug; if it still never switches to c26e, the out-of-tree xone driver may be claiming it first

($H above is the wheel's sysfs directory: H=$(ls -d /sys/class/hidraw/*/device/wheel_range | head -1 | xargs dirname). On a G923 there are no wheel_* files; its classic attributes are listed in the Sysfs API Reference.)

Behaviors that are not bugs

  • The wheel self-centers when nothing is running (compat mode, onboard profiles): firmware behavior, same as Windows with G HUB running.
  • Compat mode boots at 90°: the factory default. Set your range once (desktop mode first: wheel_profile=0, then wheel_range=900); see Configuring the Wheel.
  • Strong forces when reversing in sims that model self-aligning torque: real-car physics surfacing through a direct-drive motor, identical on Windows. Lower wheel_strength if it is too much.

Reporting a bug

Open an issue with:

  • your kernel version and distribution,
  • the driver and app versions: all four binaries answer --version, and ./tools/setup.sh doctor prints driver and app versions together,
  • dmesg | grep -iE 'rs50|g pro|g923' output,
  • cat "$H/wheel_firmware" output (RS50 / G PRO); firmware-dependent behavior (feature index drift, settings quirks) is tracked against it.

The Info / Testing page (where logi-wheel and logi-wheel-gui open) shows the wheel's name, serial and firmware plus the app and driver versions in one copyable place.

Help the project by racing

The fastest way to improve the driver is to race and report:

  • Any sim from the "expected" list in Force Feedback in Games working (or not) moves the compatibility matrix; one sentence and a wheel_firmware output is enough.
  • Real G PRO owners: feel reports on texture routing (wheel_texture_route tf vs kf) and the rev-light control (wheel_rev_level) are the top items the project cannot test itself.
  • G923 PlayStation owners: force feedback and simulated TrueForce are hardware-verified, but feel reports from real races (and any game where something is off) are what tunes them. See G923.
  • G923 Xbox owners: the Xbox edition (c26d/c26e) is implemented but unverified; a single working / not-working report would settle it.

Clone this wiki locally