[GH-ISSUE #193] Virtual Devices Created by Wolf breaking Isolation on Host System #127

New issue

Closed

opened 2026-10-15 12:56:50 +00:00 by bsakaguchi · 12 comments

bsakaguchi commented 2026-10-15 12:56:50 +00:00

Owner

Copy link

Originally created by @FtK259 on GitHub (Apr 7, 2025).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/193

Hi,

I recently noticed that the virtual devices generated by Wolf were affecting my host Linux system, breaking the expected isolation. Here is the info about the virtual joypad generated:

sudo udevadm info -a -p $(udevadm info -q path -n /dev/input/event256)

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/virtual/input/input82/event256':
    KERNEL=="event256"
    SUBSYSTEM=="input"
    DRIVER==""
    ATTR{power/control}=="auto"
    ATTR{power/runtime_active_time}=="0"
    ATTR{power/runtime_status}=="unsupported"
    ATTR{power/runtime_suspended_time}=="0"

  looking at parent device '/devices/virtual/input/input82':
    KERNELS=="input82"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{capabilities/abs}=="3003f"
    ATTRS{capabilities/ev}=="20000b"
    ATTRS{capabilities/ff}=="104870000 0"
    ATTRS{capabilities/key}=="7cdb000000000000 0 0 0 0"
    ATTRS{capabilities/led}=="0"
    ATTRS{capabilities/msc}=="0"
    ATTRS{capabilities/rel}=="0"
    ATTRS{capabilities/snd}=="0"
    ATTRS{capabilities/sw}=="0"
    ATTRS{id/bustype}=="0003"
    ATTRS{id/product}=="02ea"
    ATTRS{id/vendor}=="045e"
    ATTRS{id/version}=="0408"
    ATTRS{inhibited}=="0"
    ATTRS{name}=="Wolf X-Box One (virtual) pad"
    ATTRS{phys}==""
    ATTRS{power/control}=="auto"
    ATTRS{power/runtime_active_time}=="0"
    ATTRS{power/runtime_status}=="unsupported"
    ATTRS{power/runtime_suspended_time}=="0"
    ATTRS{properties}=="0"
    ATTRS{uniq}==""

I did add my user to group input, as the documentation ask for. Here is my /etc/udev/rules.d/85-wolf-virtual-inputs.rules file:

# Allows Wolf to acces /dev/uinput
KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput"

# Allows Wolf to access /dev/uhid
KERNEL=="uhid", TAG+="uaccess"

# Move virtual keyboard and mouse into a different seat
SUBSYSTEMS=="input", ATTRS{id/vendor}=="ab00", MODE="0660", GROUP="input", ENV{ID_SEAT}="seat9"

# Joypads
SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", GROUP="input"
SUBSYSTEMS=="input", ATTRS{name}=="Wolf PS5 (virtual) pad", MODE="0660", GROUP="input"
SUBSYSTEMS=="input", ATTRS{name}=="Wolf gamepad (virtual) motion sensors", MODE="0660", GROUP="input"
SUBSYSTEMS=="input", ATTRS{name}=="Wolf Nintendo (virtual) pad", MODE="0660", GROUP="input"

This breaks the input sandboxing and leads to unintended behavior. Is this a known issue? Is there something misconfigured on my setup?

Any guidance would be appreciated.

Originally created by @FtK259 on GitHub (Apr 7, 2025). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/193 Hi, I recently noticed that the virtual devices generated by Wolf were affecting my host Linux system, breaking the expected isolation. Here is the info about the virtual joypad generated: ```bash sudo udevadm info -a -p $(udevadm info -q path -n /dev/input/event256) Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device. looking at device '/devices/virtual/input/input82/event256': KERNEL=="event256" SUBSYSTEM=="input" DRIVER=="" ATTR{power/control}=="auto" ATTR{power/runtime_active_time}=="0" ATTR{power/runtime_status}=="unsupported" ATTR{power/runtime_suspended_time}=="0" looking at parent device '/devices/virtual/input/input82': KERNELS=="input82" SUBSYSTEMS=="input" DRIVERS=="" ATTRS{capabilities/abs}=="3003f" ATTRS{capabilities/ev}=="20000b" ATTRS{capabilities/ff}=="104870000 0" ATTRS{capabilities/key}=="7cdb000000000000 0 0 0 0" ATTRS{capabilities/led}=="0" ATTRS{capabilities/msc}=="0" ATTRS{capabilities/rel}=="0" ATTRS{capabilities/snd}=="0" ATTRS{capabilities/sw}=="0" ATTRS{id/bustype}=="0003" ATTRS{id/product}=="02ea" ATTRS{id/vendor}=="045e" ATTRS{id/version}=="0408" ATTRS{inhibited}=="0" ATTRS{name}=="Wolf X-Box One (virtual) pad" ATTRS{phys}=="" ATTRS{power/control}=="auto" ATTRS{power/runtime_active_time}=="0" ATTRS{power/runtime_status}=="unsupported" ATTRS{power/runtime_suspended_time}=="0" ATTRS{properties}=="0" ATTRS{uniq}=="" ``` I did add my user to group input, as the documentation ask for. Here is my /etc/udev/rules.d/85-wolf-virtual-inputs.rules file: ```bash # Allows Wolf to acces /dev/uinput KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput" # Allows Wolf to access /dev/uhid KERNEL=="uhid", TAG+="uaccess" # Move virtual keyboard and mouse into a different seat SUBSYSTEMS=="input", ATTRS{id/vendor}=="ab00", MODE="0660", GROUP="input", ENV{ID_SEAT}="seat9" # Joypads SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", GROUP="input" SUBSYSTEMS=="input", ATTRS{name}=="Wolf PS5 (virtual) pad", MODE="0660", GROUP="input" SUBSYSTEMS=="input", ATTRS{name}=="Wolf gamepad (virtual) motion sensors", MODE="0660", GROUP="input" SUBSYSTEMS=="input", ATTRS{name}=="Wolf Nintendo (virtual) pad", MODE="0660", GROUP="input" ``` This breaks the input sandboxing and leads to unintended behavior. Is this a known issue? Is there something misconfigured on my setup? Any guidance would be appreciated.

bsakaguchi 2026-10-15 12:56:50 +00:00

• closed this issue
• added the
  documentation
  label

bsakaguchi commented 2026-10-15 12:56:51 +00:00

Author

Owner

Copy link

@ABeltramo commented on GitHub (Apr 8, 2025):

Thanks for opening this, the docs are outdated on this front and I forgot to update them.

There should be no need anymore to add the user to the input group and we could try having a better isolation by changing the default group for those devices from input to root in the udev rules.

I'll have a play with a new set of rules on my system when I have a bit of free time and report back, it would be nice if you could test them too!

<!-- gh-comment-id:2787729520 --> @ABeltramo commented on GitHub (Apr 8, 2025): Thanks for opening this, the docs are outdated on this front and I forgot to update them. There should be no need anymore to add the user to the input group and we could try having a better isolation by changing the default group for those devices from `input` to `root` in the udev rules. I'll have a play with a new set of rules on my system when I have a bit of free time and report back, it would be nice if you could test them too!

bsakaguchi commented 2026-10-15 12:56:51 +00:00

Author

Owner

Copy link

@korotyshevnikita commented on GitHub (Apr 27, 2025):

There should be no need anymore to add the user to the input group and we could try having a better isolation by changing the default group for those devices from input to root in the udev rules.

Isolation of virtual devices is broken because the system changes the access control lists for controllers that use the same seat. Setting seat9 in udev rules fixes this (tested on Fedora Silverblue).

SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", GROUP="input"

$ getfacl -cp /dev/input/js0
user::rw-
user:korotyshev:rw-
group::rw-
mask::rw-
other::---

SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", ENV{ID_SEAT}="seat9"

$ getfacl -cp /dev/input/js0
user::rw-
group::rw-
other::---

<!-- gh-comment-id:2833305096 --> @korotyshevnikita commented on GitHub (Apr 27, 2025): > There should be no need anymore to add the user to the input group and we could try having a better isolation by changing the default group for those devices from `input` to `root` in the udev rules. Isolation of virtual devices is broken because the system changes the access control lists for controllers that use the same seat. Setting seat9 in udev rules fixes this (tested on Fedora Silverblue). SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", **GROUP="input"** > $ getfacl -cp /dev/input/js0 user::rw- **user:korotyshev:rw-** group::rw- mask::rw- other::--- SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", **ENV{ID_SEAT}="seat9"** > $ getfacl -cp /dev/input/js0 user::rw- group::rw- other::---

bsakaguchi commented 2026-10-15 12:56:52 +00:00

Author

Owner

Copy link

@ABeltramo commented on GitHub (Apr 27, 2025):

I'll have to test this myself, in theory changing the seat wouldn't change anything for non mouse/keyboard devices. So in this case I think you are just not assigning the input group and which result in just root being able to access it.

The problem is that if you have Steam installed on the host, it'll generally bundle up these additional rules: https://github.com/ValveSoftware/steam-devices/blob/master/60-steam-input.rules in order to access normal devices.
With those rules our devices will be user accessible, so we'll have to override that somehow; can we even -=uaccess? I have to look further into this..

<!-- gh-comment-id:2833322937 --> @ABeltramo commented on GitHub (Apr 27, 2025): I'll have to test this myself, in theory changing the seat wouldn't change anything for non mouse/keyboard devices. So in this case I think you are just not assigning the `input` group and which result in just `root` being able to access it. The problem is that if you have Steam installed on the host, it'll generally bundle up these additional rules: https://github.com/ValveSoftware/steam-devices/blob/master/60-steam-input.rules in order to access normal devices. With those rules our devices will be user accessible, so we'll have to override that somehow; can we even `-=uaccess`? I have to look further into this..

bsakaguchi commented 2026-10-15 12:56:52 +00:00

Author

Owner

Copy link

@korotyshevnikita commented on GitHub (Apr 27, 2025):

I think you are just not assigning the input group and which result in just root being able to access it.

If the seat in the desktop session matches the input device, the system will assign extended permissions to the individual user. Even if the owner and group are root, user will have separate 'rw-' access

<!-- gh-comment-id:2833327778 --> @korotyshevnikita commented on GitHub (Apr 27, 2025): > I think you are just not assigning the input group and which result in just root being able to access it. If the seat in the desktop session matches the input device, the system will assign extended permissions to the individual user. Even if the owner and group are root, user will have separate 'rw-' access

bsakaguchi commented 2026-10-15 12:56:52 +00:00

Author

Owner

Copy link

@MertsA commented on GitHub (Jun 6, 2025):

in theory changing the seat wouldn't change anything for non mouse/keyboard devices.

That's not how uaccess actually works. Here's the relevant udev builtin that sets the ACL for the currently logged in user. github.com/systemd/systemd@02927af799/src/udev/udev-builtin-uaccess.c (L108)

If you don't change the seat in udev then the device is going to get assigned to seat0. For any device with the uaccess tag udev will look up the uid for the active session on the corresponding seat and grant that user access to the device. You don't need to remove uaccess or change the group to input, just make sure all Wolf created devices get tagged for a non-existent seat and udev will not find a session for them.

<!-- gh-comment-id:2950747278 --> @MertsA commented on GitHub (Jun 6, 2025): > in theory changing the seat wouldn't change anything for non mouse/keyboard devices. That's not how uaccess actually works. Here's the relevant udev builtin that sets the ACL for the currently logged in user. https://github.com/systemd/systemd/blob/02927af799dbca2ca22a652dc9acc692326dbc3f/src/udev/udev-builtin-uaccess.c#L108 If you don't change the seat in udev then the device is going to get assigned to seat0. For any device with the uaccess tag udev will look up the uid for the active session on the corresponding seat and grant that user access to the device. You don't need to remove uaccess or change the group to input, just make sure all Wolf created devices get tagged for a non-existent seat and udev will not find a session for them.

bsakaguchi commented 2026-10-15 12:56:52 +00:00

Author

Owner

Copy link

@ABeltramo commented on GitHub (Jun 8, 2025):

For any device with the uaccess tag udev will look up the uid for the active session on the corresponding seat and grant that user access to the device

That makes sense, and thanks for pointing it out I wasn't aware. It should be easy to test then, we could just change the udev rule and everything should work oob, right?

<!-- gh-comment-id:2954230345 --> @ABeltramo commented on GitHub (Jun 8, 2025): > For any device with the uaccess tag udev will look up the uid for the active session on the corresponding seat and grant that user access to the device That makes sense, and thanks for pointing it out I wasn't aware. It should be easy to test then, we could just change the udev rule and everything should work oob, right?

bsakaguchi commented 2026-10-15 12:56:52 +00:00

Author

Owner

Copy link

@UlrichFrancomme commented on GitHub (Oct 3, 2025):

Hi, I had a similar issue while streaming games to another device. As soon as I start Steam in Moonlight, my host (Fedora) starts receiving command from the controller, so I could not play on the host at the same time or even some software like Darktable.

Setting the group of the joypad to root fixed the issue.

SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", ENV{ID_SEAT}="seat9", GROUP="root"

Thank you @ABeltramo for the solution, and for this tool! 😄

<!-- gh-comment-id:3365251140 --> @UlrichFrancomme commented on GitHub (Oct 3, 2025): Hi, I had a similar issue while streaming games to another device. As soon as I start Steam in Moonlight, my host (Fedora) starts receiving command from the controller, so I could not play on the host at the same time or even some software like Darktable. Setting the group of the joypad to root fixed the issue. ```sh SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", ENV{ID_SEAT}="seat9", GROUP="root" ``` Thank you @ABeltramo for the solution, and for this tool! 😄

bsakaguchi commented 2026-10-15 12:56:53 +00:00

Author

Owner

Copy link

@MertsA commented on GitHub (Oct 16, 2025):

I just went ahead and cheated a bit and set everything under uhid to a different seat by default. Might not be the best approach for wolf but with just the rules matching off the ATTRS{name} it didn't apply to the hidraw device or the leds.

# Move anything under uhid off of seat0 KERNELS=="uhid", SUBSYSTEM=="hid", TAG+="seat", ENV{ID_SEAT}="seat9"

For whatever reason the ATTRS{name} wasn't set for the hid device itself. Depending on how the virtual MAC addresses are enumerated there might be a better solution there.

<!-- gh-comment-id:3412426450 --> @MertsA commented on GitHub (Oct 16, 2025): I just went ahead and cheated a bit and set everything under uhid to a different seat by default. Might not be the best approach for wolf but with just the rules matching off the ATTRS{name} it didn't apply to the hidraw device or the leds. `# Move anything under uhid off of seat0 KERNELS=="uhid", SUBSYSTEM=="hid", TAG+="seat", ENV{ID_SEAT}="seat9"` For whatever reason the ATTRS{name} wasn't set for the hid device itself. Depending on how the virtual MAC addresses are enumerated there might be a better solution there.

bsakaguchi commented 2026-10-15 12:56:53 +00:00

Author

Owner

Copy link

@ABeltramo commented on GitHub (Dec 4, 2025):

I'm updating the documentation and putting together all the things that have been reported here I've ended up with the following:

# Allows Wolf to acces /dev/uinput (only needed for joypad support)
KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput", TAG+="uaccess"

# Allows Wolf to access /dev/uhid (only needed for DualSense emulation)
KERNEL=="uhid", GROUP="input", MODE="0660", TAG+="uaccess"

# Joypads
KERNEL=="hidraw*",   ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="input", MODE="0660", ENV{ID_SEAT}="seat9"
SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", ENV{ID_SEAT}="seat9"
SUBSYSTEMS=="input", ATTRS{name}=="Wolf PS5 (virtual) pad", MODE="0660", ENV{ID_SEAT}="seat9"
SUBSYSTEMS=="input", ATTRS{name}=="Wolf gamepad (virtual) motion sensors", MODE="0660", ENV{ID_SEAT}="seat9"
SUBSYSTEMS=="input", ATTRS{name}=="Wolf Nintendo (virtual) pad", MODE="0660", ENV{ID_SEAT}="seat9"

Can anybody else test this out to make sure it works as intended?

<!-- gh-comment-id:3611823240 --> @ABeltramo commented on GitHub (Dec 4, 2025): I'm updating the documentation and putting together all the things that have been reported here I've ended up with the following: ```bash # Allows Wolf to acces /dev/uinput (only needed for joypad support) KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput", TAG+="uaccess" # Allows Wolf to access /dev/uhid (only needed for DualSense emulation) KERNEL=="uhid", GROUP="input", MODE="0660", TAG+="uaccess" # Joypads KERNEL=="hidraw*", ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="input", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf PS5 (virtual) pad", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf gamepad (virtual) motion sensors", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf Nintendo (virtual) pad", MODE="0660", ENV{ID_SEAT}="seat9" ``` Can anybody else test this out to make sure it works as intended?

bsakaguchi commented 2026-10-15 12:56:53 +00:00

Author

Owner

Copy link

@JoelD333 commented on GitHub (Jan 17, 2026):

Hi guys, I just finished installing everything (fantastic job, thank you very much), but I was running into this issue.

The input from the Docker container was leaking into my host system.

I tried this last set of rules, but it didn’t work:

I'm updating the documentation and putting together all the things that have been reported here I've ended up with the following:
Can anybody else test this out to make sure it works as intended?

So I tested what @UlrichFrancomme suggested, and that did the trick.

Hi, I had a similar issue while streaming games to another device. As soon as I start Steam in Moonlight, my host (Fedora) starts receiving command from the controller, so I could not play on the host at the same time or even some software like Darktable.

Setting the group of the joypad to root fixed the issue.

SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", ENV{ID_SEAT}="seat9", GROUP="root"

Thank you @ABeltramo for the solution, and for this tool! 😄

I’m not sure if it’s the most correct approach, but it works.

<!-- gh-comment-id:3762650498 --> @JoelD333 commented on GitHub (Jan 17, 2026): Hi guys, I just finished installing everything (fantastic job, thank you very much), but I was running into this issue. The input from the Docker container was leaking into my host system. I tried this last set of rules, but it didn’t work: > I'm updating the documentation and putting together all the things that have been reported here I've ended up with the following: > Can anybody else test this out to make sure it works as intended? So I tested what @UlrichFrancomme suggested, and that did the trick. > Hi, I had a similar issue while streaming games to another device. As soon as I start Steam in Moonlight, my host (Fedora) starts receiving command from the controller, so I could not play on the host at the same time or even some software like Darktable. > > Setting the group of the joypad to root fixed the issue. > > SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", MODE="0660", ENV{ID_SEAT}="seat9", GROUP="root" > > Thank you [@ABeltramo](https://github.com/ABeltramo) for the solution, and for this tool! 😄 I’m not sure if it’s the most correct approach, but it works.

bsakaguchi commented 2026-10-15 12:56:53 +00:00

Author

Owner

Copy link

@clsty commented on GitHub (Mar 20, 2026):

Can anybody else test this out to make sure it works as intended?

According to my test the following works:

• On host system, create /etc/udev/rules.d/85-wolf-virtual-inputs.rules with following contents:

# Allow Wolf access /dev/uinput
KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput", TAG+="uaccess"

# Allow Wolf access /dev/uhid (needed by PS5/DualSense simulation)
KERNEL=="uhid", GROUP="input", MODE="0660", TAG+="uaccess"

# Virtual gamepad setup, which key part is `ENV{ID_SEAT}="seat9"`
KERNEL=="hidraw*",   ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9"
SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9"
SUBSYSTEMS=="input", ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9"
SUBSYSTEMS=="input", ATTRS{name}=="Wolf gamepad (virtual) motion sensors", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9"
SUBSYSTEMS=="input", ATTRS{name}=="Wolf Nintendo (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9"

• Reload to apply the rules:

  sudo udevadm control --reload-rules
  sudo udevadm trigger
  

• Restart Wolf containers.

<!-- gh-comment-id:4094816176 --> @clsty commented on GitHub (Mar 20, 2026): > Can anybody else test this out to make sure it works as intended? According to my test the following works: - On host system, create `/etc/udev/rules.d/85-wolf-virtual-inputs.rules` with following contents: ```conf # Allow Wolf access /dev/uinput KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput", TAG+="uaccess" # Allow Wolf access /dev/uhid (needed by PS5/DualSense simulation) KERNEL=="uhid", GROUP="input", MODE="0660", TAG+="uaccess" # Virtual gamepad setup, which key part is `ENV{ID_SEAT}="seat9"` KERNEL=="hidraw*", ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf X-Box One (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf PS5 (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf gamepad (virtual) motion sensors", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9" SUBSYSTEMS=="input", ATTRS{name}=="Wolf Nintendo (virtual) pad", GROUP="root", MODE="0660", ENV{ID_SEAT}="seat9" ``` - Reload to apply the rules: ```bash sudo udevadm control --reload-rules sudo udevadm trigger ``` - Restart Wolf containers.

bsakaguchi commented 2026-10-15 12:56:53 +00:00

Author

Owner

Copy link

@ABeltramo commented on GitHub (Mar 27, 2026):

Reopening this to remember that I should update the docs again with the latest suggestions 😅

<!-- gh-comment-id:4143067007 --> @ABeltramo commented on GitHub (Mar 27, 2026): Reopening this to remember that I should update the docs again with the latest suggestions 😅

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

Subscribe

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#127

No description provided.