Re: vt: Enlarge the framebuffer glyph size from 16 to 32 bits

On Sat, Aug 29, 2026 at 14:09:52 +0200, Greg Kroah-Hartman wrote:

On Fri, Aug 28, 2026 at 02:36:19PM +0000, Alan Mackenzie wrote:

quoted

On Fri, Aug 28, 2026 at 08:12:16 +0200, Thomas Zimmermann wrote:

quoted

Hi

quoted

quoted

Am 27.08.26 um 20:38 schrieb Alan Mackenzie:

quoted

vt: Enlarge the framebuffer glyph size from 16 to 32 bits.

quoted

quoted

quoted

This allows:
   o - More than 256/512 distinct half-width glyphs (in fact, up to 2^21).
   o - Unicode code points >0xffff (outside the Basic Multilingual Plane).
   o - Coloured glyphs (as before).

quoted

quoted

But what is the use case here? We have excellent support for text and 
font rendering in graphical userspace for I18N and L10N.

quoted

GUIs are sub-optimal for pure text work.  A full screen terminal is
wanted.  The current preeminent user space terminal, kmscon, appears to
lack the refinements of many decades development of the kernel's
console.

What is missing from kmscon that the kernel currently supports?

<Alt>-<Fn>, for a start.  Also the facility to enter an arbitrary Unicode
code point by holding down <AltGr> and typing the hex code on the numeric
keypad.  There are probably other things, too.

Why not just make it feature-equal there, and then make these
additional changes there as well?

I suspect the politics involved would be more difficult than here, and
I'm not good at politics.  kmscon is controlled by Redhat, and they have
a reputation for dismissing third party suggestions and patches rather
than integrating them.

But it's not just a matter of adding features.  The kernel console is an
elegant system.  You just have to add entries in /etc/inittab, select a
keyboard, select a font (all mostly done at system installation) and
that's it.  kmscon is anything but elegant.  It has something like 75
command line options, and a configuration file is virtually mandatory.

kmscon has no documentation for its keyboard system, nothing to compare
with Andries Brouwer's keymaps man page.  It uses xkb.  I remember
searching for xkb doc around 10 years ago and found nothing systematic.
Just a very helpful tutorial, which enabled me to  make my changes.

I don't think it's got doc for its various font systems either.  It might
well be that you need to use a GUI to make font changes.  That is not a
Good Thing.

As others have said, we don't want to add new features to the in-kernel
console mode due to all of the reasons the patch review has shown on
this series already (i.e. complex interactions that end up making the
system broken.)  This is best all done in userspace, where a bug there
will not cause these same problems, right?

From the user's point of view, a bug in either will render his computer
unusable.

Have you considered that the code in kmscon might not be any better than
that in the kernel's console?  I've no evidence either way.

quoted

Support for blind users exists in the kernel's console.  I don't know
how good it is, as I don't (yet) need to use it.

But others use it, so we can't break that, and the fact that you ignored
those codepaths here makes me very worried.

Hey, give me a chance!  One thing at a time.  I didn't ignore that code,
I noted (in two Kconfig's) that it would also need attention, and I
blocked it out safely when CONFIG_FB_GLYPH_21BIT was set.

It may well be (I'm not sure) that these facilities for the blind are an
integral part of the kernel's console.  That would be a good reason not
to remove it from the kernel.

quoted

quoted

In contrast, the kernel's text-mode support is limited and a hotbed for 
bugs. IMHO we shouldn't add features, but try to simplify that code base.

quoted

quoted

From a user's point of view, the kernel's console is rock solid and

dependable; it doesn't crash, and its interfaces don't suddenly change
with the latest release of KDE or Gnome or whatever.

This has nothing to do with KDE or Gnome, if you have issues with those
projects, please take it up with them and contribute to them to resolve
those issues.  I know they can always use the help.

My point is that the kernel's console is rock solid and dependable.
Things like kmscon are subject to the vagaries of fashion.

quoted

As is clear, I think the console's limitations should be eliminated.

And the rest of us feel the kernel console's code should be eliminated
entirely, when ever possible :)

The rest of you don't appear to be console users.  It's easy to advocate
for removal when you don't use it yourself.

thanks,

greg k-h

-- 
Alan Mackenzie (Nuremberg, Germany).