Integrated mode doesn't prevent dGPU wakeup from sysfs backlight traversal

[chrispouliot]

Describe the bug
On Gnome, changing brightness can sometimes hit the nvidia backlight sys file. This often happens when a monitor hotplug event puts Gnome/Mutter in a weird state. When on Integrated mode, this causes a 2-3 second delay for the laptop panel brightness to change because it is waking the nvidia dGPU even if the nvidia dGPU isn't in charge of the panel backlight.

systemd-logind traverses /sys/devices/.../0000:64:00.0/backlight/nvidia_0/ (64 is my nvidia dGPU) ancestors as part of SetBrightness handling. These sysfs reads trigger pm_runtime_get_sync on the dGPU. cardwire's current eBPF hooks block /dev/dri/*, the PCI config file, and nvidiaX device nodes, but not the backlight/ subdirectory under the dGPU's PCI sysfs path.

To Reproduce
My laptop uses the amd iGPU by default for backlight, but after hotplugging a HDMI -> USB C adapter Gnome or the kernel reverts to using nvidia as the backlight handler. To fix this, I use a mirror script which just writes the backlight changes from nvidia to the amd backlight file (this is similar to how KDE fixed this problem). But I noticed that sometimes there would be a 3 second delay to brightness changes. I confirmed it was the nvidia write by checking the active/suspended state of the dGPU when using busctl to write the brightness.

cat /sys/bus/pci/devices/0000:64:00.0/power/runtime_status
busctl --system call org.freedesktop.login1 /org/freedesktop/login1/session/_32 \
  org.freedesktop.login1.Session SetBrightness ssu backlight nvidia_0 50
cat /sys/bus/pci/devices/0000:64:00.0/power/runtime_status

Would show suspended, then active.

Expected behavior

Traversing the pcie backlight devices should not wake the nvidia dGPU. Cardwire could extend the LSM path-matching to also block reads under /sys/devices/...//backlight/ (and the corresponding /sys/class/backlight/ symlinked entries).

We will need to confirm what Gnome does when the backlight it wants to use (incorrectly, in this case) no longer allows writing or shows up. If it falls back to the amd bl1 backlight, that's perfect. The mirror script I use would clearly not work if the backlight files are blocked, but that's OK if Gnome reverts to the correct backlight on hotplug if the nvidia one is blocked (to be confirmed) or the mirror script I use could be changed to watch an event higher in the chain like watching the dbus events.

Environment details

OS: NixOS 26.05 (Yarara) x86_64
Host: ROG Zephyrus G14 GA403WM_GA403WM (1.0)
Kernel: Linux 7.0.6-cachyos
Uptime: 11 mins
Packages: 19 (flatpak-system), 2 (flatpak-user), 1462 (nix-system)
Shell: bash 5.3.9
Display (SDC419C): 2880x1800 @ 1.67x in 14", 120 Hz [Built-in]
DE: GNOME 49.4
WM: Mutter (Wayland)
CPU: AMD Ryzen AI 9 HX 370 (24) @ 2.00 GHz
GPU 1: AMD Radeon 890M Graphics [Integrated]
GPU 2: NVIDIA GeForce RTX 5060 Max-Q / Mobile [Discrete]
Memory: 4.89 GiB / 30.46 GiB (16%)

Cardwire version (cardwire --version): cardwire-cli 0.7.1

cardwire list output
Please paste the text output (do not use a screenshot):

ID  NAME                                      PCI           RENDER      CARD   DEFAULT  BLOCKED
--  ----------------------------------------  ------------  ----------  -----  -------  -------
0   Strix [Radeon 880M / 890M]                0000:65:00.0  renderD128  card1  (*)      false  
1   GB206M [GeForce RTX 5060 Max-Q / Mobile]  0000:64:00.0  renderD129  card0  ( )      true   

ls -la /dev/dri/by-path/

total 0
drwxr-xr-x 2 root root 120 May 12 14:40 .
drwxr-xr-x 3 root root 140 May 12 14:39 ..
lrwxrwxrwx 1 root root   8 May 12 14:40 pci-0000:64:00.0-card -> ../card0
lrwxrwxrwx 1 root root  13 May 12 14:39 pci-0000:64:00.0-render -> ../renderD129
lrwxrwxrwx 1 root root   8 May 12 14:39 pci-0000:65:00.0-card -> ../card1
lrwxrwxrwx 1 root root  13 May 12 14:39 pci-0000:65:00.0-render -> ../renderD128