[Bug]: Lift (B031) gesture button (HID++ CID 0x00d7) is never captured — GESTURE_BUTTON_CID hardcoded to 0x00c3

[Triangle-GitHub]

[Bug]: Lift (B031) gesture button (HID++ CID 0x00d7) is never captured — GESTURE_BUTTON_CID hardcoded to 0x00c3

• Component: Both (GUI + agent)
• OpenLogi version: 0.8.3 (openlogi --version → openlogi 0.8.3)
• Operating system: Windows
• OS version & architecture: Windows 11, build 26200 (x64)
• Device model: Logitech Lift Vertical Ergonomic Mouse (model-b031/mx_vertical_mini)
• How is the device connected? Logi Bolt receiver (also reproduced over Bluetooth-direct and wired USB)

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).

Affected area(s)

• Button remapping
• Settings / configuration (TOML)
• Other — HID++ gesture-source capture (gesture_sources always 0)

What happened?

Configuring the Lift's GestureButton in gesture mode (5-direction map, e.g. Up = "MissionControl", Click = "AppExpose") never produces any gesture input. The agent's capture session reports gesture_sources=0 gesture_buttons=0 for every connection type (Bluetooth-direct, Bolt receiver, wired USB) and even after a fully clean agent restart. The dedicated round gesture button on the Lift is therefore dead: no HID++ raw-XY capture starts for it, and no bound action ever fires from it.

The root cause is visible in the 0.8.3 source:

• crates/openlogi-device/src/reprog_controls.rs:43 hardcodes the dedicated gesture-button control id: pub const GESTURE_BUTTON_CID: u16 = 0x00c3; (the MX-line gesture button).
• crates/openlogi-device/src/session/gesture.rs:193 defines GESTURE_SOURCE_BUTTONS = [(GESTURE_BUTTON_CID, GestureButton), (HAPTIC_PANEL_CID, HapticPanel)], so the capture plan asks the device to divert 0x00c3 for a GestureButton in gesture mode.
• The Lift (B031) exposes its gesture source as 0x00d7 instead. From openlogi diag controls:

device: LIFT VERTICAL ERGONOMIC MOUSE (direct 046d:b031)
     cid    task   flags  capabilities
  0x0050  0x0038  0x0401  analytics-events
  0x0051  0x0039  0x0401  analytics-events
  0x0052  0x003a  0x0531  divertable, raw-xy, analytics-events
  0x0053  0x003c  0x0d31  divertable, raw-xy, analytics-events, raw-wheel
  0x0056  0x003e  0x0d31  divertable, raw-xy, analytics-events, raw-wheel
  0x00fd  0x00d2  0x0531  divertable, raw-xy, analytics-events
  0x00d7  0x00b4  0x03a0  divertable, raw-xy, force-raw-xy    <-- dedicated gesture source (not 0x00c3)

• In crates/openlogi-device/src/session/gesture.rs, the arm loop only diverts CIDs the device actually exposes with supports_raw_xy(): for &cid in &spec.divert_gesture_sources { if controls.iter().any(|c| c.cid == cid && c.supports_raw_xy()) { ... } }. Since the Lift's control table contains no 0x00c3, nothing gets armed → gesture_sources=0.
• Control-table lookup itself is healthy on this device: the Lift's DPI/ModeShift control 0x00fd is in DPI_MODE_SHIFT_CIDS = [0x00c4, 0x00ed, 0x00fd], and the session reliably captures it (dpi_buttons=1). The gap is specific to the gesture-source CID table.

This is platform-independent logic — it should equally affect macOS/Linux users of the Lift, not just Windows.

Steps to reproduce

1. Run OpenLogi 0.8.3 on Windows; quit Logi Options+.
2. In the GUI, set the Lift's GestureButton to gesture mode with any directions (e.g. Up = MissionControl, Click = AppExpose).
3. Press the round gesture button below the wheel and swipe in a direction.
4. Observe: nothing fires, and the agent log shows the capture session never arms a gesture source:

INFO openlogi_device::session::gesture: control capture active index=1 gesture_sources=0 gesture_buttons=0 dpi_buttons=0 buttons=0 thumbwheel=false ...

Expected behavior

The Lift's dedicated gesture source (0x00d7) should be diverted with raw-XY reporting when GestureButton is in gesture mode, gesture_sources should be ≥ 1, and hold-and-swipe should fire the bound directional actions — matching MX-line devices.

Suggested fix direction

• The GESTURE_SOURCE_BUTTONS table needs a Lift-family entry mapping the 0x00d7 control (the only control with force-raw-xy here) to ButtonId::GestureButton — either as an additional known CID or as a per-model lookup.

Diagnostics report

### OpenLogi Diagnostics
**App**
- OpenLogi (GUI): v0.8.3 (release)
- Agent: v0.8.3 (connected)
- OS: Windows (x86_64)
- Locale: en-US (UI: follow system)
- Accessibility: granted · Input hook: installed
- Launch at login: yes · Menu bar: yes · Update check: on

**Devices (2)**
- LIFT VERTICAL ERGONOMIC MOUSE — mouse
  - Connection: Logi Bolt receiver (slot 2) · Online: yes · Battery: ~70%
  - Capabilities: buttons=yes, pointer=yes, lighting=no, hires_wheel=no, thumbwheel=no
  - Model: b031 (model-ids: b031/0000/0000, ext-model: 02)
  - Transports: BTLE
  - Render: mx_vertical_mini
- G304 Lightspeed Wireless Gaming Mouse — mouse (unaffected by this report)

**Receivers (1)**
- Logi Bolt Receiver (VID 046d / PID c548)

openlogi list output

