K:04 (Qube): ввод замирает на ~1.3 с, зажатая клавиша уходит в автоповтор

[AlexBSoD]

Кратко

На K:04 с донглом Qube ввод периодически замирает целиком примерно на 1.3 секунды. Клавиша, которая была нажата в момент замирания, остаётся зажатой в HID-репорте, и хост уводит её в автоповтор — снаружи это выглядит как «залипла клавиша». Через ~1.3 с приходит release, и всё продолжается как ни в чём не бывало.

Проверено на стоковой прошивке 0.1.7 (тег v0.1.7), на чистом хосте, без стороннего софта.

Окружение

• K:04 + донгл Qube, беспроводной режим, две половины
• Прошивка 0.1.7 (стоковая, с сайта), vendor_id = 0xE126, product_id = 0x0071
• Хост: Linux, ядро 7.1.8, донгл воткнут напрямую в порт материнской платы

Симптом

Мерил чтением /dev/input/event* напрямую — сырые evdev-события, минуя раскладку, IME и любые прослойки.

Эпизод целиком:

14:30:24.346   код 36 (J)  нажатие
14:30:24.602   код 36      автоповтор ядра
14:30:24.636   код 36      автоповтор
   ...                     всего 32 повтора, ровно по 34 мс
14:30:25.660   код 36      автоповтор
14:30:25.682   код 36      отпускание   ← через 1336 мс после нажатия

Ключевой момент: между нажатием и отпусканием прошло 1336 мс, и за всё это время с клавиатуры не пришло ни одного другого события. Я печатаю с интервалом 90–130 мс между клавишами, то есть за 1.3 с должно было прилететь около десяти событий. Их нет. Замирает не одна клавиша, а весь поток целиком.

Второй эпизод из того же лога, три минуты спустя:

14:33:24.225   код 22      нажатие     Δ113 мс
14:33:24.330   код 22      отпускание  Δ105 мс
14:33:24.435   код 38 (L)  нажатие     Δ105 мс   ← ритм печати
14:33:24.690   код 38      автоповтор ×33, по 34 мс
14:33:25.5..   код 38      отпускание — 1.09 с

Клавиша ушла в автоповтор посреди слова, в темпе 105 мс между предыдущими нажатиями. Букву «l» на секунду никто не зажимает специально.

Для сравнения — нормальный участок того же лога:

14:30:23.303   код 57  нажатие     Δ 83 мс
14:30:23.305   код 33  нажатие     Δ  2 мс
14:30:23.363   код 33  отпускание  Δ 58 мс
14:30:23.468   код 57  отпускание  Δ105 мс
14:30:23.670   код 14  нажатие     Δ202 мс
14:30:23.745   код 14  отпускание  Δ 75 мс

Статистика

На стоковой 0.1.7: окно 19.9 минуты активной печати, 1654 события, два таких эпизода — 1.06 с и 1.09 с.

Оговорка про метод: так фиксируются только те замирания, при которых в момент заморозки была зажата клавиша, дающая автоповтор. Замирания в паузе между нажатиями этим способом не видны вообще, так что два эпизода за 20 минут — нижняя граница, а не оценка частоты.

По более ранним замерам другим методом (по паузе с последующим залпом накопленных событий, 58+ эпизодов за несколько часов печати): длительность 0.7–4.3 с, медиана около 1350 мс, частота порядка 70–100 эпизодов за час активной печати.

Ещё наблюдение: замирания бывают одновременными для обеих половин. Из 28 эпизодов в 12 после разморозки события приходили сразу с обеих половин одним залпом. То есть замирает что-то общее, а не связь с одной конкретной половиной.

Что исключено измерением

Всё перечисленное проверено на практике, а не рассуждением.

• Версия прошивки. Проверены четыре разные сборки плюс стоковая 0.1.7. Медиана замирания во всех 1336–1378 мс, различия в частоте в пределах статистического шума.
• Стороннее ПО на хосте. Демон, который слал донглу raw-HID пакеты (часы, раскладка), был полностью остановлен на всё время замера. Разницы нет.
• Соседняя 2.4 ГГц периферия. Приёмник Logitech Unifying физически вынимался из порта. Замирания остались.
• USB-хаб и питание по USB. Донгл переехал из хаба напрямую в порт материнской платы. Замирания остались, оба эпизода выше сняты уже на прямом порту.
• Хост. Отдельный детектор дрейфа планировщика замерял отклонение 10-миллисекундного сна каждую минуту: worst = 0 ms в каждой минуте, включая ту, в которой было замирание ввода на 3.5 с.
• USB-уровень. В момент замирания в dmesg пусто: ни ошибок xhci, ни таймаутов, ни -71/-110, ни реконнектов. С точки зрения хоста устройство просто молчит, а потом снова начинает говорить.

