More than 256/512 glyphs on the Liinux console

More than 256/512 glyphs on the Liinux console

[Alan Mackenzie]

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.

I have a proof-of-concept/works-for-me implementation which does just
this.  With a test font of 810 glyphs, my console can display many (?all)
Latin character variants, and also Greek and Cyrillic characters,
together with others.

The strategy of my implementation is to use 32 bits for each character
cell in the video buffer rather than VGA's 16.  The coding of the
foreground and background colours remains unchanged in 8 bits, and the
glyph number takes up the remaining 24 bits.  This is sufficient to hold
a complete Unicode font (if such existed).  So, for example, a white '!'
on a black background (glyph 33), currently coded as 0x0721, becomes
0x07000021.  drivers/tty/vt/consolemap.c has been enhanced to handle the
full Unicode range.  Full width characters and right-to-left scripts
remain unhandled.

The code, although "fully working", is still at an early stage of
development.  It does not yet conform with Linux standards - for example,
there are too many #ifdefs in the .c files, and there's "clever" code
which needs replacing.  It also hasn't been built for or tested on
anything but my amd64 machine.

The main source files which have been changed are:
      drivers/tty/vt/consolemap.c
      drivers/tty/vt/selection.c
      drivers/tty/vt/vc_screen.c
      drivers/tty/vt/vt.c
      drivers/tty/vt/vt_ioctl.c

      drivers/video/fbdev/Kconfig
      drivers/video/fbdev/core/bitblit.c
      drivers/video/fbdev/core/fbcon.c
      drivers/video/fbdev/core/fbcon.h
      
      include/linux/console_struct.h
      include/linux/consolemap.h
      include/linux/selection.h
      include/linux/vt_buffer.h
      include/linux/vt_kern.h
      include/uapi/linux/kd.h

, with minor amendments to:

      drivers/accessibility/Kconfig
      drivers/accessibility/speakup/Kconfig
      drivers/video/console/vgacon.c

..

The patch for this change is necessarily large, currently around 3,500
lines - there are very many places in the current console code that hard
code the size of a video buffer character as 2.  Each one of these needed
to be replaced by a variable whose value is either 2 or 4 or similar.
Macros like scr_writew have been replaced by scr_writeg (g for "glyph")
which, depending on the configuration, writes either 2 or 4 bytes to the
video buffer.  And so on.

The patch is currently based on

commit 50782d9796dc3fc65d1e1b1a90e8887de3338baf (origin/linux-6.13.y, linux-6.13.y)
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 13 15:24:29 2025 +0100

    Linux 6.13.3-rc1

, though I could easily rebase it (again!) onto a different base.

To use 24-bit glyphs, the new setting CONFIG_FB_GLYPH_24BIT needs to be
enabled, and also the new kernel parameter fbcon=glyph-24bit set.  It is
intended that the old VGA standard will continue to work unchanged.
However it is not currently possible to have 24-bit and 8/9-bit consoles
running on a machine at the same time.  Currently FB_GLYPH_24BIT is
restricted to the EFI framebuffer, though this might well not be
necessary.

With >256/512 glyph fonts, the standard program setfont works unchanged.
showconsolefont doesn't work satisfactorally at the moment and would need
amendment (it has a hard coded limit of 512 glyphs).

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?

--
Alan Mackenzie (Nuremberg, Germany).

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

[Greg Kroah-Hartman]

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?  What about the move to get rid of the vt code entirely,
if you do that, can't you get proper glyphs with the drm subsystem?

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

<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.  But again, you are going to have to answer the reason "why"
first.

thanks,

greg k-h

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

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

[Greg Kroah-Hartman]

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:
> > On Fri, Feb 21, 2025 at 03:35:59PM +0000, Alan Mackenzie wrote:
> > > 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.

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.

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

No, no need for x or wayland there from what I recall.

And there is not really any "fat" there, sorry, it's a way to give you
all of those glyph and input systems and functionality that you need.
That wasn't added for no good reason.

> > 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?

The drm console layer.

> > .... 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 don't know what fbterm is, sorry.

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

Ok, but we haven't seen the patches to know this :)

> > 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?

I agree, keeping the existing ones is key.  You are talking about
extending the existing ones in a way that adds additional complexity
when there might already be a solution for this for you.  That's why I
brought that up.

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

code formatting is NOT "inessential", please never think that.  Our
brains run on patterns and common code formatting allows us to see the
real issues here.  To not follow those formatting rules means we just
can't review your code properly.

Reviewing is harder than writing code, so you have to write the code to
make reviewing easier if you wish to have anything accepted as you have
to convince everyone else that your changes are correct.

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

Break down the changes into "one logical change per patch" to make them
easy to review.  It's an art form, think about how you want to get to
your end result and then take us on a path that is "obvious" to get
there over a series of changes.

Think of it as "showing your work" when solving a math or physics
problem that your teacher told you to follow.  No one wants to just see
the end result, they have to see all the steps along the way to even
begin to understand if the end result is correct or not.

But again, before doing that work, see how using the drm console works
for you, or not.  If not, let us and the drm developers know so that we
can work toward solving those issues, as that might actually be easier
to do.

thanks,

greg k-h

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

[Alan Mackenzie]

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.

[ .... ]

> > > 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?

> The drm console layer.

Again, does it exist yet, or alternatively are there plans to introduce
it into the kernel in the near future?

> > > .... 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 don't know what fbterm is, sorry.

It's a user level terminal emulator for the framebuffer.  It's not
important.

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

> Ok, but we haven't seen the patches to know this :)

> > > 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?

> I agree, keeping the existing ones is key.  You are talking about
> extending the existing ones in a way that adds additional complexity
> when there might already be a solution for this for you.  That's why I
> brought that up.

Where/how can I find the DRM console?

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

