Вопрос Kmbox B+ — Не работает чтение состояния кнопок (km.left / km.right)

[hex_cat]

Здарова, местным. Пересел на Kmbox B+ для DMA-сетапа на втором ПК, но столкнулся с классическим затыком при попытке уйти от GetAsyncKeyState. Хочется дергать стейты кликов напрямую через коробку, чтобы логика работала чисто по USB-протоколу со второй машины, но km.left() и km.right() упорно не хотят отдавать адекватный стейт.

Суть проблемы: переписал сурс с mouse_event на km.move, мышь по экрану летает, оффсеты отрабатывают. Но как только пытаюсь реализовать проверку зажатых кнопок через команды в COM-порт, триггеры просто молчат.

Часть кода, которой пытаюсь вычитать состояние:

public:
    __forceinline auto get_left_state() -> int
    {
        char cmd[] = "km.left()\r\n";
        this->send_command(cmd);

        // Читаем ответ из порта
        char response[8];
        DWORD bytes_read;
        ReadFile(connection_t->bpro_handle, response, sizeof(response), &bytes_read, 0);

        return bytes_read > 0 ? (response[0] - '0') : 0;
    }

В основном цикле проверяю стейты 1 и 3 (как того требует логика B-Pro), но условие if (left_pressed && right_pressed) тупо игнорится, хотя по логике всё должно летать. При этом, если возвращаю старый добрый GetAsyncKeyState на второй машине — скрипт оживает.

Где может быть косяк:

1. Тайминги и буфер UART. Возможно, контроллер не успевает обрабатывать запросы при слишком частом опросе в бесконечном цикле без нормального слипа.
2. Особенности прошивки. Слышал, что на некоторых версиях B-Pro стейты отдаются иначе или вообще требуют специфической инициализации.
3. Работа с ReadFile. Возможно, стоит копать в сторону асинхронного чтения, чтобы не ловить фризы на ожидании ответа от коробки.

Кто плотно сидит на Kmbox B-Pro и C++, как вы фиксили чтение кнопок? Есть подозрение, что нужно либо очищать буфер перед каждым запросом, либо переходить на более низкоуровневую работу с сокетами/портами.

Интересно глянуть, как у вас реализован опрос, чтобы не плодить лишний инпут-лаг.