[Bug]: Linux (Ubuntu 24.04)/X11: OpenLogi virtual mouse ignores GNOME natural scrolling setting

[Luciano-Pinto]

Pre-flight checklist

• I searched existing issues and this is not a duplicate.
• I am on the latest release or a recent master build.
• I quit Logi Options+ before running OpenLogi (the two apps fight over HID++ access and only one can own a receiver at a time).

Which part of OpenLogi?

Both

OpenLogi version

0.8.3

Operating system

Linux

OS version & architecture

Ubuntu (24.04.5 LTS) kernel 6.8.0-90-generic

Device model

MX Ergo S (bluetooth)

How is the device connected?

Bluetooth (direct, no receiver)

Affected area(s)

• Device discovery / detection
• Button remapping
• DPI control
• SmartShift
• Per-application profiles
• Battery status
• Settings / configuration (TOML)
• Auto-update
• Menu bar / tray
• Other

What happened?

Title: Linux/X11: OpenLogi virtual mouse ignores GNOME natural scrolling setting

Environment

Ubuntu, GNOME on X11

Logitech MX Ergo S

OpenLogi

Natural scrolling enabled in GNOME

Problem

After OpenLogi creates its virtual mouse devices, scrolling becomes traditional even though natural scrolling is enabled in GNOME. This could only be fixed by CLI direct intervention, as described below

And a correlated situation is, when configuring the scrolling inversion via CLI, the inversion also applies to the tilting action of the wheel. In other words, when the inversion is active via CLI, the wheel tilting to left makes the content of focused application scroll to the right, and vice-versa. The prefered output would be to isolate the vertical scrolling from horizontal scrolling so that we could configure them separately.

Steps to reproduce

The physical MX Ergo S correctly reports:

libinput Natural Scrolling Enabled: 1

but OpenLogi's virtual mouse devices report:

libinput Natural Scrolling Enabled: 0

Example:

MX Ergo S Mouse id=11
OpenLogi virtual mouse id=14
OpenLogi virtual mouse id=15

Physical device:

$ xinput list-props 11
libinput Natural Scrolling Enabled (...): 1

OpenLogi virtual devices:

$ xinput list-props 14
libinput Natural Scrolling Enabled (...): 0

$ xinput list-props 15
libinput Natural Scrolling Enabled (...): 0

The MX Ergo S does not expose native HID++ scroll inversion support in OpenLogi, so there is no scroll-direction option available in the OpenLogi UI.

Workaround

Setting natural scrolling directly on the OpenLogi virtual devices via CLI fixes the issue immediately:

Bash
$ xinput set-prop 14 "libinput Natural Scrolling Enabled" 1
xinput set-prop 15 "libinput Natural Scrolling Enabled" 1

A persistent X11 workaround is:

$ sudo mkdir -p /etc/X11/xorg.conf.d
sudo nano /etc/X11/xorg.conf.d/90-openlogi-natural-scroll.conf

and in the file insert:

Section "InputClass"
Identifier "OpenLogi natural scrolling"
MatchProduct "OpenLogi virtual mouse"
MatchIsPointer "on"
Driver "libinput"
Option "NaturalScrolling" "true"
EndSection

Expected behavior

OpenLogi virtual mouse devices should inherit or preserve the desktop environment's natural-scrolling setting, or OpenLogi should provide a software scroll-inversion fallback for devices that do not support native HID++ inversion.

Actual behavior

OpenLogi virtual mouse devices start with natural scrolling disabled, overriding the effective behavior of the physical mouse.

Below is a printscreen of the OpenLogi interface showing the impossibility of setting scroll inversion on the GUI.

Diagnostics report

### OpenLogi Diagnostics

**App**
- OpenLogi (GUI): v0.8.3 (release)
- Agent: v0.8.3 (connected)
- IPC protocol: GUI 29 / agent 29
- Inventory: ready
- OS: Linux (x86_64)
- Locale: pt-BR (UI: follow system)
- Accessibility: granted · Input hook: installed
- Launch at login: yes · Menu bar: yes · Update check: on
- Running from: source build (dev)
- Config: schema 7 · 1 configured device(s) · thumbwheel 14

