Особенности гейминга под Linux
Это руководство по играм под Linux подойдет для не знакомых с линуксом геймеров энтузиастов или знакомых с ним игроков новичков. По задумке, оно должно дать общее представление о том, что и для чего делается, и с помощью чего этого можно достичь.
Общие для всех ОС целей
Большинство пользователей и разработчиков игр не понимают, что и как надо сделать для получения удобного времяпрепровождения в играх. А по линуксу информации мало, есть куча мифов и заблуждений. Поэтому сначала независимая от ОС основа.
Режим вывода картинки
Первое, что надо получить от каждой игры - подходящий под ситуацию режим отображения картинки. Их можно разбить на 4 основных варианта:
- VSync (без VRR)
- VRR (VSync или Mailbox)
- Mailbox
- Без синхронизации
VSync (без VRR)
Частота в игре синхронизируется с частотой монитора. Нет разрыва картинок, кадры идут равномерно и промежуток между кадрами в игре совпадает с промежутком между их выводом. Только вот 60 Гц монитор не может выводить 55 fps, и вместо этого будут переключения между 30 fps и 60. Плюс к этому игре придется держать очередь кадров, из-за чего получишь пару кадров задержки. Этот метод используют обычно тогда, когда не знают как сделать лучше или задержка не имеет значения (пошаговые стратегии).
- Плюсы: легко включить
- Минусы: сильно бьет по задержке и карточка должна с запасом тянуть целевой фпс.
VSync (с VRR)
Тут уже не игра подстраивается под частоту монитора, а монитор под частоту игры. Пропадает связанная с VSync задержка и всё отлично работает в рабочем диапазоне VRR. Оптимальный вариант для большинства случаев. В соревновательных играх на железе fps порой может быть в разы выше частоты монитора, там стоит присмотреться к Mailbox.
Беда с VRR в том, что он работает только при fps в пределах частоты монитора, из-за чего в игре надо ограничить fps на пару % ниже герцовки экрана. И ограничить надо именно лимитером в игре, так как внешние приводят к аналогичной обычному vsync задержке. Часто в игре нет лимитера или настройки ограничены фиксированными частотами, типа 30/60/120. Если 120 fps на 144Hz мониторе - незначительный компромисс, то на 60 Hz остаётся использовать mailbox вместе с vrr. Результат будет как у обычного mailbox, но vrr избавит от проблем при просадках fps-а (порой даже лучше будет). Сейчас в играх начинают добавлять опцию reflex и antilag, которая должна сама позаботиться об ограничении fps.
Также в зависимости от монитора и характера колебаний fps-а в игре может проявляться мерцание на тёмных участках изображения, особенно сильно от этого страдают текущие OLED-ы.
В играх, где взаимодействие идет больше через интерфейс и перемещение мышки VRR может оказаться нежелателен сам по себе, так как в некоторых играх перемещение курсора не привязано к fps в игре, а зависит только от частоты монитора. VRR же тормоза игры придаст и ему.
- Плюсы: лучший вариант в большинстве случаев.
- Минусы: требуется настройка и в игре не всегда есть необходимые для этого инструменты. Могут быть проблемы на отдельной комбинации конфигурации и игр.
Mailbox
Когда приходит время выводить кадр на экран, монитор получает последний полностью готовый кадр. Нет разрывов картинки, фпс не надо ограничивать, но промежуток между выводом картинки может отличаться от игрового. Если монитор с низкой герцовкой, да еще и нет кратного запаса по fps в игре, то картинка будет дерганая и появится ощутимая задержка. Под виндой этот метод известен как fast sync на nvidia и enhanced sync на амд. Под вейлендом так игры выводят картинку по умолчанию, если не включено разрешение тиринга.
Стоит использовать, когда есть проблемы с VRR или когда у тебя какая-нибудь соревновательная игрушка с x2-x4 fps-ом относительно частоты монитора.
- Плюсы: всегда доступен в вейленде, хорошо работает при высоком фпс в игре.
- Минусы: проблемы с таймингами кадров и задержкой, когда мало фпсов и низкая герцовка монитора.
Без синхронизации
Доп. задержки нет, есть тиринг. Использовать имеет смысл либо когда все остальные варианты не подходят и это единственный способ хоть как-то играть. Либо когда у тебя 240 Гц+ монитор и фпс в играх так же исчисляется сотнями.
Разгрузка GPU
У рендеринга в играх есть особенность, что при упоре в gpu появляется очередь отрисовки. Которая может приводить к разной, порой огромной задержке. Какой-нибудь ведьмак в 55 fps с упором в соточку будет играться в разы хуже, чем с ограничением в 50 fps лимитером там же. Лимитер должен быть внутри игры, внешние дают эффект vsync-а. Упор в cpu такой проблемы не создаёт.
Тут аналогично ситуации с VRR. Не всегда есть адекватный лимитер в игре, также эту задачу довольно неплохо решает nvidia reflex и amd antilag (когда они есть).
Генерация кадров
Добавляют существенную задержку относительно реального fps и нагружает видюшку, из-за чего реальный fps в GPU-bound сценариях падает еще ниже. Использовать имеет смысл в нишевых случаях, хорошо подходит для CPU-bound игр и где не важна задержка, типа flight/train simulator.
Nvidia Reflex / AMD Antilag
По сути, как динамический фреймлимитер. Который не даёт игре выйти за пределы vrr при vsync-е и нагружать видюшку по полной. Порой эффект похуже, чем от ручной установки оптимального лимита по фпс, но удобнее и эти технологии могут быть в играх, где разработчики не предоставили возможность ограничить фпс.
ReBAR
Resizable BAR - технология, которая уменьшает издержки на передачу ресурсов в память видюшки. Эффект часто незначительный, но стоит включить в настройках UEFI. В редких случаях может негативно влиять на fps.
Вывод
- По возможности надо ограничивать частоту кадров игровым лимитером для разгрузки GPU или рефлексом/антилагом, а также для работы VRR. При любом способе вывода изображения.
- Если в игре x2-x4 от частоты монитора, то лучшим вариантом будет Mailbox.
- Если нет, то надо смотреть в сторону VRR + VSync при наличии игрового лимитера и VRR + Mailbox без него.
- Если всё печально, то стоит попробовать просто режим Mailbox, как меньшее зло.
- Если всё еще печальнее и у тебя 20 фпс шутан на мышке на 60 Гц мониторе, то, возможно, играть получится только без синхронизации и разрывов.
- По возможности стоит включить ReBAR.
Особенности Linux
DLSS, FSR и другие апскейлеры
Всё есть, всё работает, всё как под виндой, но есть особенности с подменой FSR в играх.
В играх с FSR4 часто можно включить поддержку FSR4 через подкидывание библиотек в папку с игрой. Как и в винде это работает, но можно просто запустить игру с PROTON_FSR4_UPGRADE=1 при использовании свежих версий Proton GE
Если игра dx11 или dx12 (в вулканом пока не работает) и там есть DLSS или XeSS, то можно подкинуть любую версию FSR через Optiscaler. Всё как под винду, только файл setup там под линукс и нужен свежий протон, актуальный гайд по установке под линукс: https://github.com/optiscaler/OptiScaler/wiki/FSR4-Compatibility-List
Low Latency Layer (Антилаг, Reflex)
Работает как и под Windows, но есть удобная поддержка Anti-lag/Reflex без привязки к GPU: https://github.com/Korthos-Software/low_latency_layer
Эта штука позволяет включить в игре antilag или рефлекс на любой карточке. Что особенно полезно для владельцев amd/intel, так как поддержка рефлекса встречается почти в каждой современной игре.
Чтобы не заморачиваться с внедрением этого слоя вручную, проще использовать протон от cachyos: https://github.com/CachyOS/proton-cachyos
Wayland
Игры и окружение рабочего стола просто работают нормально и одновременно из коробки и телодвижений. Поддержка HDR на разном уровне в разных окружениях.
По умолчанию картинка в играх рисуется как Mailbox, в свежих DE можно в настройках включить тиринг (в kde с 6.5.0 в настройках экрана можно разрешить для развернутых на весь экран окон). Включать тиринг имеет смысл в одном случае - если целенаправленно хочешь выводить картинку в играх в режиме без синхронизации, а не Mailbox или VSync. Просто так включать этот режим плохая идея, так как тиринг в играх нужен редко, а вот Mailbox режима в настройках игр практически никогда нет (и это головная боль в dx12 играх под виндой).
- Sync - Включил в игре и он есть, выключил и у тебя либо mailbox, либо тиринг, в зависимости от настроек.
- VRR - Аналогично, никаких дополнительных особенностей.
- Mailbox - По умолчанию в вейленде, но может стоять настройка на тиринг в конкретном DE (kde). В случае с разрешенным тирингом можно форсировать mailbox для отдельного приложения через запуск с переменной окружения типа MESA_VK_WSI_PRESENT_MODE=mailbox
- Без синхронизации - Режим включается в настройках DE, но не во всех может присутствовать.
Xorg (иксы)
В отличие от Wayland, у иксов особенности, с которыми придется бороться.
За отрисовку там отвечают иксы и композитор.
При выводе через композитор нормальной работы VRR добиться сложно, а VSync вносит дополнительную задержку. Поэтому при выводе через композитор одна нормально работающая схема - Mailbox.
Без композитора можно получить VSync, VRR, и режим без синхронизации. Но в этой схеме рабочее окружение работает с ограниченными возможностями, альтаб медленный и может уронить систему.
Куча возможных схем вывести картинку, они зависят от DE, игры, настроек иксов и драйвера. Но нет ни одной, которая бы просто работала. Это приводит к невозможности описать правильный подход к настройке иксов и игр, так как его не существует и всегда придется чем-то жертвовать.
Запуск игр
Игры бывают родные для ОС (нативные), игры для Windows (основная масса) и другие (через всякие эмуляторы).
Родные встречаются нечасто и «нативность» далеко не всегда говорит о лучшей их работе под линуксом. Часто самый быстрый способ решить проблему - запустить версию для Windows, особенно если играешь в стиме. Из плюсов - у родных игр есть родные установщики, можно просто скачать и поставить.
Windows игры запускаются через прослойку wine или содержащий её proton. Это требует некоторого понимания работы с ними, но запускалки игр частично берут на себя связанные с этим сложности. Используя стим, можно даже не догадываться о существовании этих прослоек.
Сложности с windows играми начинаются при выходе за пределы стима и при установке модов.
С играми через эмуляторы всё как и под другими ОС, особенности надо описывать для каждого отдельно.
Steam
Установка
Установка стима может отличаться от привычной и тут есть несколько вариантов:
- Установка из пакетного менеджера своего дистрибутива
- Установка вручную
- Установка из flatpak
Оптимальный вариант - установка через пакетный менеджер дистрибутива. Либо это пакет прямо в репозитории, либо с официального сайта стима. В отличие от ручной будут подтянуты разные неочевидные зависимости и с меньшей вероятностью придется вникать в особенности работы системы и решать необычные проблемы. Но, в зависимости от дистрибутива, надо доустановить часть необходимых 32-х битных пакетов вручную. Это зависит от дистрибутива и лучше свериться с гайдом к нему.
Через flatpak поставить проще всего и, чаще всего, это нормально работает. Но это неподдерживаемая Valve конфигурация, там бывают уникальные проблемы и есть особенности при интеграции с другими приложениями.
Ручная установка только для тех, кто понимает зачем она ему нужна, и готов самостоятельно разбираться с проблемами.
Иногда можно встретить в гайдах по стиму для разных дистрибутивов такое понятие, как запуск со стимовским рантаймом и с родным (Native). Вальве поддерживает только вариант со своим рантаймом и редко имеет смысл пытаться запускать с родным.
Запуск
Родные для линукса игры запускаются как обычные игры в винде.
Родные для windows через прослойку в виде протона.
Версию прослойки можно выбрать в настройках игры в стиме на вкладке совместимости.
Свою прослойку можно подкинуть в .steam/steam/compatibilitytools.d/. Чаще всего всё работает и с родными, но в популярных сторонних есть полезные особенности и решенные проблемы, которых по той или иной причине нет в официальной.
Популярный выбор Proton от CachyOS: https://github.com/CachyOS/proton-cachyos
Еще одна популярная сборка Proton GE: https://github.com/GloriousEggroll/proton-ge-custom
Обычно я просто использую последнюю версию CachyOS и даже не пробую официальный протон, так как там часто недостаёт свежих фиксов или могут отсутствовать библиотеки по лицензионным соображениям.
Перед покупкой игры или при проблемах с запуском стоит проверить сайт protondb. Там можно увидеть отчеты по совместимости конкретной игры и как её запускали другие люди, если сталкивались с какими-нибудь проблемами.
Для ленивых есть менеджер протонов ProtonPlus. Эта графическая утилита, для автоматической закачки и распаковки разных сборок протона куда надо.
Файлы
Файлы игры стима можно найти по такому пути: /home/ПОЛЬЗОВАТЕЛЬ/.steam/steam/steamapps/common/. Дальше, как и в аналогичной директории в windows.
Если игра запускается через proton, то другие связанные с игрой файлы находятся в: /home/ПОЛЬЗОВАТЕЛЬ/.steam/steam/steamapps/compatdata/ID_ИГРЫ/. Там в pfx/drive_c/ копируется типичная для системного диска windows структура. Там в users/steamuser/ можно найти привычные для домашней директории пользователя по windows настройки и сохранёнки игры.
Родные игры обычно пишут куда-нибудь в домашнюю директорию пользователя в ~/.config/ИГРА_ИЛИ_ИЗДАТЕЛЬ
Lutris
Ссылка: https://lutris.net/
Менеджер для игр, который объединяет разные ланчеры и позволяет запускать и ставить игры через него.
В первую очередь полезен для запуска игр за пределами стима. На сайте есть готовые рецепты установки, которые сами ставят и упаковывают под линукс игру в одно нажатие кнопки.
Также удобный инструмент для ручного запуска игр, так как не надо самому создавать префиксы и искать нужные версии wine и proton. Но сильно перегружен, из-за чего можно заплутать даже при выполнении простейших действий.
Heroic Games Launcher
Ссылка: https://heroicgameslauncher.com/
Менеджер для игр из отличных от стима ланчеров (Epic, GoG, Amazon), которых нет под linux.
Его задумка в том, чтобы собрать игры из этих ланчеров в одном месте и сделать их запуск таким же простым, как и в стиме.
PortProton
Менеджер игр в духе Lutris. Меньше готовых рецептов, но не такой перегруженный функциями и для простого управления поставленными вручную играми будет попроще.
Bottles
Ссылка: https://github.com/bottlesdevs/Bottles
По сути это просто штука для ручной установки windows приложений и просто позволяет делать типичные в процессе этого вещи через графический интерфейс. Скачать Wine, создать префикс, поставить и запустить из него приложение. Только через GUI и не надо запоминать пути и возиться с консольными утилитами.
PlayOnLinux
Кто-то до сих пор может наткнуться на эту штуку, но она устарела и толком не поддерживается. Проще использовать Bottles или PortProton.
Ручной запуск Windows игр
С ручным запуском игр куча нюансов, в основе приходится оперировать и мыслить такими сущностями:
- Прослойка для запуска (Wine, Proton). Что запускает игру.
- Префикс (что-то типа виртуального windows диска, с библиотеками и настройками прослойки).
- Библиотеки dxvk (для dx9-11 игр) и vkd3d (для dx12). Необходимые слои трансляции для directx игр, могут идти в составе прослойки, могут ставиться отдельно.
- Другие сторонние библиотеки. Иногда чего-то не хватает для запуска приложения и надо подкинуть вручную.
Запуск windows игр (и приложений) выглядит так:
- Ставятся зависимости для работы игр в систему. Когда не знаешь какие, то проще всего поставить стим (лучший вариант) или wine (с большей вероятностью чего-нибудь не хватит).
- Качается подходящая прослойка. Обычно это какая-нибудь свежая сборка Proton (с umu) или wine. Очень редко, бывают сборки под конкретную игру для фикса багов в ней.
- Она запускается и создаёт префикс под приложение в указанном месте, лучше всегда использовать отдельный префикс под каждое приложение, так как настройки и потребности у них могут отличаться.
- Ставится dxkv или vkd3d, если нет в скаченной прослойке
- После чего запускается через эту прослойку в этом префиксе установщик или уже распакованная игра, при проблемах доставляются необходимые сторонние библиотеки.
Proton требует окружение стима (umu). Т.е. umu запускает протон, с которым уже затем работаешь как с обычным wine. О прослойках и umu в отдельном разделе ниже.
Для установки библиотек часто прибегают к использованию утилиты winetricks. Она ставит выбранные библиотеки в указанный префикс и настраивает его на их использование.
Wine, Proton, UMU Launcher
Windows игры запускаются через слой трансляции, в основе которого лежит Wine (proton, wine-tkg и т.п.). Чистый Wine для этого также часто годится, но, чаще всего, он отстаёт по производительности, совместимости и разным фиксам от постоянно обновляющихся сборок. Еще неудобно управлять версиями wine при использовании пакетов из дистрибутива, поэтому всегда лучше качать какую-нибудь сборку, а сам wine ставить только для автоматического подтягивания зависимостей для его работы.
Сборки Wine от Kron4ek: https://github.com/Kron4ek/Wine-Builds/releases
- wine-staging - это wine и часть, по той или иной причине, не попавших в него исправлений и улучшений
- wine-staging-tkg - сборка на основе staging с доп. патчами.
Proton - основанный на wine слой с дополнительными улучшениями, со встроенными библиотеками и рассчитанный на работу в окружении стима. Запуск игр через него чаще всего даёт ожидаемый результат при минимуме возни и понимания происходящего, но ему нужно окружение стима. В стиме просто забрасываешь директорию с протоном и используешь, а при запуске за его пределами чуть сложнее и надо использовать umu.
Популярные сборки протона:
- proton-cachyos - оптимизированная под производительность сборка от разработчиков CachyOS. Интегрированы улучшения типа Low Latency Layer.
- proton-ge-custom - сборка от gloriouseggroll, часто содержит фиксы для каких-нибудь новых игр.
Umu (github.com) - Выдранное из стима окружение для запуска игр за его пределами. Позволяет использовать сборки протона без стима и, частично, заменяет зависимости в системе (меньше вероятность, что не хватит какой-то библиотеки).
winetricks и protontricks
Эти утилиты помогают доставить в префикс для запуска игры необходимые библиотеки и подключить их.
winetricks - в префикс wine. Указываешь путь к wine через переменную окружения WINE, указываешь путь к префиксу через переменную WINEPREFIX, затем winetricks имя_компонента для установки необходимого компонента.
protontricks - обёртка вокруг winetricks. Её суть в том, чтобы запустить winetricks через прописанный в стиме для игры протон и в её префиксе, а не искать всё это и не изворачиваться с запуском самостоятельно.
Моды
Моды из стим воркшопа просто ставятся и работают как и в винде.
Моды, работающие через подмену ресурсов игры, работают аналогично windows, но расположение файлов другое. Для windows игр wine/proton создают типичную для системного диска структуру и файлы, попадающие в домашнюю директорию пользователя (сохранёнки и конфиги), надо искать там. Для стима пример в разделе со стимом.
Некоторые моды работают не просто через подмену ресурсов самой игры, но через подкидывание туда библиотеки (*.dll файла). В Windows игра видит такой файл и подгружает его вместо стандартной библиотеки и так в игру встраивается мод. Под линуксом это не происходит автоматически и надо указать подсасывание библиотеки во время запуска игры. Это делается через переменную окружения, типа WINEDLLOVERRIDES=«dinput8.dll=n,b». В стиме команда запуска игры будет выглядеть так: WINEDLLOVERRIDES=«dinput8.dll=n,b» %command%.
Некоторые моды для windows игр могут требовать недостающие библиотеки и их надо поставить вручную или через proton/wine tricks. С установкой или работой библиотек могут быть проблемы. Чаще всего требуется поставить какую-нибудь версию .Net
Еще один тип модов работает через запуск отдельного приложения параллельно с игрой и через чтение памяти процесса игры. Но при запуске через wine/proton приложения запускаются в своём отдельном окружении и такой мод надо запустить в окружении игры. Если игра запускается из стима, то это может оказаться сложнее, чем кажется. Пример скрипта для запуска HunterPie для monster hunter world:
#!/bin/bash
cd "$(dirname "$0")"
# Steam comatibility data for Monster Hunter World
MWH_PATH_COMPDATA=~/.steam/steam/steamapps/compatdata/582010
# Path to proton, lazy method, should work
PROTON_PATH=$(cat $MWH_PATH_COMPDATA/config_info | head -n 2 | tail -n 1 | sed 's/files\/share\/fonts\///')
# Path to steam installation
STEAM_PATH=~/.steam/steam
# Run HunterPie in MWH Steam environment
STEAM_COMPAT_DATA_PATH=$MWH_PATH_COMPDATA \
WINEPREFIX=$MWH_PATH_COMPDATA/pfx \
STEAM_COMPAT_CLIENT_INSTALL_PATH=$STEAM_PATH \
$PROTON_PATH/proton run \
./HunterPie.exe
Оверлеи производительности
Аналогов intel perfmon и его прородителя от nvidia для подробной оценки производительности под линуксом нет, есть только классическое отображение графика fps, и загруженности по ресурсам.
MangoHud
Ссылка: https://github.com/flightlessmango/MangoHud
Самый популярный оверлей со статистикой производительности под линуксом. Часто присутствует в базе пакетов дистрибутива, также есть версия для работы во flatpak-е.
Запускается:
mangohud /путь/игра/bin/game(для запускаемых вручную нативных игр)mangohud %command%(команда запуска в настройках игры в стиме)gamescope --mangoapp -- %command%(аналогично, только при использовании вместе с gamescope)- автоматически для игр на Vulkan (не opengl) при наличии переменной окружения
MANGOHUD=1
Steam
В стиме появился свой оверлей производительности. Он попроще MangoHud, и его можно просто включить в настройках стима.
Железки, драйвера и сопутствующие настройки
Настройки мышки и чувствительности
За чувствительности мышки под linux отвечает библиотека libinput. Тут есть пара особенностей в плане применения и определений. Это не связано напрямую с играми, но геймеры чувствительнее к проблемам с любым инпутом.
У мышки есть три профиля работы adaptive, flat, custom.
-
adaptive - используется по умолчанию и отдаленно напоминает режим «повышенной точности курсора» в винде. Это режим с акселерацией мышки, но она зависит от её dpi и в этом режиме практически невозможно регулировать чувствительность курсора. Исторически там сложилось из-за мнения разработчика, что можно подобрать универсальный режим для всех пользователей со всеми комбинациями мышек. Из-за чего его тяжело использовать даже тем, кто предпочитает акселерацию. В kde это галочка «Включить ускорение курсора».
-
flat - режим без акселерации. В этом случае чувствительность мышки регулируется как и ожидает пользователь в режиме без акселерации, если бы не один нюанс. Ползунок в gui часто не продуман и «делитель» скорости регулируется линейно. Т.е. смещение на одну позицию влево может снизить скорость до 1.8x, еще на одну до 0.6x, потом до 0.4x, 0.2x, и 0x. Поэтому придется вбивать нужное значение вручную в GUI (если есть такая возможность как в kde), либо в конфиге. В libinput чувствительность начинается с нуля (1x), 0.2 означает +20%, а -0.2 это -20%. Поэтому если нужна, например, 1/8, то это будет -0.875
-
custom - своя собственная функция чувствительности мышки. Вопрос сложный и по нему нужен отдельный гайд, неинтересно подавляющему большинству пользователей.
В Wayland окружениях само окружение рабочего стола должно предоставить возможность настраивать мышку, у каждого свои особенности.
В Xorg можно настроить мимо окружения через xinput, только в этом случае и восстанавливать заданные настройки это окружение не сможет.
Подробнее про борьбу с настройками мышки: https://wiki.archlinux.org/title/Mouse_acceleration
DPI и настройки самой мышки. Для популярных моделей мышек бывают приложения для настройки под линукс, но везет не всем. Если такого приложения нет, то остается настроить dpi и нужные параметры под виндой и сохранить в память мышки (можно через проброс мышки по usb в виртуальную машину).
- Для razer: https://github.com/openrazer/openrazer
- Для logitech: https://github.com/pwr-Solaar/Solaar
- Для разных мышек: https://github.com/libratbag/piper
Геймпады
Большинство геймпадов поддерживаются линуксом из коробки, но не всегда доступны сразу для доступа со стороны пользователя или не определяются игрой. Чаще всего всё просто работает и читать дальше имеет смысл в том случае, если это не так.
Чтобы запущенные пользователем программы видели геймпад у него должны быть права доступа к ним. Самый распространённый способ этого добиться - рассказать системе, что доступ к геймпадам должен выдаваться каждому авторизованному пользователю в системе.
Делается это через правила udev, которые могут идти системой или в отдельном пакете, а в случае проблем можно задать самостоятельно. Обычно готовые правила идут вместе со стимом из пакетного менеджера, но могут быть вариации между дистрибутивами.
Доступ к геймпаду со стороны пользователя (udev)
Пример типичного правила для геймпада
udev - система управления устройствами linux. Правила для udev определяют, что система должна сделать с обнаруженным устройством.
Свои правила можно поместить в /etc/udev/rules.d/, например в файл 10-dualshock3.rules:
# DualShock 3 over USB hidraw KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="0268", MODE="0660", TAG+="uaccess"
# DualShock 3 over bluetooth hidraw KERNEL=="hidraw*", KERNELS=="*054C:0268*", MODE="0660", TAG+="uaccess"
В этом примере правило говорит системе, что при обнаружении hidraw устройства (железки типа геймпадов) с идентификатором поставщика 54c и идентификатором продукта 0268 разрешить доступ к нему залогиненным пользователям MODE=«0660», TAG+=«uaccess».
Для подключенных по usb это выглядит как ATTRS{idVendor}==«54c», ATTRS{idProduct}==«0268», для блютуса KERNELS==«054C:0268», MODE=«0660».
Идентификатор подключенного по usb устройства можно посмотреть командой lsusb, в выводе будет «Bus *** Device ***: ID поставщика:продукта Имя устройства».
Созданные правила должны подтянуться автоматически, перечитать правила можно принудительно командой udevadm control --reload и применить udevadm trigger.
После этого они должны будут примениться к геймпаду при его переподключении.
Готовые правила
Обычно не требуется установка вручную дополнительных правил для геймпадов и достаточно тех, что идут с системой.
Сборка правил под геймпады: https://codeberg.org/fabiscafe/game-devices-udev
Можно просто распаковать из архива в ‘/etc/udev/rules.d’. Эти правила ничем не отличаются от самописных, просто для удобства известные геймпады собраны в одном месте.
Определение геймпада играми
С определением геймпада играми много нюансов. Некоторые игры видят только первый геймпад в системе, который может оказаться виртуальным и пользователь об этом даже не подозревает. Часть ожидает назначения клавиш и осей от xbox, какие-то понимают dualshock и nintendo. В первую очередь стоит проверить, видят ли какие-либо программы геймпад в принципе. Для этого можно использовать разные программы типа «sdl2-jstest», но лучше всего подходит стим.
Настройка геймпадов обширная тема, и подробнее можно почитать на arch wiki: https://wiki.archlinux.org/title/Gamepad
Видеокарты
Драйвер видеокарты можно поделить условно на две части. В ядре идет общение и управление железкой, в пространстве пользователя обеспечивается поддержка необходимых api и функций для работы приложений.
Привычного для windows идущего с драйверами софта нет. Часть аналогичных функций находятся в других местах, других просто нет.
Драйвера AMD и Intel открытые и идут в составе ядра и дистрибутива. Из плюсов - не надо ничего делать и волноваться о проблемах с совместимостью дистрибутива. Из минусов - возможность и сложность откатиться/обновить драйвер в случае проблем зависит от возможностей дистрибутива, часто ограниченных.
Под линуксом поддержка интеловских карточек в лучшем случае посредственная, а порой просто плохая. Ютьюб посмотреть можно, а там как повезет. На нормальную работу и производительность в играх можно не рассчитывать.
Карточки Nvidia поддерживаются со дня выхода с большинством привычных для windows функций. Но идущий отдельно от ядра драйвер доставляет проблемы, а поддержка новых фишек самого linux-а реализуется с существенной задержкой или долго не решаются баги. Можно ожидать производительность на 10-30% ниже windows.
Карточки AMD быстро получают поддержку после выхода, но фишки этих карточек часто доходят с ощутимой задержкой. В то же время, плюшки самого линукса в первую очередь тестируются на них, а сами драйвера создают меньше всего проблем. В среднем производительность можно ожидать как от винды, в случаях с path tracing она может быть существенно ниже.
AMD
Актуальные нюансы можно найти в wiki: https://wiki.archlinux.org/title/AMDGPU
AMD начала прикладывать существенные усилия в поддержку linux относительно недавно. Основной фокус на карточки типа rdna2+, со всякими RX580 тоже всё отлично, но карточки старше не так распространены и их работа не так вылизана.
Думать о драйверах не надо, просто запустил и всё работает.
Кроме случаев, когда нет. Баги в mesa (драйвер в пространстве пользователя) возникают не так уж редко и приходится её откатывать. Баги в ядре случаются существенно реже.
Intel
Актуальные нюансы можно найти в wiki: https://wiki.archlinux.org/title/Intel_graphics
Как и в случае с AMD, баги чаще всего связаны с установленной версией mesa. Но из-за низкой распространённости дискретных карточек и забагованности драйверов играют на них редко, с багами часто придется разбираться самостоятельно.
Nvidia
Актуальные нюансы можно найти в wiki: https://wiki.archlinux.org/title/NVIDIA
Ставить драйвер с официального сайта имеет смысл только в случае, когда четко осознаешь что и зачем делаешь. Он не будет обновляться вместе с системой, и это повышает риски непредсказуемого поведения при обновлениях.
Для карточек, начиная с Turing (16xx, 20xx и выше) лучше ставить открытый драйвер ядра из состава дистрибутива.
Для более старых только закрытый.
Есть еще вариант использования полностью открытых драйверов (Nouveau + NVK), но в текущем состоянии нет смысла рассматривать их применения на актуальных карточках.
Звук
Обычно работает из коробки и лезть в его настройки не надо. Большая часть звуковых карточек поддерживается, но встречаются и исключения.
Также познакомиться с системой вывода звука придется, если есть желание завести объемный звук в наушниках (преобразование 7.1 из источника в HRTF вывод в наушниках). В современных дистрибутивах обычно используется PipeWire, и у него есть всё необходимое для реализации подобной функции (аналог HeSuVi под windows). В дистрибутивах старше можно встретить Pulseaudio, там это тоже возможно.
Объемный звук можно настроить вручную через конфиги, либо используя вспомогательные приложения типа Irate Goose.
Другой софт для игр
Gamescope
Ссылка: https://github.com/ValveSoftware/gamescope
Композитор wayland. Только его суть не в предоставлении пользователю полноценного окружения, а это такое «окно» для запуска внутри игр с дополнительными функциями.
Через него можно задать нужные пропорции экрана и правила растягивания картинки. Полезен, когда надо растянуть картинку с применением FSR или целочисленного скалирования. А также для старых игр, в которых нет поддержки разрешения и пропорций твоего экрана.
Gamemode
Ссылка: https://github.com/FeralInteractive/gamemode
Приблуда для того, чтобы при запуске игры применять «оптимизации» на время её работы.
В самих оптимизациях ничего необычного и они могут и не давать никакого эффекта. Там просто установка приоритетов, режима энергосбережения, отключение гашения экрана и т.п.
Может быть полезен, чтобы просто не думать об этом. Например, под линуксом может гаснуть экран при игре с геймпада, так как нажатия на него не воспринимаются как активность за компьютером.
Применяется так:
gamemoderun %command%(параметр запуска для стима)gamemoderun ./game(запуск игры напрямую)
Moonlight и Sunshine
Стриминг игры и десктопа с хоста (sunshine) на удалённую железку (moonlight)
Moonlight: https://github.com/moonlight-stream/moonlight-qt
Sunshine: https://github.com/LizardByte/Sunshine
Проверенный и качественный способ стриминга игр. Поддерживается широкий спектр устройств и можно играть со своего ПК даже на nintendo switch lite (взломанном).
