MX Master 3 over Bluetooth not detected on macOS because HID++ interface is not exposed

[bpaiement]

Symptom

MX Master 3 over Bluetooth on macOS 26.5, Apple M4, OpenLogi v0.2.0.

The UI shows "No device connected", and with OPENLOGI_LOG=debug I repeatedly see:

openlogi_hid::inventory: HID++ candidate interfaces count=0

What I found

I think count=0 is expected for this setup. I do not think OpenLogi is missing the mouse; I think macOS is not exposing the HID++ interface that OpenLogi needs.

OpenLogi looks for Logitech HID++ interfaces using the vendor usage page 0xFF00.

On my Mac, ioreg -r -c IOHIDDevice shows the MX Master 3 as 3 HID nodes, but all of them have:

PrimaryUsagePage = 0x01

I do not see any 0xFF00 node for this mouse. Other devices on the same system do expose 0xFF00, so this does not look like a general inspection issue.

That means async-hid / IOHIDManager cannot open a HID++ interface here, because macOS never publishes one for this Bluetooth connection.

This is different from using a Logitech USB receiver, where the 0xFF00 HID++ interface is exposed and can be opened.

I also tried CoreBluetooth. A normal app can connect to the bonded mouse and discover Logitech’s vendor GATT service:

00010000-0000-1000-8000-011F2000046D

with characteristic:

00010001-0000-1000-8000-011F2000046D

But the standard HID-over-GATT service 0x1812 does not appear in service discovery. This seems consistent with macOS reserving the Bluetooth HID service for the system.

I tried writing several HID++-shaped requests to the visible Logitech characteristic. They did not behave like live HID++ commands. Six different commands returned the same reply bytes, except for an echoed leading byte. So this looks more like a static/readout-style characteristic than a real HID++ request/response transport.

What this seems to mean

When connected directly over Bluetooth on macOS:

• OpenLogi cannot find the device because macOS does not expose the needed HID++ HID interface.
• A normal CoreBluetooth app also cannot reach the real HID-over-GATT service.
• A root helper probably would not fix this by itself, because root can only open HID nodes that already exist. It does not make macOS publish the missing 0xFF00 HID node.
• Logi Options+ appears to solve this using a signed DriverKit system extension, shown in macOS as Logi Options+ Driver Installer under Driver Extensions. That is much deeper OS integration than a normal app or helper daemon.

Possible supported paths

As far as I can tell, the realistic macOS options are:

• Use a Logitech USB receiver, such as Unifying or Bolt, where HID++ is exposed as USB HID.
• Add a DriverKit/HID system extension, similar to Logitech’s approach. This would likely require Apple-granted entitlements, notarization, and user approval.

So I do not think this is a simple OpenLogi bug. It looks more like a macOS Bluetooth HID limitation that affects normal third-party apps.

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔}

[linear-code]

OLG-10