SDDM slow on (32-bit) Slackware 15.0?

[Sylvain Robitaille]

Ok, so I'm becoming a very late adopter. Attribute that to how well
Slackware-14.2 has worked for me over the years.

I've only recently started installing Slackware 15.0 on systems: two
laptops so far; One 32-bit and one 64-bit. Of those I've actually
started to configure and use the 32-bit one so far. And for the
most part, that is working rather well. The system itself is not at
all hefty: it's an older Sony Vaio "netbook" computer (essentially
a small laptop), with 2GB of memory (upgraded from 1GB at the same
time that I updated the OS from Slackware-14.2). CPU is "Intel(R)
Atom(TM) CPU N450 @ 1.66GHz", so this is not the computer that will
do any sort of intensive computing, but it's quite adequate for how
I use it (and its compact size is rather important in that context).

What I'm finding, though, is that the display manager (SDDM) is
excruciatingly slow to "wake up" and present the password prompt,
and even when that becomes "visible" it will redraw it a couple of
times before actually responding to entered keystrokes. Once logged
in (or the screen locker unlocked) the system's response seems quite
normal (in fact, I'd argue "faster" with Slackware-15.0 than it was
with Slackware-14.2, but I did add memory as noted above, and replaced
the spinning rust hard drive with an SSD).

I have not yet gotten as far in setting up the other laptop with
Slackware64-15.0, so I'm still at the CLI on that one, and I don't
know if SDDM on that system (an HP Elitebook with 4 x Intel(R) Core(TM)
i5-3320M CPU @ 2.60GHz and 8GB of RAM) will exhibit similar behaviour,
though I'm expecting it to at least be "better", given the more capable
hardware.

SDDM is *supposed* to be lightweight and fast, but it sure doesn't
feel that way to me on the little Sony Vaio ...

I wonder if anyone else has seen this sort of thing with SDDM and has
found a solution. All the searches I've done so far have pointed to
missing haveged as the culprit, but this system has haveged, with its
stock configuration as provided by Slackware. If there's something
else that I should be looking at, I'd very much appreciate a pointer
or two. Thanks in advance.

[Chris Elvidge]

