lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z7idXzMcDhe_E5oN@MAC.fritz.box>
Date: Fri, 21 Feb 2025 15:35:59 +0000
From: Alan Mackenzie <acm@....de>
To: Jiri Slaby <jirislaby@...nel.org>,
  Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
  Simona Vetter <simona@...ll.ch>, linux-serial@...r.kernel.org,
  linux-kernel@...r.kernel.org
Subject: More than 256/512 glyphs on the Liinux console


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