ゲーム

提供: ArchWiki
ナビゲーションに移動 検索に移動

関連記事

このページではゲームの実行と関連するシステム設定に関する情報のみを集めています。GNU/Linux 向けの人気ゲームの一覧はゲーム一覧を見て下さい。

ゲーム環境

Linux でゲームを遊ぶための環境は様々なものが存在します:

  • ネイティブ – Linux 向けに書かれたゲーム (大抵はフリーでオープンソース)。
  • ブラウザ – この種のゲームをプレイするのに必要なのはブラウザとインターネット接続だけです。
    • プラグインベース – 遊ぶためにはプラグインのインストールが必要です。
      • Java Webstart – クロスプラットフォームのゲームを簡単にインストールするのに使われます。
      • Flash ゲームはウェブ上で最も一般的なゲームです。
    • HTML 5 によるゲームは新しい canvas と WebGL テクノロジーを使います。全てのモダンブラウザで動作しますがマシンの性能が低いと実行が非常に遅くなります。
  • 専用環境 (ソフトウェアエミュレータ) – 他のアーキテクチャや環境のために作られたソフトウェアを実行するのに必要です (あなたの国の著作権法に注意)。詳しくはエミュレータのリストを見て下さい。
    • Wine – 膨大な Windows ソフトウェアだけでなく、Windows のゲームの実行も可能にします。Wine ではゲームのパフォーマンスが下がらないため (むしろ高速に動作することもあります)、Windows で動作するシステム要件が低いゲームならば大抵は Wine でも動作します。ゲームごとの互換性の情報は Wine AppDB を見て下さい。
    • Crossover Games – Codeweavers チームのメンバーは Wine の主要なサポーターです。Crossover Games を使うことでゲームのインストールや設定を楽にしたり、他の方法を使うのと比べて信頼性を高めたりすることができます。Crossover は有料の市販品ですが、開発者がコミュニティと対話できるように フォーラム が用意されています。
    • DosBox – DOS エミュレータ。古典的な DOS タイトルを動かすのに使われます。
    • scummvm – 多数のクラシックなアドベンチャーゲームで使われていた SCUMM ゲームエンジンのゲームをエミュレートします。対応タイトルの完全なリストは ScummVM ウェブサイト を見て下さい。
  • ハードウェアエミュレータ – ソフトウェア環境ではなくデバイス全体をエミュレートします。著作権については同じです。仮想マシンを使うことで Windows 専用のゲームを遊ぶことができます。VirtualBox は 3D もサポートしています。Windows の KVM ゲストから OVMF による PCI パススルーによって直接ハードウェアを利用することも可能です。

ゲームの取得

ネイティブ

公式リポジトリや AUR からかなりの数が入手できます。Loki はいくつかのゲームのインストーラーを提供しています。

デジタル配信

  • Desura — インディーゲームに特化したデジタル配信プラットフォーム。豊富なゲームがあると考えてよいでしょう (セキュリティやバグがあまり気にならないならば)。
http://www.desura.com/ || desuraAUR[リンク切れ: パッケージが存在しません]
  • Steam — Valve によって開発されている著名なデジタル配信とコミュニケーションのプラットフォーム。最近 Linux に (開発会社によって) 移植された有名ゲームが揃っています。Source (Half-Life 2) や Goldsource (HL1) エンジンのゲーム, Serious Sam 3, Brutal Legend, 多数の Humble Bundles のゲームやその他のインディータイトルなどを含んだ巨大なライブラリが存在します。
https://store.steampowered.com || steam
  • lgogdownloaderAUR パッケージを使うことでコマンドラインから GOG タイトルをダウンロードすることができます。
  • GOG.com が公式でサポートしているのは Ubuntu と Linux Mint だけです。サポートを求めるときはこのことを覚えておきましょう。たとえ Arch でゲームが動かせなかったとしても返金してもらうことはできません。
  • ほとんどの GOG.com タイトルは DOSBox, ScummVM, Wine によってパッケージ化されています。

Java

Wine

  • Wine におけるゲーム (やその他のアプリケーション) の実行については Wine AppDB に情報が集積されています。
  • カテゴリ:Wine も参照。

playonlinux を使うのが (特に初心者には) おすすめです。必要な依存パッケージが全てインストールされ、最初の起動時に Windows ツールを自動でダウンロード、ネイティブの windows アプリケーションが正しく実行されるように設定を行います。詳しくは、公式ウェブサイトを見て下さい。

