Thank you!

[Mhytee]

Built a Windows port of your trueforce work as a SimHub plugin and added an effects synthesis engine on top so that users can drive Trueforce via telemetry: https://github.com/Mhytee/Trueforce-For-All. Your work made this possible and I couldn't thank you enough.

[mescon]

Aww, thank you for using it for something fun and constructive to simracing! ;.-)
Be sure to update as I improve the documentation and driver code... I keep finding new quirks and issues, so this driver project is essentially a "rolling release" at this point. I just set SimHub up myself (for use with a Buttkicker), so I'll check out your project when I get the chance!

[Mhytee]

Your work was the foundation to this, genuinely amazing and super solid documentation.

I know your original intent was to get TF working on Linux but it opened the door to enabling it on basically game, albeit on Windows. Trueforce in the original AC or RBR is something I never thought would be possible!

Im not sure if SimHub works on Linux through wine or proton but I would love to someday bring the effect engine back to Linux as well.

If you get a chance to try the plugin I would love to know what you think!

[mescon]

@Mhytee I finally sat down and read Trueforce-For-All properly - the whole Core, the tap, the driver channel, the LED work. This turned into the most productive code-reading session this project has had, and some of it shipped back into the kernel driver the same week. Credit where due, in both directions:

What your findings fixed over here. Your observation that bytes 6-9 ("cur") are the motor torque target while a session is active - with the window additive on top - exposed a real defect in the kernel driver: our texture stream packets were duplicating the newest audio sample into 6-9, so during texture playback the audio amplitude was commanding the motor at 250 Hz interleaved between real force updates. The driver now streams unified packets exactly the way you describe AC EVO doing it (steering force in cur, audio in the window, one packet per tick), and the improvement is measurable on hardware: the same 100 Hz texture effect now moves the steering axis 2.6x less than the old implementation. So consider "cur = torque target, window = additive overlay" independently confirmed by a second implementation on real RS50 hardware - you can strike that one off your unisolated list.

Answers for your other open questions, from our side of the wire:

