search

bayasdev / envycontrol

Easy GPU switching for Nvidia Optimus laptops under Linux
https://bayas.dev/envycontrol
MIT License
1.14k stars 55 forks source link

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

Closed wolfdaemon closed 1 week ago

wolfdaemon commented 1 week ago

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:

bayasdev commented 1 week ago

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

wolfdaemon commented 1 week ago

@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 1 week ago

@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 1 week ago

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 1 week ago

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

wolfdaemon commented 1 week ago

@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 1 week ago

@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.

wolfdaemon commented 1 week ago

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 1 week ago

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 1 week ago

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.

bayasdev commented 1 week ago

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 šŸ™ŒšŸ¼