@dj_var so is there a /etc/X11/xorg.conf file, or a file in /etc/X11/xorg.conf.d related to the Nvidia card? If so is the configuration correct when you install the nvidia driver? Or this can be removed and see how the nvidia driver works.
No display signal or image after resume from suspension after Tumbleweed upgrade with NVIDIA drivers
Well, I did make a backup of the Nvidia xorg.conf file and swapped it for a ‘default’ one instead as without that it wouldn’t load X11 at all upon reboot whereas with it now it seems to work. I did make a little tweak to the xorg.conf file before when I had the Nvidia driver to remove screen tearing, mostly by adding a parameter to the metamodes option as explained in this video tutorial: https://youtu.be/oYWer86A20s?si=6J-6sa4nIGGkgEMD
Otherwise everything else in the conf file stayed the same. But as I say, if I now go ahead and install the G06 Nvidia driver, everything works perfectly fine, until I put the computer to sleep and then the display signal won’t come back until hard reset. I am more than happy to post the whole of the Nvidia xorg.conf file here so you can see it. Also yes, there is a xorg.conf.d directory in it too and inside it there is a file called 00-keyboard.conf
Here is the content of the xorg.conf that was being used with the nvidia driver installed:
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings: version 515.65.01
Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama" "0"
EndSection
Section "Files"
EndSection
Section "InputDevice"
# generated from data in "/etc/sysconfig/mouse"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "Emulate3Buttons" "yes"
Option "ZAxisMapping" "4 5"
EndSection
Section "InputDevice"
# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection
Section "Monitor"
# HorizSync source: edid, VertRefresh source: edid
Identifier "Monitor0"
VendorName "Unknown"
ModelName "Acer SA270"
HorizSync 31.0 - 75.0
VertRefresh 56.0 - 75.0
Option "DPMS"
EndSection
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "NVIDIA GeForce GTX 750 Ti"
Option "NoLogo" "1"
Option "RenderAccel" "1"
Option "TripleBuffer" "true"
Option "MigrationHeuristic" "greedy"
Option "AccelMethod" "sna"
Option "TearFree" "true"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
Option "Stereo" "0"
Option "nvidiaXineramaInfoOrder" "DFP-0"
Option "metamodes" "DVI-I-1:1920x1080_60 +0+0 { ForceFullCompositionPipeline = On }"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
SubSection "Display"
Depth 24
EndSubSection
EndSection
Also, here is the inxi -Gxxz command being run again with the latest snapshot and nouveau drivers:
@dj_var I would disable all the nvidia systemd services related to hibernation/sleep as a temporary check.
@dj_var Option "AccelMethod" "sna" is related to Intel gpu, not nvidia?
I don’t really know about that to be honest. I just left it as it was, I need to do a bit more research on that.
Also,
How do I do that exactly? I did try to disable the services with YaST Services Manager and turning off/changing the power related settings for nvidia entries, but that either ended up in braking things or didn’t work and the result stayed the same. I might give it another go though, now that I’ve managed to upgrade the system to the latest snapshot though…do you think it’s worth it? Or am I looking in the wrong place? Should I do something else perhaps?
@dj_var systemctl status nvidia-{press tab key twice for autocompletion} will show the services installed;
systemctl status nvidia-
nvidia-hibernate.service nvidia-persistence.service nvidia-persistenced.service nvidia-powerd.service nvidia-resume.service nvidia-suspend.service
Check the status, then stop disable and mask each one of the above and see what happens.
I turned them all off and if I stop and disable nvidia-suspend.service it won’t go to suspension after I select suspend. If I re-enable it it will go to suspension but then again, no display signal afterwards…
Ok, so it has got something to do with these services, as when I selected to start them manually from YaST Services Manager the screen went blank and eventually turned off but the machine didn’t go to sleep as I didn’t select the system to go to sleep, just the graphics services pretty much. So it has something to do with these services. Something isn’t right…
@dj_var So your going to have to see what information is in the logs with journalctl.
The problem that I observed is regarding the nvidia driver that tumbleweed is using which is the driver with experimental features. On my machine I installed it several times but using the run file and the same thing is happening black screen after suspend. The solution I had and I am ok with it is the production branch version run file driver . Currently the version number is 535.154.05 for the production branch version.
> inxi -Gxxz
Graphics:
Device-1: NVIDIA GA106 [Geforce RTX 3050] vendor: ASUSTeK driver: nvidia
v: 535.154.05 arch: Ampere pcie: speed: 8 GT/s lanes: 8 ports: active: none
off: DP-3 empty: DP-1,DP-2,HDMI-A-1 bus-ID: 01:00.0 chip-ID: 10de:2507
Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.4
compositor: xfwm v: 4.18.0 driver: X: loaded: nvidia
gpu: nvidia,nvidia-nvswitch display-ID: :0.0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96
Monitor-1: DP-3 mapped: DP-4 note: disabled model: Samsung res: 1920x1080
dpi: 40 diag: 801mm (31.5")
API: EGL v: 1.5 platforms: gbm: drv: nvidia
API: OpenGL v: 4.6.0 vendor: nvidia v: 535.154.05 glx-v: 1.4
direct-render: yes renderer: NVIDIA GeForce RTX 3050/PCIe/SSE2
API: Vulkan v: 1.3.268 surfaces: xcb,xlib device: 0 type: discrete-gpu
driver: nvidia device-ID: 10de:2507
I just think this latest version of the Nvidia driver that has been released is bugged. Plain and simple, there is no other explanation really and I am clearly not the only one affected either. Even higher up in the thread there was a link to a bug assigned to Stefan Dirsch and is still ‘in progress’ and this issue wasn’t there on the previous version of the Nvidia driver. Everything worked just perfectly fine, so in my opinion we could do all the troubleshooting and logging we want but I think this needs to be fixed by the developers now really…sticking with nouveau for the time being but it kind of sucks…also Nvidia is always the same. Hoping to switch to an AMD graphics card soon and good riddance to all these problems.
@dj_var then I would suggest a bug report upstream? So does the nouveau driver meet your needs, if so why not just move on with that?
@conram New feature releases… Not interested in the open driver for your gpu to see how that performs?
As I said, nouveau is alright, just it screen tears which is kind of unacceptable in my opinion for today’s standards and expectations for computers not to mention super annoying. So it’s ok as a temporary measure but definitely not for the long term. Also, there is a bug on openSUSE’s Bugzilla already but I don’t know how to report it upstream to be honest, not do I know if one already exists.
@conram yes it’s in the default repositories.
So I uninstalled the run files and installed the open driver, it end up on black screen after loading plymouth.
Is there something I’m missing?
Now I’m back to using the run file driver again.
@conram Did you follow the instructions here https://sndirsch.github.io/nvidia/2022/06/07/nvidia-opengpu.html
I thought the open source drivers are only compatible with the newer cards (I think 20 series and above, it won’t be compatible with the 750Ti in my partner’s system) 