• Which of bytes 10-11 / cur / zero-window the wheel keys off: our driver has always sent packets with byte 10 = 0 and a pure force value in cur (that's our entire non-TrueForce force path, validated across many games), and the wheel treats those as force-only with no audio playback. With byte 10 = 4 the window plays additively. So byte 10 (the new-sample count) is the audio demultiplexer, and cur is honoured in both shapes - the zero-window and bytes 10-11 don't need to covary.
• Per-wheel identity without waiting for the feature-index resolver: the RS50 in G PRO compatibility mode spoofs the PID (c272) but keeps its own USB product string - "RS50 Base for PlayStation/PC" - while a real G PRO reports "PRO Racing Wheel". Verified live on the RS50 and against a contributor capture from a real G PRO. If WheelDiscovery reads the product string you can pick the right 0x8123 index seed (0x10 vs 0x0e) immediately.
• Your G PRO rev-LED decode (0x807A arm burst + fn2/fn6 level pair) is now implemented in the Linux driver as a wheel_rev_level sysfs attribute, with your ~160 ms pacing lesson baked in - awaiting a G PRO owner to validate. The protocol spec (docs/PROTOCOL_SPECIFICATION.md, v6.6) documents everything above with attribution to your project.

On bringing your effect engine to Linux: it's easier than your roadmap assumes, because the router-driver problem does not exist here. On Linux this kernel driver is the arbiter - it owns the wheel, and a userspace effects engine can open the TrueForce interface via hidraw (our udev rule already grants access) and stream audio packets while the driver's force channel runs alongside. That's not theoretical: it is exactly how Logitech's own SDK DLLs deliver TrueForce under Proton today, coexisting with our force stream. No filter driver, no USB tap, no signing costs. If you ever want to port the effects engine, the transport layer is a solved problem - happy to help with the wheel-side details, and libtrueforce in this repo already implements the session/stream layer in C if you want a reference or a backend.

One more independent data point for your docs: our ACC captures measured 250-500 packets/s where you measured AC EVO at ~1000, so the rate is game-chosen and the wheel accepts the whole band.

[PeposCJ]

Hello @mescon,

I am working on an open-source Windows project called LogiDynamicDash,
intended to display iRacing telemetry on the Dynamic OLED of the
Logitech RS50.

We have performed read-only HID monitoring and controlled USBPcap
captures. Our findings match your documented interface mapping:

• MI_00: joystick input
• MI_01: HID++ configuration and device state
• MI_02: force feedback / TRUEFORCE stream

We also identified and validated several RS50 configuration parameters,
including RPM brightness and mode, dampener, brake pressure, strength,
wheel angle, TF Audio, and FFB filter.

However, we have not found the transport or initialization mechanism for
the Dynamic OLED. The wheel currently falls back to its Test screen
because no known application supplies display data.

During your RS50 and TRUEFORCE research, did you encounter any OLED
transport, undocumented HID++ feature, display initialization sequence,
or Logitech application capable of sending Dynamic OLED data?

We are avoiding unknown writes and can share sanitized USB captures and
our current protocol notes if useful.

Project:
https://github.com/PeposCJ/LogiDynamicDash

Thank you for your work and for any guidance you may be able to provide.

[mescon]

Short answer: no, we never found the OLED transport. But there is a strong lead and some data that should save you time.

The RS50 bridges three sub-devices behind the wheel base, each with its own feature catalog that G Hub enumerates on every init. dev_idx 0x01 is the display / rim module, and it advertises three features:

• 0x8091 (per-key / LED matrix)
• 0x18A2 (unidentified)
• 0x9315 (unidentified)

Those last two are exactly the ones we never decoded, and if the Dynamic OLED has a HID++ transport it is almost certainly one of them. Full sub-device map is in docs/PROTOCOL_SPECIFICATION.md, section 5.3.

Two gotchas that cost a day each if you hit them cold:

1. Sub-device responses come back as report ID 0x11, not 0x12. The wheel base answers with 0x12, the sub-devices do not. Filter on 0x12 and you will conclude dev 0x01 is dead when it is answering fine.
2. Software-ID matters. The pedal MCU (dev 0x02) silently drops every request carrying SW-ID 0x01, no answer, not even a HID++ error. We had to use 0x0a. If dev 0x01 is the same, an unanswered read may just be the wrong SW-ID rather than an unsupported feature.

A useful negative result: across all 62 of our captures, dev 0x01 carried only ~390 packets each way. That is enumeration and config traffic, nothing resembling a framebuffer. So either the display data rides a different transport, or, more likely, none of our captures ever had the dash actually live. A capture of G Hub with iRacing running and the dash showing real telemetry, diffed against an idle session, is the thing that would crack this. None of ours qualify.

One architectural note that I think confirms your premise. We capture-proved the same question for the rev LEDs: games never send LED commands at all, only FFB and TrueForce packets. G Hub reads the game's telemetry and pushes the LED state itself. The OLED falling back to its Test screen looks like exactly the same story, nothing is feeding it, which is the gap LogiDynamicDash is filling.

Yes please on the sanitized captures and protocol notes. And if it is useful I can run a read-only feature enumeration against dev 0x01 on my RS50 here (root feature walk, reads only, no unknown writes) and post the catalog with indices and versions. Say the word.

[PeposCJ]

Hello @mescon,

Thank you — this is extremely helpful and gives us a much clearer direction.

Yes, please run the read-only feature enumeration against dev_idx 0x01 and share the feature IDs, indices, versions, and request/response format. The details about report 0x11 and Software ID 0x0A are especially valuable.

We also contacted Logitech directly, but unfortunately they only referred us to the public SDK resources and did not provide any useful technical information about the Dynamic OLED.

We are excited to collaborate and can share our sanitized USBPcap captures, protocol notes, confirmed parameter mappings, and read-only explorer code.

What would be most useful for us to test next on Windows: reviewing our captures for dev_idx 0x01, reproducing your read-only feature walk, or another controlled test?

Thank you again — this feels like a very strong lead.

[mescon]

Ran the read-only feature enumeration on dev_idx 0x01 (the display/rim module). Transport first: it answers on report ID 0x11, and both SW-ID 0x08 and 0x0a work for it. Requests are the standard 0x10, 0x01, <featIdx>, (fn<<4)|swid, params.

Full catalog (IFeatureSet.getCount = 15; IRoot at index 0):

idx  featID  ver  flags            name (best-effort)
  1  0x0001    2                   IFeatureSet
  2  0x0003    7                   DeviceInformation
  3  0x0005    5                   DeviceTypeAndName
  4  0x0011    0                   (non-public)
  5  0x00C3    1                   (non-public)
  6  0x1602    0                   Password (TDE/manufacturing gate)
  7  0x1807    4  hidden,obsolete  ConfigurableProperties
  8  0x180B    0  hidden,obsolete  ConfigurableDeviceProperties
  9  0x18A2    0                   (undecoded)   <- OLED candidate
 10  0x18B1    0  hidden,obsolete  (undecoded)   <- OLED candidate
 11  0x1E00    0  hidden           EnableHiddenFeatures
 12  0x1E02    0  hidden,obsolete  ManageDeactivatableItems (auth)
 13  0x1EB0    0  hidden,obsolete  TDE access (test)
 14  0x8091    0                   per-key / LED matrix
 15  0x9315    0  hidden,obsolete  (undecoded)   <- OLED candidate

For the OLED, the undecoded candidates on this module are 0x18A2, 0x18B1, and 0x9315 (0x8091 looks like the LED matrix). None is an obvious framebuffer feature by number, which matches what I found before: the display data most likely rides one of these, or a transport that only appears when the dash is actually live. A G Hub + iRacing capture with the dash showing real telemetry, diffed against an idle session, is still the thing that would pin it down.

Happy to run reads against any of these indices if you tell me which. Send your captures and notes whenever.

[mescon]

A concrete capture request, for @PeposCJ or anyone with the RS50 + G Hub + a sim: the one protocol piece still missing for RS50 rev lights on Linux is the live feed. Games never send RPM to the wheel; G Hub reads the game's telemetry and streams the rev state to the 10-LED strip itself. I have the strip's config plane decoded (colors, direction, brightness, slots) but not that live stream, so Linux can configure the strip but not animate it yet.

The ask: two short captures, engine idle vs engine revving (revs sweeping the LED strip), so the live-feed messages diff right out. This is also exactly the idle-vs-live pair that would help corner the Dynamic OLED transport, so one session serves both hunts if your dash is active.

Below is a guided script following the same pattern as the repo's other capture tools (tshark + USBPcap, run as Administrator). Edit the block at the top for your tshark path, and run it once with list to find the wheel's USBPcap interface. It takes the two captures with prompts and timers, then just attach both .pcapng files here and mention which game you used.

windows_rev_feed_capture.bat (save as a .bat file, edit the config block, run as Administrator)

@echo off
setlocal enabledelayedexpansion

:: ============================================================
:: RS50 rev-light LIVE FEED capture (G Hub + a game, revs moving)
:: ============================================================
:: WHY: games never send RPM to the wheel; G Hub reads game telemetry
:: and streams the rev-light state to the RS50's 10-LED strip itself.
:: The Linux driver has the strip's CONFIG protocol decoded (colors,
:: direction, brightness, slots) but not this live feed, so rev lights
:: cannot animate on Linux yet. Two captures - engine idle vs engine
:: revving - let us diff out exactly the messages that carry the live
:: rev state.
::
:: OUTPUT: two .pcapng files next to this script, named
::   YYYY-MM-DD_rev_idle.pcapng  and  YYYY-MM-DD_rev_revving.pcapng
:: ============================================================

