I have seen this behavior in two of my computers. Both have NVIDIA cards, but one was using nouvoau and the other the proprietary one. In one case this behavior only happened after a kernel update (the other happened right after upgrading from 14.2 to 15.0). Both of these computers are pure 64-bit (no multilib), On all my other machines this problem does not happen and sddm is working fine (and some have nvidia cards).

Looking at my Xorg log files I see that in both cases X starts fine, detects all hardware and then SDDM just exits (ie there is no error at all in the log, just a clean exit). I've never managed to find out why sddm quits right after starting.

I got tired of looking for answers, so I just switched to xdm on those computers (created an /etc/rc.d/rc.4.local that goes straight to xdm, without trying sddm).

xorg is increasingly becoming automated and i am wondering if it can be a problem as well. For the most part it seems to work but it
still needs to pointed in the right direction sometimes. I switched back to intel graphics (intel uhd graphics 630) and with a bit of
tweaking i have it working well enough for my purpose for now. Just to see if i could get sddm working i tried it with the intel graphics and ended up with
a black screen although i was able to open another terminal and startx despite it so it was not a lockup and afterward when sddm was un-commented
in /etc/rc.d/rc.4 xdm worked again so go figure it. If you wanted xorg log i have attached it too for this set up. as well as my intel xorg.conf.

Let's try again.... sddm has its own log; did you check that? As your problem seems to center on sddm (& nvidia) it might tell you where the spanner gets in; xorg.log seems a red herring when other xorg stuff is functional...

Ok well i have to agree maybe the sddm log would be a place to look as well. i will attach it.
Funny i should have looked here a bit more. i could not see anything here that meant anything to me

Attached Files

sddm.log (11.0 KB, 18 views)

Sunny Jim, I saw authentication issues, probably from executing SDDM as User instead of root. Ideally set inittab to runlevel 3 and login as root. Disable your Wayland Cinammon script and jkust let SMM take you to the GUI Chooser/Login page. From there you can choose among the options for whichever WM/DE you want and determine IF they work... Wayland might not. Any WM/DE that fails will simply drop you back to the Chooser/Login screen so you can login to one that does work or troubleshoot the one that didn't.

Ok i looked again at the sddm.log after i erased it and tried again and couldn't see anything about Wayland or Cinammon. I remember switching to cinnamon to try to see if it would help and i switched
back to kde and still no sddm functionality in either desktops. I have attached a new fresher sddm.log

Attached Files

sddm.log (323 Bytes, 10 views)

yeah my xorg.conf ties things up pretty much so i think that part is ok. It might have helped if sddm hadn't been so tightly integrated that you cannot see a separate source package
to more easily examine the source code. xdm works well enough i suppose and even has themes for it in sbopkg although i might have liked to use some of the different themes shown for sddm
in the control centre, funny and when i looked at xdm and how it runs it does not seem to use xorg.conf but seems to do it's own thing. Why reinvent the wheel when you have a configuration
file for xorg already ? Maybe this is why sddm fails because it was made like xdm but it does not do as good of a job.

Nothing mysterious at all. The SDDM source code is here: https://slackware.uk/slackware/slack...-0.19.0.tar.xz
I think you are mixing up concepts here.
XDM and SDDM are both graphical session managers. You do not need either of them if you want to run or use X.Org. In Runlevel 3 you can just type "startx" to get logged into your graphical X session. In runlevel 4 you get greeted with a login GUI, but XDM and SDDM are nothing more than a program that runs on top of your X.Org and pre-configure some of the aspects of your graphical X session for you.
Considering your lack of understanding of the interactions between X.Org, SDDM and XDM and the differences/similarities between XDM and SDDM, perhaps you need to re-examine your configurations because I think your problems are self-inflicted.
You could perhaps simplify your troubleshooting by downloading a Live version of Slackware 15 and boot that from a USB stick. Does SDDM show the same issues in Slackware Live as on your own installation of Slackware?
Get the ISO from https://slackware.nl/slackware-live/...e64-15.0-live/ or from https://slackware.uk/liveslak/slackware64-15.0-live/

Did the same thing on 14.0 when kdm required a bunch of stuff I didn't want.
Since then I just use XDM and nothing else, sddm is too fat for my use case anyway.
You know sddm depends on KDE and will not work without it, right?
I'd fork a startx script if XDM weren't there, but prefer graphical login for rc.4 TBH.

How can something be 'too fat for your use case' ? Is your PC low on disk space? Most of space taken up by the sddm package is bitmaps that are part of the SDDM theming.
This is not true. SDDM depends on Qt5 only, there is no dependency on KDE at all.

Feature creep. And qt5 in Slackware is part of KDE project, hosted by KDE project, patched by KDE project, and maintained by KDE project.

From that I'll venture a guess that you stopped using KDE when v4 was released and never looked back. Understandable but no longer accurate. V4 got decent after 2 years. Plasma 5 has always been decent. KDE learned a hard lesson back when v4 first was released. Default KDE Plasma 5, complete with the Evil 3, Akonadi, Baloo, and all that indexing stuff, uses about 940MB RAM on this box and Xfce uses about 850MB. If I turn off all the indexing "offenders", Plasma 5 drops to under 800MB. I have a few installs that utilize closer to 500MB.

SDDM is not bloated by default and can be configured to use even less. I have a few distros using other DMs, like LightDM. SDDM by default uses roughly the same resources and can easily be customized to use less. I can sort of understand not wanting to mess with KDE but sacrificing QT cuts one off from a lot of really good software. The main reason I have so many drives/partitions and systems installed is to keep abreast of Linux progress. It is by no means stagnant, though systemd is a substantial "spanner in the gearbox". It, too, has improved but I'm not at all fond of the divergence it has caused for very little gain for most users.

It's not that I want to get rid of qt, far from it. I used qt3 qt4 and qt5 before.
My problem's that KDE has been using all of qt extensions, and I want just qtbase without 1st, 2nd, and 3rd party extensions.
So I compile my own qtbase package from the start, avoiding any dependencies which official packages may or may not bring.
This also means I never report any qt bugs here, considering my system's way beyond official support.
I do sometimes report Slackware bugs, but only if I can reporoduce them on default Slackware ...

That's pretty cool, elcore, but it doesn't change the fact that SDDM is quite lightweight, comparing nicely with all the others, just having more features, but features easily disabled for minimalists. It's perfectly valid not to use it for ANY reason (even just "I don't like it") but it is best to not misrepresent, right?

hmm i have been having weird drm errors in the xorg log so i reinstalled libdrm (slackpkg reinstall libdrm) and that fixed the errors (WW)
and just out of curiosity i tried sddm again and the normal console login screen on vt 1 locked up! Although i was able to switch
to another terminal and startx and post this entry. I have attached the update relevant log. I just wonder why cinnamon is being mentioned
among other things when i am using update slackware 15 kde plasma?

Attached Files

sddm.log (1.7 KB, 10 views)