sddm greeter not shown after update (KDE+X11)

fakirinho · 2024-02-29 08:02:25

Hi! After last update I did yesterday, greeter is no longer being displayed, only mouse cursor visible and "movable". I'm running Arch with KDE, Nvidia GPU (integrated Intel graphics card is disabled). KDE and X11.

journalctl hints that sddm-greeter has dumped core.

When I switch to some other tty, after logging in I get:

Cannot open display "default display"

When I manually start sddm-greeter I get:

[08:53:20.134] (II) GREETER: High-DPI autoscaling enabled
[08:53:20.139] (WW) GREETER: could not connect to display
[08:53:20.140] (II) GREETER: Could not load the Qt platform plugin "xcb" in "" even though it was found.
[08:53:20.141] (WW) GREETER: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix the problem.

I have not changed any settings recently. After the update, I have had issue powering my laptop off, as it hanged for quite some time showing tty1 output (few lines from boot time, nothing new), not responding to keystrokes. Then I have forcibly shut it down...

Hard to paste some more logs, if some more output is neede, I can ... post a photo

Any advise?

Last edited by fakirinho (2024-02-29 08:06:06)

seth · 2024-02-29 08:14:47

journalctl hints that sddm-greeter has dumped core.

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855

Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

And that coredump would likely be helpful to gage the problem, too…
https://wiki.archlinux.org/title/Core_d … _core_dump

fakirinho · 2024-02-29 08:28:27

seth wrote:

Please post your complete system journal for the boot

http://0x0.st/HRtF.txt

When it comes to core dump, I'm slowly working on it.

fakirinho · 2024-02-29 08:36:58

...and core dump related info: http://0x0.st/HRv6.txt

seth · 2024-02-29 08:38:13

It's in the journal

Feb 29 09:23:17 PLPCLPD-1035 systemd-coredump[1087]: Process 1034 (sddm-greeter) of user 973 dumped core.
                                                     
                                                     Stack trace of thread 1034:
                                                     #0  0x00007473368ab32c n/a (libc.so.6 + 0x8d32c)
                                                     #1  0x000074733685a6c8 raise (libc.so.6 + 0x3c6c8)
                                                     #2  0x00007473368424b8 abort (libc.so.6 + 0x244b8)
                                                     #3  0x0000747336e980c2 _ZNK14QMessageLogger5fatalEPKcz (libQt5Core.so.5 + 0x980c2)
                                                     #4  0x00007473383b0b34 _ZN13QSGRenderLoop28handleContextCreationFailureEP12QQuickWindow (libQt5Quick.so.5 + 0x1b0b34)
                                                     #5  0x00007473383b1919 n/a (libQt5Quick.so.5 + 0x1b1919)
                                                     #6  0x00007473383b68f5 n/a (libQt5Quick.so.5 + 0x1b68f5)
                                                     #7  0x0000747337545b81 _ZN7QWindow5eventEP6QEvent (libQt5Gui.so.5 + 0x145b81)
                                                     #8  0x0000747337093ef8 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 0x293ef8)
                                                     #9  0x0000747337538f34 _ZN22QGuiApplicationPrivate18processExposeEventEPN29QWindowSystemInterfacePrivate11ExposeEventE (libQt5Gui.so.5 + 0x138f34)
                                                     #10 0x000074733751a6d5 _ZN22QWindowSystemInterface22sendWindowSystemEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Gui.so.5 + 0x11a6d5)
                                                     #11 0x000074733272f540 n/a (libQt5XcbQpa.so.5 + 0x5f540)
                                                     #12 0x000074733590df69 n/a (libglib-2.0.so.0 + 0x59f69)
                                                     #13 0x000074733596c3a7 n/a (libglib-2.0.so.0 + 0xb83a7)
                                                     #14 0x000074733590c162 g_main_context_iteration (libglib-2.0.so.0 + 0x58162)
                                                     #15 0x00007473370e2d0c _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2e2d0c)
                                                     #16 0x0000747337092c04 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x292c04)
                                                     #17 0x00007473370940a3 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2940a3)
                                                     #18 0x000061df61b7d5b5 n/a (sddm-greeter + 0x125b5)
                                                     #19 0x0000747336843cd0 n/a (libc.so.6 + 0x25cd0)
                                                     #20 0x0000747336843d8a __libc_start_main (libc.so.6 + 0x25d8a)
                                                     #21 0x000061df61b80655 n/a (sddm-greeter + 0x15655)

