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 <[email protected]> > > 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).
