Troubleshooting

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
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"	Add yourself to the input group: sudo usermod -aG input "$USER", then log out and back in
Force feedback pulls the wrong way	A native game and a Wine/Proton game can want opposite signs: toggle Invert constant force in logi-dd (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-dd)
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
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

($H above is the wheel's sysfs directory: H=$(ls -d /sys/class/hidraw/*/device/wheel_range | head -1 | xargs dirname).)

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' output,
• cat "$H/wheel_firmware" output; firmware-dependent behavior (feature index drift, settings quirks) is tracked against it.

The Info / Testing page in logi-dd shows serial, firmware, 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 owners: whether TrueForce works under Proton on your wheel is an open question only you can answer (the G923 shares the TrueForce protocol).