Подозрения

Дальше — уже гипотезы, а не измерения. Проверить их у меня пока не получилось, поэтому выкладываю как есть.

1. Приоритеты прерываний в макро-пути.

rmk-macro/src/codegen/chip/bind_interrupt.rs:243-246 отдаёт MPSL её штатные прерывания:

EGU0_SWI0 => ::nrf_sdc::mpsl::LowPrioInterruptHandler;
RADIO     => ::nrf_sdc::mpsl::HighPrioInterruptHandler;
TIMER0    => ::nrf_sdc::mpsl::HighPrioInterruptHandler;
RTC0      => ::nrf_sdc::mpsl::HighPrioInterruptHandler;

При этом rmk-macro/src/codegen/chip/chip_init.rs:146-152 для nRF52 генерирует конфиг, в котором приоритеты не выставляются вообще:

let mut config = ::embassy_nrf::config::Config::default();
#dcdc_config
let p = ::embassy_nrf::init(config);

То есть gpiote_interrupt_priority и time_interrupt_priority остаются на значении по умолчанию — P0, на том же уровне, который MPSL держит за своими RADIO/TIMER0/RTC0.

Показательно, что в самом репозитории требование известно: examples/use_rust/nrf52840/src/main.rs:41-43 явно выставляет

config.gpiote_interrupt_priority = ::embassy_nrf::interrupt::Priority::P3;
config.time_interrupt_priority = ::embassy_nrf::interrupt::Priority::P3;
::embassy_nrf::interrupt::USBD.set_priority(::embassy_nrf::interrupt::Priority::P2);

Но для всего, что собирается через #[rmk_central] / #[rmk_peripheral], эта настройка теряется.

Задержанные радио-прерывания объяснили бы наблюдаемое: и замирание всего потока сразу, и то, что обе половины замирают синхронно, и то, что длительность стабильно держится около 1.3 с независимо от версии прошивки.

2. Дисплей на Qube. На донгле SPIM3 регистрируется через add_interrupt! в keyboards/k04/src/qube.rs:20-22 и по той же причине оказывается на P0. Это единственная периферия на донгле, которая активно шевелит SPI на 8 МГц во время печати. Собрал себе безэкранный вариант донгла, чтобы это проверить, — как будут результаты, отпишусь здесь же.

3. Источник тактирования MPSL. Если MPSL работает от RC-осциллятора (±500 ppm), а не от кварца 32.768 кГц, окна радио плавают сильнее, чем могли бы. Не проверял, есть ли на платах кварц.

[AlexBSoD]

Апдейт по замерам, важный: замирание воспроизводится вообще без донгла.

Отключил донгл совсем и подключил клавиатуру напрямую по Bluetooth к хосту. За 63.8 минуты, 5212 событий — эпизод такой же природы:

15:58:15.029   код 22      нажатие     Δ  7 мс
15:58:15.044   код 22      отпускание  Δ 15 мс
15:58:15.052   код 20 (T)  нажатие     Δ  8 мс   ← темп аккордов
15:58:15.307   код 20      автоповтор ×61
   ...                     2.06 с
15:58:17.384   код 20      отпускание  ← через 2332 мс после нажатия

Всё как раньше: за 2.33 секунды ни одного другого события, при том что вокруг интервалы 7–15 мс. Рядом ещё два коротких — код 30 держался 279 мс и 428 мс, оба успели уйти в автоповтор (ядро включает его через ~250 мс), что при таком темпе печати тоже аномалия.

Отсюда следствия по моим подозрениям из issue:

Подозрение №2 (дисплей на Qube) отпадает. На половинках экрана нет, донгла в этой конфигурации нет вообще, а замирание есть. SPIM3 тут ни при чём.

Подозрение №1 (приоритеты прерываний) остаётся единственным живым. Оно как раз объясняет обе конфигурации: chip_init.rs генерирует один и тот же Config::default() и для #[rmk_central], и для #[rmk_peripheral] — я проверил, codegen/orchestrator.rs и codegen/split/peripheral.rs зовут один и тот же expand_n. То есть P0 стоит одинаково на всех устройствах: и на донгле, и на обеих половинках. Что бы ни было центральным устройством — донгл или левая половина — конфликт приоритетов с MPSL присутствует.

