From: "Albert Cahalan" <acahalan@gmail.com>
To: linux-kernel <linux-kernel@vger.kernel.org>, aeb@cwi.nl, hpa@zytor.com
Subject: console font limits
Date: Tue, 1 May 2007 00:09:46 -0400 [thread overview]
Message-ID: <787b0d920704302109r352e6653wc71a0638cbfbdcce@mail.gmail.com> (raw)
I'm having problems with a font I just created. It's a rather big one,
intended for a framebuffer console in UTF-8 mode. The strace program
reports that /bin/setfont fails on a KDFONTOP ioctl with EINVAL.
In reading the kernel code, I find this:
vt.c:static int con_font_set(struct vc_data *vc, struct console_font_op *op)
vt.c-{
vt.c- struct console_font font;
vt.c- int rc = -EINVAL;
vt.c- int size;
vt.c-
vt.c- if (vc->vc_mode != KD_TEXT)
vt.c- return -EINVAL;
vt.c- if (!op->data)
vt.c- return -EINVAL;
vt.c- if (op->charcount > 512)
vt.c- return -EINVAL;
Ouch. Why is the old VGA limit being applied to the framebuffer console?
Could this just get removed? I dearly hope we aren't still storing the
framebuffer data as two bytes per character+attribute pair.
I nearly hit the 32-pixel height limit as well, yet another relic from
the VGA hardware. I also nearly hit the 64 KB font size limit.
Currently I'm doing a 15x30 font with 870 glyphs to represent 978
different Unicode code points. This is for a 200 DPI display with
an anti-aliasing filter, so fonts need to be big. I'm considering 15x36
so that I'll have more room for double-accented letters, but clearly
the kernel would block that too.
BTW, the PSF font format documentation seems to suggest that
there is a way to make the kernel handle combining accents:
http://www.win.tue.nl/~aeb/linux/kbd/font-formats-1.html
Does anybody know if that really works? I could sure use that.
next reply other threads:[~2007-05-01 4:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 4:09 Albert Cahalan [this message]
2007-05-01 11:49 ` Geert Uytterhoeven
2007-05-01 12:11 ` Antonino A. Daplas
2007-05-01 15:05 ` H. Peter Anvin
2007-05-01 15:49 ` Albert Cahalan
2007-05-02 18:02 ` Jan Engelhardt
2007-05-03 6:17 ` Albert Cahalan
2007-05-03 7:12 ` Jan Engelhardt
2007-05-03 14:14 ` Albert Cahalan
2007-05-03 14:26 ` Jan Engelhardt
2007-05-03 15:56 ` Geert Uytterhoeven
2007-05-03 18:27 ` Jan Engelhardt
2007-05-03 20:15 ` H. Peter Anvin
2007-05-03 20:16 ` Jan Engelhardt
2007-05-04 0:17 ` Kyle Moffett
2007-05-04 0:39 ` H. Peter Anvin
2007-05-04 3:58 ` Daniel Hazelton
2007-05-04 4:59 ` Antonino A. Daplas
2007-05-04 15:34 ` Jesse Barnes
2007-05-06 23:35 ` Daniel Hazelton
2007-05-03 7:19 ` H. Peter Anvin
2007-05-03 7:45 ` Helge Hafting
2007-05-03 10:20 ` Alan Cox
2007-05-01 17:06 ` Ken Moffat
2007-05-03 17:11 ` Andries Brouwer
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=787b0d920704302109r352e6653wc71a0638cbfbdcce@mail.gmail.com \
--to=acahalan@gmail.com \
--cc=aeb@cwi.nl \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®