Bug 1192751

Ok. Meanwhile I figured out, that if one runs

  xrandr --auto 

on the DISPLAY the screen lightens up and everything is fine again. Hmm.

I can confirm this issue.
I observe black screen in display manager after the upgrade (20211110-0 -> 20211111-0)
I use NVIDIA proprietary driver (470.86) and the nvidia config from suse-prime package.
Operating System: openSUSE Tumbleweed 20211110
Kernel Version: 5.14.14-2-default (64-bit)
Graphics Platform: X11
NVIDIA GeForce GTX 1060 with Max-Q Design on Dell G3 3779

The problem I'm having after the update is that my laptop screen goes blank when the display manager (tested SDDM and lightdm) is started. The output is visible only on an external monitor connected via HDMI, but it must be connected before the system boots. After logging in and starting the KDE Plasma, the image is visible on both monitors.

I am also able to enter the password (despite black screen) in SDDM and lightdm and login to the desktop (Plasma) without connected external monitor, so the display manager is fully operable.
Immediately after entering and confirming the password, the Plasma splash screen is shown.

Created attachment 853793 [details]
X.Org X Server 1.20.13 log

Created attachment 853794 [details]
X.Org X Server 1.21.1.1 log

I've attached the logs from X.Org X Server. To compare the differences before and after the update.