ゲームの実行

特定のゲームや、ゲームのタイプによっては実行するのに特別な設定を必要としたり、または設定されていることが前提になっていることがあります。大抵のゲームは、何も設定をしなくても Arch Linux で動作し、コンパイル時の最適化によって、他のディストリビューションよりもパフォーマンスが出ることもあります。しかしながら、特別な環境を使っている場合、希望通りにゲームをスムーズに実行するために多少の設定やスクリプトが必要になるでしょう。

マルチスクリーン環境

マルチスクリーン環境ではフルスクリーンのゲームで問題が発生することがあります。そのようなときは、別の X サーバーを実行するのが一つの解決方法になりえます。他の方法は NVIDIA の記事を見てみて下さい (NVIDIA 以外を使っているユーザーも見る価値があります)。

キーボード操作

多くのゲームはキーボードの入力を横取りするため、ウィンドウの切り替え (alt-tab) ができなくなることがあります。

SDL のゲーム (例: Guacamelee) では Ctrl-g を押すことでキーボードの占有を無効にすることが可能です。

また、sdl-nokeyboardgrabAUR[リンク切れ: アーカイブ: aur-mirror] をダウンロードすることでも SDL のゲーム中にキーボードコマンドを使えるようにすることができます。さらに、libx11-nokeyboardgrabAUR[リンク切れ: パッケージが存在しません] を使うことで X11 レベルでキーボードの占有を無効にしたり、libx11-ldpreloadnograbAUR[リンク切れ: アーカイブ: aur-mirror] で LD_PRELOAD を使って特定の占有を止めるようにしてアプリケーションを実行するなど細かい制御をすることもできます。Wine/lib32 ユーザーは各 lib32 ライブラリにも気をつけて下さい。

ノート: SDL はときどき入力システムを使うことができなくなることが知られています。そのような場合は、数秒間待機すると入力できるようになることがあります。

別の X サーバーでゲームを起動する

上記のような場合だと、別の X サーバーを実行するのが必要もしくは望ましいかもしれません。二番目の X サーバーを実行することには複数の利点が存在します。より良いパフォーマンス、Ctrl+Alt+F7/Ctrl+Alt+F8 を使ってゲームを"最小化"することができる、ゲームがグラフィックドライバーと問題を起こしてもメインの X サーバーはクラッシュしないなどです。新しい X サーバーは ALSA へのリモートアクセスログインと同じく、ユーザーは音声を聞くために audio グループに入っている必要があります。

別の X サーバーを起動するには次のようにします (例として Xonotic を使っています): 

$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR

さらに、別の X 設定ファイルを使うことでちょっとしたスパイスを振りかけることができます: 

$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR

別の xorg.conf を使う理由としては、メインの設定では、NVIDIA の Twinview を使って Xonotic のような 3D ゲームをマルチスクリーンの中央、全ての画面にまたがって、レンダリングしているのが考えられます。これが望ましくない場合は、二番目の X を起動してセカンドスクリーンを無効にした設定を使うようにするというのが良いでしょう。

Openbox を利用してホームディレクトリや /usr/local/bin でゲームを起動するスクリプトは以下のようになります: 

