bayasdev/envycontrol

[BUG] Black Screen when in NVIDIA discrete graphics mode on Debian 12

Closed this issue · 11 comments

wolfdaemon commented

Describe the bug
After rebooting the system as instructed by envycontrol -s nvidia on the system's root account (Debian does not have sudo by default), the screen displays nothing when X startx is executed on the next boot.

Here are some specifications:

To Reproduce
Steps to reproduce the behavior:

  1. Log into root with su -
  2. Run envycontrol -s nvidia
  3. Run reboot
  4. Log into new session
  5. Run startx
  6. See nothing

Expected behavior
The screen is supposed to display the X environment (such as the i3 desktop homescreen) after executing startx on the subsequent boot following the execution of su - & envycontrol -s nvidia.

Screenshots
If applicable, add screenshots to help explain your problem.

System Information:

  • Model: Acer Predator PHN16-71
  • Distro: Debian 12 Stable (Bookworm)
  • Kernel: 6.1.0-22-amd64
  • DE/WM and Display Manager (if applicable): i3 with no display manager (startx)
  • EnvyControl version: 3.4.0
  • Nvidia driver version: 535.183.01-1~deb12u1
  • lspci output:
0000:00:00.0 Host bridge: Intel Corporation Device a72a (rev 01)
0000:00:01.0 PCI bridge: Intel Corporation Raptor Lake PCI Express 5.0 Graphics Port (PEG010) (rev 01)
0000:00:02.0 VGA compatible controller: Intel Corporation Raptor Lake-S UHD Graphics (rev 04)
0000:00:04.0 Signal processing controller: Intel Corporation Raptor Lake Dynamic Platform and Thermal Framework Processor Participant (rev 01)
0000:00:0e.0 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller Intel Corporation
0000:00:14.0 USB controller: Intel Corporation Raptor Lake USB 3.2 Gen 2x2 (20 Gb/s) XHCI Host Controller (rev 11)
0000:00:14.2 RAM memory: Intel Corporation Raptor Lake-S PCH Shared SRAM (rev 11)
0000:00:14.3 Network controller: Intel Corporation Raptor Lake-S PCH CNVi WiFi (rev 11)
0000:00:15.0 Serial bus controller: Intel Corporation Raptor Lake Serial IO I2C Host Controller (rev 11)
0000:00:15.3 Serial bus controller: Intel Corporation Device 7a4f (rev 11)
0000:00:16.0 Communication controller: Intel Corporation Raptor Lake CSME HECI (rev 11)
0000:00:1a.0 PCI bridge: Intel Corporation Raptor Lake PCI Express Root Port (rev 11)
0000:00:1c.0 PCI bridge: Intel Corporation Device 7a3c (rev 11)
0000:00:1c.6 PCI bridge: Intel Corporation Device 7a3e (rev 11)
0000:00:1e.0 Communication controller: Intel Corporation Device 7a28 (rev 11)
0000:00:1e.3 Serial bus controller: Intel Corporation Device 7a2b (rev 11)
0000:00:1f.0 ISA bridge: Intel Corporation Device 7a0c (rev 11)
0000:00:1f.3 Multimedia audio controller: Intel Corporation Raptor Lake High Definition Audio Controller (rev 11)
0000:00:1f.4 SMBus: Intel Corporation Raptor Lake-S PCH SMBus Controller (rev 11)
0000:00:1f.5 Serial bus controller: Intel Corporation Raptor Lake SPI (flash) Controller (rev 11)
0000:02:00.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge 4C 2020] (rev 02)
0000:03:00.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge 4C 2020] (rev 02)
0000:03:01.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge 4C 2020] (rev 02)
0000:03:02.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge 4C 2020] (rev 02)
0000:03:03.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Maple Ridge 4C 2020] (rev 02)
0000:04:00.0 USB controller: Intel Corporation Thunderbolt 4 NHI [Maple Ridge 4C 2020]
0000:38:00.0 USB controller: Intel Corporation Thunderbolt 4 USB Controller [Maple Ridge 4C 2020]
0000:6c:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01)
0000:6d:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Killer E2600 GbE Controller (rev 21)
10000:e0:01.0 System peripheral: Intel Corporation RST VMD Managed Controller
10000:e0:01.1 PCI bridge: Intel Corporation Device a72d (rev 01)
10000:e1:00.0 Non-Volatile memory controller: Sandisk Corp WD PC SN810 / Black SN850 NVMe SSD (rev 01)
bayasdev commented

