Bug 466178

Summary:	kscreenlocker crash recovery advice doesn't make sense when there are no VTs
Product:	[Plasma] plasmashell	Reporter:	bluescreenavenger
Component:	Screen locking	Assignee:	Plasma Bugs List <plasma-bugs-null>
Status:	CONFIRMED ---
Severity:	minor	CC:	nate
Priority:	VLO
Version First Reported In:	6.2.4
Target Milestone:	1.0
Platform:	Compiled Sources
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=473247
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description bluescreenavenger 2023-02-21 02:21:28 UTC

SUMMARY
***
The kscreenlocker recovery advice doesn't make sense when there are not VTs. to switch back to the running session to press CTRL+ALT+F0 (since the logind VT number is 0 when there are none). And then on the bottom, it says "you can get back to this screen by pressing "CTRL+ALT+Fc2" where "c2" is the logind session
***

STEPS TO REPRODUCE
1. Build a kernel without VTs
2. Start KDE Plasma
3. Lock the screen
4. Kill the screen locker somehow, with an SSH session or something

OBSERVED RESULT
1. The messages are shown above, the second CTRL+ALT+Fx key that it tells the user to press will likely vary by the logind session number

EXPECTED RESULT
Honestly I am not sure what the solution is.
CTRL+ALT+Fx bindings still work without VTs, but it's only if there is another session to switch to
Most display manager's don't keep the greeter running, and some run the greeter as root, so the greeter isn't a logind session for the greeter.

I almost wonder if logind would need to be amended to have a dbus command that starts a usermode terminal on its own Wayland session on the seat, with a login getty on i or something

This is in a similar vein as https://github.com/systemd/systemd/issues/26313 ...although in this instance, kwin is usually able to respond to user key commands, (where I opened https://github.com/systemd/systemd/issues/26313 in the case where it's the display server that hangs solid)

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kernel 6.1
KDE Plasma Version: 5.26.80
KDE Frameworks Version: 5.102.0
Qt Version: 5.15.8

Comment 1 bluescreenavenger 2023-08-07 02:45:56 UTC

I opened https://github.com/systemd/systemd/issues/26313 for systemd/logind 
My thinking is that, logind will have to listen on the keyboard for a key binding, like a long press and hold of CTRL+SHIFT+ESC or something

and when that happens, emit a dbus signal that the display manager will start the greeter, or switch to the greeter session if it is running on the seat, and then the user will be able to log in with a separate session. Maybe a minimalistic one provided by kmscon, or combining cage and foot.

Comment 2 bluescreenavenger 2024-04-07 02:36:42 UTC

https://github.com/systemd/systemd/pull/29542 is out of draft and waiting further review, but right now if you hit Ctrl+Alt+Shift+Esc with that applied org.freedesktop.login1.Manager emits the SecureAttentionKey signal, with the seat object that it was originated from, to where a display manager can react to it, and show its greeter

If this gets merged, it might allow users to log in and start a second session to run the command (although it will have to be a minimal one like Weston, or one that pairs cage/foot)

It might be better than guessing the VT

Comment 3 bluescreenavenger 2024-06-29 00:27:36 UTC

https://github.com/systemd/systemd/pull/29542 is merged, which might be relevant to this
This could allow new instructions to where they are to press Ctrl+Alt+Shift+Esc and then log in with a new session (would have to be like Weston or something because you can't have two systemd handled sessions) and then run the command with that

...that is once the patch is in in sddm

Comment 4 bluescreenavenger 2024-07-09 23:19:48 UTC

Now SDDM supports responding when systemd emits SecureAttentionKey after the user presses Ctrl+Alt+Shift+Esc

GDM support is pending, as is LightDM (patches are yet to be reviewed)

BUT this might be better advice to the user, press Ctrl+Alt+Shift+Esc, log in selecting a different session type, then run the loginctl command?

Comment 5 bluescreenavenger 2024-08-07 02:21:36 UTC

Please see https://bugs.kde.org/show_bug.cgi?id=473247#c7 I accidentally posted in the wrong tab