Feb 29 09:23:16 PLPCLPD-1035 sddm-greeter[1034]: QGLXContext: Failed to create dummy context
Feb 29 09:23:16 PLPCLPD-1035 sddm-greeter[1034]: failed to acquire GL context to resolve capabilities, using defaults..
Feb 29 09:23:17 PLPCLPD-1035 sddm-greeter[1034]: Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(ResetNotification), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)

Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General

fakirinho · 2024-02-29 08:48:39

seth wrote:

Please post your Xorg log

There it goes: http://0x0.st/HRvC.txt

seth · 2024-02-29 09:02:20

Get rid of xf86-video-intel and enable https://wiki.archlinux.org/title/NVIDIA … de_setting - use the "nvidia_drm.modeset=1" kernel parameter (modprobe.conf won't do!), stay away from fbdev=1 until nvidia has fixed that.

You've a hybrid graphics system and are somehow (likely because of the simpledrm device flipping the card order) on the nvidia GPU, but all outputs are on the intel one that uses the modesetting driver despite xf86-video-intel being loaded (what you don't want)

fakirinho · 2024-02-29 09:26:12

Still no luck. Uninstalled mentioned intel drivers, but also switched back to proprietary drivers I was using for years (last time I've uploaded journal and Xorg log was on nvidia-open to which I've had switched to check if it changes anything; now I'm back to proprietary "nvidia" drivers). Also, unplugged the laptop from the dock, so that the logs are bit clearer: less devices, simpler config.

Here is journal once again: http://0x0.st/HRwN.txt
and Xorg.0.log: http://0x0.st/HRwq.txt

Also, nvidia_drm modeset is as requested:

$ sudo cat /sys/module/nvidia_drm/parameters/modeset
Y

seth · 2024-02-29 09:36:30

The order is still reversed

[    16.884] (**) OutputClass "nvidia" ModulePath extended to "/usr/lib/nvidia/xorg,/usr/lib/xorg/modules,/usr/lib/xorg/modules"
[    16.884] (**) OutputClass "nvidia" ModulePath extended to "/usr/lib/nvidia/xorg,/usr/lib/xorg/modules,/usr/lib/nvidia/xorg,/usr/lib/xorg/modules,/usr/lib/xorg/modules"
[    16.884] (**) OutputClass "nvidia" setting /dev/dri/card1 as PrimaryGPU

grep -ri nvidia /{etc,usr/share}/X11/xorg.conf*

I suspect the SDDM failure isn't b/c or a broken GL installation but

[    16.984] (II) NVIDIA(0):     "NULL"
[    17.157] (II) NVIDIA(0): Setting mode "NULL"

and missing reverse prime.

"ibt=off " is btw. no longer required.

fakirinho · 2024-02-29 09:56:30

grep -ri nvidia /{etc,usr/share}/X11/xorg.conf*

...results in http://0x0.st/HRwJ.txt

I need to check how I've forced my system to start on nvidia GPU, not intel. I'm sure I've followed one of the methods on ArchWiki. Maybe that method got invalidated?

seth · 2024-02-29 09:58:27

/etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf
/usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf

Post both files. In doubt move /etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf away (out of /etc/X11)

fakirinho · 2024-02-29 10:15:51

Both outputs in one go: https://0x0.st/HRwU.txt

I've followed this method to force system to use only nvidia GPU: https://wiki.archlinux.org/title/NVIDIA … phics_only

seth · 2024-02-29 10:22:47

You're not going to run on the nvidia chip *only* (this way)
If you want to and can, disable the IGP in teh BIOS/UEFI

Otherwise make sure to have

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

and
a) the output names have to match (xrandr --listproviders)
b) xinitrc is irrelevant for SDDM, https://wiki.archlinux.org/title/NVIDIA_Optimus#SDDM

