[HN Gopher] KMSCon - A Userspace System Console That Does Not De...
       ___________________________________________________________________
        
       KMSCon - A Userspace System Console That Does Not Depend on Any
       Graphics Server
        
       Author : 1vuio0pswjnm7
       Score  : 17 points
       Date   : 2022-12-27 20:33 UTC (2 hours ago)
        
 (HTM) web link (cgit.freedesktop.org)
 (TXT) w3m dump (cgit.freedesktop.org)
        
       | mrlonglong wrote:
       | Does it supports the ability to scroll back to see things ? That
       | one got removed from the Linux console years ago and I miss it.
        
         | 1vuio0pswjnm7 wrote:
         | "That one got removed from the Linux console years ago and I
         | miss it."
         | 
         | 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.
        
         | jchw wrote:
         | Seems like yes. There's keyboard shortcuts for scrolling listed
         | here:
         | 
         | https://cgit.freedesktop.org/~dvdhrm/kmscon/tree/docs/man/km...
        
           | mrlonglong wrote:
           | Perfect. In that case I'll be trying it out on a headless
           | machine soon.
        
       | mrlonglong wrote:
       | In addition some of us don't use systemd login. Will it still
       | work with the alternative elogind daemon?
        
         | jchw wrote:
         | 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.
         | 
         | [1]: https://sr.ht/~kennylevinsen/seatd/
        
       | Vogtinator wrote:
       | 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.
        
         | bitbang wrote:
         | gentoo's kmscon package is sourced from that fork
        
         | jchw wrote:
         | Does SimpleDRM alleviate the need for fbdev support yet? In the
         | time intervening, it actually was merged.
        
       | 1vuio0pswjnm7 wrote:
       | https://github.com/dvdhrm/kmscon
       | 
       | https://www.freedesktop.org/wiki/Software/kmscon/
        
       | jchw wrote:
       | 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:
       | 
       | 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.
        
       ___________________________________________________________________
       (page generated 2022-12-27 23:01 UTC)