Subject: Re: wsdisplay on vesafb is slow
To: None <email@example.com>
From: Valeriy E. Ushakov <firstname.lastname@example.org>
Date: 12/27/2006 04:46:51
On Tue, Dec 26, 2006 at 20:33:35 -0500, Thor Lancelot Simon wrote:
> Subject: Re: wsdisplay on vesafb is slow
> On Mon, Dec 25, 2006 at 10:04:01PM -0800, Aaron J. Grier wrote:
> > On Thu, Dec 21, 2006 at 04:31:24PM -0500, Thor Lancelot Simon wrote:
> > > On Thu, Dec 21, 2006 at 03:58:18PM -0500, Michael Lorenz wrote:
> > > > There was a proposal for a VESA BIOS extension to talk to a blitter
> > > > but as far as I remember it never got anywhere.
> > >
> > > Can't it use VGA text mode for text, at least?
> > vesafb would cease to be a framebuffer, then, and isn't that the whole
> > point of vesafb?
> > > The problem is, with wscons attached to vesafb, the console is
> > > unusuably slow; with wscons attached to vga, and a direct-hardware-
> > > access X server, X11 is unsafe.
> > so pick your poison.
> That's an incredibly bogus non-answer. We already have wscons drivers
> that provide accellerated text rendering using hardware text modes while
> also providing usable-by-X frame buffers.
> What exactly is the excuse why vesafb must (according to you, and
> evidently Michael too) not work that way? The fact that it can't is
> responsible for a major longstanding security hole in the i386 port.
I agree with Thor here. I have little clue about vga text mode, but
wscons distinguishes (WSDISPLAYIO_SMODE) between mapped and emulated
(i.e. text console) modes. Just treat vga text mode as a peculiar
"acceleration" for the emulated mode and switch to the framebuffer for
the mapped mode.
It makes life easier for the driver author to always run in the same
framebuffer mode, so that switching to the wscons mapped mode in the
driver is basically a no-op, but that's a weak excuse :)
email@example.com | Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen