The only suggestion I have left is to print/log a warning msg that the viewport's width or height is unexpectedly 0, so anyone troubleshooting will have a good clue that DisplayWidth() and/or DisplayHeight() returned a bad value.

* Feedback: Set-default-resolution-if-monitor-absent.patch

The current patch hardcodes the 1024x768 resolution when there's no monitor.
But I noticed that in the earlier parts of Panel::GetPrimaryViewport(), when something goes wrong, the code returns the "fallback" width and height to the caller. This "fallback" is computed from the X Window's Display's width and height. I've confirmed that this is where the 1024x768 comes from in my tests.
So a proposed solution is that when the monitor width and height are 0, use the fallback width/height. And if anything goes wrong with the fallback width/height, THEN hardcode to 1024x768.

Agreed.
What do you think about this proposal?

Currently in Panel::GetPrimaryViewport()

	fallback.width = DisplayWidth(Dpy, Scr);
	fallback.height = DisplayHeight(Dpy, Scr);

Proposal (after the 2 lines above):

	if( fallback.width <= 0 ) fallback.width = 1024;
	if( fallback.height <= 0 ) fallback.height = 768;

Then, near the end of the function:

result.width  = (crtc_info->width  > 0 ? crtc_info->width  : fallback.width);
result.height = (crtc_info->height > 0 ? crtc_info->height : fallback.height);

The main difference here is it would set a fallback witdh,height rect greater than 0 for other places that this function could possibly return.

Thanks for mentioning Excalibur + slim display manager.

I had upgrade from Daedalus to Excalibur.
So my stack was Excalibur + xfce + lightdm
But it was only booting to the command line, and I had to run startx manually every time.

I've installed slim and chosen that as the display manager. Now on boot, startx does work automatically and I get to the slim logon.

:-)

Slim did not actually crash. Instead, it intentionally exit() the app because it caught a PAM exception that it thought was too serious to continue.

* Where the exit() is occurring

The exit() occurs in App::Login() when the code tries to open a PAM session. Here's a condensed version of the code:

try{
	pam.open_session();
}
catch(PAM::Cred_Exception& e){
	/* Credentials couldn't be established */
	return;
}
catch(PAM::Exception& e){
	exit(ERR_EXIT);
}

There are two error handling paths. The "Cred_Exception" path is considered "non-fatal" and returns control to the caller. The "Exception" path is considered "fatal" and will exit the app.

* Initial explanation

The Exception is thrown from Authenticator::open_session. Here's a condensed version:

void Authenticator::open_session(void)
{
	switch ((last_result=pam_setcred(pam_handle, PAM_ESTABLISH_CRED)))
	{
		default:
		case PAM_CRED_ERR:
		case PAM_CRED_UNAVAIL:
			throw Exception(pam_handle, "pam_setcred()", last_result);

		case PAM_ACCT_EXPIRED:
		case PAM_PERM_DENIED:
		case PAM_CRED_EXPIRED:
		case PAM_USER_UNKNOWN:
			throw Cred_Exception(pam_handle, "pam_setcred()", last_result);

		case PAM_SUCCESS:
			break;
	}

	switch ((last_result=pam_open_session(pam_handle, 0)))
	{
		default:
			throw Exception(pam_handle, "pam_open_session()", last_result);

		case PAM_SUCCESS:
			break;
	}
	return;
}

The code makes a call to pam_setcred() and pam_open_session(). For the pam_setcred() error handling, the code treats some errors as fatal, while others are non-fatal, including PAM_USER_UNKNOWN, which is the situation we're testing. Looking at the pam_setcred() man page, PAM_USER_UNKNOWN is a possible return value.

For pam_open_session(), all errors are fatal errors. Look at the pam_open_session() man page, there are only a few errors that can be returned.

But even though the code looks good, what happens is that for a bad user name, pam_setcred() does NOT return PAM_USER_UNKNOWN, or any other error code! Instead, pam_open_session() DOES return PAM_USER_UNKNOWN, even though that's not a documented return code. PAM_USER_UNKNOWN is treated as a fatal exception, causing slim to exit.