(inventory read from the running agent)
Logi Bolt Receiver (vid=046d pid=c548, receiver-uid=<redacted>)
  └─ slot 2 ● LIFT (mouse, wpid=b031, battery=70% full (discharging))
          model_ids=[b031,0000,0000] ext=02 serial=<redacted> unit_id=<redacted> transports=btle

Config (bindings excerpt)

[devices."serial:<redacted>".bindings.GestureButton]
Up    = "MissionControl"
Down  = "ShowDesktop"
Left  = "NextDesktop"
Right = "NextTab"
Click = "AppExpose"

Logs

INFO openlogi_device::session::gesture: control capture active index=255 gesture_sources=0 gesture_buttons=0 dpi_buttons=1 buttons=0 thumbwheel=false wake_rearm=true   # BTLE-direct
INFO openlogi_device::session::gesture: control capture active index=1  gesture_sources=0 gesture_buttons=0 dpi_buttons=0 buttons=0 thumbwheel=false wake_rearm=true   # Bolt receiver
INFO openlogi_device::session::gesture: control capture active index=1  gesture_sources=0 gesture_buttons=0 dpi_buttons=0 buttons=0 thumbwheel=false wake_rearm=true   # fresh agent restart (15:07)
INFO openlogi_agent_core::runtime::hook: gesture click → executing bound action button=Back action=Screenshot       # only clicks ever fire
(no "gesture swipe → executing bound action" line has ever appeared on this machine)

Related observations

• OS-hook gesture buttons (Back/Forward in gesture mode via WH_MOUSE_LL) also never commit a swipe on this machine — click arm works, no gesture swipe log line ever. A separate probe installing a WH_MOUSE_LL hook confirmed the OS delivers un-injected WM_MOUSEMOVE deltas here, so this is probably a second, distinct issue (see also fix(hook,hid): revive gesture mode on Middle/Back/Forward #918, [Bug]: Gesture mode fails to capture input on all buttons — HID++ path drops swipe events, OS-hook path drops everything including the Click action #946, Gesture swipes never commit on Windows #471).
• The OS hook receives standard button-4/5 events from this device (dispatched as Back/Forward), so single-action bindings on those buttons work fine (verified in the log above). Whether they physically map to dedicated side buttons or to the round gesture control is not part of this report.

[aislandener]

Same bug on a third device and a third CID — M720 Triathlon (046d:b015), Bluetooth-direct, on Linux. Its gesture source is 0x00d0 (task 0x00ad, MultiPlatform Gesture Button), so it misses the hardcoded GESTURE_BUTTON_CID = 0x00c3 exactly like the Lift's 0x00d7.

openlogi diag controls sees it fine:

device: M720 Triathlon Multi-Device Mouse (direct 046d:b015)
     cid    task   flags   capabilities
  0x0052  0x003a  0x0171  divertable, raw-xy
  0x0053  0x003c  0x0171  divertable, raw-xy     <- Back
  0x00d0  0x00ad  0x0171  divertable, raw-xy     <- MultiPlatform Gesture Button
  0x00d7  0x00b4  0x03a0  divertable, raw-xy, force-raw-xy

The bundled asset metadata is correct too — m720_triathlon/metadata.json maps m720-triathlon-6b015_c208 → SLOT_NAME_GESTURE_BUTTON (208 = 0xD0) — so only the runtime constant is wrong. And as expected, every capture line reports:

control capture active index=255 gesture_sources=0 gesture_buttons=0 dpi_buttons=0 buttons=0

One extra data point: fixing the divert alone is not enough

This may be worth knowing before the fix lands. I diverted 0x00d0 externally, out of band:

$ solaar config "M720 Triathlon" divert-keys 208 Diverted
$ solaar show "M720 Triathlon"   # confirms it stuck
    7: MultiPlatform Gesture Button, default: Multi Platform Gesture Button
        reporting: ['diverted']

With the divert already applied by someone else, I pressed the button three times with a live tail -f on ~/.local/state/openlogi/agent.*.log. Zero log lines — the agent never reacted. It stayed diverted the whole time (the agent did not revert it either).

So the notification path filters on the same CID set, not just the divert-plan path. A fix that only widens the set of CIDs the agent requests to divert would still drop these events unless the inbound 0x1b04 handler is widened too.

For reference, while 0x00d0 is left at default the button just emits its factory persistent mapping (0x1C00 → Alt+Ctrl+TAB), which is what reaches the desktop instead of any binding. Read straight off the evdev node:

10:49:45.144  KEY_LEFTCTRL  DOWN
10:49:45.144  KEY_LEFTALT   DOWN
10:49:45.154  KEY_TAB       DOWN
10:49:45.161  KEY_TAB       UP

Nothing in the agent log at that timestamp.

Given three devices now (0x00c3 MX line, 0x00d7 Lift, 0x00d0 M720), a per-device control table — or simply treating any control whose task id marks it a gesture button as a gesture source — would probably age better than a constant.

Environment

• OpenLogi 0.8.3 (AUR openlogi-bin)
• Logitech M720 Triathlon 046d:b015, HID++ 4.5, fw MPM 04.10.B0013, Bluetooth-direct (no Unifying receiver)
• Arch Linux, kernel 7.1.9, Hyprland 0.56.2 (Wayland)
• Logi Options+ not installed; Solaar not running (used only as a read-only probe, and for the one-off divert above)

[4ni1ak]

Fixed in #1473 — added 0x00d7 alongside the MX-line CID as a recognized gesture-button source. Confirmed the same flag signature independently on a second device (Logi POP Mouse, #859), which gave enough confidence to add it as a general alternate CID rather than gating it per-model.