> code formatting is NOT "inessential", please never think that.

However necessary code formatting is (and it is necessary), it doesn't
form part of the essence of the changes.  I'm sure we're agreed that
proposed changes are best judged by that essence.  That was all I meant.

> Our brains run on patterns and common code formatting allows us to see
> the real issues here.  To not follow those formatting rules means we
> just can't review your code properly.

I understand.

[ .... ]

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

> Break down the changes into "one logical change per patch" to make them
> easy to review.  It's an art form, think about how you want to get to
> your end result and then take us on a path that is "obvious" to get
> there over a series of changes.

> Think of it as "showing your work" when solving a math or physics
> problem that your teacher told you to follow.  No one wants to just see
> the end result, they have to see all the steps along the way to even
> begin to understand if the end result is correct or not.

Thanks.  I have a fair amount of work to do to achieve this.

> But again, before doing that work, see how using the drm console works
> for you, or not.  If not, let us and the drm developers know so that we
> can work toward solving those issues, as that might actually be easier
> to do.

I would actually appreciate the work I've done being superfluous.  ;-)
But where can I find the drm console?

> thanks,

> greg k-h

And thank you, too.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Jiri Slaby]

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?

-- 
js
suse labs

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

[Greg Kroah-Hartman]

On Mon, Feb 24, 2025 at 09:08:50PM +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?

Yes, that is what I was referring to, but couldn't remember the name,
thanks for the pointer.

greg k-h

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

[Alan Mackenzie]

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.

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.

> -- 
> js
> suse labs

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Greg Kroah-Hartman]

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

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

[Jiri Slaby]

On 26. 02. 25, 11:09, Greg Kroah-Hartman wrote:
> I don't know why distros seem to not be using it anymore, maybe there's
> something else?

FWIW I re-tried that thing yesterday and it doesn't work with 
FB_DEVICE=n at all... We disabled FB_DEVICE in openSUSE in 6.12.9.

kmscon should work with drm directly and be able to use even 
acceleration. But it renders nothing for me (without fbdev). Reported at:
https://bugzilla.suse.com/show_bug.cgi?id=1237599

thanks,
-- 
js
suse labs

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

[Alan Mackenzie]

Hello, Greg.

On Wed, Feb 26, 2025 at 11:09:57 +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 25, 2025 at 04:15:38PM +0000, Alan Mackenzie wrote:
> > On Mon, Feb 24, 2025 at 21:08:50 +0100, Jiri Slaby wrote:

[ .... ]

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

Which list would that be?  There are over 100 occurrences of "DRM" in the
file MAINTAINERS.  I am also interested in this.  There is a very great
deal of functionality in drivers/tty/vt.  It will be quite a task to
replace 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.

What would the boot console be?  Some console needs to be in place early
enough to be able to display "Kernel panic - unable to mount the root
partition".

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

Agreed.

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

Jiri pointed to some problems yesterday from his point of view as a SuSE
maintainer.  Perhaps kmscon just needs bringing back into maintenance.  I
haven't actually looked at it yet.

> thanks,

By the way, I'll be away from my email for a few days, so won't be able
to answer any posts in that time.

> greg k-h

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Greg Kroah-Hartman]

On Thu, Feb 27, 2025 at 01:05:15PM +0000, Alan Mackenzie wrote:
> Hello, Greg.
> 
> On Wed, Feb 26, 2025 at 11:09:57 +0100, Greg Kroah-Hartman wrote:
> > On Tue, Feb 25, 2025 at 04:15:38PM +0000, Alan Mackenzie wrote:
> > > On Mon, Feb 24, 2025 at 21:08:50 +0100, Jiri Slaby wrote:
> 
> [ .... ]
> 
> > > > 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.
> 
> Which list would that be?  There are over 100 occurrences of "DRM" in the
> file MAINTAINERS.  I am also interested in this.  There is a very great
> deal of functionality in drivers/tty/vt.  It will be quite a task to
> replace it.

dri-devel@lists.freedesktop.org is the list.

thanks,

greg k-h

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

[Jiri Slaby]

On 27. 02. 25, 14:05, Alan Mackenzie wrote:
>> I don't know why distros seem to not be using it anymore, maybe there's
>> something else?
> 
> Jiri pointed to some problems yesterday from his point of view as a SuSE
> maintainer.  Perhaps kmscon just needs bringing back into maintenance.  I
> haven't actually looked at it yet.

It was a bug and it works again with kmscon's git snapshot. This commit 
in particular:
https://github.com/Aetf/kmscon/commit/1de5e30ea4c8b9fc21623e5520b409c8e27a31d8

thanks,
-- 
js
suse labs

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

[Alan Mackenzie]

Hello, dri-devel.

The context of the following post is a thread on Linux kernel lists where
I am proposing to extend the Linux console to handle more than 256/512
distinct glyphs.

On Fri, Feb 28, 2025 at 20:24:33 -0800, Greg Kroah-Hartman wrote:
> On Thu, Feb 27, 2025 at 01:05:15PM +0000, Alan Mackenzie wrote:
> > Hello, Greg.

> > On Wed, Feb 26, 2025 at 11:09:57 +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Feb 25, 2025 at 04:15:38PM +0000, Alan Mackenzie wrote:
> > > > On Mon, Feb 24, 2025 at 21:08:50 +0100, Jiri Slaby wrote:

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

Is this (still) the case?  Have people on dri-devel developed a Linux
console which supersedes the code in drivers/tty/vt, or are they in the
midst of doing so?

Where can I best inform myself about this, and (possibly) install this
replacement console on my system for my own use?

Thanks for any information!

[ .... ]

> dri-devel@lists.freedesktop.org is the list.

> thanks,

> greg k-h

-- 
Alan Mackenzie (Nuremberg, Germany).