Post by Sylvain Robitaille
Ok, so I'm becoming a very late adopter. Attribute that to how well
Slackware-14.2 has worked for me over the years.
I've only recently started installing Slackware 15.0 on systems: two
laptops so far; One 32-bit and one 64-bit. Of those I've actually
started to configure and use the 32-bit one so far. And for the
most part, that is working rather well. The system itself is not at
all hefty: it's an older Sony Vaio "netbook" computer (essentially
a small laptop), with 2GB of memory (upgraded from 1GB at the same
time that I updated the OS from Slackware-14.2). CPU is "Intel(R)
do any sort of intensive computing, but it's quite adequate for how
I use it (and its compact size is rather important in that context).
What I'm finding, though, is that the display manager (SDDM) is
excruciatingly slow to "wake up" and present the password prompt,
and even when that becomes "visible" it will redraw it a couple of
times before actually responding to entered keystrokes. Once logged
in (or the screen locker unlocked) the system's response seems quite
normal (in fact, I'd argue "faster" with Slackware-15.0 than it was
with Slackware-14.2, but I did add memory as noted above, and replaced
the spinning rust hard drive with an SSD).
I have not yet gotten as far in setting up the other laptop with
Slackware64-15.0, so I'm still at the CLI on that one, and I don't
know if SDDM on that system (an HP Elitebook with 4 x Intel(R) Core(TM)
though I'm expecting it to at least be "better", given the more capable
hardware.
SDDM is *supposed* to be lightweight and fast, but it sure doesn't
feel that way to me on the little Sony Vaio ...
I wonder if anyone else has seen this sort of thing with SDDM and has
found a solution. All the searches I've done so far have pointed to
missing haveged as the culprit, but this system has haveged, with its
stock configuration as provided by Slackware. If there's something
else that I should be looking at, I'd very much appreciate a pointer
or two. Thanks in advance.

I recently installed 32-bit 15 on an old Pentium M 2Gb 200Gb using PXE
and Slackware on a USB stick. The machine won't boot directly from USB.

Using runlevel 4 just results in a blank screen (no login prompt),
requiring a reboot. This happens with sddm.conf using autologin too.
Runlevel 3 allows me to log in at the command line, so I put:
[[ $(tty) == /dev/tty1 ]] && startx
at the end of .bashrc, which works for me.
I can't be bothered trying to fix sddm.

[Sylvain Robitaille]

Post by Chris Elvidge
I recently installed 32-bit 15 on an old Pentium M 2Gb 200Gb using PXE
and Slackware on a USB stick. The machine won't boot directly from USB.

(nod)

Post by Chris Elvidge
Using runlevel 4 just results in a blank screen (no login prompt),
requiring a reboot. This happens with sddm.conf using autologin too.
[[ $(tty) == /dev/tty1 ]] && startx
at the end of .bashrc, which works for me.
I can't be bothered trying to fix sddm.

That's even worse than what I'm seeing. Any chance there's some insight
in /var/log/sddm.log that might help?

[Jimmy Johnson]

Post by Chris Elvidge
I recently installed 32-bit 15 on an old Pentium M 2Gb 200Gb using PXE
and Slackware on a USB stick. The machine won't boot directly from USB.

(nod)

Post by Chris Elvidge
Using runlevel 4 just results in a blank screen (no login prompt),
requiring a reboot. This happens with sddm.conf using autologin too.
[[ $(tty) == /dev/tty1 ]] && startx
at the end of .bashrc, which works for me.
I can't be bothered trying to fix sddm.

Runlevel 4 is right, I think you missed something during the install.
Try '# slackpkg reinstall sddm' and see if that works.

[Chris Elvidge]

Post by Jimmy Johnson

Post by Chris Elvidge
I recently installed 32-bit 15 on an old Pentium M 2Gb 200Gb using PXE
and Slackware on a USB stick. The machine won't boot directly from USB.

(nod)

Post by Chris Elvidge
Using runlevel 4 just results in a blank screen (no login prompt),
requiring a reboot. This happens with sddm.conf using autologin too.
[[ $(tty) == /dev/tty1 ]] && startx
at the end of .bashrc, which works for me.
I can't be bothered trying to fix sddm.

Runlevel 4 is right, I think you missed something during the install.
Try '# slackpkg reinstall sddm' and see if that works.

Complete fuck-up on my part. I had excluded KDE packages and just kept
xfce. KDE/ also in /etc/slackpkg/blacklist. Hence - no sddm. Slackpkg
reinstall sddm says no package!

However, thanks Jimmy, slackpkg reinstall xdm, change inittab to
runlevel 4 and a reboot gives me a login screen.

Sorry for the off-topic chatter.

[Jimmy Johnson]

SDDM is*supposed* to be lightweight and fast, but it sure doesn't
feel that way to me on the little Sony Vaio ...
I wonder if anyone else has seen this sort of thing with SDDM and has
found a solution. All the searches I've done so far have pointed to
missing haveged as the culprit, but this system has haveged, with its
stock configuration as provided by Slackware. If there's something
else that I should be looking at, I'd very much appreciate a pointer
or two. Thanks in advance.

This post is on 14.2 but could be applied to 15.0. "[SOLVED] turned off
the haveged daemon"

https://www.linuxquestions.org/questions/slackware-14/turned-off-the-haveged-daemon-4175680148/

[Sylvain Robitaille]

Post by Jimmy Johnson
This post is on 14.2 but could be applied to 15.0. "[SOLVED] turned off
the haveged daemon"
https://www.linuxquestions.org/questions/slackware-14/turned-off-the-haveged-daemon-4175680148/

Thanks I'll have a look. The trouble, of course, is that if sddm (or
Plasma?) depends on being able to read /dev/random, disabling haveged
might make things worse instead of better ... Still, it's certainly
worth looking into.

