From: Alan Mackenzie <acm@muc.de>
To: Helge Deller <deller@gmx.de>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
Simona Vetter <simona@ffwll.ch>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: vt: Enlarge the framebuffer glyph size from 16 to 32 bits
Date: Tue, 1 Sep 2026 11:14:43 +0000 [thread overview]
Message-ID: <apazo2RIHiEAtpNN@MAC.fritz.box> (raw)
In-Reply-To: <ae1ae01a-677e-4c51-bf9a-ebe7b2e91e4f@gmx.de>
On Mon, Aug 31, 2026 at 19:21:30 +0200, Helge Deller wrote:
> On 8/31/26 16:45, Alan Mackenzie wrote:
> > On Mon, Aug 31, 2026 at 08:20:10 +0200, Thomas Zimmermann wrote:
> >> Am 29.08.26 um 16:39 schrieb Alan Mackenzie:
[ .... ]
> > I've been using the console for around 28 years, now. I don't recall it
> > crashing at all. My current font and keyboard files are in exactly the
> > same form as they were 28 years ago. These formats are stable and
> > dependable.
> >> I've spend the last years working on related code (fbcon) and it
> >> mostly feels dated and unmaintained. Our prime implementation (again
> >> fbcon) has been de-facto unmaintained for years. We recently had
> >> contributors who are pushing the ioctls semantics and found bugs in
> >> fbcon for a number of corner cases.
[ .... ]
> >> FTR I'm not at all interested in eliminating the kernel's console.
> > Other people, in particular Greg KH, have said this is the current aim.
> > I'm worried for myself. It is far from clear that there is a suitable
> > replacement for the kernel's console, and its elimination could easily
> > happen without that replacement. I suppose I could always (laboriously)
> > maintain the console for myself personally. Or there's always the BSDs.
> > I just don't know what I'd do.
> Alan, I really appreciate your efforts to enhance the kernel console code!
> And I'm not interested to eliminate the kernel console either.
> >> But there are must-have features and nice-to-have features. IMHO for
> >> the kernel console i18n really belongs in the later category.
> > It's 2026, four decades after VGA was the latest thing, and Unicode
> > support is merely a nice-to-have?
> No. IMHO Unicode support would be great.
Thank you, indeed! That's cheering to hear.
> Thanks!
> Helge
--
Alan Mackenzie (Nuremberg, Germany).
prev parent reply other threads:[~2026-09-01 11:14 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 18:38 vt: Enlarge the framebuffer glyph size from 16 to 32 bits Alan Mackenzie
2026-08-27 18:42 ` [Patch 1/9]: Make consolemap.c handle Unicode planes outside BMP Alan Mackenzie
2026-08-27 19:14 ` sashiko-bot
2026-08-28 4:57 ` Jiri Slaby
2026-08-29 11:51 ` Alan Mackenzie
2026-08-27 18:45 ` [Patch 2/9]: Glyph size: Use GLYPH_SZ/HW rather than hardcoded 2, 1 Alan Mackenzie
2026-08-27 19:22 ` sashiko-bot
2026-08-27 18:47 ` [Patch 3/9]: Replace scr_readw/writew by scr_readg/writeg, etc Alan Mackenzie
2026-08-27 19:18 ` sashiko-bot
2026-08-29 12:11 ` Greg Kroah-Hartman
2026-08-29 13:33 ` Alan Mackenzie
2026-08-27 18:48 ` [Patch 4/9]: Amend internal manipulation of glyph structure Alan Mackenzie
2026-08-27 19:19 ` sashiko-bot
2026-08-27 18:50 ` [Patch 5/9]: vt: Amend three Kconfig files Alan Mackenzie
2026-08-27 19:12 ` sashiko-bot
2026-08-27 18:52 ` [Patch 6/9]: vt: Use u32 and typedef u1632 to handle whole glyphs Alan Mackenzie
2026-08-27 19:22 ` sashiko-bot
2026-08-27 18:54 ` [Patch 7/9]: vt: Handle up to 2^21 glyphs, rather than 256/512 Alan Mackenzie
2026-08-27 19:14 ` sashiko-bot
2026-08-27 18:56 ` [Patch 8/9]: vt: Enhancements to the VT ioctl interface Alan Mackenzie
2026-08-27 19:25 ` sashiko-bot
2026-08-27 18:58 ` [Patch 9/9]: vt: Misc changes, e.g. to #include directives Alan Mackenzie
2026-08-27 19:25 ` sashiko-bot
2026-08-29 12:06 ` Greg Kroah-Hartman
2026-08-28 6:12 ` vt: Enlarge the framebuffer glyph size from 16 to 32 bits Thomas Zimmermann
2026-08-28 14:36 ` Alan Mackenzie
2026-08-29 12:09 ` Greg Kroah-Hartman
2026-08-29 14:39 ` Alan Mackenzie
2026-08-31 6:20 ` Thomas Zimmermann
2026-08-31 14:45 ` Alan Mackenzie
2026-08-31 17:21 ` Helge Deller
2026-09-01 11:14 ` Alan Mackenzie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apazo2RIHiEAtpNN@MAC.fritz.box \
--to=acm@muc.de \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.