From: "Antonino A. Daplas" <adaplas@gmail.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Albert Cahalan <acahalan@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
aeb@cwi.nl, hpa@zytor.com
Subject: Re: console font limits
Date: Tue, 01 May 2007 20:11:56 +0800 [thread overview]
Message-ID: <1178021516.4372.62.camel@daplas> (raw)
In-Reply-To: <Pine.LNX.4.64.0705011347300.27246@anakin>
On Tue, 2007-05-01 at 13:49 +0200, Geert Uytterhoeven wrote:
> On Tue, 1 May 2007, Albert Cahalan wrote:
> > 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.
>
> The shadow screen (accessed using scr_*()) still uses the old VGA
> format.
And this will entail a lot of work to change (Is it worth it to rework
the code and remove the limitation?). The linux-console project
(http://linuxconsole.sourceforge.net/) might have , but I don't know its
current status.
Tony
next prev parent reply other threads:[~2007-05-01 12:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 4:09 console font limits Albert Cahalan
2007-05-01 11:49 ` Geert Uytterhoeven
2007-05-01 12:11 ` Antonino A. Daplas [this message]
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=1178021516.4372.62.camel@daplas \
--to=adaplas@gmail.com \
--cc=acahalan@gmail.com \
--cc=aeb@cwi.nl \
--cc=geert@linux-m68k.org \
--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