Splitting this out of a related aside in #1392 so it doesn't get lost.
What happened
@natagomes01 reported (macOS 26.6.2, OpenLogi 0.8.3, MX Vertical over Bluetooth-direct, no receiver):
Separately, on this same machine the agent diverted the MX Vertical's wheel over Bluetooth (HiResWheel) while probing the device, never surfaced it in the inventory (Bluetooth direct, cf. #115 / #707), and scrolling died until a power-cycle of the mouse.
So: during device probing, the agent appears to divert the wheel (HiResWheel 0x2121?) into a mode HID++ event-based capture expects, but because the device never surfaces properly in inventory over Bluetooth-direct (the same symptom as #115 and #707), nothing re-asserts the wheel back to normal reporting — leaving the physical scroll wheel producing no OS scroll events until the mouse is power-cycled.
Why filing without full repro steps
I don't have this hardware and I'm working from the one-line summary above, not a firsthand repro. @natagomes01 said they could provide the exact steps — could you add them here (OpenLogi version/build, exact sequence that triggers the probe-time divert, and whether this reproduces on a clean device add vs. only after some other action)? That'll make this actionable instead of just a pointer to #1392.
Possibly related
Splitting this out of a related aside in #1392 so it doesn't get lost.
What happened
@natagomes01 reported (macOS 26.6.2, OpenLogi 0.8.3, MX Vertical over Bluetooth-direct, no receiver):
So: during device probing, the agent appears to divert the wheel (HiResWheel
0x2121?) into a mode HID++ event-based capture expects, but because the device never surfaces properly in inventory over Bluetooth-direct (the same symptom as #115 and #707), nothing re-asserts the wheel back to normal reporting — leaving the physical scroll wheel producing no OS scroll events until the mouse is power-cycled.Why filing without full repro steps
I don't have this hardware and I'm working from the one-line summary above, not a firsthand repro. @natagomes01 said they could provide the exact steps — could you add them here (OpenLogi version/build, exact sequence that triggers the probe-time divert, and whether this reproduces on a clean device add vs. only after some other action)? That'll make this actionable instead of just a pointer to #1392.
Possibly related