Linux without kernel-level VTs seems like a good idea. As a long time user, it will be weird, but ultimately welcome. I think for most desktop setups, it'll be better if all of the weird old fbdev, text mode and VT garbage is cleared out; some of it may still be needed in the kernel codebase itself, but I don't think we need it in desktop kernels.
Luckily, it looks like 2023 might be our year. This Reddit post details an exploration earlier this year:
And came to the conclusion that everything was almost ready, with the notable exception of Plymouth, which handles the boot splash in most desktop distros.
So in theory, Plymouth, a recovery console, terminal emulators, and Wayland compositors are all able to work with CONFIG_VT=n, if the pieces are all put together. I think in this case, your logind implementation would handle the switching; it already handles switching resources when VTs are changed, so this makes enough sense.
I think there's a lot of anxiety around being able to build robust and dependable bits at the bottom layer, and it's pretty justified honestly. But if the Linux desktop stack is able to succeed at it, it seems like it could lift off a lot of legacy kernel code, offer improved internationalization and accessibility for terminal sessions, improve the seamlessness and integration of early boot and terminal sessions, and so forth.
There may never be a "year of the Linux Desktop" that meets everyone's criteria, but 2023 looks to be another year where long-standing efforts finally start to bear fruit more substantially. I'm looking forward to it.
If you are OK using gnu screen, you can auto spawn screen if tty is /dev/tty2 - tty6 (adjust if you allow logins on other ttys). Screen will mess up ability to run startx, but if not using X, use screen on /dev/tty1 - tty6.
I do the above (via a shell snippet in /etc/profile.d) to get scrollback and an idle lock, via screen, on tty2-6, and, if tty1, add an alias that invokes vlock after startx exits to lock the virt console that X is using on exit from X.
Sticking with screen. Installed kmscon, manually ran kmscon on a single virtual console, switched back and forth from kmscon to X and back three times. On the third time, X shutdown like it detected a conflict (it looked like a crash, but the logs showed an orderly shutdown of X). Current setup with auto spawned screen instances is stable.
Afaik elogind itself does not provide full seat management. That said, seatd[1] exists. I believe that it should work with kmscon, but I haven't tried.
It'd be nice to make elogind/seatd/etc. work for this use case if it doesn't today.
The original project is dead - no activity since 2014. https://github.com/Aetf/kmscon is the most active fork FWICT, I contributed there some time ago, ironically to improve the fbdev support.
Given the comments here about activity, I should note that I _do_ have further work on user-space virtual terminals in the nosh package in the pipeline. I just have not been able to access the machine that the repository holding them is on for over a year.
16 comments
[ 3.0 ms ] story [ 84.1 ms ] threadLuckily, it looks like 2023 might be our year. This Reddit post details an exploration earlier this year:
https://www.reddit.com/r/linux/comments/sycbn0/showstoppers_...
And came to the conclusion that everything was almost ready, with the notable exception of Plymouth, which handles the boot splash in most desktop distros.
Well, it seems like that issue was fixed:
https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/13...
So in theory, Plymouth, a recovery console, terminal emulators, and Wayland compositors are all able to work with CONFIG_VT=n, if the pieces are all put together. I think in this case, your logind implementation would handle the switching; it already handles switching resources when VTs are changed, so this makes enough sense.
I think there's a lot of anxiety around being able to build robust and dependable bits at the bottom layer, and it's pretty justified honestly. But if the Linux desktop stack is able to succeed at it, it seems like it could lift off a lot of legacy kernel code, offer improved internationalization and accessibility for terminal sessions, improve the seamlessness and integration of early boot and terminal sessions, and so forth.
There may never be a "year of the Linux Desktop" that meets everyone's criteria, but 2023 looks to be another year where long-standing efforts finally start to bear fruit more substantially. I'm looking forward to it.
https://cgit.freedesktop.org/~dvdhrm/kmscon/tree/docs/man/km...
https://github.com/Aetf/kmscon
https://seclists.org/oss-sec/2020/q3/174
He proposed a patch but instead Linux kernel developers disabled scrolling!
You can still satisfy the need for scrolling by using NetBSD.
(I use both Linux and NetBSD)
With the --sb-size flag one can purportedly set the maximum lines of scrollback in kmscon.
I do the above (via a shell snippet in /etc/profile.d) to get scrollback and an idle lock, via screen, on tty2-6, and, if tty1, add an alias that invokes vlock after startx exits to lock the virt console that X is using on exit from X.
But, KMSCon looks worth checking out.
It'd be nice to make elogind/seatd/etc. work for this use case if it doesn't today.
[1]: https://sr.ht/~kennylevinsen/seatd/
* http://jdebp.uk./Softwares/nosh/guide/user-virtual-terminals...