However, to establish whether that condition is the cause at all, just remove the config first.

fakirinho · 2024-02-29 10:25:28

moving /etc/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf out of /etc/X11 did the trick. although obviously I've landed on Intel:

[stawka@PLPCLPD-1035 ~]$ glxgears -info
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER   = Mesa Intel(R) UHD Graphics (TGL GT1)
GL_VERSION    = 4.6 (Compatibility Profile) Mesa 24.0.1-arch1.1
GL_VENDOR     = Intel

I've also (long time ago) followed the remaining part of that linked page - so I've set the stuff in ~/.xinitrc and /usr/share/sddm/scripts/Xsetup as described in the article.

Last edited by fakirinho (2024-02-29 10:27:02)

fakirinho · 2024-02-29 10:30:22

ouch. isn't that the issue?

[stawka@PLPCLPD-1035 ~]$ xrandr --listproviders 
Providers: number : 2
Provider 0: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 7 associated providers: 0 name:modesetting
Provider 1: id: 0x2ba cap: 0x0 crtcs: 0 outputs: 0 associated providers: 0 name:NVIDIA-G0

name is now NVIDIA-G0, not NVIDIA-0, as I have configured for SDDM:

[stawka@PLPCLPD-1035 ~]$ cat /usr/share/sddm/scripts/Xsetup
#!/bin/sh
# Xsetup - run as root before the login dialog appears
/usr/NX/scripts/vgl/vglgenkey
xrandr --setprovideroutputsource modesetting NVIDIA-0
xrandr --auto

seth · 2024-02-29 10:58:08

"xrandr --setprovideroutputsource modesetting NVIDIA-0" will certainly fail, yes.

fakirinho · 2024-02-29 11:19:18

I've updated both - ~/.xinitrc and /usr/share/sddm/scripts/Xsetup - so that "NVIDIA-0" was changed to "NVIDIA-G0", moved 10-nvidia-drm-outputclass.conf back into /etc/X11/xorg.conf.d/ but the behaviour is exactly the same - sddm-greeter core-dumps the same way, all the symptoms remaining the same, according to my brief check. This is the difference I get on xrandr when using NVIDIA-0 and NVIDIA-G0 - it seems both are failing, but G0 option is much different (well, if the NVIDIA-0 is wrong name, there's no surprise it fails like it does, but the G0 failure is not understandable to me...)

[stawka@PLPCLPD-1035 ~]$ xrandr --setprovideroutputsource modesetting NVIDIA-0
Could not find provider with name NVIDIA-0
[stawka@PLPCLPD-1035 ~]$ xrandr --setprovideroutputsource modesetting NVIDIA-G0
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:  0x2d4
  Serial number of failed request:  16
  Current serial number in output stream:  17

So I've moved 10-nvidia-drm-outputclass.conf out of the /etc/X11/xorg.conf.d/ again, just to have working setup that is bit more convenient to discuss than my smartphone I'm eager to pursue this further and have it solved. I'm really interested in having my setup running fully on nvidia GPU or really easily switchable to the discrete card, so I'm also open to some other suggestions.

fakirinho · 2024-02-29 15:02:17

...what I have observed now is that when I move file 10-nvidia-drm-outputclass.conf back into the /etc/X11/xorg.conf.d/ and reboot the system, I still have core dump on the sddm-greeter, but when I start session manually on different tty (startx /usr/bin/startplasma-x11), I get the proper login screen and can start KDE Plasma session.

Could there be something wrong with the Xorg configuration?

seth · 2024-02-29 15:08:01

What does the xorg log for the later X11 session look like?
What's the output of "glxinfo -B" in that session?

