[Feature]: Software scroll inversion for RatchetWheel (0x2130) devices

[LRRun]

Pre-flight checklist

• I searched existing issues and the Roadmap, and this isn't already tracked.

Problem / motivation

OpenLogi disables per-device scroll inversion unless a device exposes HID++ 0x2121 HiResWheel with the native inversion capability. A Logitech Signature Plus M750 L connected through a Logi Bolt receiver instead exposes 0x2130 RatchetWheel and does not expose 0x2121, so the GUI reports that native HID++ scroll inversion is unavailable.

The same mouse and connection support reversed scrolling in Logi Options+, which indicates that a software/host-side implementation is possible. OpenLogi 0.7.1 on macOS 26.6.2 reproduces the problem.

No existing M750 scroll-inversion or 0x2130 fallback issue was found.

Proposed solution

Add a per-device software scroll-inversion path for 0x2130 RatchetWheel devices.

Suggested behavior:

• Continue to prefer native 0x2121 inversion when the device advertises has_invert.
• Implement the 0x2130 get/set wheel-mode calls and wheel-movement notification decoding.
• When inversion is enabled on an 0x2130 device, divert wheel reports to HID++, invert the vertical delta, and inject the resulting OS scroll event through OpenLogi's existing input-injection layer.
• Restore ordinary HID reporting when the software inversion setting is disabled or OpenLogi exits.
• Keep the setting scoped to the physical mouse so the macOS trackpad direction is unchanged.
• Clearly label the GUI mode as a software fallback rather than native HID++ inversion.

If divert-and-inject is not reliable on every platform, an OS-hook transformation for the selected physical device could be used as the fallback instead.

Alternatives considered

• macOS “Natural scrolling”: changes system-level behavior and does not provide OpenLogi's per-device separation.
• Manually setting invert_scroll = true: the agent intentionally gates the write on the live scroll_inversion capability.
• Forcing the persisted capability flags: cannot add 0x2121 firmware support and would make OpenLogi attempt an unsupported write.
• Treating 0x2130 as native inversion support: the RatchetWheel protocol only exposes HID/HID++ report diversion, not an inversion bit.

Related area(s)

• GUI
• CLI
• Button actions / remapping
• DPI
• SmartShift
• Per-application profiles
• Configuration (TOML)
• Auto-update
• Other

Additional context

Hardware and software

• Device: Logitech Signature Plus M750 L / Logi M750
• Connection: Logi Bolt receiver, VID 046d, PID c548
• OpenLogi: 0.7.1
• OS: macOS 26.6.2, Apple Silicon
• Logi Options+: reversed scrolling works with the same device

Redacted openlogi list output

Logi Bolt Receiver (<redacted>, vid=046d pid=c548)
  └─ slot 2 ● Logi M750 (mouse, wpid=?, battery=85% full (discharging))
          model_ids=[b02c,0000,0000] ext=03 serial=<redacted> unit_id=<redacted> transports=btle

openlogi diag features result

The device reports 32 features. Relevant entries:

13  0x2130  v0
14  0x2201  v2

There is no 0x2121 entry.

openlogi diag wheel output

device: Logi M750 (slot 2 on receiver <redacted>)
Error: read HiResWheel mode

Caused by:
    device does not expose HID++ feature 0x2121

OpenLogi already names 0x2130 as RatchetWheel in the feature registry, but it has no implementation registered: https://github.com/AprilNEA/OpenLogi/blob/master/crates/openlogi-hidpp/src/feature/registry.rs

The available 0x2130 protocol description exposes report diversion and wheel-movement events, but no native inversion flag: https://lekensteyn.nl/files/logitech/x2130_ratchetwheel.html

[linear-code]

OLG-247

[tata-meow]

Same issue here — Signature M650 connected through Bolt, macOS. The GUI reports native HID++ scroll inversion as unavailable, and openlogi diag features confirms the device exposes 0x2130 (RatchetWheel) but not 0x2121 (HiResWheel). Logi Options+ reverses the wheel fine on the same hardware.

I've reviewed #847 which takes the software-inversion approach on the capture layer (negating the native event fields in place). The design looks right — I have a macOS + M650 setup and can help verify the macOS path if it gets rebased.