PerKeyLighting.write was force-claiming SW control via rgb_control.write(True) through _ensure_sw_control whenever a saved per-key map was applied. On startup with rgb_control persisted as False, the apply path would re-enable LED Control and overwrite the persister with True — making "off" impossible to keep across restarts. The fix treats rgb_control as the single gate for LED activity: when it's off, Solaar performs no SW claim, no per-key/zone wire writes, no SW release on apply (we never claimed), no profile-management restoration, and no shutdown-animation trigger on exit. This lets another tool (OpenRGB etc.) drive the LEDs without Solaar fighting it. Settings that don't actively change current lighting are still allowed: NV-config writes for startup/shutdown animations, brightness control (its own feature, no color push), and persister updates for per-key/zone state so colors survive an off→on toggle. UI: _apply_rgb_gates already greys per-key/zone/idle/sleep rows when rgb_control is off. Fix a race where the async-read completion callback in _update_setting_item would re-set sensitivity from the user lock-icon flag alone and undo the grey-out if rgb_control's read happened to complete first. Extract _gate_blocks as the single source of truth and AND-combine it into _update_setting_item's set_sensitive call. |
||
|---|---|---|
| .. | ||
| cli | ||
| ui | ||
| __init__.py | ||
| configuration.py | ||
| custom_logger.py | ||
| dbus.py | ||
| gtk.py | ||
| i18n.py | ||
| listener.py | ||
| tasks.py | ||
| version | ||