Re: [kbd] [patchv2 3/3] VT: Bump font size limitation to 64x128 pixels
Samuel Thibault <[email protected]> Sun, 18 Dec 2022 15:55:32 +0100
| Newsgroups | dev.linux.lists.kbd,org.kernel.vger.linux-kernel |
|---|---|
| Organization | I am not organized |
| Message-ID | <20221218145532.syqzu76q23rz4tx6@begin> |
Hello, Alexey Gladkov, le dim. 18 déc. 2022 15:39:38 +0100, a ecrit: > On Sun, Dec 18, 2022 at 01:32:12AM +0100, Samuel Thibault wrote: > > This moves 32x32 font size limitation checking down to drivers, so that > > fbcon can allow large fonts. > > > > We still keep a limitation to 64x128 pixels so as to have a simple bounded > > allocation for con_font_get and in the userland kbd tool. That glyph size > > will however be enough to have 128x36 characters on a "16/9 8K display". > > > > Signed-off-by: Samuel Thibault <[email protected]> > > > > --- > > V1 -> V2: Switch con_font_get to kvmalloc/kvfree instead of kmalloc/kfree > > > > Index: linux-6.0/drivers/tty/vt/vt.c > > =================================================================== > > --- linux-6.0.orig/drivers/tty/vt/vt.c > > +++ linux-6.0/drivers/tty/vt/vt.c > > @@ -4575,17 +4575,20 @@ void reset_palette(struct vc_data *vc) > > /* > > * Font switching > > * > > - * Currently we only support fonts up to 32 pixels wide, at a maximum height > > - * of 32 pixels. Userspace fontdata is stored with 32 bytes (shorts/ints, > > - * depending on width) reserved for each character which is kinda wasty, but > > - * this is done in order to maintain compatibility with the EGA/VGA fonts. It > > - * is up to the actual low-level console-driver convert data into its favorite > > - * format (maybe we should add a `fontoffset' field to the `display' > > - * structure so we won't have to convert the fontdata all the time. > > + * Currently we only support fonts up to 128 pixels wide, at a maximum height > > + * of 128 pixels. Userspace fontdata may have to be stored with 32 bytes > > + * (shorts/ints, depending on width) reserved for each character which is > > + * kinda wasty, but this is done in order to maintain compatibility with the > > + * EGA/VGA fonts. It is up to the actual low-level console-driver convert data > > + * into its favorite format (maybe we should add a `fontoffset' field to the > > + * `display' structure so we won't have to convert the fontdata all the time. > > * /Jes > > */ > > > > -#define max_font_size 65536 > > +#define max_font_width 64 > > +#define max_font_height 128 > > +#define max_font_glyphs 512 > > +#define max_font_size (max_font_glyphs*max_font_width*max_font_height) > > As a suggestion that you can safely ignore. Maybe make max_font_glyphs a > sysctl parameter to be able to use larger fonts ? > > I get requests from time to time in kbd that it is not possible to load a > larger font. 64KiB was really low, while the theoretically possible max was 32*32*512 = 512KB, so I understand there used to be such requests :) Here, by setting the max to 64x128*512, I don't think we'll need more. Even with a 8K screen (will such really exist and want a text console?) the max 64x128 gets 128 characters on a single line, for soemthing like 36 lines. So I guess it's not worth adding yet another sysctl :) Samuel