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