AprilNEA / AprilNEA/OpenLogi

[Feature]: Hold MiddleClick while DpiToggle is held (for CAD pan/orbit)

Closed
#1,046 1 comment 4 reactions 0 assignees View on GitHub
needs: triage type: feature
Dominant language
Rust
Stars
21k
Forks
675
Avg merge
2d 5h
Merged PRs (30d)
172

Description

### Pre-flight checklist

- [x] I searched existing issues and the [Roadmap](https://github.com/AprilNEA/OpenLogi#roadmap), and this isn't already tracked.

### Problem / motivation

I use an MX Master with OpenLogi on Windows 11 and I want the DPI button to work as a middle mouse button I can hold down.

I use Autodesk Inventor and Civil 3D. In both of those, pan only works if middle click stays held while I drag. A quick click does nothing useful.

This mapping works in Logi Options+. I hold the DPI button, drag, and the view pans. I let go and it stops.

In OpenLogi it does not. I have:

```toml
DpiToggle = "MiddleClick"
```

It feels like OpenLogi sends one middle click and immediately releases it. I noticed this on v0.7.10 and it is still the same on v0.8.1.

I did read that v0.8.0 added hold support and short vs long press. From the docs that looks like it is for keyboard shortcuts (push-to-talk and similar), not for keeping a mouse button held. I also tried the short/long form with MiddleClick on both sides and that still just clicks.

Setup:

- Wireless Mouse MX Master (`unit:7f3e9855`)
- Windows 11 Version 25H2 (OS Build 26200.9168)
- Software: Autodesk Inventor, Autodesk Civil 3D

### Proposed solution

I would like DpiToggle to be able to hold middle click for as long as I hold the physical button, the same way Options+ does.

Something like:

```toml
DpiToggle = { HoldMouseButton = "Middle" }
```

Or just make `MiddleClick` stay down while the button is held, instead of firing a tap.

What I need in the app:

- Press DPI button -> middle button goes down and stays down
- Drag the mouse -> Inventor / Civil 3D pan as usual
- Release DPI button -> middle button comes up
- If OpenLogi crashes or loses the device mid-hold, please release middle click so it does not get stuck
- Do not wait half a second before it starts. Pan needs to begin as soon as I press

I am not sure if the DPI button currently reports a full press and release to the remapper, or only a pulse. If it is only a pulse, that would also need to change for this to work.

### Alternatives considered

- Leaving `DpiToggle = "MiddleClick"` after updating to v0.8.1. Still just a click.
- `DpiToggle = { short = "MiddleClick", long = "MiddleClick" }`. Still just a click.
- Just using the scroll-wheel click as middle click. That does pan, but then I cannot use the DPI button the way I do in Options+.

Options+ already handles this on this mouse. I am trying to drop Options+ and this is the main thing I am missing.

I saw #399 / #960 for holding a key until you release the button, and #961 for short vs long press. This is basically that idea, but for middle click on the DPI button.

### Related area(s)

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

### Additional context

Relevant part of my config (`schema_version = 6`):

```toml
[devices."unit:7f3e9855".bindings]
MiddleClick = "MiddleClick"
Back = "MouseBack"
Forward = "MouseForward"
DpiToggle = "MiddleClick"
ThumbwheelScrollUp = "HorizontalScrollRight"
ThumbwheelScrollDown = "HorizontalScrollLeft"
GestureButton = "None"
```

Contributor guide

No contributing guide indexed for this repository

Research direction

No source files or tests are named. Start by tracing the DpiToggle/button-action remapping entry point and the existing hold support referenced in #399 and #960, then inspect how MiddleClick press and release events and device-loss cleanup are handled. Done means the provided TOML mapping holds middle click during the physical press, releases it promptly, and does not leave it stuck after a device loss.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
desktop, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.