games-on-whales/wolf
1
0
Fork 0
mirror of https://github.com/games-on-whales/wolf.git synced 2026-10-15 21:12:08 +00:00
Code Issues 119 Projects Packages Wiki Activity

[GH-ISSUE #365] 16 virtual joypads are getting spawned for a one real #247

New issue
Closed
opened 2026-10-15 12:58:42 +00:00 by bsakaguchi · 6 comments
bsakaguchi commented 2026-10-15 12:58:42 +00:00
Owner
Copy link

Originally created by @superpositionedpixel on GitHub (Mar 5, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/365

To begin with: the package itself is amazing and it works really good!

And the problem is the following: I have a one physically attached gamepad which is a DS4, and it's displayed as /dev/input/js0 in the host system.

But when I connect to the Wolf container using a Moonlight, the container logs are getting filled with a

wolf-1  | 20:15:26.505332151 INFO  | [DOCKER] Starting container: /Wolf-UI_7827191080123364297
wolf-1  | 20:15:26.608173119 INFO  | Creating PS joypad for controller 0
wolf-1  | 20:15:26.659333149 INFO  | Requesting accelerometer events for controller 0
wolf-1  | 20:15:26.659393572 INFO  | Requesting gyroscope events for controller 0
wolf-1  | 20:15:27.229895199 INFO  | Creating PS joypad for controller 1
wolf-1  | 20:15:27.281299457 INFO  | Requesting accelerometer events for controller 1
wolf-1  | 20:15:27.281359420 INFO  | Requesting gyroscope events for controller 1
wolf-1  | 20:15:27.531018977 INFO  | Creating PS joypad for controller 2
wolf-1  | 20:15:27.582742855 INFO  | Requesting accelerometer events for controller 2
wolf-1  | 20:15:27.582808788 INFO  | Requesting gyroscope events for controller 2
wolf-1  | 20:15:27.780145927 INFO  | Creating PS joypad for controller 3
wolf-1  | 20:15:27.831494891 INFO  | Requesting accelerometer events for controller 3
wolf-1  | 20:15:27.831548041 INFO  | Requesting gyroscope events for controller 3
wolf-1  | 20:15:28.095154738 INFO  | Creating PS joypad for controller 4
wolf-1  | 20:15:28.147300917 INFO  | Requesting accelerometer events for controller 4
wolf-1  | 20:15:28.147349338 INFO  | Requesting gyroscope events for controller 4
wolf-1  | 20:15:28.322059252 INFO  | Creating PS joypad for controller 5
wolf-1  | 20:15:28.373981982 INFO  | Requesting accelerometer events for controller 5
wolf-1  | 20:15:28.374035833 INFO  | Requesting gyroscope events for controller 5
wolf-1  | 20:15:28.540299311 INFO  | Creating PS joypad for controller 6
wolf-1  | 20:15:28.591916318 INFO  | Requesting accelerometer events for controller 6
wolf-1  | 20:15:28.591955241 INFO  | Requesting gyroscope events for controller 6
wolf-1  | 20:15:28.883126408 INFO  | Creating PS joypad for controller 7
wolf-1  | 20:15:28.934733697 INFO  | Requesting accelerometer events for controller 7
wolf-1  | 20:15:28.934788540 INFO  | Requesting gyroscope events for controller 7
wolf-1  | 20:15:29.098435411 INFO  | Creating PS joypad for controller 8
wolf-1  | 20:15:29.149871439 INFO  | Requesting accelerometer events for controller 8
wolf-1  | 20:15:29.149911494 INFO  | Requesting gyroscope events for controller 8
wolf-1  | 20:15:29.328881635 INFO  | Creating PS joypad for controller 9
wolf-1  | 20:15:29.381102995 INFO  | Requesting accelerometer events for controller 9
wolf-1  | 20:15:29.381185239 INFO  | Requesting gyroscope events for controller 9
wolf-1  | 20:15:29.671221879 INFO  | Creating PS joypad for controller 10
wolf-1  | 20:15:29.722735171 INFO  | Requesting accelerometer events for controller 10
wolf-1  | 20:15:29.722780266 INFO  | Requesting gyroscope events for controller 10
wolf-1  | 20:15:29.725913891 INFO  | Creating PS joypad for controller 11
wolf-1  | 20:15:29.778163935 INFO  | Requesting accelerometer events for controller 11
wolf-1  | 20:15:29.778240488 INFO  | Requesting gyroscope events for controller 11
wolf-1  | 20:15:29.933096819 INFO  | Creating PS joypad for controller 12
wolf-1  | 20:15:29.985026622 INFO  | Requesting accelerometer events for controller 12
wolf-1  | 20:15:29.985071616 INFO  | Requesting gyroscope events for controller 12
wolf-1  | 20:15:30.301613019 INFO  | Creating PS joypad for controller 13
wolf-1  | 20:15:30.353600450 INFO  | Requesting accelerometer events for controller 13
wolf-1  | 20:15:30.353635496 INFO  | Requesting gyroscope events for controller 13
wolf-1  | 20:15:30.656476943 INFO  | Creating PS joypad for controller 14
wolf-1  | 20:15:30.708831873 INFO  | Requesting accelerometer events for controller 14
wolf-1  | 20:15:30.708896023 INFO  | Requesting gyroscope events for controller 14
wolf-1  | 20:15:30.885553949 INFO  | Creating PS joypad for controller 15
wolf-1  | 20:15:30.938178044 INFO  | Requesting accelerometer events for controller 15
wolf-1  | 20:15:30.938229641 INFO  | Requesting gyroscope events for controller 15
wolf-1  | 20:15:42.711886316 INFO  | [LOBBY] Creating new lobby

That wouldn't be much a problem, but... Every "virtual" joypad gets an input from the real one: that's where problems begin :)
I'm using a Wolf+Moonlight to play a game which has local co-op, not the online one. We connect to the same session from two different devices, I'm from the LAN and other person from the Internet in order to play

I've tried to look for a related problems both in a Moonlight's repo and Wolf's repo, but didn't find anything similar.

Gamepad is connected over a bluetooth, wired (USB) connection leads to the same behaviour.
The thing with the udev rules doesn't change this at all from what I'm seeing.

The only thing that helps to actually play is the following:

  1. make sure to check a "force a #1 gamepad always connected" in the Moonlight's settings
  2. connect to the container, it maps as a single gamepad (logs are not getting filled with many of them)
  3. connect a gamepad to do a single action and reconnect it again several times: for some reason only a single action is passed from a real gamepad in this case. This step is used to connect as a single "player" to the ingame lobby, not the four players at the same time
  4. quit session without getting a container/session with a game actually closed
  5. remove that "force #1 gamepad" check from the settings
  6. log in again with these 16 gamepads and start to play with no issues

OS and kernel is

Kernel: 6.18.12-1-MANJARO arch: x86_64 bits: 64
Desktop: Xfce v: 4.20.1 Distro: Manjaro Linux

Also I've tried both a moonlight-qt package and the flatpak-ed one, both of them behave the same way.

I'm really looking forward to even nearly get to what's causing this actually.

Thanks for help in advance!

Originally created by @superpositionedpixel on GitHub (Mar 5, 2026). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/365 To begin with: the package itself is amazing and it works really good! And the problem is the following: I have a one physically attached gamepad which is a DS4, and it's displayed as `/dev/input/js0` in the host system. But when I connect to the Wolf container using a Moonlight, the container logs are getting filled with a ``` wolf-1 | 20:15:26.505332151 INFO | [DOCKER] Starting container: /Wolf-UI_7827191080123364297 wolf-1 | 20:15:26.608173119 INFO | Creating PS joypad for controller 0 wolf-1 | 20:15:26.659333149 INFO | Requesting accelerometer events for controller 0 wolf-1 | 20:15:26.659393572 INFO | Requesting gyroscope events for controller 0 wolf-1 | 20:15:27.229895199 INFO | Creating PS joypad for controller 1 wolf-1 | 20:15:27.281299457 INFO | Requesting accelerometer events for controller 1 wolf-1 | 20:15:27.281359420 INFO | Requesting gyroscope events for controller 1 wolf-1 | 20:15:27.531018977 INFO | Creating PS joypad for controller 2 wolf-1 | 20:15:27.582742855 INFO | Requesting accelerometer events for controller 2 wolf-1 | 20:15:27.582808788 INFO | Requesting gyroscope events for controller 2 wolf-1 | 20:15:27.780145927 INFO | Creating PS joypad for controller 3 wolf-1 | 20:15:27.831494891 INFO | Requesting accelerometer events for controller 3 wolf-1 | 20:15:27.831548041 INFO | Requesting gyroscope events for controller 3 wolf-1 | 20:15:28.095154738 INFO | Creating PS joypad for controller 4 wolf-1 | 20:15:28.147300917 INFO | Requesting accelerometer events for controller 4 wolf-1 | 20:15:28.147349338 INFO | Requesting gyroscope events for controller 4 wolf-1 | 20:15:28.322059252 INFO | Creating PS joypad for controller 5 wolf-1 | 20:15:28.373981982 INFO | Requesting accelerometer events for controller 5 wolf-1 | 20:15:28.374035833 INFO | Requesting gyroscope events for controller 5 wolf-1 | 20:15:28.540299311 INFO | Creating PS joypad for controller 6 wolf-1 | 20:15:28.591916318 INFO | Requesting accelerometer events for controller 6 wolf-1 | 20:15:28.591955241 INFO | Requesting gyroscope events for controller 6 wolf-1 | 20:15:28.883126408 INFO | Creating PS joypad for controller 7 wolf-1 | 20:15:28.934733697 INFO | Requesting accelerometer events for controller 7 wolf-1 | 20:15:28.934788540 INFO | Requesting gyroscope events for controller 7 wolf-1 | 20:15:29.098435411 INFO | Creating PS joypad for controller 8 wolf-1 | 20:15:29.149871439 INFO | Requesting accelerometer events for controller 8 wolf-1 | 20:15:29.149911494 INFO | Requesting gyroscope events for controller 8 wolf-1 | 20:15:29.328881635 INFO | Creating PS joypad for controller 9 wolf-1 | 20:15:29.381102995 INFO | Requesting accelerometer events for controller 9 wolf-1 | 20:15:29.381185239 INFO | Requesting gyroscope events for controller 9 wolf-1 | 20:15:29.671221879 INFO | Creating PS joypad for controller 10 wolf-1 | 20:15:29.722735171 INFO | Requesting accelerometer events for controller 10 wolf-1 | 20:15:29.722780266 INFO | Requesting gyroscope events for controller 10 wolf-1 | 20:15:29.725913891 INFO | Creating PS joypad for controller 11 wolf-1 | 20:15:29.778163935 INFO | Requesting accelerometer events for controller 11 wolf-1 | 20:15:29.778240488 INFO | Requesting gyroscope events for controller 11 wolf-1 | 20:15:29.933096819 INFO | Creating PS joypad for controller 12 wolf-1 | 20:15:29.985026622 INFO | Requesting accelerometer events for controller 12 wolf-1 | 20:15:29.985071616 INFO | Requesting gyroscope events for controller 12 wolf-1 | 20:15:30.301613019 INFO | Creating PS joypad for controller 13 wolf-1 | 20:15:30.353600450 INFO | Requesting accelerometer events for controller 13 wolf-1 | 20:15:30.353635496 INFO | Requesting gyroscope events for controller 13 wolf-1 | 20:15:30.656476943 INFO | Creating PS joypad for controller 14 wolf-1 | 20:15:30.708831873 INFO | Requesting accelerometer events for controller 14 wolf-1 | 20:15:30.708896023 INFO | Requesting gyroscope events for controller 14 wolf-1 | 20:15:30.885553949 INFO | Creating PS joypad for controller 15 wolf-1 | 20:15:30.938178044 INFO | Requesting accelerometer events for controller 15 wolf-1 | 20:15:30.938229641 INFO | Requesting gyroscope events for controller 15 wolf-1 | 20:15:42.711886316 INFO | [LOBBY] Creating new lobby ``` That wouldn't be much a problem, but... Every "virtual" joypad gets an input from the real one: that's where problems begin :) I'm using a Wolf+Moonlight to play a game which has local co-op, not the online one. We connect to the same session from two different devices, I'm from the LAN and other person from the Internet in order to play I've tried to look for a related problems both in a Moonlight's repo and Wolf's repo, but didn't find anything similar. Gamepad is connected over a bluetooth, wired (USB) connection leads to the same behaviour. The thing with the udev rules doesn't change this at all from what I'm seeing. The only thing that helps to actually play is the following: 1. make sure to check a "force a `#1` gamepad always connected" in the Moonlight's settings 2. connect to the container, it maps as a single gamepad (logs are not getting filled with many of them) 3. connect a gamepad to do a single action and reconnect it again several times: for some reason only a single action is passed from a real gamepad in this case. This step is used to connect as a single "player" to the ingame lobby, not the four players at the same time 4. quit session without getting a container/session with a game actually closed 5. remove that "force `#1` gamepad" check from the settings 6. log in again with these 16 gamepads and start to play with no issues OS and kernel is ``` Kernel: 6.18.12-1-MANJARO arch: x86_64 bits: 64 Desktop: Xfce v: 4.20.1 Distro: Manjaro Linux ``` Also I've tried both a `moonlight-qt` package and the flatpak-ed one, both of them behave the same way. I'm really looking forward to even nearly get to what's causing this actually. Thanks for help in advance!
bsakaguchi commented 2026-10-15 12:58:44 +00:00
Author
Owner
Copy link

@aritanah commented on GitHub (Mar 6, 2026):

Hello, I was having this exact same problem and I find it funny that I’ve never seen anyone talking about it before. It becomes very problematic when you want to play while using the host PC.

The only thing that works for me was launching Moonlight with the following variable:

SDL_GAMECONTROLLER_IGNORE_DEVICES=0x054c/0x0ce6,0x045e/0x02ea

Where 0x054c/0x0ce6 is the ID of the virtual DS4 controller created by Moonlight and 0x045e/0x02ea is the ID of the virtual XBOX controller. This prevents it from creating duplicate devices, but for some reason Moonlight will still detect the device connected via USB and will only create a single virtual device.

This works perfectly if you also replace the default joystick mapping in the specific Wolf session inside the TOML file with XBOX like this:

[paired_clients.settings]
controllers_override = [ 'XBOX' ]

I did this for all paired clients because, for some reason, several games were not working correctly with the default mapping of my DS4.

I should also mention that I’m using Moonlight in the latest AppImage version, so to automate the process I created this shortcut for it:

[Desktop Entry]
Name=Moonlight
Comment=Stream games and other applications from another PC running Sunshine or GeForce Experience
Exec=env SDL_GAMECONTROLLER_IGNORE_DEVICES=0x054c/0x0ce6,0x045e/0x02ea /PATH TO THE APPIMAGE/Moonlight-6.1.0-x86_64.AppImage
Icon=PATH TO THE ICON
Terminal=false
Type=Application
Categories=Qt;Game;
Keywords=nvidia;gamestream;stream;sunshine;remote play;
X-AppImage-Version=6.1.0

I know this is more of a workaround, but it would be great if this could eventually be fixed.

<!-- gh-comment-id:4013495480 --> @aritanah commented on GitHub (Mar 6, 2026): Hello, I was having this exact same problem and I find it funny that I’ve never seen anyone talking about it before. It becomes very problematic when you want to play while using the host PC. The only thing that works for me was launching Moonlight with the following variable: ``` SDL_GAMECONTROLLER_IGNORE_DEVICES=0x054c/0x0ce6,0x045e/0x02ea ``` Where `0x054c/0x0ce6` is the ID of the virtual DS4 controller created by Moonlight and `0x045e/0x02ea` is the ID of the virtual XBOX controller. This prevents it from creating duplicate devices, but for some reason Moonlight will still detect the device connected via USB and will only create a single virtual device. This works perfectly if you also replace the default joystick mapping in the specific Wolf session inside the TOML file with XBOX like this: ``` [paired_clients.settings] controllers_override = [ 'XBOX' ] ``` I did this for all paired clients because, for some reason, several games were not working correctly with the default mapping of my DS4. I should also mention that I’m using Moonlight in the latest AppImage version, so to automate the process I created this shortcut for it: ``` [Desktop Entry] Name=Moonlight Comment=Stream games and other applications from another PC running Sunshine or GeForce Experience Exec=env SDL_GAMECONTROLLER_IGNORE_DEVICES=0x054c/0x0ce6,0x045e/0x02ea /PATH TO THE APPIMAGE/Moonlight-6.1.0-x86_64.AppImage Icon=PATH TO THE ICON Terminal=false Type=Application Categories=Qt;Game; Keywords=nvidia;gamestream;stream;sunshine;remote play; X-AppImage-Version=6.1.0 ``` I know this is more of a workaround, but it would be great if this could eventually be fixed.
bsakaguchi commented 2026-10-15 12:58:44 +00:00
Author
Owner
Copy link

@Skerga commented on GitHub (Mar 6, 2026):

This is known and happens afaik if the udev rules aren't set up correctly, leading to the controller being passed to the host system. witch spawns a new virtual controller, which is passed to the host etc.

See here for udev rules:
https://games-on-whales.github.io/wolf/stable/user/quickstart.html#_virtual_devices_support

<!-- gh-comment-id:4013950630 --> @Skerga commented on GitHub (Mar 6, 2026): This is known and happens afaik if the udev rules aren't set up correctly, leading to the controller being passed to the host system. witch spawns a new virtual controller, which is passed to the host etc. See here for udev rules: https://games-on-whales.github.io/wolf/stable/user/quickstart.html#_virtual_devices_support
bsakaguchi commented 2026-10-15 12:58:44 +00:00
Author
Owner
Copy link

@aritanah commented on GitHub (Mar 6, 2026):

Isso é conhecido e acontece, pelo que sei, se as regras do udev não estiverem configuradas corretamente, levando ao controlador ser passado para o sistema host. Isso cria um novo controlador virtual, que é passado para o host, etc.

Veja aqui as regras do udev: https://games-on-whales.github.io/wolf/stable/user/quickstart.html#_virtual_devices_support

I had already set those udev rules, but just to be sure I checked them again. However, I still need to run Moonlight with the variable SDL_GAMECONTROLLER_IGNORE_DEVICES=0x054c/0x0ce6,0x045e/0x02ea to prevent Moonlight from creating duplicate devices. For some reason, those rules don’t seem to work for me.

I’m not sure how much this matters either, but here is the output of the groups command:

aritana lp cdrom floppy audio dip video plugdev input render netdev bluetooth scanner docker lpadmin gamemode

Just for reference, here are my OS and kernel:

Kernel: Linux 6.18.12+deb14-amd64
OS: Debian GNU/Linux forky/sid (forky) x86_64
<!-- gh-comment-id:4014801387 --> @aritanah commented on GitHub (Mar 6, 2026): > Isso é conhecido e acontece, pelo que sei, se as regras do udev não estiverem configuradas corretamente, levando ao controlador ser passado para o sistema host. Isso cria um novo controlador virtual, que é passado para o host, etc. > > Veja aqui as regras do udev: [https://games-on-whales.github.io/wolf/stable/user/quickstart.html#_virtual_devices_support ](https://games-on-whales.github.io/wolf/stable/user/quickstart.html#_virtual_devices_support) I had already set those udev rules, but just to be sure I checked them again. However, I still need to run Moonlight with the variable `SDL_GAMECONTROLLER_IGNORE_DEVICES=0x054c/0x0ce6,0x045e/0x02ea` to prevent Moonlight from creating duplicate devices. For some reason, those rules don’t seem to work for me. I’m not sure how much this matters either, but here is the output of the `groups` command: ``` aritana lp cdrom floppy audio dip video plugdev input render netdev bluetooth scanner docker lpadmin gamemode ``` Just for reference, here are my OS and kernel: ``` Kernel: Linux 6.18.12+deb14-amd64 OS: Debian GNU/Linux forky/sid (forky) x86_64
bsakaguchi commented 2026-10-15 12:58:44 +00:00
Author
Owner
Copy link

@superpositionedpixel commented on GitHub (Mar 7, 2026):

SDL_GAMECONTROLLER_IGNORE_DEVICES=0x054c/0x0ce6,0x045e/0x02ea

Wow!
That has actually solved the issue, thanks a lot!
It does make sense since the Moonlight attaches these virtual gamepads again and again to the session. I hadn't even thought that it could be possible. Looks like these virtual controllers getting passed to the host for real

Sadly, as I already mentioned, nothing is changed by adding or not adding these udev rules from the docs: local gamepad worked both with and without them along with this issue persisted in both ways. Only this env variable solved the issue

I dunno if I should close this. @aritanah provided a great workaroung-like solution, but there could also be more elegant udev-like or some other description/solution which prevents this container-to-host "leak" in general

Anyway, thank you two a lot again!

<!-- gh-comment-id:4016852044 --> @superpositionedpixel commented on GitHub (Mar 7, 2026): > SDL_GAMECONTROLLER_IGNORE_DEVICES=0x054c/0x0ce6,0x045e/0x02ea Wow! That has actually solved the issue, thanks a lot! It does make sense since the Moonlight attaches these virtual gamepads again and again to the session. I hadn't even thought that it could be possible. Looks like these virtual controllers getting passed to the host for real Sadly, as I already mentioned, nothing is changed by adding or not adding these udev rules from the docs: local gamepad worked both with and without them along with this issue persisted in both ways. Only this env variable solved the issue I dunno if I should close this. @aritanah provided a great workaroung-like solution, but there could also be more elegant udev-like or some other description/solution which prevents this container-to-host "leak" in general Anyway, thank you two a lot again!
bsakaguchi commented 2026-10-15 12:58:45 +00:00
Author
Owner
Copy link

@clsty commented on GitHub (Apr 29, 2026):

The document for udev rules has been updated in github.com/games-on-whales/wolf@eb46742182 , which means the correct udev rules should be:

github.com/games-on-whales/wolf@eb46742182/docs/modules/user/pages/quickstart.adoc (L722-L733)

Please try this if you'd like to. @superpositionedpixel @aritanah

The story is that, I've just switched from Debian 13 to NixOS and I tried the quickstart script by JBailes to generate a Nix file which gives me the udev rules from older document. After that I tried the latest Gamepad-UI container to find there're 12 gamepads indicated by the top bar (when I restarted it becomes 16, so maybe the number is somehow random).

And when I use the udev rules from the latest document, the number of gamepads becomes 1 as normal.

@HashimHS I guess that's also the cause for your gamepad counted as 2 when enabling SDL support for Gamepad-UI container. In that case, writing the correct udev rules in /etc/udev/rules.d/85-wolf-virtual-inputs.rules and then running sudo udevadm control --reload-rules && sudo udevadm trigger and then restarting Wolf should fix the problem.

<!-- gh-comment-id:4340352316 --> @clsty commented on GitHub (Apr 29, 2026): The document for udev rules has been updated in https://github.com/games-on-whales/wolf/commit/eb4674218284def75b40c9326684f214fa695a1c , which means the correct udev rules should be: https://github.com/games-on-whales/wolf/blob/eb4674218284def75b40c9326684f214fa695a1c/docs/modules/user/pages/quickstart.adoc?plain=1#L722-L733 Please try this if you'd like to. @superpositionedpixel @aritanah --- The story is that, I've just switched from Debian 13 to NixOS and I tried [the quickstart script by JBailes](https://github.com/JBailes/wolf/blob/26c9c164ba486b141738025adf6776511b1a9b38/quickstart/nixos.sh#L36-L42) to generate a Nix file which gives me [the udev rules from older document](https://github.com/JBailes/wolf/blob/26c9c164ba486b141738025adf6776511b1a9b38/quickstart/nixos.sh#L36-L42). After that I tried the latest [Gamepad-UI container](https://github.com/games-on-whales/gow/pull/293) to find there're 12 gamepads indicated by the top bar (when I restarted it becomes 16, so maybe the number is somehow random). And when I use the udev rules from the latest document, the number of gamepads becomes 1 as normal. @HashimHS I guess that's also the cause for [your gamepad counted as 2](https://github.com/games-on-whales/gow/pull/293#issuecomment-4173077979) when enabling SDL support for Gamepad-UI container. In that case, writing the correct udev rules in `/etc/udev/rules.d/85-wolf-virtual-inputs.rules` and then running `sudo udevadm control --reload-rules && sudo udevadm trigger` and then restarting Wolf should fix the problem.
bsakaguchi commented 2026-10-15 12:58:45 +00:00
Author
Owner
Copy link

@HashimHS commented on GitHub (Apr 29, 2026):

@clsty this could explain the issue, thanks! I will try out this solution.

<!-- gh-comment-id:4341562624 --> @HashimHS commented on GitHub (Apr 29, 2026): @clsty this could explain the issue, thanks! I will try out this solution.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
beta
feat/fedora-base-images
stable
axolotlitehotfix/randomly-generated-client-id
feat/vulkan-image
ci/image-smoke-harness
nv12-producer-pin
fix/nvidia-zero-copy
fix/amd-dma-buf-negotiation
fix/joypad-input-leak
codex/party-mode-split-render
ci-fedora-images
test/gst-wld-block-linear
fix/nvidia-blackwell-zero-copy
feat/embed-wolf-den
fix/fake-udev-write-db
fix/session-runner-user
fedora-dockerfile
feat/comprehensive-display-modes
aimee/quickstart-scripts
JBailes-patch-1
dev-nix
dev-fake-uinput
dev-tracy
fix/gst_vaapi
v2024.07
v2023.06
v2023.02
v2022.11
Labels
Clear labels   
🧠 1 - 🤖 999

   
AMD

   
bug

   
bug

   
cannot reproduce

   
documentation

   
duplicate

   
easy

   
enhancement

   
enhancement

   
enhancement

   
fixed?

   
fixed?

   
good first issue

   
hard

   
help wanted

   
Intel

   
invalid

   
LXC

   
medium

   
moonlight-protocol

   
Multi GPU

   
nixos

   
not a bug

   
nvidia

   
pull-request
Mirrored from GitHub Pull Request

  
question

   
wontfix
No labels
🧠 1 - 🤖 999
AMD
bug
bug
cannot reproduce
documentation
duplicate
easy
enhancement
enhancement
enhancement
fixed?
fixed?
good first issue
hard
help wanted
Intel
invalid
LXC
medium
moonlight-protocol
Multi GPU
nixos
not a bug
nvidia
pull-request
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
games-on-whales/wolf#247
No description provided.