Subject: Re: Ultra 5 X11
To: Michael <macallan18@earthlink.net>
From: Eduardo Horvath <eeh@NetBSD.org>
List: port-sparc
Date: 02/10/2005 17:32:00
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