Describe the bug
On a 2-GPU laptop (AMD iGPU + NVIDIA dGPU) in Smart mode, granting an application dGPU access — either via the cardwire-gui "Allowed (dGPU)" toggle for a .desktop-launched Flatpak app, or via CARDWIRE_FORCE_GPU=1 set through flatpak override --user --env— does not result in /dev/nvidia0 being unblocked for that process. /dev/nvidiactl, /dev/nvidia-uvm, /dev/nvidia-modeset, and /dev/nvidia-caps/* are all present and correctly permissioned throughout, but /dev/nvidia0 specifically remains absent (ENOENT) for the granted process, causing CUDA initialization to fail.
To Reproduce
Set Cardwire to Smart mode (cardwire set smart)
Install a Flatpak app that spawns a child process needing CUDA access (in my case, Jan AI, ai.jan.Jan, which spawns a llama-server child process via its Tauri backend)
Grant the app dGPU access via cardwire-gui's per-app toggle (shows as Allowed (dGPU), ID: ai.jan.Jan.desktop)
Launch the app via its .desktop entry (gtk-launch ai.jan.Jan.desktop)
Observe: bwrap: Can't get type of source /dev/nvidia0: No such file or directory — sandbox construction fails before the app even starts
Alternatively, launch via terminal (flatpak run ai.jan.Jan) — sandbox construction succeeds, but the CUDA runtime inside still fails: ggml_cuda_init: failed to initialize CUDA: no CUDA-capable device is detected
As a further isolation step, set flatpak override --user --env=CARDWIRE_FORCE_GPU=1 ai.jan.Jan (confirmed applied via flatpak override --user --show ai.jan.Jan), relaunch — identical failure, /dev/nvidia0 still absent (ls -la /dev/nvidia* run while the process is live confirms this directly)
cardwire launch --gpu 0 flatpak run com.discordapp.Discord (tested on a separate app, Discord, same machine) also did not prevent an unrelated but related symptom: Discord's Chromium GPU-info collector still hits the same restricted 0000:01:00.1 PCI node during enumeration regardless of render-target GPU selection
Expected behavior
Once an app is granted dGPU access in Smart mode (via the GUI toggle or CARDWIRE_FORCE_GPU), /dev/nvidia0 (and any other NVIDIA device nodes the driver/CUDA runtime needs) should become accessible to that process and its child processes, allowing CUDA to initialize normally.
Environment details
Distro: Fedora Linux 44 (Workstation Edition)
Kernel: 7.1.13-200.fc44.x86_64
Hardware: ASUS ROG Zephyrus G15 GA503RS
CPU: AMD Ryzen 7 6800HS with Radeon Graphics
iGPU: AMD Radeon 680M (PCI 0000:07:00.0)
dGPU: NVIDIA GeForce RTX 3080 Laptop GPU, 8GB (PCI 0000:01:00.0)
NVIDIA driver: 610.57.04 (akmod-nvidia, MOK-signed)
Display server: GNOME / Wayland
cardwire-cli 0.12.1
cardwire list --json
{
"0": {
"id": 0,
"name": "AMD Radeon 680M",
"pci": "0000:07:00.0",
"render": 128,
"card": 1,
"default": true,
"discrete": false,
"virtual_gpu": false,
"available": true,
"vendor": "AMD",
"driver": "amdgpu",
"blocked": false,
"launchable": true,
"nvidia": false,
"nvidia_minor": "none"
},
"1": {
"id": 1,
"name": "NVIDIA GeForce RTX 3080 Laptop GPU",
"pci": "0000:01:00.0",
"render": 129,
"card": 0,
"default": false,
"discrete": true,
"virtual_gpu": false,
"available": true,
"vendor": "Nvidia",
"driver": "nvidia",
"blocked": true,
"launchable": true,
"nvidia": true,
"nvidia_minor": "0"
}
}
Additional context
Also tested cardwire gpu --unblock 1 directly — rejected with Per GPU block is only available on manual mode
Also tested switching to manual mode to use per-GPU unblock — rejected with Manual mode is only available on Desktop or system with either 1 GPU or 3+ GPUs (this laptop has exactly 2 GPUs)
Confirmed working baseline: Hybrid mode fully unblocks the dGPU and CUDA initializes correctly (CUDA0: RTX 3080 Laptop GPU) — the bug appears isolated to Smart mode's per-app grant mechanism, not the eBPF blocking mechanism in general
Suspect the per-app analyzer/grant may not correctly propagate to Flatpak-sandboxed apps and/or their spawned child processes, since the same symptom (device node ENOENT despite a nominally-granted app) reproduced across two different Flatpak apps (Jan, Discord) and two different grant mechanisms (GUI toggle, CARDWIRE_FORCE_GPU env var)
Describe the bug
On a 2-GPU laptop (AMD iGPU + NVIDIA dGPU) in Smart mode, granting an application dGPU access — either via the cardwire-gui "Allowed (dGPU)" toggle for a .desktop-launched Flatpak app, or via CARDWIRE_FORCE_GPU=1 set through flatpak override --user --env— does not result in /dev/nvidia0 being unblocked for that process. /dev/nvidiactl, /dev/nvidia-uvm, /dev/nvidia-modeset, and /dev/nvidia-caps/* are all present and correctly permissioned throughout, but /dev/nvidia0 specifically remains absent (ENOENT) for the granted process, causing CUDA initialization to fail.
To Reproduce
Set Cardwire to Smart mode (cardwire set smart)
Install a Flatpak app that spawns a child process needing CUDA access (in my case, Jan AI, ai.jan.Jan, which spawns a llama-server child process via its Tauri backend)
Grant the app dGPU access via cardwire-gui's per-app toggle (shows as Allowed (dGPU), ID: ai.jan.Jan.desktop)
Launch the app via its .desktop entry (gtk-launch ai.jan.Jan.desktop)
Observe: bwrap: Can't get type of source /dev/nvidia0: No such file or directory — sandbox construction fails before the app even starts
Alternatively, launch via terminal (flatpak run ai.jan.Jan) — sandbox construction succeeds, but the CUDA runtime inside still fails: ggml_cuda_init: failed to initialize CUDA: no CUDA-capable device is detected
As a further isolation step, set flatpak override --user --env=CARDWIRE_FORCE_GPU=1 ai.jan.Jan (confirmed applied via flatpak override --user --show ai.jan.Jan), relaunch — identical failure, /dev/nvidia0 still absent (ls -la /dev/nvidia* run while the process is live confirms this directly)
cardwire launch --gpu 0 flatpak run com.discordapp.Discord (tested on a separate app, Discord, same machine) also did not prevent an unrelated but related symptom: Discord's Chromium GPU-info collector still hits the same restricted 0000:01:00.1 PCI node during enumeration regardless of render-target GPU selection
Expected behavior
Once an app is granted dGPU access in Smart mode (via the GUI toggle or CARDWIRE_FORCE_GPU), /dev/nvidia0 (and any other NVIDIA device nodes the driver/CUDA runtime needs) should become accessible to that process and its child processes, allowing CUDA to initialize normally.
Environment details
Distro: Fedora Linux 44 (Workstation Edition)
Kernel: 7.1.13-200.fc44.x86_64
Hardware: ASUS ROG Zephyrus G15 GA503RS
CPU: AMD Ryzen 7 6800HS with Radeon Graphics
iGPU: AMD Radeon 680M (PCI 0000:07:00.0)
dGPU: NVIDIA GeForce RTX 3080 Laptop GPU, 8GB (PCI 0000:01:00.0)
NVIDIA driver: 610.57.04 (akmod-nvidia, MOK-signed)
Display server: GNOME / Wayland
cardwire-cli 0.12.1
cardwire list --json
{
"0": {
"id": 0,
"name": "AMD Radeon 680M",
"pci": "0000:07:00.0",
"render": 128,
"card": 1,
"default": true,
"discrete": false,
"virtual_gpu": false,
"available": true,
"vendor": "AMD",
"driver": "amdgpu",
"blocked": false,
"launchable": true,
"nvidia": false,
"nvidia_minor": "none"
},
"1": {
"id": 1,
"name": "NVIDIA GeForce RTX 3080 Laptop GPU",
"pci": "0000:01:00.0",
"render": 129,
"card": 0,
"default": false,
"discrete": true,
"virtual_gpu": false,
"available": true,
"vendor": "Nvidia",
"driver": "nvidia",
"blocked": true,
"launchable": true,
"nvidia": true,
"nvidia_minor": "0"
}
}
Additional context
Also tested cardwire gpu --unblock 1 directly — rejected with Per GPU block is only available on manual mode
Also tested switching to manual mode to use per-GPU unblock — rejected with Manual mode is only available on Desktop or system with either 1 GPU or 3+ GPUs (this laptop has exactly 2 GPUs)
Confirmed working baseline: Hybrid mode fully unblocks the dGPU and CUDA initializes correctly (CUDA0: RTX 3080 Laptop GPU) — the bug appears isolated to Smart mode's per-app grant mechanism, not the eBPF blocking mechanism in general
Suspect the per-app analyzer/grant may not correctly propagate to Flatpak-sandboxed apps and/or their spawned child processes, since the same symptom (device node ENOENT despite a nominally-granted app) reproduced across two different Flatpak apps (Jan, Discord) and two different grant mechanisms (GUI toggle, CARDWIRE_FORCE_GPU env var)