linux-kernel - Re: [PATCH] Kernel fbcon UNICODE font support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1012020137320.28091@casper.infradead.org>
Date:	Thu, 2 Dec 2010 13:50:28 +0000 (GMT)
From:	James Simmons <jsimmons@...radead.org>
To:	Microcai <microcai@...oraproject.org>
cc:	Vojtech Pavlik <vojtech@...e.cz>, linuxconsole@...r.kernel.org,
	linuxconsole-dev@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] Kernel fbcon UNICODE font support


> 在 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.