Excalibur RC1 + Xfce + slim + auto login shows Untitled window

Eeqmcsq · 2025-10-12 20:22:19

Has anyone tried using Excalibur + slim display manager and turned on auto login? I'm seeing a black window covering the desktop with an "Untitled window" in the top panel. My investigation suggests that slim is launching this window. I can click on it and close it with Alt+F4, and the normal Xfce desktop is now shown.

https://imgur.com/a/71EY4uv

I've seen this on two PCs now, (AMD A6-3620, AMD FX-8120), so I don't think it's something weird with one specific PC.

I don't see this problem in Excalibur + MATE, because choosing MATE installs lightdm, not slim. I also don't see this problem in Daedalus + Xfce + slim. So something must have changed in slim between Daedalus and Excalibur.

If no one has any solutions or workarounds, I'll have to download the slim source code in Daedalus and Excalibur, and find out what's going on - yuck

* Test details

- Image file: devuan_excalibur_6.0.0-rc1_amd64_netinstall.iso
- Downloaded from: https://files.devuan.org/devuan_excalib … aller-iso/
- UEFI or Legacy boot doesn't matter.
- In the installer's "Software selection" screen, I chose these:
- Devuan desktop environment
- Xfce
- SSH server
- standard system utilities

- After the installation, manually log in to the Xfce desktop.
- Turn on slim's auto login:
- sudo mousepad /etc/slim.conf
- Uncomment "default_user", and specify <your user name>.
- Uncomment "auto_login", and specify "yes".
- Reboot to trigger the auto login to the Xfce desktop
- In the Xfce desktop, the main desktop pane is blocked by a black window. The Xfce's top and bottom panels appear on top of the window in their correct positions (top/bottom) of the screen. In the top panel, I see a window "button" titled "Untitled window".

If I right click on this "Untitled window" -> Launch New Instance, I see this error: "Failed to execute child process "/proc/1415/exe" (Permission denied)".

Using ps -ef | grep 1415, the 1415 process is "/usr/bin/slim -d".

If I run "sudo /proc/1415/exe", I see "slim: Another instance of the program is already running with the PID 1415", confirming that 1415 is slim.

My current conclusion is that this window was launched by slim, intended for the login screen. But after auto logging in, slim didn't clean up the unneeded window.

golinux · 2025-10-12 20:50:02

There has been some action on slim in the last few days

<devuanci> Starting build pdns-recursor (unstable:arm64) for job devuan-package-builder (previous build: STILL UNSTABLE -- last SUCCESS slim_1.4.1-1devuan1+excalibur1 (excalibur-proposed-updates) 1 day 0 hr ago)

<devuanci> Starting build pdns-recursor (unstable:arm64) for job devuan-package-builder (previous build: STILL UNSTABLE -- last SUCCESS slim_1.4.1-1devuan1+excalibur1 (excalibur-proposed-updates) 21 hr ago)

It should be ready for Excalibut release when that finally happens.

Altoid · 2025-10-12 20:58:21

Hello:

Eeqmcsq wrote:

... something must have changed in slim between Daedalus and Excalibur.

golinux wrote:

... some action on slim in the last few days.

There was a bug marked as done some days ago:

devuan-dev @2025-10-11 05:46 -300 wrote:

bug#857: marked as done (slim 1.4.1 auto_login window bug) ### <--- this

https://lists.dyne.org/lurker/message/2 … 5d.en.html

Maybe not competely squashed or [?] but not a problem, it is just RC1.

golinux wrote:

... should be ready for Excalibut release ...

Exactly. 8^D

Best,

A.

Last edited by Altoid (2025-10-12 21:05:43)

Eeqmcsq · 2025-10-12 22:29:43

One thing that makes me uneasy about the fix, the guy wrote:

"Maybe someone who actually knows what they are doing can fix this?"

That always makes me nervous about whether the code change is really a fix, or whether it breaks something else. We'll see.

golinux · 2025-10-12 22:43:14

Eeqmcsq (and other complainers) . . . You are always very welcome to provide a better option if you doubt those who are taking action to fix it.

Eeqmcsq · 2025-10-12 22:46:35

Yes, I understand. That's why I'm currently trying to figure out how to download the slim package so I can read the code and get an idea of what that area of code is doing. It's not something I wanted to do today, but I want a reliable fix.

Altoid · 2025-10-12 22:48:08

Hello:

Eeqmcsq wrote:

... really a fix, or whether it breaks something else.

Good question ...

And that's exactly what release candidates* are for: finding the answer/s. ;^ )
* testing cycles prior to finally releasing Excalibur to stable.

There's nothing to be nervous about, just have to be patient.

Best,

A.

fsmithred · 2025-10-12 23:39:25

"Maybe someone who actually knows what they are doing can fix this?"