[Jimmy Johnson]

Post by Sylvain Robitaille

Post by Jimmy Johnson
This post is on 14.2 but could be applied to 15.0. "[SOLVED] turned off
the haveged daemon"
https://www.linuxquestions.org/questions/slackware-14/turned-off-the-haveged-daemon-4175680148/

Thanks I'll have a look. The trouble, of course, is that if sddm (or
Plasma?) depends on being able to read /dev/random, disabling haveged
might make things worse instead of better ... Still, it's certainly
worth looking into.

Sometimes haveged needs more resources to work, if you can't supply the
resources that is when it needs to be turned off. Read the post before
you make a decision. With 2GB ram it may help to turn it off, but don't
go by what I say, I don't know what I'm talking about. :)

[Sylvain Robitaille]

Post by Jimmy Johnson

Post by Jimmy Johnson
This post is on 14.2 but could be applied to 15.0. "[SOLVED] turned off
the haveged daemon"
https://www.linuxquestions.org/questions/slackware-14/turned-off-the-haveged-daemon-4175680148/

Thanks I'll have a look. ...

Sometimes haveged needs more resources to work, if you can't supply the
resources that is when it needs to be turned off. Read the post before
you make a decision. With 2GB ram it may help to turn it off, but don't
go by what I say, I don't know what I'm talking about. :)

I did read the thread (not just the post), of course, and I have
turned off haveged. /proc/sys/kernel/random/entropy_avail seems
to indicate plenty of entropy available, though sddm still quite
slow to respond, despite the system being otherwise quite usable.
Oh, hang on ... perhaps the delay now is only in the screen locking?
More experimentation to do; If necessary I'll break down and simply
install a different display manager, or perhaps resort to xdm. My
latest tests might have only been of the screen locker, though (in which
case I'll of course want to figure out how to speed it up, but that's a
different matter entirely).

Thanks for following up.

[Petri Kaukasoina]

Post by Sylvain Robitaille
32-bit one
it's an older Sony Vaio "netbook" computer (essentially
a small laptop), with 2GB of memory (upgraded from 1GB at the same
time that I updated the OS from Slackware-14.2). CPU is "Intel(R)
What I'm finding, though, is that the display manager (SDDM) is
excruciatingly slow to "wake up" and present the password prompt,
and even when that becomes "visible" it will redraw it a couple of
times before actually responding to entered keystrokes. Once logged
in (or the screen locker unlocked) the system's response seems quite
normal
SDDM is *supposed* to be lightweight and fast, but it sure doesn't
feel that way to me on the little Sony Vaio ...

I see similar slowness with Slackware64 on a 64-bit Pentium 4 (3.20GHz) with
4 GB RAM and Intel Corporation 82945G/GZ Integrated Graphics Controller.

I don't think SDDM is lightweight. kdm in 14.2 is lightweight and fast. SDDM
uses direct rendering via opengl, and I guess it expects more than the old
Intel graphics can deliver. After I remove file /usr/lib64/dri/i915_dri.so,
sddm behaviour becomes better. Then the llvmpipe software rasterizer does
the rendering instead of the i915 "amber" hardware driver. And it seems to
work better...

Even better, move to xdm. Create file /etc/rc.d/rc.4.local with this content:

#
if [ -x /usr/bin/xdm ]; then
exec /usr/bin/xdm -nodaemon
fi

And chmod +x /etc/rc.d/rc.4.local

[Jim Diamond]

Post by Petri Kaukasoina

Post by Sylvain Robitaille
32-bit one

<snip>

Post by Petri Kaukasoina

Post by Sylvain Robitaille
What I'm finding, though, is that the display manager (SDDM) is
excruciatingly slow to "wake up" and present the password prompt,
and even when that becomes "visible" it will redraw it a couple of
times before actually responding to entered keystrokes. Once logged
in (or the screen locker unlocked) the system's response seems quite
normal
SDDM is *supposed* to be lightweight and fast, but it sure doesn't
feel that way to me on the little Sony Vaio ...

