Корректно проверять и отображать таймаут Layer LED

[suregoodru]

Воспроизведение

Проверено на Ergohaven M4CR0Pad v3 по USB.

На firmware 4.0.5:

1. Открыть настройки Layer LED.
2. Установить таймаут в 0 или другое значение.
3. Entropy показывал успешное сохранение после ответа на SET, хотя повторный GET возвращал прежнее значение.
4. После перезапуска приложения UI снова показывал старое значение.

После обновления Entropy до 0.3.4 UI мог показывать 128m: firmware M4CR0Pad v3 не включала описание LED timeout в Vial schema, а legacy fallback отображал QSID 317 как произвольное байтовое значение.

Первопричина

Проблема состояла из двух частей:

• Entropy использовал для Layer LED режим SetOnly, поэтому успешный ответ на команду не подтверждал, что устройство фактически применило значение.
• Entropy не учитывал variants поля с type: select при вычислении диапазона и отображении значения Layer LED.

Отдельная причина отсутствия сохранения находилась в firmware M4CR0Pad v3: QSID 317 был зарегистрирован, но из-за конфигурации RGB_MATRIX использовал weak setter без записи. Исправление firmware: ergohaven/vial-qmk#39

Что исправляет этот PR

• После записи Layer LED по USB Entropy выполняет отложенный readback через существующий механизм проверки.
• Статус сохранения устанавливается только при совпадении прочитанного и запрошенного значений; при отказе устройства UI возвращается к фактическому значению и показывает ошибку.
• Для Bluetooth сохраняется SetOnly, потому что немедленный GET может конфликтовать с асинхронным сохранением RMK во flash.
• Для Layer LED select диапазон вычисляется по числу variants, а UI показывает label выбранного варианта вместо сырого индекса.
• Legacy numeric schema остаётся совместимой с прежним поведением.

С firmware из связанного PR M4CR0Pad v3 предлагает варианты Never, 1 min, 2 min, 5 min, 10 min, 15 min, 30 min, 60 min; Never кодируется индексом 0.

Автоматическая проверка

• Новый parser test подтверждает диапазон 0..7 и labels select-схемы.
• Fake-HID regression test подтверждает, что USB-запись с успешным SET, но несовпадающим GET, не получает ложный статус сохранения.
• cargo +1.92.0 test layer_led — 5 тестов прошли.
• Изолированные timing-sensitive тесты очередей — 8 тестов прошли.
• Полный последовательный suite: 502/505; три существующих timing-sensitive теста очередей падают только в полном прогоне и проходят изолированно.
• cargo +1.92.0 clippy --all-targets — код возврата 0, с существующими предупреждениями репозитория.
• rustfmt +1.92.0 --check --edition 2021 для пяти изменённых файлов — успешно.
• cargo +1.92.0 build --release — успешно.

Проверка на реальном устройстве

С firmware из ergohaven/vial-qmk#39:

• Entropy вместо 128m показывает label фактического варианта.
• Установка Never обычным drag в UI даёт readback QSID 317=0; после полного USB-переподключения и нового запуска UI снова показывает Never.
• Установка 10 min даёт readback QSID 317=4; после полного USB-переподключения Entropy снова показывает 10 min.
• При установленном 1 min RGB-подсветка клавиш физически выключается через минуту бездействия и включается после нажатия клавиши.
• После проверки пользовательское значение возвращено в Never и подтверждено readback 0.
• MacropadDisplay был приостановлен на время изолированной проверки; актуальный код codex-macropad обращается только к Vial RGB effect/speed/hue/saturation/brightness и не использует QSID 317.

Refs #146

[kissetfall]

Проверил PR на синтетическом слиянии с текущим main: конфликтов нет, 565/565 тестов прошли, Clippy и release-сборка прошли. Блокирующих ошибок в Entropy-коде не нашёл; USB readback и отображение select-вариантов реализованы корректно. Сохранение SetOnly для Bluetooth выглядит намеренным и безопасным для асинхронной записи RMK.

Перед слиянием нужно:

• обновить ветку от текущего main (сейчас она отстаёт на 18 коммитов), чтобы получить актуальный CI;
• согласовать выпуск со связанным firmware PR Исправить сохранение таймаута RGB на M4CR0Pad v3 vial-qmk#39: без него старый M4CR0Pad v3 продолжит игнорировать запись таймаута, хотя Entropy теперь корректно обнаружит несовпадение;
• после зелёного CI выполнить финальную проверку USB на Never и одном ненулевом значении с переподключением устройства.

Версию и общий changelog можно оформить в общем release-коммите Entropy. После rebase и зелёного CI PR готов к approval.

[suregoodru]

Обновил ветку на актуальный main.

Связку Entropy с firmware PR ergohaven/vial-qmk#39 проверили по USB на реальном M4CR0Pad v3:

• Never (0) сохраняется после переподключения устройства;
• ненулевое значение (1 min) также сохраняется после переподключения;
• при значении 1 min подсветка действительно выключается через минуту бездействия;
• Entropy выполняет readback и не показывает успешное сохранение, если прошивка проигнорировала значение.

Профильные тесты очереди записи и readback прошли: 23/23. Release-сборка также прошла. Со стороны связки Entropy и прошивки сценарий проверен полностью.

[kissetfall]

Проверил актуальный head e9abdb61c9003e019aab3514a6c462ce704f3351 после rebase.

• локально прошли 565/565 тестов, Clippy и проверка i18n;
• GitHub Actions зелёный на Linux, Windows, macOS Apple Silicon и Intel;
• автор подтвердил USB readback и работу таймаута на M4CR0Pad v3;
• связанное firmware-изменение ergohaven/vial-qmk#39 уже слито в ветку ergohaven (cb48b91787fc47767d2fda263286873d3e438ea5).

Блокеров не осталось.