f73fe2d295
The 0x50 variant requires a device-specific address byte at frame[1] on every TX frame. Until now we left state.device_addr=None and sent 0x00 as a placeholder, relying on the device to either be permissive enough to respond, or to send an unsolicited frame early enough for _unwrap_centurion_frame to learn the address passively. Strict firmware silently drops device_addr=0x00 requests, which breaks dongle feature discovery before it can start: _discover_dongle_features times out, has_bridge is False, create_centurion_receiver falls through to create_device, Device.__init__ leaves _protocol=None, and a later read_battery() dispatches HID++ 1.0 read_register(BATTERY_CHARGE) that the dongle rejects with INVALID_SUB_ID_COMMAND. Port strain08's fix from LGSTrayEx (commits 1439b27a + c6d21972): right after registering a 0x50 handle, write a 64-byte all-zero frame with just the report ID set. That elicits an error/unsolicited response whose byte[1] is the real device address. Read up to 3 x 500ms until a matching frame arrives, then store the address on the handle state so subsequent TX frames carry it correctly. On timeout the probe logs a warning and leaves device_addr=None, so behavior falls back to the current 0x00-placeholder path (no regression for devices where the probe isn't needed). The passive learn-on-first-RX in _unwrap_centurion_frame is preserved as a second line of defense. |
||
|---|---|---|
| .github | ||
| bin | ||
| docs | ||
| lib | ||
| po | ||
| rules.d | ||
| rules.d-uinput | ||
| share | ||
| tests | ||
| tools | ||
| .coveragerc | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .pre-commit-config.yaml | ||
| .python-version | ||
| CHANGELOG.md | ||
| COPYRIGHT | ||
| LICENSE.txt | ||
| MANIFEST.in | ||
| Makefile | ||
| README.md | ||
| RELEASE.md | ||
| RHEL.md | ||
| Release_Notes.md | ||
| mkdocs.yml | ||
| pyproject.toml | ||
| release.sh | ||
| setup.py | ||
README.md
Solaar
Solaar is a Linux manager for many Logitech keyboards, mice, and other devices that connect wirelessly to a Unifying, Bolt, Lightspeed or Nano receiver as well as many Logitech devices that connect via a USB cable or Bluetooth. Solaar is not a device driver and responds only to special messages from devices that are otherwise ignored by the Linux input system.
More Information - Usage - Capabilities - Rules - Manual Installation - Known Issues
Solaar supports:
- pairing/unpairing of devices with receivers
- configuring device settings
- custom button configuration
- running rules in response to special messages from devices
For more information see the main Solaar documentation page. -
Installation Packages
Up-to-date prebuilt packages are available for some Linux distros (e.g., Fedora) in their standard repositories. If a recent version of Solaar is not available from the standard repositories for your distribution, you can try one of these packages:
- Arch solaar package in the extra repository
- Ubuntu/Kubuntu package in Solaar stable ppa
- NixOS Flake package in Svenum/Solaar-Flake
Solaar is available from some other repositories but may be several versions behind the current version:
- a Debian package, courtesy of Stephen Kitt
- a Ubuntu package is available from universe repository
- a Gentoo package, courtesy of Carlos Silva and Tim Harder
- a Mageia package, courtesy of David Geiger