Подозрение №3 (тактирование MPSL) перестало быть подозрением — это видно в коде. rmk-macro/src/codegen/chip/chip_init.rs:111-117:

let lfclk_cfg = ::nrf_sdc::mpsl::raw::mpsl_clock_lfclk_cfg_t {
    source: ::nrf_sdc::mpsl::raw::MPSL_CLOCK_LF_SRC_RC as u8,
    ...
};

MPSL действительно работает от RC-осциллятора, а не от внешнего кварца 32.768 кГц. Есть ли кварц физически на платах K:04 — не знаю, но если есть, то MPSL_CLOCK_LF_SRC_XTAL дал бы заметно более стабильные радио-окна.

Собрал себе сборку, где gpiote_interrupt_priority и time_interrupt_priority выставлены в Priority::P3 (плюс SPIM3 на донгле тоже уведён с P0), гоняю. Отпишусь с результатом.

[AlexBSoD]

Проверил подозрение №1 на практике: приоритеты прерываний проблему не устраняют.

Собрал прошивку (донгл + обе половины) поверх 0.1.7, где в chip_init.rs для nRF52 выставлено

config.gpiote_interrupt_priority = ::embassy_nrf::interrupt::Priority::P3;
config.time_interrupt_priority = ::embassy_nrf::interrupt::Priority::P3;

плюс на донгле SPIM3 уведён с P0 на P3 при инициализации дисплея. Правка попадает во все три образа: codegen/orchestrator.rs и codegen/split/peripheral.rs зовут один и тот же expand_n, а K:04 конфиг чипа не переопределяет. Косвенно это видно и по размеру: образы половин изменились (675840 против 676352 байт), хотя обычно они байт-идентичны между сборками, раз собираются без Vial.

Замирание всё равно случилось:

17:43:36.101   код 39      нажатие     Δ 52 мс
17:43:36.236   код 39      отпускание  Δ135 мс
17:43:36.304   код 20 (T)  нажатие     Δ 68 мс   ← ритм печати
17:43:36.554   код 20      автоповтор ×31
   ...                     1.02 с
17:43:37.595   код 20      отпускание  ← через 1291 мс

1291 мс — ровно та же характерная длительность, что и на стоке (1336 мс, медиана прошлых замеров 1350–1378 мс). Сигнатура не изменилась: за время заморозки не приходит ни одного события, при темпе печати 52–135 мс вокруг.

Про частоту — осторожно. За окно с P3 набралось 2685 событий и один эпизод, против 2 эпизодов на 1654 события у стока с донглом. Формально это втрое реже в пересчёте на события, и субъективно замирания стали попадаться заметно реже. Но это одна точка против одной, окна по часу, а обнаруживаются только те заморозки, при которых что-то было зажато. Так что как «стало лучше» я бы это защищать не стал — нужны часы плотной печати на каждую конфигурацию, чтобы разница перестала быть шумом. Твёрдо можно сказать одно: полностью проблему это не снимает.

Итого по всем моим подозрениям из issue: №2 (дисплей) отпал, №1 (приоритеты) проверен и не подтвердился, №3 (RC вместо кварца) остаётся непроверенным. Всё остальное — версия прошивки, стороннее ПО на хосте, USB-хаб и питание, соседняя 2.4 ГГц периферия, сам хост, наличие донгла как такового — было исключено измерением раньше.

Снаружи, по evdev-событиям, дальше не разглядеть: случаи «исполнение на центральном устройстве встало» и «данные от половины не пришли вовремя» дают на хосте абсолютно одинаковую картину. Разделить их может только диагностика изнутри прошивки — например, тик-задача, которая жалуется на просроченный тик, плюс счётчики принятых пакетов и реконнектов split-линка. Если подскажете, что вам полезнее видеть, соберу и погоняю.

[AlexBSoD]

Причина найдена: замирания вызывает собственная BLE-реклама переподключения.

Оказалось, что диагностика изнутри прошивки не требует никакой пересборки — фича usb_log в сборке донгла уже включена, а фильтр стоит на Debug (rmk/src/usb/mod.rs), так что всё нужное сыпется в /dev/ttyACM0. Читал так:

sudo sh -c 'stty -F /dev/ttyACM0 raw; cat /dev/ttyACM0' | ts '%H:%M:%.S'

ts из moreutils ставит хостовые метки времени — без них лог прошивки не сопоставить с evdev.

Механизм

rmk/src/ble/mod.rs:48:

const DIRECTED_RECONNECT_WINDOW_MS: u64 = 1_300;

rmk/src/ble/mod.rs:618-675: каждый цикл длиной ble_reconnect_timeout_seconds (в keyboard_qube.toml = 60) центральное устройство сначала 1.3 с зовёт забонженный хост через Advertisement::ConnectableNonscannableDirectedHighDuty — это самый агрессивный режим рекламы в BLE, интервал 3.75 мс и потолок 1.28 с по спецификации. Затем остаток минуты идёт щадящий directed-режим, ловится bonded host reconnect timeout, и всё повторяется.

Причём при активном USB это не прекращается никогда — rmk/src/ble/mod.rs:238-250:

if crate::state::active_transport().is_some() {
    warn!("Advertising timeout while another transport is active, staying awake");
    continue;
}

Комментарий рядом с этим кодом упоминает, что BLE-стек нужен ещё и для split-линков, а Qube уже подключён к ПК по USB. Но вывод сделан только про сон: клавиатура не засыпает — и уходит на новый круг рекламы. Про то, что high-duty реклама на 1.3 с оставляет split-линк без эфира, речи нет.

Доказательство

Два независимых лога с хостовыми метками времени: evdev (/dev/input/event*) и USB-лог прошивки.

Пауза ввода (evdev)	Длительность	Окно рекламы (прошивка)
19:43:24.122 → 19:43:25.532	1410 мс	19:43:24.248 → 19:43:25.527
19:46:24.219 → 19:46:25.622	1403 мс	19:46:24.332 → 19:46:25.609
19:47:23.327 → 19:47:26.454	3127 мс	19:47:24.369 → 19:47:25.647
19:48:24.319 → 19:48:25.690	1371 мс	19:48:24.403 → 19:48:25.684

Ввод замирает за десятые доли секунды до строки [adv] directed high duty reconnect и оживает через несколько миллисекунд после [adv] directed reconnect timed out. В минутах 19:44 и 19:45 совпадений нет ровно потому, что в это время я не печатал.

Измеренные окна рекламы: 1277 / 1278 / 1280 / 1286 мс. Измеренные замирания за неделю: 1291 / 1336 / 1350–1378 / 1371 / 1403 / 1410 мс.

Проверка от обратного

Стёр бонд, чтобы донглу некого стало звать. После этого directed high duty reconnect пропал из лога полностью, и замирания исчезли:

Конфигурация	Событий	Эпизодов	Частота
Донгл, сток 0.1.7	1654	2	1 на 827
Донгл, приоритеты P3	2685	1	1 на 2685
Прямой BLE, без донгла	6082	1	1 на 6082
Донгл, бонд стёрт	2633	0	—

За контрольное окно (12.8 минуты плотной печати): ноль окон high-duty рекламы, ноль разрывов split-линка, ноль замираний. Осталась только щадящая fast/slow undirected реклама раз в 30 с, которая ни на что не влияет.

Что это объясняет из наблюдавшегося ранее

• длительность замираний около 1.3 с — это буквально DIRECTED_RECONNECT_WINDOW_MS;
• независимость от версии прошивки — код одинаков во всех сборках, включая сток;
• синхронное замирание обеих половин — общий радио-ресурс центрального устройства;
• воспроизведение вообще без донгла — половина в роли central рекламируется точно так же;
• чистый хост по всем метрикам — проблема целиком внутри устройства;
• бесполезность правки приоритетов NVIC;
• частота порядка 60 эпизодов в час активной печати — период цикла ровно 60 с.

Предложение

Не запускать reconnect-рекламу, пока активен другой транспорт. В той самой ветке rmk/src/ble/mod.rs:238-250, где сейчас стоит continue, логично не крутить цикл заново, а дождаться исчезновения активного транспорта — либо, если реклама всё же нужна, не использовать для неё high-duty режим при живом split-линке. Как минимум стоит сделать DIRECTED_RECONNECT_WINDOW_MS и повтор цикла настраиваемыми через [rmk], чтобы это можно было отключить из keyboard.toml.

Обходной путь для пользователей — стереть бонд, но осторожно: стирать надо с обеих сторон. Если стереть только на клавиатуре, хост (и любой ранее спаренный телефон) продолжит автоподключаться к теперь открытому окну пейринга, и получится цикл fast undirected advertising → connection established → no long term key каждые 600 мс, то есть радио занято постоянно вместо 1.3 с в минуту. Стало заметно хуже, пока я не убрал устройство и на хосте, и на телефоне.