* Root cause

During my debugging, I found out that a manual login using the slim GUI doesn't have these problems because the code doesn't even try to go through the App::Login() code. Instead the code validates the user/password FIRST, and THEN goes into the login process. So I wondered why the autologin doesn't try to validate the user name first.

I just discovered that the slim's autologin code DID try to validate the user name first. There's even a comment in the Auth_Exception error handling that describes the possibility of a bad user name. Here's the condensed code:

if (autologin)
{
	try {
		pam.check_acct();
		Login(true);
	}
	catch(PAM::Auth_Exception& e){
		// The default user is invalid
	}
}

So the entire mess with Authenticator::open_session() could have been avoided. So why didn't Authenticator::check_acct() throw an Auth_Exception that would have skipped the auto login attempt on a bad user name?

void Authenticator::check_acct(void)
{
	switch((last_result=pam_acct_mgmt(pam_handle, PAM_SILENT)))
	{
		case PAM_ACCT_EXPIRED:
		case PAM_USER_UNKNOWN:
		case PAM_PERM_DENIED:
			throw Auth_Exception(pam_handle, "pam_acct_mgmt()", last_result);

     	default:
		case PAM_NEW_AUTHTOK_REQD:
		case PAM_AUTH_ERR:
		case PAM_SUCCESS:
	 	break;
 	}
}

pam_acct_mgmt() is supposed to check if a user account is valid. And this function IS handling the error code PAM_USER_UNKNOWN and would have thrown an Auth_Exception.

But according to my tests, pam_acct_mgmt() is actually returning error code 7 - PAM_AUTH_ERR (Authentication failure), which this code treats as "OK to proceed", which allows the autologin to proceed. I have no idea why pam_acct_mgmt() would return an authentication failure for a bad user name. Maybe a bug in the pam library?

* Possible fix

The simplest fix from within slim is to move "case PAM_AUTH_ERR:" to the first section so it throws an Auth_Exception and tells the autologin code to skip the autologin and proceed with the login GUI. I've confirmed that this change solves the autologin + bad user name crash in both Daedalus slim and "unstable" slim.

Of course, I don't know anything about PAM or what other situations could trigger a PAM_AUTH_ERR, so I don't know what side effects could occur with this change.

- This patch addresses an issue I had: when should App::Login() close the child "Untitled" window. The patch closes it as late as possible, just before Su.Login(). From my debugging, slim waits inside Su.Login() during the desktop session. So if anything went wrong earlier, the child window is still available.
- Otherwise, no suggestions, etc that I can think of.

* Feedback: Set-default-resolution-if-monitor-absent.patch

The current patch hardcodes the 1024x768 resolution when there's no monitor.

result.width = (crtc_info->width == 0 ? 1024 : crtc_info->width);
result.height = (crtc_info->height == 0 ? 768 : crtc_info->height);

But I noticed that in the earlier parts of Panel::GetPrimaryViewport(), when something goes wrong, the code returns the "fallback" width and height to the caller. This "fallback" is computed from the X Window's Display's width and height. I've confirmed that this is where the 1024x768 comes from in my tests.

So a proposed solution is that when the monitor width and height are 0, use the fallback width/height. And if anything goes wrong with the fallback width/height, THEN hardcode to 1024x768.

result.width  = (crtc_info->width  > 0 ? crtc_info->width  : fallback.width  > 0 ? fallback.width  : 1024);
result.height = (crtc_info->height > 0 ? crtc_info->height : fallback.height > 0 ? fallback.height :  768);

I also have some feedback about the patches, so I'll post that in a separate comment.

And I have an explanation for the autologin + bad user name crash from examining the daedalus slim source code. I need to confirm that the explanation is still the same in "unstable" slim. Then I'll write a separate comment.

* My test notes

