Subject: Re: ofb proposal
To: Brian Hechinger <wonko@4amlunch.net>
From: Michael <macallan18@earthlink.net>
List: port-macppc
Date: 01/29/2005 12:51:12
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

>> - - if we don't use ofb as console the current code will fall back to
>> serial
>
> also, the -current issue with the kernel correctly outputing console 
> to the
> video of your choice and then init using serial console anyway.  lately
> proving to be very annoying as the machine that is acting as serial 
> console
> for the mac crashed the other day when i was in -current, and the 
> reset of
> that machine hangs the mac.  that's not good.  ;)
Update your sources :)

>> - - maybe make the rest of ofb machine-independent, the other
>> OpenFirmware / OpenBOOT platforms could use it.
> this is never a bad idea.  the more MI things are, the better.
Currently framebuffer drivers are far from machine independent, they 
have to rely on things like OF to figure out if they're console ( the 
kernel should tell them I guess ) or which resolution  they should use. 
Although sharing them between macppc and sparc64 should work with minor 
#ifdef'ing

>> - - a chance to reset the console in case - for instance - an Xserver
>> crashes and fails to clean up after itself
>
> or in the case of my 8600+Radeon, when the Xserver exits it never 
> returns
> the console back to the way it was.  xdm fixes this since it grabes the
> video and resets it for its own needs, but if i use startx and then 
> exit
> X, i never get my video back for text mode.
That's the Xserver's fault, it's supposed to leave the video hardware 
in exactly the same state as it found it ( apart from framebuffer 
content of course ) - it works on all my boxes now, no idea what goes 
wrong with the Radeon.

>> So far there are two drivers which we could use - machfb from sparc64 
>> (
>> in -current, should work on macppc but is untested because the only 
>> ATi
>> Rage chip I have is soldered on my U10's mainboard. It compiles
>> flawlessly though. ) and my experimental voodoofb which supports
>> Voodoo3 graphics boards.
>
> what do you need to test?  i'm sure i could find someone who could dig 
> up
> the card you need to test this.
a PCI Rage 3D (or something similar, as long as it's somehow 
Mach64-based) with Macintosh firmware which works with OF 1.0.5 would 
be all I need video RAM doesn't really matter, shouldn't be less than 
2MB though. With that I could probably figure out what goes wrong with 
Riccardo's 4400 and its onboard Rage too.

btw. the Voodoo3 driver works fine now, no resolution switching yet but 
the blitter is devilishly fast, it's hard to tell the difference to a 
textmode console :)

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQfvNEMpnzkX8Yg2nAQK6gQgAr5fNdyVJpGbYj2x+XvHOZi4r0z8gsfAh
hxyCOl47WwmS8iHD5BobL+er3VN3X6fjVmWw9Mb9q5GoLXLWJIqT9J8hDF1My21V
BuudQErjSoIljh7tOgS+FJUQOChswCWXj+16PabXbiA+sgIXLy5lDOGH2Ip4qP6r
2sB7tBXuayz69dQgFRQkFLI92OWQJ88Vw5app7J/PrHzVsSJXNidj7/FNSs9i6xo
lVp3FwhLUJ5ed1un0Bb6wxLZtqumkxsaB/0sFGpYmpen1XAG5yNPf2OFjWup45Tv
tKA2PiaPAzbTUQvN7+GwEcvMJEs/3NeZFZfulxVf5P9rKW0wGoB80Q==
=iIQ5
-----END PGP SIGNATURE-----