Thanks for confirmation and input! Same issue here. Seems GNOME session somehow does some RANDR calls during login/setup. Now I also understand why I haven't seen this  issue when I tested this the first time with xorg-server 21.1.0. I used gdm autologin feature with a GNOME as Xsession. For example you're lost with xdm and icewm as Xsession. (well you can login via ssh and then run 'XAUTHORITY=<...> DISPLAY=:0 xrandr --auto" ;-) )

So using autologin feature of sddm might be a viable worlaround for you for now.

(In reply to Stefan Dirsch from comment #7)
> So using autologin feature of sddm might be a viable worlaround for you for
> now.

I can't, because I use pam_mount to mount encrypted hard drives.

Hi, I can confirm that this issue happens to me too with nvidia driver and Intel + GeForce MX450 hybrid laptop (sddm crashes in 20211111 according to journalctl). Gdm works fine. I am using gdm now as a 'workaround', looking forward to seeing this got fixed soon.

Created attachment 853813 [details]
Xorg.log

and here is one more log of failing nvidia-card

Reported upstream

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1254

Reported upstream

https://gitlab.freedesktop.org/xorg/xserver/-/issues/1254

Temporary workaround is reverting to a pre update snapshot and protecting all xorg packages until a fix is in place

Am not sure whether it is the same issue but I have lost 'auto login' ability with Plasma KDE with Suse-Prime (0.8.5-1.1).  If I remove Suse-Prime or install an old version (say 0.7.1.7-1.3), auto login works again )although with a raft of error messages on booting.   

Fresh install today - System info:

Operating System: openSUSE Tumbleweed 20211121
KDE Plasma Version: 5.23.3
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
Kernel Version: 5.15.2-1-default (64-bit)
Graphics Platform: X11
Processors: 16 × Intel® Core™ i7-10700 CPU @ 2.90GHz
Memory: 15.2 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 2060/PCIe/SSE2

@Garry Yes, could be the same issue. Could be that KDE desktop doesn't run any of these RANDR calls which initializes the internal Laptop screen. So that the screen remains black. You might add some session autostart, which runs 'xrandr --auto ' as workaround
or use 'offload' mode.

Thanks Stefan

My p/c is a desktop not a laptop.  I do not have any of the other issues like the black screen, just the auto-login not working - although all the settings (like the setting in the file in etc / sysconfig / displaymanager is: DISPLAYMANAGER_AUTOLOGIN="xxx") appear correct.

Hmm. What does mean the autologin does not work exactly?

Although my system is set to auto-login, it stops at the sddm screen. I then have to add my password before the plasma session starts.

If I remove the 'suse-prime' rpm or roll back to an earlier version of suse-prime (say 0-7-17-1.3) my p/c then boots to the plasma desktop (athough it shows a raft of error messages whilst booting).

Hope this makes sense?  Is there are system data/ reports that I can gather that may help?

This sounds weird. Autologin (display manager configuration) should not be related to which driver is being used.

I suggest to handle this in a separate ticket.

(In reply to Stefan Dirsch from comment #20)
> I suggest to handle this in a separate ticket.

Can the ticket be be mentioned here after creation so that people following this issue can know when it is resolved? for now i protected all packages regarding this issue on my work stations, i'm pretty sure others did too

(In reply to Jeroen Mathon from comment #21)
> (In reply to Stefan Dirsch from comment #20)
> > I suggest to handle this in a separate ticket.
> 
> Can the ticket be be mentioned here after creation so that people following
> this issue can know when it is resolved? for now i protected all packages
> regarding this issue on my work stations, i'm pretty sure others did too

Feel free to add it here once you've opened the new ticket.

*** Bug 1192923 has been marked as a duplicate of this bug. ***

*** Bug 1193341 has been marked as a duplicate of this bug. ***

(In reply to Stefan Dirsch from comment #12)
> Reported upstream
> 
> https://gitlab.freedesktop.org/xorg/xserver/-/issues/1254

There is no real progress upstream, except the link back to this bug report. Is it an option to revert X-Server to 1.20.x in TW until this is fixed?

(In reply to Axel Braun from comment #25)
> (In reply to Stefan Dirsch from comment #12)
> > Reported upstream
> > 
> > https://gitlab.freedesktop.org/xorg/xserver/-/issues/1254
> 
> There is no real progress upstream, except the link back to this bug report.
> Is it an option to revert X-Server to 1.20.x in TW until this is fixed?

I second this, i currently have packages on protected to prevent them from updating, but not everyone is so lucky

What about adding 'xrandr --auto' in /usr/share/sddm/scripts/Xsetup ?

I've tested it and it works as a workaround, until this is eventually fixed in Xorg.
I cannot see any possible problematic side effect of invoking this command in Xsetup. Although it will only work for SDDM.

(In reply to Michael Pujos from comment #27)
> What about adding 'xrandr --auto' in /usr/share/sddm/scripts/Xsetup ?
> 
> I've tested it and it works as a workaround, until this is eventually fixed
> in Xorg.
> I cannot see any possible problematic side effect of invoking this command
> in Xsetup. Although it will only work for SDDM.

Is full functionality(HDMI Port active) with this workaround achieved?:
[P1]: A display session can be started with or without the HDMI/Graphics card working(This means integrated graphics do the job)
[P2]: HDMI Port works and the second graphics card can be used for a second screen as well as ofloading graphics

P1 is the minimal asked functionality on this bug since some users cant even start sddm/DM's

(In reply to Michael Pujos from comment #27)
> What about adding 'xrandr --auto' in /usr/share/sddm/scripts/Xsetup ?

tried this, and does not work for me:
X1E:~ # update-alternatives --display default-displaymanager
default-displaymanager - auto mode
  link best version is /usr/lib/X11/displaymanagers/sddm
  link currently points to /usr/lib/X11/displaymanagers/sddm
  link default-displaymanager is /usr/lib/X11/displaymanagers/default-displaymanager

Hmmm, I use a non standard /etc/sddm.conf, so you might have to add 'xrandr --auto' at the end of /usr/etc/X11/xdm/Xsetup instead.

Another workaround would be to use suse-prime's "offload mode".

(In reply to Stefan Dirsch from comment #31)
> Another workaround would be to use suse-prime's "offload mode".
Wouln'd that impair functionality, Does this mean people can use both the internal screen as well as the HDMI port or does this mean people can only use either the internal screen or the HDMI screen

Hmm. Not sure how suse-prime is related to additional outputs. It just makes use of the discrete nVidia GPU for rendering. It does not help to drive outputs connected to the nVidia GPU. It only supports Optimus systems (everything connected to internal GPU).

The only thing that should be necessary to handle external outputs (HDMI, DP, TB3) managed the the NVIDIA dGPU is a Xorg config using the nvidia Xorg driver (and kernel modules of courses).
So offload should work just fine for this use case (though I did not try it).

(In reply to Michael Pujos from comment #30)
> Hmmm, I use a non standard /etc/sddm.conf, so you might have to add 'xrandr
> --auto' at the end of /usr/etc/X11/xdm/Xsetup instead.

That does not work either. Still a black screen, restarting X-Server does not change result

Meanwhile I've added the patch from https://gitlab.freedesktop.org/xorg/xserver/-/issues/1254#note_1205673 

https://gitlab.freedesktop.org/xorg/xserver/uploads/2cd40ad0605a0a0855a0836ac5673706/0001-xfree86-activate-GPU-screens-on-autobind.patch

to

https://build.opensuse.org/package/show/X11:XOrg/xorg-x11-server

but I haven't tested it yet. Maybe somebody else affected could ....

(In reply to Stefan Dirsch from comment #36)
> but I haven't tested it yet. Maybe somebody else affected could ....

I installed the patched version and it solved the issue for me. Thank you very much!

Thanks @Dura-Kovács This sounds at least promising! :-)

(In reply to Stefan Dirsch from comment #36)

> https://build.opensuse.org/package/show/X11:XOrg/xorg-x11-server
> 
> but I haven't tested it yet. Maybe somebody else affected could ....

Works for me as well! Thanks!

Nice. I just submitted this to factory/Tumbleweed. So let's close this one as FIXED.

This is an autogenerated message for OBS integration:
This bug (1192751) was mentioned in
https://build.opensuse.org/request/show/943815 Factory / xorg-x11-server

The only issue this patch introduced is that mate-panel wouldn't start at login when connected to an external monitor. I shall open a new ticket for this.

I also want to leave a sincere huge "Thank You!" to all people involved to solve this issue.
Having been about to fiddle around with the lot of non-working hints found with too simple google searches I found this solution on here just in time.
The Xserver provided @ https://bugzilla.opensuse.org/show_bug.cgi?id=1192751#c36 saved my recent Tumbleweed update.

Nice work from all of you!

Best regards,
Manuel