[Bug]: Cannot Middle-Click and Drag When Another Key Is Bound to the Middle Mouse Button.
- Dominant language
- Rust
- Stars
- 21k
- Forks
- 675
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 172
Description
### Pre-flight checklist
- [x] I searched [existing issues](https://github.com/AprilNEA/OpenLogi/issues?q=is%3Aissue) and this is not a duplicate.
- [x] I am on the [latest release](https://github.com/AprilNEA/OpenLogi/releases/latest) or a recent `master` build.
- [x] 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?
GUI (desktop app)
### OpenLogi version
0.6.19
### Operating system
macOS
### OS version & architecture
macOS 26.5
### Device model
MX Anywhere 3S
### How is the device connected?
Bluetooth (direct, no receiver)
### Affected area(s)
- [ ] Device discovery / detection
- [x] Button remapping
- [ ] DPI control
- [ ] SmartShift
- [ ] Per-application profiles
- [ ] Battery status
- [ ] Settings / configuration (TOML)
- [ ] Auto-update
- [ ] Menu bar / tray
- [ ] Other
### What happened?
When other keys are bound to the middle mouse button click, it is impossible to click and drag with the middle mouse button. Because the electromagnetic scroll wheel’s middle button is too stiff, I need to remap another button to the middle mouse button while retaining middle-click-and-drag functionality. This is essential in apps such as Figma and Blender.
### Steps to reproduce
1. Bind the sensitivity-switch button to middle-click.
2. Middle-click-and-drag does not work in applications such as Blender.
3. When the physical middle mouse button is set to middle-click, middle-click-and-drag works normally.
### Diagnostics report
```markdown
### OpenLogi Diagnostics
**App**
- OpenLogi (GUI): v0.6.19 (release)
- Agent: v0.6.19 (connected)
- IPC protocol: GUI 8 / agent 8
- Inventory: ready
- OS: macOS 26.5 (arm64)
- Locale: zh-Hans-CN (UI: follow system)
- Accessibility: granted · Input hook: installed
- Launch at login: no · Menu bar: yes · Update check: on
- Running from: source build (dev)
- Config: schema 3 · 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 (1)**
- MX Anywhere 3S — mouse (codename: MX Anywhere 3S)
- Connection: Bluetooth (direct) · Online: yes · Battery: 80% (discharging, full)
- Capabilities: buttons=yes, pointer=yes, lighting=no
- DPI: 1450 dpi (range 200–8000, 157 steps)
- Model: direct:046d:b037:serial:2615zatcyjy8 (model-ids: b037/0000/0000, ext-model: 00)
- Transports: BTLE
- Render: mx_anywhere_3s · direct
```
### `openlogi list` output
```text
```
### Logs
```shell
```
### macOS permissions (if applicable)
- [x] OpenLogi has **Accessibility** permission (needed to remap buttons via the event tap).
- [x] OpenLogi has **Input Monitoring** permission (needed for Bluetooth-direct devices and capture).
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in the GUI button-remapping and macOS input-hook paths, reproducing the reported binding with an MX Anywhere 3S and checking how middle-button press, hold, and drag events are handled. Done means a button remapped to middle-click supports middle-click-and-drag in apps such as Blender and Figma, while the existing physical middle-button behavior remains working.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- macos, rust
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100