I see similar slowness with Slackware64 on a 64-bit Pentium 4 (3.20GHz) with
4 GB RAM and Intel Corporation 82945G/GZ Integrated Graphics Controller.
I don't think SDDM is lightweight. kdm in 14.2 is lightweight and fast. SDDM
uses direct rendering via opengl, and I guess it expects more than the old
Intel graphics can deliver. After I remove file /usr/lib64/dri/i915_dri.so,
sddm behaviour becomes better. Then the llvmpipe software rasterizer does
the rendering instead of the i915 "amber" hardware driver. And it seems to
work better...
#
if [ -x /usr/bin/xdm ]; then
exec /usr/bin/xdm -nodaemon
fi
And chmod +x /etc/rc.d/rc.4.local

I agree with Petri, why not use xdm. It is fast, lightweight and
reliable. Unless sddm gives you something you really need or want that xdm
doesn't, I don't see the point.

An alternative to creating the file (as Petri suggests) is to do the
far more satisfying
# removepkg sddm

Jim

[Henrik Carlqvist]

Post by Jim Diamond
I agree with Petri, why not use xdm.

Agree, if xdm is good enough for your purposes, use that, it will be the
quickest and easiest solution.

When I started to migrate from Slackware 14.2 to 15.0 sddm turned out to
be a show stopper which had to be replaced. I downloaded, compiled and
evaluated a bunch of different login managers and ended up installing
part of the complete Trinity Desktop Environment just to get access to
its tdm login manager which basically is the same as the kdm login
manager from KDE 3.

My main reason not to take the simple route of xdm was that tdm has a
menu choice of window manager / desktop environment at login. With xdm
you will need to hardcode that choice in configuration files in different
users home directories.

Tdm also looked much like kdm did in previous versions of Slackware,
including a graphical list of users where the list of users could be
taken from a network catalog service.

In my experience the low version number of sddm reflected its bugginess.
It also lacked some features that I had become used to and the developers
stated that one of those features would never be implemented.

regards Henrik

[Chris Elvidge]

Post by Henrik Carlqvist

Post by Jim Diamond
I agree with Petri, why not use xdm.

Agree, if xdm is good enough for your purposes, use that, it will be the
quickest and easiest solution.

For me, the major problem with xdm (on a single user machine) is the
lack of autologin.

I force installed sddm from the kde section of the slackware install dvd
after the conversation up thread and still got a blank screen, albeit
with a pointer, so removed it again.

I've also tried slim (from SBo, self-compiled) but for some reason it
greys out reboot and shutdown buttons on the menu and panel. Even
changing the shutdown and reboot options in slim.conf didn't make it
work. Disabled after 3 tries.

[Sylvain Robitaille]

Post by Chris Elvidge
For me, the major problem with xdm (on a single user machine) is the
lack of autologin.

sddm.conf on the stock sddm installation from Slackware-15.0:

[Autologin]
# Whether sddm should automatically log back into sessions when they exit
Relogin=false

# Name of session file for autologin session (if empty try last logged in)
Session=

# Username for autologin session
User=

Maybe that helps?

Post by Chris Elvidge
I force installed sddm from the kde section of the slackware install dvd
after the conversation up thread and still got a blank screen, albeit
with a pointer, so removed it again.

odd ...

Post by Chris Elvidge
I've also tried slim (from SBo, self-compiled) but for some reason it
greys out reboot and shutdown buttons on the menu and panel. Even
changing the shutdown and reboot options in slim.conf didn't make it
work. Disabled after 3 tries.

Needs elevated privilege, in order to run reboot or shutdown, perhaps?

Perhaps some insight into that exists in the documentation (I'm not
finding anything from an admittedly *quick* search ...)

[Chris Elvidge]

Post by Sylvain Robitaille

Post by Chris Elvidge
For me, the major problem with xdm (on a single user machine) is the
lack of autologin.

[Autologin]
# Whether sddm should automatically log back into sessions when they exit
Relogin=false
# Name of session file for autologin session (if empty try last logged in)
Session=
# Username for autologin session
User=
Maybe that helps?

