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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