On Wednesday March 1 2017 06:32:45 Duncan wrote:
>Without kdm or similar installed, kde4/plasma4 didn't have a greeter
>available and I had to be careful not to lock the screen, etc, because
>there was no way to unlock it as I had no greeter.
So you are saying that despite what the resident expert said, the display manager *is* involved and responsible for showing the password dialog and unlocking?
That's what I assumed too. I guess that without proper documentation the only way to figure out what really happens is to try to make sense of the code.
>Plasma5, by contrast, appears to have its own screen-unlock greeter, and
Both have kscreenlocker_greet.
Did you ever try to integrate xscreensaver? That's the approach I'm following now (and appreciating its author's vitriolic remarks about other supposedly equivalent approaches ;) )
It should even be able to run my screensaver "hack" of choice (kclock.kss), the only thing I haven't yet gotten to work is integration with the KDE lock screen feature. Replacing kscreenlocker_greet with a script as described in the xscreensaver documentation works, but after unlocking the screensaver KWin remains in some sort of locked state.
>Any such backdoors would be considered security bugs, and thus
>exterminated. (To the extent possible with X, of course.)
When you configure kscreenlocker5 for building it checks for the presence of loginctl, for the exact reason of being able to regain control if there's no greeter. I do have loginctl, but its (un)lock_session(s) functions have no effect. Presumably that's because Ubuntu 14.04 doesn't use systemd, but if what you say about display managers is true I should probably experiment with other, better maintained ones. Possibly even see if sddm will work...
>user, tho I am following git commits), if the wayland transition
>continues native wayland will likely be the primary focus, tho X may well
>still be supported, possibly as legacy, and projecting further out,
>perhaps plasma7 will be native-wayland-only, tho still with the
>possibility of running rootless X-nested sessions for legacy X apps.
I certainly hope that KDE desktops don't turn into open source OS X systems where you need to run an additional X server if you need to use X11 applications, be it local or remote. As long as X11 apps can still be used seemlessly (and older, not-so-graphically-capable hardware can still be used) I don't really care what the main displaying protocol is.
This probably all depends on what options Qt provides, but possibly also on what Gnome does.
I will beg no more, never liked that anyway ;)
R.
