Plasma 6.6: геймпад как «активность» — почему это важно и как с этим работать

Plasma 6.6 учитывает ввод с игровых контроллеров как активность пользователя, что предотвращает самопроизвольный уход системы в сон во время игры. Это небольшое, но важное изменение имеет широкие последствия: от удобства геймеров до политики энергосбережения в корпоративных средах. В статье объясняется, как это работает с точки зрения стеков ввода (libinput, BlueZ, evdev), как Wayland меняет логику обработчика активности, какие риски и сценарии использования стоит предусмотреть, а также даются практические советы по диагностике и настройке. Отдельно разбираются связанные улучшения — доступность, индикаторы уведомлений и багфиксы панели — и влияние на тестирование и устойчивость десктопа. Также кратко упоминается дистрибутив НАЙС.ОС как одна из сборок Linux для специализированных сценариев.

Один фикс — тысяча пересадок: почему признание геймпада как активности важно

Проблема знакома: в разгар матча включается авто‑блокировка экрана или система уходит в спящий режим, потому что контроллер не «считается» за активность. В Plasma 6.6 это исправили — ввод с геймпада теперь считается за активность и предотвращает автоматический сон/блокировку. На первый взгляд — мелочь, но это решение резюмирует несколько больших трендов: интеграция десктопа с игровыми сценариями, переход на Wayland, и более внимательное отношение к доступности.

Техническая анатомия проблемы

Почему геймпад раньше часто не мешал сну системы? Всё из‑за того, что в Linux ввод проходит через несколько слоёв:

физические устройства (USB HID, Bluetooth/BlueZ),
ядро — evdev/hidraw,
слой ввода — libinput, XInput в X11 или Wayland протоколы,
композитор/DE (KWin в случае KDE), который решает, считать ли события «пользовательской активностью».

Раньше многие DE ориентировались в первую очередь на мышь/клавиатуру. События от HID‑контроллеров могли классифицироваться иначе или игнорироваться при расчёте idle‑таймера. Плюс Wayland изменил модель безопасности и доставки событий — приложение не получает глобальный доступ к устройствам так, как это было в X11. Поэтому придётся явно учесть контроллеры в логике «активности» на уровне композитора или ScreenSaver сервиса.

Куда смотрит Plasma (и что поменялось в 6.6)

В Plasma 6.6 разработчики явно добавили обработку событий от игровых контроллеров в механизм определения активности. Это включает не только кнопки и стики, но и события от джойстика, D‑pad и триггеров — другие события вводятся в логику, как и любые движения курсора или нажатия клавиш.

Побочные улучшения вокруг этой темы — поддержка новых настроек уведомлений, «Slow Keys» для доступности в Wayland и режимы масштабирования указателя — говорят о том, что проект смотрит шире, чем «просто фиксы багов».

Почему это влияет на Wayland

Wayland усиливает изоляцию ввода: приложения не могут просто слушать все события устройств. Отсюда следуют два эффекта:

Композитор ответственен за интерпретацию ввода и должен сам решать, какая активность засчитывается.
Реализация должна корректно обрабатывать устройства, подключённые через Bluetooth, чтобы не было пропаданий событий при переключении профилей или при соединении с адаптерами.

В 6.6 видно, что KWin и компоненты, ответственные за энергопотребление, скоординировали решение — и это ключевой момент для стабильной работы на Wayland‑сессиях.

Практические сценарии и последствия

Решение выгодно выглядят в нескольких реальных сценариях:

Игры без клавиатуры: couch gaming, локальные сессии Steam Big Picture, эмуляторы — теперь не придётся выключать sleep или использовать костыли.
Steam Deck и портированные среды: устройства с Linux, где управление часто идёт с контроллера, станут удобнее для типичного пользователя.
Доступность: пользователи, которые используют контроллеры как альтернативный способ взаимодействия, получают корректное поведение блокировки и сна.

Но есть и побочные эффекты, которые требуют внимания.

Риски и как с ними обращаться

Потребление батареи: если джойстик постоянно генерирует мелкие события (например, плохой калибровкой стиков), система может не переходить в энергосберегающий режим. Решение — добавить порог для «считающейся» активности или фильтровать только значимые события.
Безопасность и приватность: в публичных терминалах или киосках нежелательно, чтобы подключённый контроллер предотвращал автоматическую блокировку. Для таких сценариев нужна политика, которая отключает распознавание контроллера как активности (kiosk‑mode, systemd/loginctl inhibitors, udev rules).
Ошибочные устройства: некоторые USB‑адаптеры/эмуляторы ввода могут посылать шум, приводя к постоянной активности. Рекомендация — мониторить /dev/input и использовать evtest или libinput debug-events при отладке.

Конфигурация и диагностика: что полезно знать

Несколько полезных инструментов и команд для диагностики и управления:

systemd: loginctl lock-session / loginctl unlock-session — для управления сессиями. systemd-inhibit покажет активные ингибиторы сна.
libinput: libinput debug-events — отслеживает события устройств, удобно для проверки, какие события уходят с геймпада.
evtest: проверка сырого ввода с /dev/input/eventX.

Если контроллер мешает сну, но играет роль в интерфейсе киоска — лучше централизованно управлять политиками через PAM, systemd‑unit'ы или udev‑правила, а не полагаться только на поведение DE.

Accessibility, UX и дальше — почему это не только про игры

Поддержка «Slow Keys» в Wayland, настройка тональности кожи emoji и возможность скрыть индикаторы таймаута уведомлений — это не только косметика. Это часть большой задачи: сделать рабочий стол гибким для разных пользователей. Для людей с ограниченными возможностями управление задержками ввода, чувствительностью и визуальной отдачей критично.

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

Сравнение с другими экосистемами

Windows долгое время корректно трактует ввод с контроллера как «активность» — частично из‑за исторически более монолитной модели драйверов и более устоявшейся модели взаимодействия с играми. На Linux решение требует координации множества проектов: ядро, BlueZ, libinput, compositor, desktop‑environments. Поэтому фикс в Plasma — знак зрелости десктопа и экосистемы.

Тренды и прогнозы

Рост Linux‑гейминга и портов (Steam Proton, native‑игры) повышает потребность в таких нишевых улучшениях.
Wayland продолжит диктовать безопасность ввода; композиторы станут всё более ответственными за обработку нестандартных устройств.
Больше внимания к доступности: DE будут внедрять функции, которые раньше были «надстройками».
В корпоративных и встроенных системах появятся политики для тонкой настройки того, какие устройства считаются «активностью».

Вывод

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

Вопросы к обсуждению

Какой сценарий важнее для вас в работе с контроллерами — комфорт дома или безопасность в публичных терминалах? Сталкивались ли вы с ситуациями, когда устройство ввода мешало спать системе, и как решали проблему? Какие дополнительные механизмы (thresholds, фильтрация событий, udev‑rules) вы бы хотели видеть у DE для тонкой настройки «активности»?