That quote sounds familiar, as in - I wrote that regarding merging some branches in the documentation section of our git repo. I'm not sure how to best do it without screwing up the repo. It had nothing to do with slim unless someone else said the same words.

Try the version of slim in excalibur-proposed-updates. 1.4.1-1devuan1+excalibur1

code can be fount here: https://git.devuan.org/devuan/slim/src/ … ed-updates

rbit · Yesterday 01:10:52

Someone else said those words here https://bugs.devuan.org/cgi/bugreport.cgi?bug=857
see also, https://git.devuan.org/devuan/slim/issues/9

Yes, it is unknown whether the patch will cause other issues at this point, that's what testing should help with.

Also of note, this bug is reported to debian, and they may come up with another (better) fix.
https://bugs.debian.org/1117831

Last edited by rbit (Yesterday 01:11:37)

Eeqmcsq · Yesterday 04:33:56

I did some tests between Dadealus's slim and Excalibur's slim. I don't have an explanation for why the code was changed, but I have a guess. I also don't have a good proposal for a solution, because I don't understand enough about the login error handling and XWindows to figure out where to move the code. Not in one afternoon, anyway.

* Daedalus slim
When Daedalus slim shows the login screen, if there are 2 monitors, the login screen is shown on one monitor, and the other monitor shows the background. In the case of Devuan, the background is a small solid blue 50x31 image, which slim tiles horizontally and vertically. So slim shows a solid blue background, which looks OK on the 2nd monitor.

But if you have a unique background image, that unique image gets tiled over to the 2nd monitor. Now the user sees two monitors with this unique background, but only one of them contains the login screen. So this is my guess as to the original reason why the code was changed - to not show anything on the 2nd monitor, which does not contain any login GUI, to avoid confusing the user.

When slim starts, it requests for a Display, a Screen, and a Root window. I don't understand these XWindows concepts, but my debugging shows that the width and height is the sum of both monitors side by side, such as 3840x1080.

* Excalibur slim
In Excalibur slim, the implemented solution was to create a child window that's the width/height of just the primary monitor. All of the login window's GUI/background/etc will be placed inside this child window. As a result, nothing is shown on the 2nd monitor.

When you log in manually, Excalibur slim destroys the child window that it created, so you don't see this child window.

But when you autologin, the code jumps straight to the user/password login logic, and never destroys this child window, resulting in this "Untitled window" that's the size of the primary monitor. That's because the code never NEEDED to clean up any child windows before. The previous Root window was owned by the X server.

So it sounds easy to say "just destroy the child window before doing the auto login", but I don't know what happens if the auto login fails and slim has to show the login GUI. Will the code recreate a new child window for the login GUI? If yes, someone will have to move the code logic so this child window gets recreated when it's needed. This means refactoring the code and retesting the different code paths, including error handling code paths.

The reason why commenting out the code block seems to work is that both the child window and the Root window refer to the same Root window. So the behavior ends up being the same as Daedalus slim - there's no untitled window, but the background tiles to the 2nd monitor. And the slim code is smart enough to recognize that the child window refers to the same Root window, so it does NOT try to destroy the Root window that it didn't create.

That's all the time I have for this problem. It'll be up to the Debian maintainers who should know this code better than I can - at least in 1 afternoon's debugging - to figure out a good solution.

Eeqmcsq · Yesterday 05:00:54

@fsmithred: I never figured out how to download from git, and I don't think I'll have time to sidetrack and figure that out (waaay too many other hobby-time projects in progress). So I can't compile and test the "excalibur-proposed-updates" branch.

But I CAN download the two main files related to this problem - "app.cpp", "panel.cpp" - and compare them to the Excalibur slim that I debugged today. I don't see any changes in "excalibur-proposed-updates" that would fix this "Untitled window" problem. None of the code changes have anything to do with this child window that slim is creating.

fsmithred · Yesterday 15:05:48

I just realized that the rc1 desktop-live iso is still using lightdm. I made a new iso today and made sure slim was installed. It seems to be fixed. Please test.
https://files.devuan.org/devuan_excalib … p-live.iso

sha256sum

186c0f8a994d7a1223c16f3cee2763c099e2a4e29fcab9fdef3dbee7a48dc824  devuan_excalibur_6.0.0-rc2_amd64_desktop-live.iso

Edit: This one has the wrong version of the Release Notes. I'll wait to hear about slim before I make a new iso.

greenjeans · Yesterday 22:42:03

Tested. 2012 Compaq CQ-58 dual core AMD C-60 APU

Would not boot up the live-session normally, or in failsafe mode. Had to use "e" to edit, added nomodeset to the boot command and it started booting. Metric TON of those alsactl restore warnings during the process, over and over again, we really need to fix that.

