Re: More than 256/512 glyphs on the Liinux console

Greg Kroah-Hartman
2025-02-26T10:30:56Z

On Tue, Feb 25, 2025 at 04:15:38PM +0000, Alan Mackenzie wrote:
> Hello, Jiri.
>
> On Mon, Feb 24, 2025 at 21:08:50 +0100, Jiri Slaby wrote:
> > On 24. 02. 25, 19:22, Alan Mackenzie wrote:
> > > Hello, Greg.
>
> > > On Sun, Feb 23, 2025 at 08:47:53 +0100, Greg Kroah-Hartman wrote:
> > >> On Sat, Feb 22, 2025 at 03:36:12PM +0000, Alan Mackenzie wrote:
> > >>> On Sat, Feb 22, 2025 at 09:48:32 +0100, Greg Kroah-Hartman wrote:
>
> > > [ .... ]
>
> > >>> But I think you are also asking why I use the console at all. That's
> > >>> a fair question which I'll try to answer.
>
> > >> I'm not disputing using the console, it's the vt layer that I'm talking
> > >> about. The DRM developers have the long-term goal of getting rid of
> > >> CONFIG_VT which will remove a ton of mess that we have overall.
> > >> DRM-based consoles should provide the same functionality that a vt
> > >> console does today. If not, please let them know so that the remaining
> > >> corner cases can be resolved.
>
> > > Does a DRM based console exist at the moment? I spent quite some time
> > > looking for it yesterday, but found nothing.
>
> > I didn't read the thread, but are you looking e.g. for kmscon?
>
> No, I wasn't. I was looking for a drm replacement for the drivers/tty/vt
> code inside the kernel. I may have misunderstood Greg when he referred
> to a replacement which uses drm.

No, this is what I was referring to. Also maybe we should be asking on
the drm list? The developers there were working to get rid of CONFIG_VT
so I know they have plans for what they see replacing it.

> kmscon doesn't seem to be a suitable replacement for the Linux console.
> According to Wikipedia, it stopped being maintained ~10 years ago. Also,
> it is a user level program, not a kernel level program, so will only become
> active later in the boot process than the current console, which is not
> a good thing. It might well steal key sequences from application
> programs, the way X and X window managers do, but maybe it doesn't. On
> Gentoo, kmscon is "masked", i.e. strongly recommended not to be
> installed, and installable only after taking special measures.

Yes, it will be "after" the boot console, but that should be it. It
shouldn't be stealing any keys away from anything, but rather going
through the existing apis we have for input devices and the like.

I don't know why distros seem to not be using it anymore, maybe there's
something else?

thanks,

greg k-h