**Assets**
- Source: user cache · Index: loaded (210 models) · User cache: present
- Cache path: ~/.local/share/openlogi/assets · Bundle assets: absent

**Devices (2)**
- MX Ergo S — trackball (codename: MX Ergo S)
  - Connection: Bluetooth (direct) · Online: yes · Battery: 45% (discharging, good)
  - Capabilities: buttons=yes, pointer=yes, lighting=no
  - DPI: 600 dpi (range 100–4000, 79 steps)
  - Model: 0b03e (model-ids: b03e/0000/0000, ext-model: 00)
  - Transports: BTLE
  - Render: mx_ergo_s · direct
- C922 Pro Stream Webcam — camera
  - Connection: unknown · Online: yes · Battery: n/a
  - Capabilities: not probed
  - Model: 085c
  - Render: ⚠️ none (silhouette) · Slot 0

openlogi list output

$ openlogi list                                                                                     ✔  12:19:56 
(inventory read from the running agent)
MX Ergo S (—, vid=046d pid=b03e)
  └─ slot 255 ● MX Ergo S (trackball, wpid=?, battery=45% good (discharging))
          model_ids=[b03e,0000,0000] ext=00 serial=2621ZA621128 unit_id=26e472dc transports=btle

Cameras (1 Logitech UVC)
  └─ ● C922 Pro Stream Webcam (camera, vid=046d pid=085c, up to 2304x1536@60, id=/dev/v4l/by-id/usb-046d_C922_Pro_Stream_Webcam_C8C03CCF-video-index0)

Logs

$ OPENLOGI_LOG=debug openlogi list                                                                  ✔  12:19:59 
2026-09-11T15:20:58.680528Z DEBUG RPC{rpc.deadline=2026-09-11T15:21:08.680484284Z otel.kind="client" otel.name=Agent.protocol_version rpc.trace_id=00}: tarpc::client: SendRequest
2026-09-11T15:20:58.680617Z DEBUG RPC{rpc.deadline=2026-09-11T15:21:08.680484284Z otel.kind="client" otel.name=Agent.protocol_version rpc.trace_id=00}: tarpc::client: ReceiveResponse
2026-09-11T15:20:58.680642Z DEBUG RPC{rpc.deadline=2026-09-11T15:21:08.680636420Z otel.kind="client" otel.name=Agent.declare_client rpc.trace_id=00}: tarpc::client: SendRequest
2026-09-11T15:20:58.680690Z DEBUG RPC{rpc.deadline=2026-09-11T15:21:08.680636420Z otel.kind="client" otel.name=Agent.declare_client rpc.trace_id=00}: tarpc::client: ReceiveResponse
2026-09-11T15:20:58.680704Z DEBUG RPC{rpc.deadline=2026-09-11T15:21:08.680700099Z otel.kind="client" otel.name=Agent.snapshot rpc.trace_id=00}: tarpc::client: SendRequest
2026-09-11T15:20:58.680763Z DEBUG RPC{rpc.deadline=2026-09-11T15:21:08.680700099Z otel.kind="client" otel.name=Agent.snapshot rpc.trace_id=00}: tarpc::client: ReceiveResponse
(inventory read from the running agent)
MX Ergo S (—, vid=046d pid=b03e)
  └─ slot 255 ● MX Ergo S (trackball, wpid=?, battery=45% good (discharging))
          model_ids=[b03e,0000,0000] ext=00 serial=2621ZA621128 unit_id=26e472dc transports=btle

Cameras (1 Logitech UVC)
  └─ ● C922 Pro Stream Webcam (camera, vid=046d pid=085c, up to 2304x1536@60, id=/dev/v4l/by-id/usb-046d_C922_Pro_Stream_Webcam_C8C03CCF-video-index0)

macOS permissions (if applicable)