:: ================= EDIT THIS BLOCK IF NEEDED =================
:: Path to tshark (comes with Wireshark):
set TSHARK=C:\Program Files\Wireshark\tshark.exe
:: The USBPcap interface the wheel is on. Run this script with the
:: word "list" first to see all interfaces with their numbers:
::     windows_rev_feed_capture.bat list
:: then set the matching one here (USBPcap1, USBPcap2, ...):
set INTERFACE=\\.\USBPcap1
:: Where the .pcapng files land (default: this script's folder):
set CAPTURE_DIR=%~dp0
:: =============================================================

if "%CAPTURE_DIR:~-1%"=="\" set CAPTURE_DIR=%CAPTURE_DIR:~0,-1%

if not exist "%TSHARK%" (
    echo ERROR: tshark not found at: %TSHARK%
    echo Install Wireshark ^(with the USBPcap component^) or edit the
    echo TSHARK line in the EDIT THIS BLOCK section of this script.
    pause
    exit /b 1
)

if /i "%~1"=="list" (
    echo Available capture interfaces:
    echo.
    "%TSHARK%" -D
    echo.
    echo Set the INTERFACE line in this script to the matching
    echo \\.\USBPcapN value, then run again with no argument.
    pause
    exit /b 0
)

for /f %%i in ('powershell -command "Get-Date -Format yyyy-MM-dd"') do set DATE=%%i

cls
echo ==================================================================
echo   RS50 rev-light live feed capture
echo ==================================================================
echo.
echo PREREQUISITES:
echo   - Run from an Administrator CMD prompt
echo   - RS50 attached, G Hub running
echo   - A game with working rev lights on the wheel, in a drivable
echo     state ^(any sim where you can sit in the car and rev^)
echo.
echo TWO captures will be taken:
echo   1. IDLE    ^(~15 s^): sit in the car, engine at idle, do NOT rev
echo   2. REVVING ^(~30 s^): sweep the revs up and down through the
echo      whole range, slowly, 4-5 times
echo.
echo Press ENTER when you are in the car and ready for capture 1...
pause >nul

call :start_capture "rev_idle"
echo.
echo   [RECORDING] IDLE - keep the engine at idle. 15 seconds...
timeout /t 15 /nobreak >nul
call :stop_capture "rev_idle"

echo.
echo Capture 2 is next. Press ENTER, then start sweeping the revs...
pause >nul

call :start_capture "rev_revving"
echo.
echo   [RECORDING] REVVING - sweep the revs now. 30 seconds...
timeout /t 30 /nobreak >nul
call :stop_capture "rev_revving"

echo.
echo DONE. Files:
dir /b "%CAPTURE_DIR%\%DATE%_rev_*.pcapng" 2>nul
echo.
echo Please attach BOTH files to the GitHub issue, and mention which
echo game you used and whether the wheel's rev LEDs were visibly
echo moving during capture 2.
pause
exit /b 0

:start_capture
set OUTPUT_FILE=%CAPTURE_DIR%\%DATE%_%~1.pcapng
echo   Starting capture: %~1
start "" /b "%TSHARK%" -i "%INTERFACE%" -w "%OUTPUT_FILE%" -q
timeout /t 2 /nobreak >nul
tasklist /fi "imagename eq tshark.exe" 2>nul | findstr /i "tshark.exe" >nul
if errorlevel 1 (
    echo   ERROR: tshark failed to start. Run as Administrator and
    echo   check the INTERFACE setting ^(try: this script with "list"^).
    pause
    exit /b 1
)
goto :eof

:stop_capture
taskkill /f /im tshark.exe >nul 2>&1
timeout /t 1 /nobreak >nul
echo   [STOPPED] %DATE%_%~1.pcapng
if exist "%CAPTURE_DIR%\%DATE%_%~1.pcapng" (
    for %%A in ("%CAPTURE_DIR%\%DATE%_%~1.pcapng") do echo   Size: %%~zA bytes
)
goto :eof

[mescon]

Update on the rev-light front, with a discovery that changes what the requested capture is for. Hardware testing found the RS50 accepts the G PRO's level-based rev-light command: writing 0-10 to the driver's wheel_rev_level drives the strip as a live rev display (0 dark, 10 all lit). v0.16.0 ships that wired to game telemetry: the new logi-tf-sim daemon reads UDP telemetry (DiRT Rally 2.0 / classic Codemasters format, AMS2 / PCars2) and feeds RPM to the strip - and synthesizes TrueForce engine haptics for games without native support (the TF4ALL model, on Linux, using your wire-format analysis as the foundation - thank you again).

The same session also decoded a long-standing protocol misunderstanding: the five custom LIGHTSYNC slots ARE effect values 5-9 (0x05 = CUSTOM 1); there is no separate slot activate, and the driver's slot switching never actually rendered before this release.

The idle-vs-revving capture pair above is still very valuable: it would settle how G Hub itself feeds the display (per-LED? level? a redline flash?) and the rev display's exact config source - and the same pair helps corner the Dynamic OLED transport.

Release: https://github.com/mescon/logitech-trueforce-linux-driver/releases/tag/v0.16.0

[PeposCJ]

Hello @mescon,

Sorry for the delay — the weekend got in the way and we have not been able to complete the requested captures yet.

We plan to run the idle and revving tests tomorrow evening and will share both .pcapng files along with the exact test conditions and game used.

Thank you for continuing to share your findings

[PeposCJ]

Hello @mescon,

We completed the requested captures using iRacing WITHOUT G Hub running.
One important detail: the G Hub application was closed during both captures. The RS50 rev-light strip still animated visibly during the revving test.

• 2026-07-22_rev_idle.pcapng: engine held at idle.
• 2026-07-22_rev_revving.pcapng: several full RPM sweeps, with the RS50 rev-light strip visibly animating.

Our initial comparison found a clear live-feed pattern in the revving capture that does not appear during idle:

• G Hub repeatedly sends report 0x10:
  10 FF 0B 2D 00 00 00
• followed by report 0x11:
  11 FF 0B 6D 00 01 00 0A 00 LL ...
• LL changes from 0x00 to 0x0A, matching the visible 0–10 LED level.
• The updates appear to run at approximately 60 Hz while the RPM level is changing.
• The wheel responds with corresponding 0x12 reports.

This appears consistent with the level-based rev-light command you identified, rather than G Hub sending an independent state for each LED.

We have attached both .pcapng files. Please let us know what you find or whether another controlled capture would help.

2026-07-22_rev_capture.zip