AprilNEA / AprilNEA/OpenLogi

[Device]: Add Logitech MX Keys support

Open
#521 19 comments 12 reactions 0 assignees View on GitHub
area: hidpp needs: triage
Dominant language
Rust
Stars
21k
Forks
675
Avg merge
2d 5h
Merged PRs (30d)
172

Description

### Pre-flight checklist

- [x] I quit **Logi Options+** before testing.
- [x] I searched existing issues for my device.

### Device model

Logitech MX Keys

### Connection

Bluetooth (direct, no receiver)

### What's the problem?

Device is detected but a feature doesn't work

### `openlogi list` output

```text
MX Keys (direct 046d:b35b)
slot: 255 (direct device index 0xff)
transports: equad + btle
model IDs: b35b, 408a, 0000
```

### `openlogi diag features` output

```text
idx id ver name
0 0x0000 v1 Root
1 0x0001 v1 FeatureSet
2 0x0003 v2 DeviceInformation
3 0x0005 v0 DeviceTypeAndName
4 0x1d4b v0 WirelessDeviceStatus
5 0x0020 v0 ConfigChange
6 0x0007 v0 DeviceFriendlyName
7 0x1000 v1 BatteryStatus
8 0x1b04 v4 ReprogControls5
9 0x1814 v1 ChangeHost
10 0x1815 v1 HostsInfo
11 0x1982 v1 Backlight2
12 0x40a3 v0 FnInversionMultiHost
13 0x4100 v0 Encryption
14 0x4220 v0 LockKeyState
15 0x4521 v0 DisableKeys
16 0x4531 v1 MultiPlatform
17 0x00c2 v0 DfuControlUnsigned
```

### Details

The keyboard is detected over Bluetooth-direct, but several advertised HID++
features are not currently available through the full OpenLogi stack.

Test environment:

- macOS 26.6, Apple Silicon (`arm64`)
- OpenLogi development build based on 0.6.23
- Logi Options+ removed / not running
- Input Monitoring granted to the OpenLogi Agent

Current findings:

- Discovery and the device card work.
- The keyboard exposes legacy BatteryStatus `0x1000` v1, not UnifiedBattery
`0x1004`, so the existing battery path needs a typed fallback.
- It exposes Backlight2 `0x1982` v1. Live read and the physical on/off toggle
have been verified on the keyboard.
- It exposes FnInversionMultiHost `0x40a3` and DisableKeys `0x4521`; both need
capability-aware live read/write/confirmation paths.
- Persistent Agent inventory already owns the working Bluetooth HID++ channel.
Capture and route-addressed operations must reuse that channel instead of
opening competing handles.

Proposed atomic PR series:

- [x] Reuse inventory-owned channels for input capture. (#522)
- [ ] Route existing Agent hardware operations through inventory-owned channels. (#532)
- [ ] Add the legacy `0x1000` BatteryStatus fallback.
- [ ] Add safe Backlight2 v1 controls with live state and confirmed writes.
- [ ] Add resilient multi-/single-host Fn-lock controls.
- [ ] Add guarded Disable Keys controls based on the firmware support mask.

Acceptance criteria:

- [ ] MX Keys remains visible and usable in the GUI over Bluetooth-direct.
- [ ] Agent inventory, capture, IPC, and background operations do not compete
by opening separate handles for the same HID node.
- [ ] Battery status is populated through `0x1000` when `0x1004` is absent.
- [ ] Backlight on/off reads, writes, confirms, and restores correctly.
- [ ] Fn-lock reads the concrete current host, writes, confirms, and restores.
- [ ] Disable Keys renders only firmware-supported keys and confirms writes.
- [ ] Every merged PR passes the full workspace format, Clippy, and test gate.

Device-side key remapping is intentionally not an acceptance criterion for
this device issue. The MX Keys control table observed here marks its controls
as divertable, not `REPROGRAMMABLE`; OpenLogi should not expose the managed
device-remap panel on this keyboard without a separate safe design.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the `openlogi list` and `openlogi diag features` entry points, then trace Agent inventory, capture, IPC, and background hardware operations. Review PRs #522 and #532 before working on one atomic feature area. Done means the relevant MX Keys capability works over Bluetooth-direct, avoids competing HID channels, and passes the full workspace format, Clippy, and test gate.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
desktop-dev, embedded-iot
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.