~/game.sh
if [ $# -ge 1 ]; then
        game="$(which $1)"
        openbox="$(which openbox)"
        tmpgame="/tmp/tmpgame.sh"
        DISPLAY=:1.0
        echo -e "${openbox} &\n${game}" > ${tmpgame}
        echo "starting ${game}"
        xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1
else
        echo "not a valid argument"
fi

chmod +x したら、次のようにしてスクリプトを使うことが可能です: 

$ ~/game.sh xonotic-glx

マウス検出の調整

マウスの素早い操作が鍵を握るゲームの場合、マウスのポーリングレートを調整することで精度を上げられます。

OpenAL とバイノーラル音声

OpenAL を使っているゲームでは、ヘッドフォンを使用している場合、OpenAL の HRTF フィルターを使ってより良いポジショナルオーディオを得ることができます。有効にするには、次のコマンドを実行して下さい: 

echo "hrtf = true" >> ~/.alsoftrc

または、AUR から openal-hrtfAUR をインストールして、/etc/openal/alsoftrc.conf のオプションを編集して下さい。

Source エンジンのゲームの場合、HRTF を有効にするにはゲーム内設定の `dsp_slow_cpu` を `1` に設定します。設定しなかった場合は代わりに自前の処理がゲームによって有効にされます。また、ネイティブランタイムを使うように Steam を設定するか、または openal.so のネイティブランタイムのコピーをローカルコピーにリンクさせる必要があります。完全性のために、以下のオプションを使って下さい: 

dsp_slow_cpu 1 # Disable in-game spatialiazation
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it doesn't interfere with your perception of the sound effects.
snd_pitchquality 1 # Use high quality sounds

Pulseaudio の調整

PulseAudio を使っている場合、最適な動作をさせるためにデフォルト設定から変更することができる部分がいくつかあります。

realtime プライオリティと負の nice レベルを有効にする

Pulseaudio はオーディオデーモンとしてリアルタイムの優先度で実行されるようにビルドされます。しかしながら、システムがロックアップする可能性があるというセキュリティ上のリスクのため、デフォルトでは標準のスレッドと同じようにスケジューリングされます。これを変更するには、まずユーザーを audio グループに追加してください。そして、/etc/pulse/daemon.conf の以下の行をアンコメント・編集してください: 

high-priority = yes
nice-level = -11

realtime-scheduling = yes
realtime-priority = 5

編集したら pulseaudio を再起動します。

高品質なリミックスを使ってサウンドを良くする

Arch の Pulseaudio ではリミックスチャンネルにデフォルトで speex-float-0 を使っていますが、これはやや低品質なリミックスとされています。あなたのシステムに負担を増やす余裕がある場合は、以下の設定をすることでサウンドを良くすることが可能です: 

resample-method = speex-float-10

ハードウェアバッファを Pulse のバッファリングに合わせる

バッファをあわせることで音の途切れを減らし、ほんの僅かですがパフォーマンスを向上させることができます。詳しくは ここ を見て下さい。

Cgroups

Cgroups はプロセスをグループでまとめてユーザースペースで優先順位を付けて、レイテンシーを最小限にすることができるカーネルのアジャストメントです。IO の優先順位や CPU の優先順位など、複数のファクターを調整することができます。Systemd は Cgroups を暗示的に管理することができ、多数のスレッドが実行しているシステムをスムーズに動作させます。systemd をインストールするだけでこの動作の改善が行われます。

CPU 周波数スケーリングの設定を確かめる

適切な cpu 周波数スケーリングドライバーを使うように正しく設定されている場合、システムはデフォルトの governor を Ondemand に設定します。デフォルトでは、この governor はシステムが CPU の 95% を利用しているときのみ、非常に短い時間だけ、クロックを変更します。この設定では、電力が節約され熱が少なめですむ代わりに、パフォーマンスにかなり影響を与えることになります。システムの governor をチューニングすることで、ダウンクロックするのをアイドル状態の時だけに限ることが可能です。詳しくは Cpufrequtils#ondemand governor を調整するを参照。

パフォーマンスを向上させる

メインの記事も参照してください: パフォーマンスの最大化。Wine プログラムに関しては、Wine#パフォーマンス を見てください。素晴らしいゲーミング体験のためには、低遅延、安定した応答時間 (変動がない)、十分なスループット (FPS) が必要です。 小さな変動のある源が複数存在すると、それらが時々重なり合って、顕著なカクつきを生み出してしまうでしょう。ゆえに、ほとんどの場合、スループットを少し下げて、応答時間の安定性を増やすことが推奨されます。

clock_gettime のスループットを改善する

ユーザ空間のプログラム (特にゲーム) は、現在の時刻を取得する clock_gettime(2) をたくさん呼び出して、ゲームの物理演算や fps の計算などを行います。時間の使用頻度は以下を実行することで確認できます: 

# perf top

read_hept (または acpi_pm_read) のオーバーヘッドを見てください。

あなたが非常に正確なタイマーを必要としていないならば、hpet (high precision event timer) や acpi_pm (ACPI Power Management Timer) から、より高速な TSC (time stamp counter) タイマーに切り替えることができます。以下のカーネルパラメータを追加することで、TSC を利用可能にし有効化してください: 

tsc=reliable clocksource=tsc

その後、再起動し、以下を実行して clocksource を確認してください: 

# cat /sys/devices/system/clocksource/clocksource*/current_clocksource

以下を実行すれば、現在利用可能なタイマーすべてを確認できます: 

# cat /sys/devices/system/clocksource/clocksource*/available_clocksource

そして、current_clocksource にタイマー名を echo し (つまり、書き込んで)、タイマーを変更してください。Zen 3 システムにおける [1] のベンチマークでは、hpet や acpi_pm と比べて tsc のスループットのほうが約50倍良くなっています。

Tweaking kernel parameters for response time consistency

You can install the realtime kernel to get very good response time consistency out of the box at the price of quite some CPU throughput loss. Additionally the realtime kernel is not compatible with nvidia-open-dkms and does not change the scheduler for SCHED_NORMAL (also named SCHED_OTHER) processes, which is the default process scheduling type. The following kernel parameter changes improve the response time consistency for the realtime kernel even further, as well as other kernels such as the default linux kernel:

Disable proactive compaction because it introduces jitter according to kernel documentation: 

# echo 0 > /proc/sys/vm/compaction_proactiveness

If you have enough free RAM increase the number of minimum free Kilobytes to avoid stalls on memory allocations: [2][3]. Do not set this below 1024 KB or above 5% of your systems memory. Reserving 1GB: 

# echo 1048576 > /proc/sys/vm/min_free_kbytes

Avoid swapping (locking pages that introduces latency and uses disk IO) unless the system has no more free memory: 

# echo 10 > /proc/sys/vm/swappiness

Disable zone reclaim (locking and moving memory pages that introduces latency spikes): 

# echo 0 > /proc/sys/vm/zone_reclaim_mode

Disable Transparent Hugepages (THP). Even if defragmentation is disabled, THPs might introduce latency spikes. [4][5] 

# echo never > /sys/kernel/mm/transparent_hugepage/enabled
# echo never > /sys/kernel/mm/transparent_hugepage/shmem_enabled
# echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

Note that if your game uses TCMalloc (e.g., Dota 2 and CS:GO) then it is not recommended to disable THP as it comes with a large performance cost. [6]

Reduce the maximum page lock acquisition latency while retaining adequate throughput [7][8][9]: 

# echo 1 > /proc/sys/vm/page_lock_unfairness

Tweak the scheduler settings. The following scheduler settings are in conflict with cfs-zen-tweaksAUR so for each setting choose only one provider. By default the linux kernel scheduler is optimized for throughput and not latency. The following hand-made settings change that and are tested with different games to be a noticeable improvement. They might not be optimal for your use case; consider modifying them as necessary [10][11]: 

# echo 0 > /proc/sys/kernel/sched_child_runs_first
# echo 1 > /proc/sys/kernel/sched_autogroup_enabled
# echo 500 > /proc/sys/kernel/sched_cfs_bandwidth_slice_us
# echo 1000000 > /sys/kernel/debug/sched/latency_ns
# echo 500000 > /sys/kernel/debug/sched/migration_cost_ns
# echo 500000 > /sys/kernel/debug/sched/min_granularity_ns
# echo 0 > /sys/kernel/debug/sched/wakeup_granularity_ns
# echo 8 > /sys/kernel/debug/sched/nr_migrate

Make the changes permanent

Usually, the advice for permanently setting kernel parameters is to configure create a sysctl configuration file or change your boot loader options. However, since our change span both procfs (/proc, containing sysctl) and sysfs (/sys), the most convenient way is to use systemd-tmpfiles: 

/etc/tmpfiles.d/consistent-response-time-for-gaming.conf
#    Path                  Mode UID  GID  Age Argument
w /proc/sys/vm/compaction_proactiveness - - - - 0
w /proc/sys/vm/min_free_kbytes - - - - 1048576
w /proc/sys/vm/swappiness - - - - 10
w /proc/sys/vm/zone_reclaim_mode - - - - 0
w /sys/kernel/mm/transparent_hugepage/enabled - - - - never
w /sys/kernel/mm/transparent_hugepage/shmem_enabled - - - - never
w /sys/kernel/mm/transparent_hugepage/khugepaged/defrag - - - - 0
w /proc/sys/vm/page_lock_unfairness - - - - 1
w /proc/sys/kernel/sched_child_runs_first - - - - 0
w /proc/sys/kernel/sched_autogroup_enabled - - - - 1
w /proc/sys/kernel/sched_cfs_bandwidth_slice_us - - - - 500
w /sys/kernel/debug/sched/latency_ns  - - - - 1000000
w /sys/kernel/debug/sched/migration_cost_ns - - - - 500000
w /sys/kernel/debug/sched/min_granularity_ns - - - - 500000
w /sys/kernel/debug/sched/wakeup_granularity_ns  - - - - 0
w /sys/kernel/debug/sched/nr_migrate - - - - 8

After that reboot and see if the values applied correctly.

共有オブジェクトを即座に読み込んで初回の遅延を減らす

使用するゲームに対して以下の環境変数を設定してください: 

LD_BIND_NOW=1

これにより、プログラムコードを実行時に読み込む必要性がなくなり (ld.so(8) を参照)、関数が初めて呼ばれたときの遅延をなくします。システム上に実際には存在せず決して呼ばれないライブラリにリンクしている startplasma-x11 やその他のプログラムに対してこの変数を設定しないでください。この場合、プログラムは起動時に存在しない共有オブジェクトにリンクしようとして失敗するので、問題の特定は簡単です。ほとんどのゲームはこの変数を有効化した状態で問題なく起動するはずです。

ユーティリティ

Gamemode

Gamemode は、ゲームがホスト OS に最適化のセットを一時的に適用するように要求できるようにする、Linux 用のデーモン/ライブラリの組です。これによりゲームのパフォーマンスを向上できます。

ACO コンパイラ

ノート: 以下の方法は、AMDGPU ドライバを動作させている AMD GPU でしか動作しません。

AMDGPU#ACO コンパイラ を参照。

fsync パッチ

Steam#Fsync パッチ を参照。

DRI の遅延を軽減する

Direct Rendering Infrastructure (DRI) の設定ファイルは、Mesa と Nouveau を含むすべての DRI ドライバに適用されます。/etc/drirc を編集することで DRI の設定をシステム全体に対して変更することができますし、$HOME/.drirc を編集すればユーザ単位で変更できます。これらのファイルが存在しない場合、まず作成する必要があります。両方のファイルは同じ構文を使用します。オプションに関するドキュメントは https://dri.freedesktop.org/wiki/ConfigurationOptions/ で見られます。vblank との同期を無効化することで入力の遅延を減らすには、以下を追加してください: 

<driconf>
   <device>
       <application name="Default">
           <option name="vblank_mode" value="0" />
       </application>
   </device>
</driconf>

スケジューリングポリシーによってフレームレートやレスポンスを改善する

カーネルがタスクを優先順位付けできるように適切なスケジューリングポリシーを与えれば、ほとんどのゲームにおいて利益を得られます。これらのポリシーは、理想的にはアプリケーション自体によってスレッドごとに設定されるべきです。

アプリケーション自体がスケジューリングポリシーを実装していない場合、schedtool というアプリケーションとそれに関連するデーモンの schedtooldAUR を使えば、これらのタスクの多くを自動的に処理できます。

どのプログラムがどのポリシーを使用するかを編集するには、/etc/schedtoold.conf を編集し、プログラム名の後に必要な schedtool 引数を追加してください。

ポリシー

SCHED_ISO (-pf や -ck カーネルで使用されている BFS/MuQSSPDS スケジューラでのみ実装されています) は、プロセスが CPU の最大80%まで使用できるようになるだけでなく、できるかぎり遅延とスタッタリングを減らすことにつながります。全てではなくとも多くのゲームで効果が得られます: 

bit.trip.runner -I

SCHED_FIFO は、より良く機能する代替を提供します。あなたのアプリケーションが SCHED_FIFO でよりスムーズに動作するかを確認してみるべきでしょう。スムーズに動作する場合は、SCHED_FIFO を代わりに使用すべきです。とはいえ、SCHED_FIFO はシステムのリソースを枯渇させるリスクがあるので、注意してください。以下のよな -I が使用されるケースでこれを使用します: 

bit.trip.runner -F -p 15

Nice レベル

次に、先に処理させる必要があるタスクを昇順に nice レベルを設定します。ゲームなど、マルチメディアのタスクは基本的に nice レベルを -4 にすることが推奨されています: 

bit.trip.runner -n -4

コアアフィニティ

ドライバーがマルチスレッドするべきか、あるいはプログラムがマルチスレッドするべきかは、開発において多少の混乱が存在します。ドライバとプログラムの両方に同時にマルチスレッドさせてしまうと、フレームレートの低下などの大幅なパフォーマンスの劣化が発生し、クラッシュのリスクを増加させてしまいます。

最近のゲームや、GLSL を無効にしないで実行される Wine プログラムなどがこの例に含まれます。単一のコアを選択して、ドライバーだけがプロセスを管理できるようにするには、-a 0x# フラグを使います。# はコアの番号に置き換えて下さい。例えば、1番目のコアを使うには: 

bit.trip.runner -a 0x1

CPU にはハイパースレッディングによって 2 または 4 のコアしか存在しないのに 4 あるいは 8 もコアがあるように認識されることがあります。その場合、仮想コア 0101 (1 と 3) を使うには: 

bit.trip.runner -a 0x5

一般的なケース

高いフレームレートと低遅延を必要とするほとんどのゲームでは、上記のフラグを全て使うのが一番良い結果になります。ただし、アフィニティはプログラムごとに確認してください。ほとんどのネイティブゲームは正しい使い方を理解しています。一般的なケースのフラグ例: 

bit.trip.runner -I -n -4
Amnesia.bin64 -I -n -4
hl2.exe -I -n -4 -a 0x1 #GLSL が有効化された状態の Wine

Optimus やその他の便利なプログラム

一般的に、ゲームが動作するのに必要なプロセスはゲーム自体のプロセスよりも上のレベルに renice されるべきです。奇妙なことに、Wine には reverse scheduling という既知の問題が存在し、重要なプロセスに nice レベルが高く設定されることがあります。そこで、スケジューリングポリシーを設定すると動作が改善します。Wineserver も CPU 全体を消費することはあまりなく、必要なときは優先度を高くする必要があるので、無条件で SCHED_FIFO を設定したほうが良いでしょう。 

optirun -I -n -5
wineserver -F -p 20 -n 19
steam.exe -I -n -5

別のカーネルの使用

ノート: Linux-ck を使用していると、全体的なフレームレートは向上しつつも、フレームレートが安定しなかったり他のパフォーマンスに問題が起こったりするということを多数のユーザーが報告しています。それでも BFQ を使ってみたい場合は BFS スケジューラを無効にして Linux-ck をコンパイルしてみると良いかもしれません。

標準の Arch カーネルは一般的な使用のためのベースラインとしては十分です。しかしながら、あなたのコンピュータに搭載されたコアが16未満で、主にワークステーションとして使っている場合、バッチ処理のスループットを多少犠牲にして Linux-ck を使用することで大幅なレスポンスの向上を得ることができます。自分でカーネルをコンパイルしたくないのならば、Repo-ck を追加して、このリポジトリに入っているカーネルを使うこともできます。事前に最適化済みのカーネルを使用することは、結果として生じる可能性のあるスループットのロスとの相殺に必ずなるので、あなたが使っているアーキテクチャに相応しいカーネルを選択するようにしてください。

BFQ を使う

BFQ は linux-zen や Linux-ck に付属している io スケジューラであり、シンプルになるように最適化されており、サーバー以外のワークロードに対してよりよい応答性とスループットを実現します。有効にするには、Linux-ck#BFQ I/O スケジューラを有効にする方法を見て下さい。多くのガイドでは SSD には noop や deadline を使うことが推奨されていますが、複数のスレッドがデバイスにアクセスしようとしたときに応答性に悪影響を及ぼすことがあるので注意してください。スループットのアドバンテージがどうしても必要というわけでもない限り bfq を使用するのがベストです。

周辺機器

マウス

マウスのアクセラレーションを設定して、マウスをより正確にコントロールできるようにすると良いかもしれません。

マウスに4つ以上のボタンが付いている場合、マウスボタン を参照すると良いかもしれません。

ゲーミングマウス (特に Logitech と Steelseries) を使用している場合、piper を使ってマウスの DPI、LED などを設定すると良いかもしれません。サポートされているデバイスの完全なリストはこのページを見てください。logitech デバイスだけの場合は solaar もあります。

LED

openrgbAUR を使ってマザーボードや RAM の点灯を変更できます。

参照

  • [12] - reddit.com 上の Linux ゲーミングに関するフォーラム。サブページ: Wiki, FAQ。
  • Linux Gaming Guide - Linux ゲーミングのエクスペリエンスの最適化に関するテクニック集
「https://wiki.archlinux.jp/index.php?title=ゲーム&oldid=28803」から取得