• OpenLogi has Accessibility permission (needed to remap buttons via the event tap).
• OpenLogi has Input Monitoring permission (needed for Bluetooth-direct devices and capture).

[Luciano-Pinto]

A final comment I forgot to add. This specific behaviour happened after a system update. Before, Gnome's settings were being correctly interpreted.

More accurate wording would be that the update exposed or re-triggered the behavior, because the underlying problem is the virtual device property.

[4ni1ak]

Traced this through `crates/openlogi-hook/src/linux.rs` and `crates/openlogi-agent-core`. Two distinct things are being reported here, and I want to separate them:

1. The virtual device not inheriting GNOME's natural-scroll setting. OpenLogi's Linux hook grabs the physical mouse exclusively and re-emits pass-through events (including `REL_WHEEL`/`REL_HWHEEL`, unmodified) through a synthetic uinput device named `"OpenLogi virtual mouse"` (`VIRTUAL_DEVICE_NAME` in `linux.rs`). OpenLogi doesn't set any libinput/X11 property on that device, natural-scroll included — that's entirely an X11/libinput + GNOME (mutter/`gsd-input`) runtime concern, applied per-device when a pointer is detected. Since your physical MX Ergo S gets it right but the freshly-created synthetic device doesn't, this looks like GNOME's per-device settings application not (re-)triggering correctly for a uinput pointer device that appears mid-session (after the desktop session is already up) rather than something OpenLogi's hook can directly control — I don't see a hook or property OpenLogi could set on its own uinput device that forces libinput's natural-scroll config bit, since that's a runtime `libinput_device_config` call GNOME itself makes. I can't rule this out with more certainty without an actual GNOME/X11 session, which I don't have here.

2. Software scroll-inversion fallback for devices without native HID++ invert, isolated per axis. Confirmed by `git grep`: today `invert_scroll`'s only consumer is `configured_wheel_mode` in `orchestrator.rs`, gated by `capabilities.scroll_inversion` (the firmware-reported invert bit) → `openlogi_hid::set_scroll_inversion_on`, a pure HID++ write. There is no software-side invert anywhere in `openlogi-hook`'s Linux (or other platform) pass-through — a device without the native capability has no way to get inverted scrolling from OpenLogi at all today, and nothing here touches `REL_HWHEEL` independently of `REL_WHEEL`, so I can't explain the "inversion also flips tilt" behavior you saw from the current code as written; that'd need a repro to pin down further.

Building the fallback for (2) properly means: a software invert path in the hook's scroll translation, decoupled per axis (vertical vs. horizontal), gated to devices without the native capability, plus (per this repo's IPC contract) a wire-schema bump since it changes what config the agent acts on. That's more than a drop-in fix I'd want to guess at blind, and (1) may not be an OpenLogi-side bug at all. Flagging both for now rather than opening an unverified PR — happy to pick this up if a maintainer confirms the natural-scroll gap is reproducible against current `master` (not just the version this was filed against) and scopes the invert-fallback feature.

[4ni1ak]

Update to my "(1) can't explain it" comment above: I later found and fixed a real bug in exactly the mechanism I said I couldn't rule out — build_virtual_device() in crates/openlogi-hook/src/linux.rs never set the synthetic "OpenLogi virtual mouse" uinput device's input_id, so it kept evdev's default sample vendor/product ID (0x1234/0x5678) instead of the real physical mouse's. GNOME/libinput key several per-device settings — natural scrolling and pointer-acceleration profile both among them — off the reported vendor/product ID via org.gnome.desktop.peripherals.mouse. With every re-injected Logitech mouse presenting the same generic, unrecognized ID, GNOME had no per-device record to apply any of your settings to, natural-scroll included — matching "before, GNOME's settings were being correctly interpreted" and the fact that it's the virtual device specifically, not the physical MX Ergo S.

That fix is in open PR #1453 (fix(hook): carry the mouse's vendor/product ID onto its uinput mirror), not yet merged. Once it lands, it's worth re-testing natural scrolling here before assuming this needs separate work — if it's still broken after that fix ships, this is a distinct issue after all.