The gear-driven G923 gets its own feature set from this driver, separate from the direct-drive RS50 / G PRO path: it speaks a different classic protocol, so its force feedback, settings and game setup all differ. This page collects everything G923-specific.

The one rule to remember: PROTON_ENABLE_HIDRAW=1 is for the direct-drive wheels only. On a G923 it kills force feedback and enables nothing. Never copy it from someone else's post.

Use logi-launch %command% and the question does not arise: it resolves the recipe from the wheel you have plugged in, and on a G923 it never sets that variable.

Two editions, with different USB IDs and support levels:

The G920 and G29 are not covered by this project; they keep working with the in-tree kernel drivers, unchanged.

• Full classic force feedback: constant, spring, damper, friction, inertia, periodic and ramp effects plus autocenter, driven by a classic force-feedback engine ported from berarma's new-lg4ff. The wheel boots as c267 and the driver switches it to PC mode (c266) automatically.

• Settings under the classic sysfs names (Oversteer-compatible, not the wheel_* names the direct-drive wheels use): range (40-900 degrees), gain, autocenter, combine_pedals, plus a read-only ffb_output showing the live force. Details in the Sysfs API Reference.

• Pedals the right way round. This wheel sends all three pedals inverted, 255 with the pedal released and 0 with it flat to the floor, and nothing in HID marks an axis as inverted, so every layer passes that on unchanged. Left alone, a game reads every pedal as fully applied at rest. The driver turns them the right way up, so a released pedal reads 0 like every other Linux input device. Raw HID is left exactly as the wheel sent it, because a Wine or Proton game reading the wheel that way expects the Windows convention. If you have already inverted these axes inside your games, clear that setting or set the g923_pedal_invert module parameter to N.

• Rev LEDs as standard Linux LEDs: five /sys/class/leds entries (::RPM1 to ::RPM5), one per mirrored pair of the 10-LED strip, usable by any LED-aware tool. logi-tf-sim drives them from a game's live telemetry, the same RPM display the direct-drive wheels get. They fill outside in, ::RPM1 first.

  Their brightness files are covered by the packaged udev rule, so a normal user can drive them. If the strip stays dark after an upgrade, reload the udev rules (sudo ./tools/setup.sh does it).

• Simulated TrueForce through logi-tf-sim (next section).

• logi-wheel and logi-wheel-gui recognise the wheel and expose its four settings, with its own wheel image on the Info / Testing page and its own button labels (the 18 real buttons of a PlayStation G923, captured from the hardware; the RS50 callout diagram is not shown for this wheel).

Hardware-verified on a real c266: constant force and autocenter feel correct in Assetto Corsa Competizione, and the LED sweep.

Simulated TrueForce is verified end to end on the same wheel: Assetto Corsa Competizione and EVO, with the car stationary in the pit box and the engine revving (force feedback cannot produce anything there, so what you feel came from telemetry), and the rev strip filling 0 to 5 and draining back, read from the brightness files rather than judged by eye.

The apps show a G923 only what it has, so LIGHTSYNC, the response-curve editors, the onboard profile slots and the desktop / onboard mode toggle are absent rather than greyed out. Desktop profiles (computer-side presets you save and apply) do work here, despite the wheel having no onboard slots. Gain and autocenter appear as percentages in the app while the sysfs files keep their raw 0-65535 scale, so Oversteer and scripts are unaffected.

The force-feedback self-test on Info / Testing runs the full sequence and marks friction skipped: the classic engine advertises every effect except FF_FRICTION. See Configuring the Wheel.

(The app is logi-wheel, with logi-dd kept as a symlink. This wheel is why it is not called that any more: see Installation.)

Force feedback works out of the box in native and Proton games; the wheel is a standard Linux force-feedback wheel. Per game:

1. Launch Options: logi-launch %command%.
2. Properties, Controller: set Disable Steam Input for the game.

That is the whole setup, and it is the same line as on every other wheel. What it does behind that line is not the same, which is the point of using it: on a G923 it never sets PROTON_ENABLE_HIDRAW, and it starts the simulated TrueForce daemon, which a direct-drive wheel does not want because it has the game's own.

By hand instead: leave Launch Options empty for most sims, since plain force feedback needs nothing there. The exception is DirectInput sims (Le Mans Ultimate, rFactor 2, iRacing, RaceRoom), and even there the one line is logi-launch %command%, on a G923 just as on a direct-drive wheel: the launcher runs the logi-ffb proxy for you. Whether a game needs that proxy is about how it asks for force feedback, not about which wheel is plugged in.

