Subject: Re: framebuffer access
To: Miles Nordin <carton@Ivy.NET>
From: Michael <macallan18@earthlink.net>
List: port-sparc64
Date: 11/16/2005 09:51:39
Hello,

>      m> wsdisplay was never meant to be a framebuffer device,
> 
> In that case, it would be nice if the ``text'' mode framebuffer were
> smart enough to drop into ddb while X is running.

This requires someone telling the driver about it. 
The problem with switching consoles is - if one console is in graphics
mode you need to tell the program hogging it to let go, wait for an ack,
then switch. Forcing a switch WILL break things since there's no such
thing as virtualization in any meaningful way.

> And there's more.  Why is switching between ``virtual consoles'' a
> machine-dependent feature, so that new ports have to wait years before
> someone goes back and adds it?  

Good question. It shouldn't really be in the driver.

> Why isn't there a way. as there is on Linux, to run a
> machine-independent unaccelerated ``Xframebuffer'' server on any port
> that has a software-rendered wscons console?

There is - use XFree's wsfb driver.

> Why is it impossible to run a software-rendered console on i386
> (something Linux has done, I think _by default_, for years)?

It is possible. Use machfb or run vga in graphics mode.

have fun
Michael