Booted up in 1024x768 with no way to change it on my widescreen. I don't know if the amd graphics firmware is on the iso, if not this could be the problem. It did autolog me in just fine.

Eeqmcsq · Today 04:48:17

@fsmithred - I confirmed that the live desktop rc2 is using slim. And I do not see the "Untitled window" when the live desktop auto logs in. I also did a 2-monitor test, and slim's background DOES tile onto the 2nd monitor.

The problem is that both of these behaviors are not possible with the source code downloaded from "apt source --compile slim". I did that from the live desktop (see my test notes), and confirmed that the source code IS creating the child window "Untitled window" and the background should NOT tile onto the 2nd monitor.

The only conclusion I can think of is that you're building slim for the live desktop from a different source code than what's available from "apt source". Perhaps your versiom of slim code INCLUDES the code change that comments out creating the child window?

Other than that, there were no surprises in my rc2 live desktop tests.

* Test Notes

- Confirm that slim is the display manager.
  + Ans: Yes. "ps -ef | grep slim" shows "/usr/bin/slim -d".
- Screen resolution OK?
  + Ans: Yes. xrandr shows 1920x1080 on FX-8120's monitor, 1600x900 on A6-3620's monitor.
    - I was testing both PCs at the same time. Each PC has its own monitor. These resolutions are the correct max resolution for the connected monitor.
- Check that slim.conf has auto login enabled.
  + Ans: Yes, "cat /etc/slim.conf" shows:
    default_user devuan
    auto_login   yes
- Check if slim + auto login showed the "Untitled window".
  + Ans: slim + auto login did NOT show an "Untitled window".
    ? How is this possible? Does this build contain the code change that disabled slim from creating the child window that causes the "Untitled window"? Or is this using an older version of slim?
      - Version of slim: "apt show slim" shows version is "1.4.1-devuan1+excalibur1".
      - Also, "slim -v" shows 1.4.1.
        - This seems like the current version. Daedalus slim was 1.4.0.
- I downloaded the source code using "apt source --compile slim". This includes enabling deb-src, installing dpkg-dev. I didn't install all of the dependencies required to compile, just enough to get the source code patched and the compiling started.
  - Taking a look at panel.cpp, at the bottom, slim's code IS creating the child window. Why don't I see it in the live desktop auto login??? Is the source code from apt source NOT correct for the slim binary in the live desktop???
  - I can't compile and test slim like I did yesterday, because it requires a reboot to run the compiled slim binary, which will wipe out the live desktop environment. This is as far as I can go.
- Logging out, then logging back in as devuan/devuan, any problems?
  + Ans: No problems seen.
- Quick check: Confirm that RAID is NOT installed on the live desktop.
  + Ans: Confirmed. "cat /proc/mdstat" shows "No such file or directory".
- Quick check: There's an mdadm.deb in the root / directory.
  + Ans: Confirmed. mdadm_4.4-11devuan3_amd64.deb is there.
- Dual monitor test: Reboot to a fresh live desktop, then log out to observe the slim login GUI and background.
  ? Ans: The background tiles to the 2nd monitor, even though the source code says the child window IS being created with the dimensions of the 1st monitor, which should keep the background ONLY on the 1st monitor. There's definitely a source code to binary mismatch (or some voodoo magic) going on with the live desktop slim.
- Memtest: still runs?
  + Ans: Both menu options worked in UEFI and legacy boot.

fsmithred · Today 10:25:54

Thanks once again for your test report. There are different sources.

Without a deb-src line for excalibur-proposed-updates, 'apt source slim' gives me slim_1.4.1-1devuan1.debian.tar.xz
and with that source I get slim_1.4.1-1devuan1+excalibur1.debian.tar.xz

deb http://deb.devuan.org/merged excalibur-proposed-updates main
deb-src http://deb.devuan.org/merged excalibur-proposed-updates main

More info: The upstream dev thinks we have the wrong solution, but he is currently unavailable to give us more info.

Here's the relevant commit: https://git.devuan.org/devuan/slim/comm … 86db1173ff

The officially official Devuan Forum!

#1 2025-10-12 20:22:19

Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#2 2025-10-12 20:50:02

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#3 2025-10-12 20:58:21

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#4 2025-10-12 22:29:43

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#5 2025-10-12 22:43:14

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#6 2025-10-12 22:46:35

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#7 2025-10-12 22:48:08

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#8 2025-10-12 23:39:25

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#9 Yesterday 01:10:52

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#10 Yesterday 04:33:56

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#11 Yesterday 05:00:54

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#12 Yesterday 15:05:48

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#13 Yesterday 22:42:03

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#14 Today 04:48:17

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

#15 Today 10:25:54

Re: Excalibur RC1 + Xfce + slim + auto login shows Untitled window

Board footer