On Thu, Feb 10, 2005 at 12:08:59PM -0500, Michael wrote:
> 
> >In practice, things start to break down if you do that.  First of all,
> >OBP only initializes the screen if it's the console device.  But that
> >shouldn't really be a problem since the machfb driver should be smart
> >enough to initialize the framebuffer itself.
> In theory it should set up something usable, the question is if video 
> memory and registers would still be mmap()able through /dev/ttyE0.

Once again, this is a wscons issue.  If wscons manages to get itself
initialized correctly it should work.

> >Finally, if the machfb driver is capable of initializing the display
> >it should also be capable of taking over the console from the X server.
> >That it doesn't should be considered a bug.
> Which console? XFree doesn't tell wscons what it does to the video 
> hardware so wscons has no way to print anything meaningful on the 
> screen as long as XFree is running. Handing it back when the Xserver 
> exits works fine.

This is not a PC (although it does use some of the same hardware).
There is no character mode display.  Everything is in graphics mode.
And machfb can initialze the screen from powerup.  I have seen it
do so.  Whatever strange things XFree does to the display machfb 
should be able to undo.  Or detect and work around.  And the X
server should be able to recover from whatever machfb did.  Under
Solaris I can hit Stop-A, get to the OBP, type some commands, type
`go' and resume X (after a refresh screen) with no problems.  In
fact, I just did.  I don't see why NetBSD can't do the same.

Eduardo