Logitech's own SDK TrueForce path does not work for the PlayStation G923 on Linux: the SDK DLL delegates the actual haptics to G HUB, which Proton does not provide. Skip the TrueForce file install for this wheel; it buys nothing.

Instead, the G923 speaks the same TrueForce stream protocol as the RS50 and G PRO on its third USB interface, which the driver exposes for userspace. logi-tf-sim streams the same telemetry-driven engine haptics to it, while mirroring the wheel's live force-feedback output (ffb_output) into the stream so force feedback and TrueForce agree instead of fighting. Hardware-confirmed as vibration; feel reports under real game telemetry are welcome. Setup is the same as for the other wheels: Simulated TrueForce.

The Xbox G923 (046d:c26e in PC mode) routes force feedback through the same HID++ path as the G920. It boots into a console-only mode (046d:c26d) with no input node at all; installing usb_modeswitch (a recommended, not required, package) lets a udev rule switch it into PC mode automatically on plug-in. If it never switches, the out-of-tree xone driver may have claimed the device first.

Force feedback and TrueForce are both confirmed on a real unit by an owner over the course of issue #27. Neither existed for this wheel on Linux before.

Two separate problems kept this strip dark, and both are now fixed.

The display starts switched off. 0x807A fn2 reports which effect the strip is showing, and this wheel answers 0 for "nothing". In that state it refuses every level with an internal error, so a completely correct command looked ignored. Sending fn3 with effect 2 starts the display, after which the same level is accepted. The driver reads the state at probe and sends that call only for a wheel reporting 0, never for one already showing something.

Nothing registered any LED device for it. This edition reaches neither the direct-drive path (which exposes wheel_rev_level) nor the classic path (which registers the LED classdevs, and whose device table lists c266 and c267 but not c26e). So even with the protocol right there was nothing for a telemetry feeder to write to. It now exposes the same five ::RPM1..RPM5 entries the PlayStation edition does, so logi-tf-sim, Oversteer and any LED-aware tool work with no change.

The strip follows RPM in a game: confirmed by an owner in Assetto Corsa EVO on the force engine route below (issue #72, 2026-09-07). It needs a telemetry feed like any rev strip, so it lights only in games logi-tf-sim can read. The driver logs what it found at probe:

logitech-dd 0003:046D:C26E.0007: G923 (Xbox): rev strip: 0x807A at index 0x12, 5 LEDs, display off (will be switched on)

If your rev lights do not follow RPM, that line (or its absence) in dmesg is the first thing to report.

Two owners independently found the same setup in September 2026 (issues #72 and #84): the driver's own force engine, g923_xbox_dd_engine=1, with raw HID left off (PROTON_ENABLE_HIDRAW unset). On the stock HID++ 0x8123 path force feedback and TrueForce are mutually exclusive on this wheel, because the firmware sums the effects where the driver cannot see them; on the engine they arrive together. Measured on a real unit: all four condition effects (spring, damper, friction, inertia) alive, and the rev strip following revs when fed.

echo 'options hid-logitech-dd g923_xbox_dd_engine=1' | sudo tee /etc/modprobe.d/logitech-trueforce.conf
sudo modprobe -r hid-logitech-dd && sudo modprobe hid-logitech-dd

Set the rotation range in the app; a game may show 1080 through Logitech's SDK, which is its guess and changes nothing. 0.40.1 made the engine read and set the real range and strength through the wheel's classic feature, scale its force by the strength slider, switch the wheel's own centring spring off at load, and stop the motor whine from the wheel's 2 ms position reports. Still opt-in and marked experimental: a faint residue of that whine is being worked on in issue #85, and findings for this route are collected in issue #87.

With Logitech's own SDK library in the game's prefix, the launcher takes this wheel down the same route as a direct-drive wheel (since the release from 0.41.0): raw HID scoped to it, a dinput8 proxy that answers the SDK's rotation question, and the simulated daemon for the rev lights and screen only. The game's own force and TrueForce, engine note included, reach the wheel. The range set in the app moves it; Assetto Corsa EVO's own steering-lock setting sends nothing on this route, so it stays inert here (on Windows it goes through G HUB). Proven with the SDK files from a G HUB install (issue #91); whether the copies the app's Setup page installs stream on this edition is still to be confirmed by an owner.

A PID-scoped udev rule (installed by the packages and by setup.sh) reclaims c266/c267/c26e from a competing driver that wins the initial bind race; every other Logitech device stays on its usual driver. The one exception is berarma's new-lg4ff (hid-logitech-new), blacklisted outright since it otherwise races this driver for c266/c267; a wheel you ran on it (G29, G27, DFGT, ...) falls back to the in-tree hid-logitech instead.