All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Simona Vetter <simona@ffwll.ch>,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
	Helge Deller <deller@gmx.de>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [Patch 1/9]: Make consolemap.c handle Unicode planes outside BMP
Date: Sat, 29 Aug 2026 11:51:20 +0000	[thread overview]
Message-ID: <apLHuOHMjO5OzX9E@MAC.fritz.box> (raw)
In-Reply-To: <d1437839-5a08-46d9-b40d-83faae7b19c9@kernel.org>

Thanks for trying the patch out.

On Fri, Aug 28, 2026 at 06:57:04 +0200, Jiri Slaby wrote:
> On 27. 08. 26, 20:42, Alan Mackenzie wrote:
> > vt: 32b glyph: 1. Make consolemap.c handle Unicode planes outside BMP

> > For this, add a fourth layer "planes" onto the sparse map in
> > this file.  Also handle glyph numbers up to 2^21 rather than
> > 256/512.  Move the conversion between __user and kernel data
> > from consolemap.c to vt_ioctl.c.

> > Signed-off-by: Alan Mackenzie <acm@muc.de>

> > diff --git a/drivers/tty/vt/consolemap.c b/drivers/tty/vt/consolemap.c
> > index 3fa89a2dbeba..2f695d97f0eb 100644
> > --- a/drivers/tty/vt/consolemap.c
> > +++ b/drivers/tty/vt/consolemap.c
> > @@ -34,11 +34,11 @@
> >   #include <linux/tty.h>
> >   #include <linux/uaccess.h>
> >   #include <linux/console.h>
> > -#include <linux/consolemap.h>
> >   #include <linux/vt_kern.h>
> > +#include <linux/consolemap.h>

> Why do you do this?

That's a remnant of a struggle to put in new declarations such that the
kernel would build at all.  I've just tried restoring the original order
of the #includes for consolemap.h and vt_kern.h, and it builds equally
well.  So that change could/should be undone.

> >   #include <linux/string.h>

> > -static unsigned short translations[][E_TABSZ] = {
> > +static u1632 translations[][E_TABSZ] = {

> This breaks the build at this point, right?

I'm assuming your error message was "symbol u1632 undeclared".  I don't
understand yet what's happened here.  u1632 gets declared in
consolemap.h, so should be avaiable throughout consolemap.c.

> u1632 is a bad name though.

Possibly.  It's the best I could come up with, given it should be concise
and thus not cause a lot of refilling of the source code.  I'm not sure
what would be better instead of u1632.

> See also what Sashiko thinks:
> https://sashiko.dev/#/patchset/apCEDM2sWv_M354-%40MAC.fritz.box

Sashiko has pointed out a number of errors I'll need to fix.  I got nine
emails directly from it.

> thanks,
> -- 
> js
> suse labs

-- 
Alan Mackenzie (Nuremberg, Germany).

  reply	other threads:[~2026-08-29 11:51 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 [this message]
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

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=apLHuOHMjO5OzX9E@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.