Post by Chris Elvidge
I force installed sddm from the kde section of the slackware install dvd
after the conversation up thread and still got a blank screen, albeit
with a pointer, so removed it again.

odd ...

Post by Chris Elvidge
I've also tried slim (from SBo, self-compiled) but for some reason it
greys out reboot and shutdown buttons on the menu and panel. Even
changing the shutdown and reboot options in slim.conf didn't make it
work. Disabled after 3 tries.

Needs elevated privilege, in order to run reboot or shutdown, perhaps?
Perhaps some insight into that exists in the documentation (I'm not
finding anything from an admittedly *quick* search ...)

I've now got sddm to work.

I uninstalled sddm and then did a thorough check for anything sddm
related (by filename) and deleted it/them. And rebooted.

Installed sddm (from DVD) and immediately changed sddm.conf to include
Session=xfce (as only xfce is installed, no KDE), and User=chris
Rebooted and it worked, straight to xfce session.

I wonder whether the Session= line in sddm.conf makes a difference. As
sddm is part of KDE, is a blank Session= actually trying to find KDE by
default? And failing unless it is told to start xfce.

Now I've got it working I'm loath to test further.

Shutdown and Reboot are not greyed out, either.

[Sylvain Robitaille]

Post by Henrik Carlqvist
My main reason not to take the simple route of xdm was that tdm has a
menu choice of window manager / desktop environment at login. With xdm
you will need to hardcode that choice in configuration files in
different users home directories.

Yeah; I do like that about kdm; It puzzles me that they didn't carry
that over to sddm ...

Post by Henrik Carlqvist
In my experience the low version number of sddm reflected its
bugginess.

... and that might just be a valid impression ...

Post by Henrik Carlqvist
It also lacked some features that I had become used to and the
developers stated that one of those features would never be
implemented.

:-/ On the other hand, it *is* open-source ... I'm not above hacking
in features I believe I need, if I need such features ...

[Henrik Carlqvist]

:-/ On the other hand, it *is* open-source ... I'm not above hacking in
features I believe I need, if I need such features ...

Yes, but such a fix, if not wanted by upstream developers, basically
means that you then have to clone and maintain your own login manager. It
is not allways easy to get fixes/patches approved by upstream project
maintainers.

I don't remember exactly which feature it was. Maybe it was the
possibility to list users from an LDAP or NIS server, maybe it was the
possibility to only list selected users. However, some googling for that
feature revealed that the developers did not want that feature in sddm.

For me this was the turning point when I realized that I needed to find a
long term solution to replace sddm with. It would not be a solution to
skip Slackware 15.0 and hope for a better login manager in the next
version of Slackware. Right now my plan is to use tdm for Slackware 15
and future versions of Slackware.

I evaluated a bunch of other login managers including lightdm and slim. I
had a number of requirements like being able to select window manager/
destkop environment, presenting a list of selected users from a network
catalog service and menu or buttons to shutdown or reboot. The login
manager also needed to work with screensavers to allow other users to
start new X sessions on another virtual console.

Tde and tdm was a little bit trickier to install than most other
evaluated login managers which often were standalone programs installable
from slackbuilds.org. Tdm (like kdm) requires most of tde installed just
like kdm was part of the kde-workspace package. Once installed though,
tdm behaved like kdm and was configured with a tmrc file looking just
like good old kdmrc.

The only minor annoyance with tdm is that the dialog says "Login to TDE",
but the important thing is that it is possible to select among all the
installed window managers and desktop environments. Yes, it would be
possible to hack the code to make it say something like "Login to
Slackware", but I didn't care to do that.

regards Henrik

[Sylvain Robitaille]

Post by Henrik Carlqvist
Yes, but such a fix, if not wanted by upstream developers, basically
means that you then have to clone and maintain your own login manager.
It is not allways easy to get fixes/patches approved by upstream
project maintainers.

Both true points. It's still an option, though.