* Test the slim compiled from git.devuan.org
 * Details
   - https://git.devuan.org/devuan/slim/
   - branch: suites/unstable (default branch)

 * Test cases
   + slim - auto_login (yes) - untitled window?
     + Confirmed as fixed: No "untitled window" appears.
     + 2nd confirmation: In App::Login(), commenting out the new code provided by the patch "Patch-to-fix-auto_login-regression-introduced-in-1.4.patch" causes the Untitled Window to appear, confirming that this patched code is what fixed the problem.

         if ( autologin )
         {
            //LoginPanel->ClosePanel();
         }

   ! slim - auto_login (yes) + default_user (bad name). What will the error handling do?
     ! Ans: No login screen. This is the same crash reported as new in daedalus slim and excalibur slim, and still occurs on this "suites/unstable" slim.
       - "ps -ef | grep slim" doesn't show slim running.

   + slim - auto_login (yes) + default_user (no name). What will the error handling do?
     + Login screen is displayed normally.
     + No regression here.

   + Monitorless auto_login (yes) - Will slim crash?
     + Confirmed as fixed: Unplug the VGA cable, power on the PC, wait for the auto login duration, plug in the VGA cable -> Xfce desktop is shown. "ps -ef | grep slim" shows that slim is running.
     + 2nd confirmation: Restoring the original code causes slim to crash again, confirming that "Set-default-resolution-if-monitor-absent.patch" has fixed this crash.
     
        result.width = crtc_info->width;
        result.height = crtc_info->height;

* My setup/compile notes, in case I (or someone else) needs this

* Download commands
  mkdir slimunstable
  cd slimunstable
  git clone https://git.devuan.org/devuan/slim/
  cd slim
  git status
    - The default branch is suites/unstable. I assume this is the correct branch?

* Setup/compile commands
   dpkg-source --before-build .
   dpkg-checkbuilddeps
     - This will tell you which dependencies are not found, and you'll have to install them.
   debian/rules
     - This creates a directory obj-x86_64-linux-gnu with a Makefile.
   cd obj-x86_64-linux-gnu
   make -j<number of parallel jobs>
     - The executable "slim" is created in this directory.

* Copying slim to /usr/bin
  - Do this just once: Make a backup of the original slim.
      sudo cp -ax /usr/bin/slim /usr/bin/slim.orig_installed
  - Copy the compiled slim.
      sudo cp -f slim /usr/bin

I discovered ANOTHER way to crash Excalibur slim with auto login: specify a user name that doesn't exist.

