SDDM in tty1 by default

[Matthias Klumpp]

2016-09-16 8:17 GMT+02:00 Maximiliano Curia <maxy at gnuservers.com.ar>:
> Hi,
>
> I've used sddm in tty1 for a while to test it out (this was sometime ago,
> things could have changed since). And there were a couple of things that
> bothered me.
>
> - If you start a second session it tries to use tty2. This might slowly eat
>   all your vts, but more importantly is that together with the next issue it
>   breaks the second session support.

This is actually not an issue in itself, because the same happens
already when tty7 is occupied (tty8 will be used), so you might run
out of ttys even faster with the old setup.

> - It failed to start the display if the current tty is "busy". By busy, it
>   could be that getty was activated there is a user logged in that vt, etc
>   (using systemd the getty is not running till you switch to that terminal)
>
>   In the systemd service file we have:
>   # Change this if you want to start sddm in a different tty
>   Conflicts=getty at tty7.service
>   After=getty at tty7.service
>
>   That means that in order to use a second session we would need to first
>   allocate tty1 and tty2 in the service file.

Yes, obviously. We patch this file to shut down getty on tty7 at time,
and of course we need to have it replace the one on tty1 - I am
running that configuration here without any issues.

> - Logging out shows getty, kills it, then starts sddm. This is probably
>   something related to the systemd internals, and the mentioned getty rules.
>   It's only a minor delay, so it could be ignored, but it stills annoys me.

That sounds like a bug... I'll try to reproduce it (but it's a rather
minor one, IMO)

> This was tested using systemd, using a sysv-init, you'll probably need to
> either edit the inittab or the sddm configuration. Otherwise you'll probably
> experience a restarting loop (which can only be fixed remotely)?
>
> So before making the switch I would suggest to test this use cases in sddm.

Yes, I haven't run any non-systemd system for quite a long time (it
only occasionally happens in containers). If I have some time next
weekend, I will test this in a VM.

> Also, as a side note, I'm currently running sddm 0.14, but it has an ugly
> change regarding the way it handles the themes.
>
> Now it embeds the 'maui' theme (which is now named the empty string theme),
> and falls back to that if something failed.
>
> In previous versions, if you had a theme installed and no configuration file
> it would just use that one.
>
> In this version (without the breeze patch) without a configuration file, it
> uses the maui theme regardless of what other themes you have installed (so
> you'll need to create a sddm conf file to use breeze).
>
> With the breeze patch, if you have the breeze theme installed it uses
> breeze, if you don't have breeze installed then it starts with maui with an
> error message, if you want to use another theme you'll need a configuration
> file.

That sounds fine, except that it shouldn't throw an error if a theme
is missing - check a list of pre-defined themes, and pick the one
that's best automatically, but always prefer the configuration file
(and only throw an error if the theme mentioned in the external config
doesn't exist).

> If you have a configuration file using 'maui', then it starts in error mode,
> as 'maui' is no longer present, you need to say Current=
> in the Themes configuration.

Brr...

> The lxqt team complained about this breeze theme dependency in the past and
> again the irc channel when we discussed about this new 'feature' in sddm.
>
> So far, I'm skipping 0.14, hoping that 0.15 fixes this use case (they are
> supposedly adding a configuration dir that might help deal with this issue).

Maybe we don't need to skip the release and can simply apply a patch
for this as soon as one becomes available? ;-)

Cheers,
    Matthias

-- 
I welcome VSRE emails. See http://vsre.info/