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

[Alan Mackenzie]

Hello, Greg.

Thanks for the reply.

On Sat, Feb 22, 2025 at 09:48:32 +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 21, 2025 at 03:35:59PM +0000, Alan Mackenzie wrote:

> > Dear Linux Maintainers,

> > The Linux console is currently restricted to 256/512 glyphs, the VGA
> > standard from the 1980s.  I would like that restriction to be lifted, and
> > believe that many other console users would agree.

> First off, why?

I use the console as my primary means of interacting with my PC, and in
recent years have become increasingly irritated by the appearance of
Ufffd in place of, for example, eastern European characters in people's
names.  I've often wished "somebody" would fix this.  In the end, that
somebody had to be me.

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.

For pure text work (such as hacking code, reading emails), the main
alternative is a GUI such as X-Windows (or Wayland).  These insert
several layers of "fat" between the user and the "muscle" of the kernel.

Like many drivers of modern cars, who would dearly love to get rid of
electronic this and that, electric mirror adjustment, electric window
opening and so on, I need a simple uncluttered environment.  I want to
drive a speedboat, not a luxury yacht.

All the features of GUI systems take up space on the screen, thus
reducing the space available for the user's work.  All these systems
"steal" key sequences from application programs, making them less
useful.  For example <alt>-<tab> is a useful key sequence in Emacs,
provided it is running on the console.  In text work, I have absolutely
no use for scroll bars, menus, window decorations, and the like - they
just get in the way.

The console is a stable interface.  My use of it has barely changed in
around 25 years.  By contrast, GUI environments are continually
changing, forcing users to spend time learning new features and
(arbitrarily) changed existing features.  I don't like this.

The console is also rock-solid reliable - just as other parts of the
kernel are.  X-Windows, for example is not so reliable.  Back in
December, the root partition on my new Gentoo system became full.  This
prevented X from even starting.  With the console (and a rescue CD) I
was able to recover the situation.

> What about the move to get rid of the vt code entirely, ....

Getting rid of the vt code would be a Bad Thing.  People depend on it.
What is the alternative?

> .... if you do that, can't you get proper glyphs with the drm
> subsystem?

I don't know.  I've looked briefly at fbterm, a terminal which uses drm.
It steals key sequences too, some of which are needed in Emacs.
Although not as bad as GUIs, it puts awkward layers between the user and
Linux too.

I think using drm in place of fbterm.c and bitblit.c would need a lot of
design and implementation work.  The change I'm proposing barely changes
the design at all.

> Doing huge changes for a subsystem that almost everyone agrees should
> only be kept around for legacy reasons is a rough undertaking.

Isn't there a principle in Linux that preserving existing user
interfaces is of utmost importance?

> <snip>

> > I would very much like further to develop and to refine this code to the
> > point where it is suitable for inclusion in the mainline kernel.  What do
> > you say?

> Only you can decide what you want to work on.  If you have working
> patches, and submit them so that they can be reviewed, we'll be glad to
> do so.

As I've already written, I've got working code, but it needs refinement
before I submit it.  Otherwise reviewers would likely reject it for
"inessential" reasons like code formatting.  This will likely take me
several days.

What is the best way of submitting such a large patch (~3,500 lines)?  I
committed it to my own local git repository in three main stages (around
equal size), and have applied corrections after rebasing and the odd bug
fix.

> But again, you are going to have to answer the reason "why" first.

I hope this email goes some way towards this.

> thanks,

> greg k-h

Thank you too!

-- 
Alan Mackenzie (Nuremberg, Germany).