When I tested this (I think it was the latest / 1.4.1-1devuan4, but I'm not positive about that), it simply displayed the login window with the (incorrect) user name filled in as default.  This, I believe, should be the expected behavior.

[edit]
The latest slim/testing does crash when the user name does not exist.  Not sure what version I tested where it worked.  Maybe it was in-between versions (development).

[edit2]
I'm a little confused now.  I'm sure I'm doing something wrong/unusual here.  First I did apt source slim/unstable, then I followed the INSTALL instructions to build it (cmake ../slim-1.4.1 ; make), and auto-login with an invalid user just puts me at the login screen with the invalid username filled in (no crash).

[edit3]
It occurred to me, it's probably due to my build settings being different.  I don't think I included PAM or ConsoleKit, so the crash might be in one of those #ifdef blocks.

[edit4]
OK, as ralph mentioned above, the trick was to run debian/rules - then run make in the directory it creates.  So now at least I can test the same code line.

[edit5]
The issue seems to start with App::Login().
In the first #ifdef USE_PAM block, when the attempted autologin user does not exist, the PAM::Exception is caught, and slim exits with ERR_EXIT code.
When USE_PAM is not defined, the "pw" variable gets a value of 0, and App::Login() returns.
So, naturally, I tried changing that exit(ERR_EXIT); to a return; in the USE_PAM block.
But... that just moved things down the road a little bit.  The main loop in App::Run() continues until it hits the call to AuthenticateUser(), where we run into more troubles.  There is a separate AuthenticateUser() function for use with USE_PAM.  Once again, the call to pam.authenticate() is caught with PAM::Exception, where we find another exit(ERR_EXIT);.  Changing this to return false; just causes the main App::Run() to get caught in a never-ending loop, attempting to log into a nonexistent user account.  I'm looking at the non- USE_PAM version of AuthenticateUser(), maybe some of this code needs to be added to the USE_PAM version.  But it's getting late here now, and my time will be a bit limited the next few days...

But in doing so, I discovered ANOTHER way to crash Excalibur slim with auto login: specify a user name that doesn't exist. Additionally, I confirmed that Daedalus slim ALSO crashes in the same way. This suggests that the auto login's error handling logic is bad, and is not caused by any changes between Daedalus slim and Excalibur slim.

I don't have the focus and concentration tonight to hunt this new crash down in Daedalus slim and Excalibur slim source code to confirm that they're caused by the same bad code. So on the next block of free time, I will:

  - Code review the proposed fixes to 1.4.1-1devuan4.
  - Download, compile, and test the patches.
  - Hunt down this new crash in Daedalus slim and Excalibur slim source code.
                 
* My test notes

+ Test the slim currently installed
 + devuan_excalibur_6.0.0_amd64_netinstall.iso
   * Software selection
     - Devuan desktop environment
     - Xfce
     - ssh server
     - standard system utilities

 * Test slim, installed version
   * Details
     - Version: 1.4.1-1devuan1

   ! slim - auto_login (yes) - untitled window?
     ! Ans: Reproduced: Untitled window appears

   ! slim - auto_login (yes) + default_user (bad name). What will the error handling do?
     ! Ans: No login screen.
       - slim appears to have crashed: "ps -ef | grep slim" doesn't show slim running.
       - This is a NEW crash.

       * Test on daedalus slim: 1.4.0-0devuan2
         ! Ans: Yes, daedalus slim ALSO crashes.

   + slim - auto_login (yes) + default_user (no name). What will the error handling do?
     + Login screen is displayed normally.

   ! Monitorless slim crash
     ! Ans: Reproduced: No login screen.
       - slim appears to have crashed: "ps -ef | grep slim" doesn't show slim running.

The relevant patches, if you'd like to review the code:
https://git.devuan.org/devuan/slim/src/ … -1.4.patch
and
https://git.devuan.org/devuan/slim/src/ … sent.patch

@golinux - The most I can tell you is that during my Excalibur + MATE desktop testing, I did a quick test of all of the clearlooks-phenix themes (cinnabar, darkpurpy, deepsea, lightpurpy, sapphire), and the lightpurpy was the only one that didn't load. That's when I investigated that theme to find the root cause.

@fsmithred - I just confirmed that the light purpy theme installed manually (sudo apt-get install ./clearlooks-phenix-lightpurpy-theme_7.0.1-6_all.deb) now loads correctly in the MATE desktop's Appearance app, instead of showing a question mark. This confirms the fix for this theme's package. This ends the sidetrack to the light purpy theme problem. Thanks for fixing it.

So back on topic, the current status is that Excalibur has a proposed fix to slim that restores the previous auto-login behavior (without the Untitled window), but potentially breaks an upcoming slim feature involving multiple monitors. Someone has also filed the same bug in Debian slim, so they might have a better fix.

You can download the package here :
https://pkgmaster.devuan.org/devuan/poo … -6_all.deb

(or apt download <package> if you have ceres enabled in sources)

Make sure that you have the last published version from here but it may no longer be viable and was only tested for the default Xfce desktop:
https://git.devuan.org/devuan/documenta … t/graphics

If you are adventurous, I left notes how to theme Devuan here but that is also likely outdated:
https://git.devuan.org/devuan/documenta … -devuan.md

Note that I am still on Chimaera and dreading when it will no longer be viable.

Hope you can find a fix!

$ dpkg-source --before-build .

within the packaging branch so as to apply any patch series (in case of quilt packaging). Doing so sets up all actual "before build" source in that workarea. (One may undo that by using --after-build instead)

If I then want to compile and prepare a local .deb for testing, I'd use

$ dpkg-checkbuilddeps

to tell which build dependencies need to be installed, and then use the command

$ debian/rules

i.e., execute the debian/rules make script by the shell with working directory at the project top. This typically creates a .deb file somewhere, possibly in the parent directory.