DWM and init4 graphic session with SDDM

joenew · 06-02-2022, 11:41 AM

I've used DWM window manager for years with Slackware 14.2, and now after upgrading to 15.0 I noticed some strange behavior.
In the end I installed Slackware 15.0 from scratch on a clean partition, to exclude the cause was related to some issue in my old config. But in fact that strange problem appears even on this vanilla installation.

What happens:
Let's say you have two windows on the "tag 1" (workspace 1), for instance a terminal and a browser window, and the "tag 2" is empty.
When you change from tag "1" to "2", the image of previous screen persists, instead you expected the new tag empty or with your background wallpaper. It's like the previous screen image getting the new one "dirty". The image of terminal and browser windows will still appear in front of you but it's just an image on the screen, you cannot interact with these windows... Hope I explain clearly enough...

When happens:
It happens with runlevel 4 only.
On new clean slack I set init4 in inittab and SDDM display manager appears, then I created a "dwm.desktop" file in /usr/share/xsessions which calls "Exec=/usr/bin/start-dwm-session". This is just a copy of my usual xinitrc shell script.

If I switch back to init3 runlevel, the issue disappears.
I would stay in "init3" as in the past but I need an app, "TeamViewer", that requires a graphic display manager taking control of graphic session.

I noticed this issue both with dwm-6.2 available on slackbuilds.org and 6.3, packaged using the same script a bit edited.

Is there any dwm user can test it?
Any suggests are really appreciated!

ethelack · 06-03-2022, 11:08 AM

Have installed the slackbuild dwm and using sddm I notice the same behaviour but I have a cron job that runs every five minutes which changes the wallpaper, as soon as it changed the behaviour disappeared. Does your $HOME/.xinitrc have an entry setting the wallpaper this may be why you do not have the problem using dwm from level 3.

my script is:
#!/bin/sh
feh --randomize --bg-scale --no-fehbg ~/Pictures &

If it exists SDDM executes $HOME/.xsessionrc script after login so you could try putting a feh command in there and seeing if it will fix it.

Tried it and it worked for me.

joenew · 06-03-2022, 11:33 AM

No, I haven't any wall paper.
When I usually start dwm, both in init4 and in init3, I just see a black raw background.

Try to test after commenting "feh" line in your xinitrc, you should reproduce this strange behavior.
On the other hand you could try to temp switch to init3, close your working windows, then launch as root:

"telinit 3"

X session will quit and you can login in TTY.
Then "startx" having an ~/.xinitrc in which is called "dwm".

You should noticed no problems even without any wallpapers...

Let me know if you can test, thanks!

joenew · 06-03-2022, 01:02 PM

By adding a wallpaper using "feh" solves:

Code:

feh --bg-scale .config/wallpaper.png &

Or at least hides the issue..

The question:
is that a issue or is just due to dwm lack of internal support for wallpapers?

I don't know, may be a display manager expects that feature active in DE.
This would explain no issues using xfce or plasma.
I also tried with XDM and it seems to add its own light blue wallpaper, solving the problem.
Maybe SDDM has not a default activated wallpaper an demands DE/WM for that.

If you know some more precise explanations, will be appreciated!
Thanks for suggest!

ethelack · 06-03-2022, 07:49 PM

By default SDDM runs /usr/share/sddm/scripts/Xsession which executes any xinitrc scripts which exist in system wide /etc/X11/xinit/xinitrc.d but not $HOME/.xinitrc instead it will execute $HOME/.xsessionrc if it exists.

XDM runs /etc/X11/xdm/Xsession which has a case for failsafe to execute "xsetroot -solid SteelBlue" perhaps dwm defaults to it.

joenew · 06-04-2022, 07:51 AM

In my config it works a bit different, seems sddm looks for ".desktop" files in /usr/share/xsessions/ dir. Here there are various config files, one for each desktop environment.
Below my dwm config:

Code:

$ cat /usr/share/xsessions/dwm.desktop 
[Desktop Entry]
Name=dwm Session
Comment=Use Xsession to start the desktop configured by xwmconfig
Exec=/usr/bin/start-dwm-session

It calls "start-dwm-session" for execution, which is a copy of my ~/xinitrc script.
As you wrote likely this config wasn't needed, thanks to /usr/share/sddm/scripts/Xsession script tat calls the other scripts you explained.
Anyway... That's not the matter, I mean persistent image of previous screens cannot depend on what config file is used to manage the graphic session, or better it does depend on it (if you have "feh" launched for instance the problem disappears) but this doesn't answer why without a wallpaper we notice that ugly behavior. Hope the sense of my question is clearer.

As regard XDM... so, if it didn't have any failsafe xsetroot definition we should notice the same problem of SDDM, right?