@wolfdaemon did you follow the steps outlined in the wiki?

wolfdaemon commented

@wolfdaemon did you follow the steps outlined in the wiki?

I did not. Pardon me, I did not notice this section upon my initial viewing. I will test this and report my findings as soon as possible.

bayasdev commented

@wolfdaemon did you follow the steps outlined in the wiki?

I did not. Pardon me, I did not notice this section upon my initial viewing. I will test this and report my findings as soon as possible.

You're welcome 😅

bayasdev commented

Here is the quote from the wiki:

Instructions for Ubuntu and its derivatives

Ubuntu bundles its own tool for managing Nvidia Optimus graphics, before using EnvyControl please run sudo prime-select on-demand followed by sudo systemctl mask gpu-manager.service to prevent gpu-manager from interfering.

Here is my output for executing prime-select on-demand as root:


-bash: prime-select: command not found

Here is my output for executing prime-select on-demand as root:


Unit gpu-manager.service does not exist, proceeding anyway.

Created symlink /etc/systemd/system/gpu-manager.service → /dev/null.

That command is Ubuntu specific it does not exist on Debian

wolfdaemon commented

My fault, I followed the wrong section. Deleted the previous to prevent confusion.

wolfdaemon commented

@wolfdaemon did you follow the steps outlined in the wiki?

To clarify on this text on the wiki section cited:

What to do if my display manager is not supported?

This step is only required for nvidia mode, you need to setup your display to manager to execute a script with the following content:

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

Is the wiki stating to execute the following commands upon the startup of the display manager?
Specifically for startx, would that be something like inserting the following commands in ~/.xinitrc or similar?

bayasdev commented

@wolfdaemon did you follow the steps outlined in the wiki?

To clarify on this text on the wiki section cited:

What to do if my display manager is not supported?

This step is only required for nvidia mode, you need to setup your display to manager to execute a script with the following content:

xrandr --setprovideroutputsource modesetting NVIDIA-0

xrandr --auto

Is the wiki stating to execute the following commands upon the startup of the display manager?

Specifically for startx, would that be something like inserting the following commands in ~/.xinitrc or similar?

That's correct, the wiki needs to be reworked but have not had enough time for it.

  • 👍1
wolfdaemon commented

When using the following within ~/.xinitrc:

xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

My output of startx is this:

X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
Current Operating System: Linux alpha 6.1.0-22-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.94-1 (2024-06-21) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-22-amd64 root=UUID=40ed63bd-6c2a-4f37-b1c8-aa5a896d92d1 ro quiet
xorg-server 2:21.1.7-3+deb12u7 (https://www.debian.org/support) 
Current version of pixman: 0.42.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Jul  3 00:04:27 2024
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE) event17 - PIXA3848:00 093A:3848 Touchpad: kernel bug: clickpad advertising right button. See https://wayland.freedesktop.org/libinput/doc/1.22.1/clickpad-with-right-button.html for details
(EE) event17 - PIXA3848:00 093A:3848 Touchpad: kernel bug: clickpad advertising right button. See https://wayland.freedesktop.org/libinput/doc/1.22.1/clickpad-with-right-button.html for details
randr: falling back to unsynchronized pixmap sharing
xinit: connection to X server lost

waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.

My output with a completely blank/empty ~/.xinitrc file:

X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
Current Operating System: Linux alpha 6.1.0-22-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.94-1 (2024-06-21) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-22-amd64 root=UUID=40ed63bd-6c2a-4f37-b1c8-aa5a896d92d1 ro quiet
xorg-server 2:21.1.7-3+deb12u7 (https://www.debian.org/support) 
Current version of pixman: 0.42.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Jul  3 00:12:26 2024
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE) event7  - PIXA3848:00 093A:3848 Touchpad: kernel bug: clickpad advertising right button. See https://wayland.freedesktop.org/libinput/doc/1.22.1/clickpad-with-right-button.html for details
(EE) event7  - PIXA3848:00 093A:3848 Touchpad: kernel bug: clickpad advertising right button. See https://wayland.freedesktop.org/libinput/doc/1.22.1/clickpad-with-right-button.html for details
xinit: connection to X server lost

waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.
wolfdaemon commented

More information:

Booting to black screen without the ~/.xinitrc file with the recommended commands, I managed to open a terminal from memory (like with a keybind) and type following commands blindly.

The results are as follows:

  1. Input: xrandr --auto
    Result: Displays the window manager GUI as normal

  2. Input xrandr --setprovideroutputsource NVIDIA-0
    Output:

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  35 (RRSetProviderOutputSource)
  Value in failed request:  0x1b7
  Serial number of failed request:  16
  Current serial number in output stream:  17
wolfdaemon commented

Update: Potential resolution?

Debian-specific: xinit --auto in ~/.xsessionrc?

From my very limited testing (pictured below), it appears that adding xrandr --auto into the ~/.xsessionrc file has resolved this issue. This could potentially be a Debian-specific technicality.

Test Cases

Test 1: The "Display" section for Minecraft 1.21 detecting NVIDIA GPU in use

2024-07-03_03 01 04

Test 2: Checking if the active GPU state is in an active state or suspended

2024-07-03-031008_1767x74_scrot

Useful note(s?) & citations:

  1. For Debian (and derivatives) specifically, ~/.xsessionrc is the apparently the current iteration for X GUI startup scripts upon login over the historical features for files such as .xinitrc & .xsession.

    1. Debian Wiki: Xinitrc:

      Note that ~/.xinitrc is only for configuring the initialization of xinit. If you want the script to be called when ever an X Session is started, then you should instead use ~/.xsession. Most WindowManagers also have a method of starting programs when they first startup.

    2. Unix & Linux StackExchange: Difference between .xinitrc, .xsession and .xsessionrc

      .xinitrc and .xsession are historical features of the X11 Window system so they should be available and have a similar behavior on all Unix systems. On the other hand, .xsessionrc is a Debian feature and distributions that are not based on Debian don't have it unless they've implemented something similar.

  • 🎉1
bayasdev commented

Added

Update: Potential resolution?

Debian-specific: xinit --auto in ~/.xsessionrc?

From my very limited testing (pictured below), it appears that adding xrandr --auto into the ~/.xsessionrc file has resolved this issue. This could potentially be a Debian-specific technicality.

Test Cases

Test 1: The "Display" section for Minecraft 1.21 detecting NVIDIA GPU in use

2024-07-03_03 01 04

Test 2: Checking if the active GPU state is in an active state or suspended

2024-07-03-031008_1767x74_scrot

Useful note(s?) & citations:

  1. For Debian (and derivatives) specifically, ~/.xsessionrc is the apparently the current iteration for X GUI startup scripts upon login over the historical features for files such as .xinitrc & .xsession.

    1. Debian Wiki: Xinitrc:

      Note that ~/.xinitrc is only for configuring the initialization of xinit. If you want the script to be called when ever an X Session is started, then you should instead use ~/.xsession. Most WindowManagers also have a method of starting programs when they first startup.

    2. Unix & Linux StackExchange: Difference between .xinitrc, .xsession and .xsessionrc

      .xinitrc and .xsession are historical features of the X11 Window system so they should be available and have a similar behavior on all Unix systems. On the other hand, .xsessionrc is a Debian feature and distributions that are not based on Debian don't have it unless they've implemented something similar.

Amazing! Added this to the README 🙌🏼

  • ❤️1