SDDM crashes in the client code, though.
It fails to create GL context and then nose-dives.

I'll re-stress that the by far best approach here is to disable the IGP in the firmware, if that's possible.
It'll spare you the framebuffer copies.

fakirinho · 2024-02-29 16:05:31

seth wrote:

What does the xorg log for the later X11 session look like?
What's the output of "glxinfo -B" in that session?

shit managed to hit the fan when it comes to this solution - it no longer works not sure how I managed to do so... for sure, in the meantime, with that "bloody 10-nvidia-drm-outputclass.conf moved out of /etc/X11/xorg.conf.d/" I've did the the "nvidia-xconfig" (sudo) and tried to rebooting afterwards with the file moved back. obviously, no luck. then I've removed the nvidia-xconfig generated file and tried to grab xorg log as you've asked, but then it was no longer working

seth wrote:

I'll re-stress that the by far best approach here is to disable the IGP in the firmware, if that's possible.
It'll spare you the framebuffer copies.

I'd love that and even went to try it back once more (as I did that check almost two years ago), but my BIOS is not allowing this. plenty of configuration stuff, nothing about the GPUs...

For now, it seems that I've lost the possibility of using nvidia GPU. which sucks. not that I need it often, but I want to have that possibility... Any other ideas?

Ahh, when I managed to start that "separate" KDE Plasma session (startx /usr/bin/startplasma-x11), xrandr shown the name of the GPU as a NVIDIA-0, not NVIDIA-G0. that change of the name shown by xrandr alone is bit odd to me. I'm starting to think I should blame nvidia drivers.

seth · 2024-02-29 20:29:41

tried to grab xorg log as you've asked, but then it was no longer working

What is "not working"?
Ideally provide journal and xorg log for the broken status quo
There's another thread facing a crash in the nvidia 550xx kernel module, so you might want to try to downgrade that (and the kernel) or use an older 545xx dkms module from the ALA.

Arch Linux

#1 2024-02-29 08:02:25

sddm greeter not shown after update (KDE+X11)

#2 2024-02-29 08:14:47

Re: sddm greeter not shown after update (KDE+X11)

#3 2024-02-29 08:28:27

Re: sddm greeter not shown after update (KDE+X11)

#4 2024-02-29 08:36:58

Re: sddm greeter not shown after update (KDE+X11)

#5 2024-02-29 08:38:13

Re: sddm greeter not shown after update (KDE+X11)

#6 2024-02-29 08:48:39

Re: sddm greeter not shown after update (KDE+X11)

#7 2024-02-29 09:02:20

Re: sddm greeter not shown after update (KDE+X11)

#8 2024-02-29 09:26:12

Re: sddm greeter not shown after update (KDE+X11)

#9 2024-02-29 09:36:30

Re: sddm greeter not shown after update (KDE+X11)

#10 2024-02-29 09:56:30

Re: sddm greeter not shown after update (KDE+X11)

#11 2024-02-29 09:58:27

Re: sddm greeter not shown after update (KDE+X11)

#12 2024-02-29 10:15:51

Re: sddm greeter not shown after update (KDE+X11)

#13 2024-02-29 10:22:47

Re: sddm greeter not shown after update (KDE+X11)

#14 2024-02-29 10:25:28

Re: sddm greeter not shown after update (KDE+X11)

#15 2024-02-29 10:30:22

Re: sddm greeter not shown after update (KDE+X11)

#16 2024-02-29 10:58:08

Re: sddm greeter not shown after update (KDE+X11)

#17 2024-02-29 11:19:18

Re: sddm greeter not shown after update (KDE+X11)

#18 2024-02-29 15:02:17

Re: sddm greeter not shown after update (KDE+X11)

#19 2024-02-29 15:08:01

Re: sddm greeter not shown after update (KDE+X11)

#20 2024-02-29 16:05:31

Re: sddm greeter not shown after update (KDE+X11)

#21 2024-02-29 20:29:41

Re: sddm greeter not shown after update (KDE+X11)

Board footer