Thread (23 messages) flat view 23 messages, 5 authors, 4d ago

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

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2026-08-29 12:11:34
Also in: dri-devel, linux-serial, lkml

On Fri, Aug 28, 2026 at 02:36:19PM +0000, Alan Mackenzie wrote:
On Fri, Aug 28, 2026 at 08:12:16 +0200, Thomas Zimmermann wrote:
quoted
Hi
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
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
But what is the use case here? We have excellent support for text and 
font rendering in graphical userspace for I18N and L10N.
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?  Why not
just make it feature-equal there, and then make these additional changes
there as well?

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?
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.
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
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.
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 :)

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help