Post by Henrik Carlqvist
It would not be a solution to skip Slackware 15.0 and hope for a
better login manager in the next version of Slackware.

I can agree with that ...

With thanks in particular to Petri Kaukasoina for mentioning that
disabling (well, I believe he said he removed it) the i915_dri.so
library helped on his system, I have indeed improved the situation
at this end. It's still not particularly quick, so it might *still*
get xdm or a different display manager instead of sddm, but it *is*
notably improved.

I simply told the X server to disable DRI:

### /etc/X11/xorg.conf.d/90-vaio.conf
# 2023-05-04 Sylvain Robitaille

Section "Device"
Identifier "Card0"
Option "DRI" "false"
EndSection

That makes a noticeable difference. Whether it's enough remains to be
seen.

Thanks to all who followed this and tried to help.

[Sylvain Robitaille]

Post by Jim Diamond
I agree with Petri, why not use xdm. It is fast, lightweight and
reliable. Unless sddm gives you something you really need or want
that xdm doesn't, I don't see the point.

I'm not ruling it out, but I'd like to find the *source* of the problem
and fix *that* before resorting to fixing the symptoms.

Post by Jim Diamond
An alternative to creating the file (as Petri suggests) is to do the
far more satisfying
# removepkg sddm

:-)

[Jim Diamond]

Post by Sylvain Robitaille

Post by Jim Diamond
I agree with Petri, why not use xdm. It is fast, lightweight and
reliable. Unless sddm gives you something you really need or want
that xdm doesn't, I don't see the point.

I'm not ruling it out, but I'd like to find the *source* of the problem
and fix *that* before resorting to fixing the symptoms.

OK, now I see the point. :-)

Good luck fighting the good fight.

Jim

[Sylvain Robitaille]

Post by Jim Diamond

Post by Sylvain Robitaille
I'm not ruling it out, but I'd like to find the *source* of the problem
and fix *that* before resorting to fixing the symptoms.

OK, now I see the point. :-)
Good luck fighting the good fight.

disabling DRI in X configuration seems to have made it quite usable,
and it makes sense in the context of this hardware that that would
be the cause of the problem. I wouldn't call it "swift", but the
truth is that this computer itself could never be accused of being
"swift". It's small and lightweight, and is able to run a modern
Slackware installation. That serves the purposes I have for it.

[Sylvain Robitaille]

Post by Petri Kaukasoina
I don't think SDDM is lightweight. kdm in 14.2 is lightweight and
fast. SDDM uses direct rendering via opengl, and I guess it expects
more than the old Intel graphics can deliver.

Oh! Well that's certainly significant, then. This system is definitely
not up to opengl (it's a small Sony Vaio "netbook", intended for
lighhtweight tasks).

Post by Petri Kaukasoina
After I remove file /usr/lib64/dri/i915_dri.so, sddm behaviour becomes
better. Then the llvmpipe software rasterizer does the rendering
instead of the i915 "amber" hardware driver. And it seems to work
better...

I do see that i915 is loaded on this system, but *not* i915_dri. ah
wait ... you're referring to a library, not the kernel module ...

indeed ...

COMMAND PID USER FD TYPE ... NAME
Xorg 4625 root mem REG ... /usr/lib/dri/i915_dri.so
kwin_x11 4915 syl mem REG ... /usr/lib/dri/i915_dri.so
plasmashe 4964 syl mem REG ... /usr/lib/dri/i915_dri.so
kmix 5003 syl mem REG ... /usr/lib/dri/i915_dri.so
wpa_gui 5061 syl mem REG ... /usr/lib/dri/i915_dri.so
firefox 6118 syl mem REG ... /usr/lib/dri/i915_dri.so
kscreenlo 15977 syl mem REG ... /usr/lib/dri/i915_dri.so

so ... definitely something worth looking into here ... Thank you.

Post by Petri Kaukasoina
Even better, move to xdm. ...

I might just do that, but I'd *like* to use the newer display manager
if I can, especially if it isn't *really* the problem.