From: James Simmons <jsimmons@infradead.org>
To: Microcai <microcai@fedoraproject.org>
Cc: Vojtech Pavlik <vojtech@suse.cz>,
linuxconsole@vger.kernel.org,
linuxconsole-dev@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] Kernel fbcon UNICODE font support
Date: Thu, 2 Dec 2010 13:50:28 +0000 (GMT) [thread overview]
Message-ID: <alpine.LFD.2.00.1012020137320.28091@casper.infradead.org> (raw)
In-Reply-To: <1290932981.710.2.camel@cai.gentoo>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1665 bytes --]
> 在 2010-11-28日的 09:15 +0100,Vojtech Pavlik写道:
> >
> > Well, on VGA you could use the 512 glyphs available (9 bit character, 7
> > bit attribute) and dynamically change the font in the video memory to
> > always contain the characters that you need on the screen. Chances are
> > that you won't need all 512 at any single time. The screen isn't that
> > large in classic VGA mode.
> >
> > But since VGA is mostly dead these days anyway, it'd be a neat hack, but
> > probably not worth the effort.
>
> Can't do that. That's too tricky, and some times we *DO* need more than
> 512 different glyphs.
BTW the console developement branch is at
git://git.infradead.org/~jsimmons/public_git/linuxconsole-2.6.git
I have managed to do massive cleanup to the console layer but its not
quite ready for general testing. Its mostly working but there are still
some major bugs. As for the VC screen buffers the issue is that the default
screen buffers where based on the VGA text mode. In fact the visible VC for
vgacon is the actually vga video buffer. When we do a VT switch it copys
the video buffer to a software buffer and then loads the vga video buffer
with the VCs software buffer we switched to.
This is nice and neat for vgacon but it doesn't flow so nicely with
graphical consoles or text LCDs. What I like to see is the attribute
buffer be split from the vc_screenbuf. The bonus is in embbeded systems we
could arrange the code so we could have a light weight printk VT without
the extra junk of the VC. Do we really need a attribute buffer for printk?
I believe that would be the first step in the right direction.
next prev parent reply other threads:[~2010-12-02 13:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-26 5:53 Microcai
2010-11-27 12:57 ` Samuel Thibault
2010-11-27 16:18 ` microcai
2010-11-27 16:39 ` Samuel Thibault
2010-11-28 6:50 ` microcai
2010-11-28 8:15 ` Vojtech Pavlik
2010-11-28 8:29 ` Microcai
2010-12-02 13:50 ` James Simmons [this message]
2010-12-02 13:59 ` Samuel Thibault
2010-12-02 18:25 ` James Simmons
2010-11-28 8:47 ` Samuel Thibault
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=alpine.LFD.2.00.1012020137320.28091@casper.infradead.org \
--to=jsimmons@infradead.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxconsole-dev@lists.sourceforge.net \
--cc=linuxconsole@vger.kernel.org \
--cc=microcai@fedoraproject.org \
--cc=vojtech@suse.cz \
/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®