There was also some discussion about being able to do quiesce OF once 
we don't need OF directly for console I/O. It all sounds good to me. I 
would assume that darwin does something similar to what you propose 
before it loads a native video driver or attaches the NDRV through a 
wrapper. Would be interesting if we could attach vga to pc cards 
without fcode drivers too, but that's a design goal for much later.

On Jan 28, 2005, at 1:44 PM, Michael wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> I've been hacking some framebuffer drivers into wsdisplay conformity 
> on sparc64 and now I was wondering if they could be used on macppc too 
> - especially the machfb driver for the Ultra 5 and 10 onboard video 
> chip could be useful ( it supports various mach64 / Rage 3D chips ). 
> The problem is, that console attachment works quite different in 
> sparc64 and macppc - on macppc ofb_cnattach gets called very early, 
> sets up a basic framebuffer console and later attaches the rest via 
> PCI. On sparc64 there's no equivalent to ofb_cnattach, it simply uses 
> the PROM output or something similar until a driver takes over the 
> console.
> The macppc approach has several problems:
> - - you can't use another console display driver than ofb without 
> hacking machdep.c
> - - if we don't use ofb as console the current code will fall back to 
> serial
> - - all of ofb's own shortcomings.
>
> What I'd like to do is the following:
> - - move the ofb_cnattach code somewhere else so it's always present 
> in the kernel even without using the ofb driver.
> - - use this code to implement the early boot console to display 
> kernel output until a framebuffer driver takes over - or all the time 
> if none does
> - - maybe make the rest of ofb machine-independent, the other 
> OpenFirmware / OpenBOOT platforms could use it.
> This would allow to use other framebuffer drivers as console without 
> having to worry about macppc specifics. What would remain of ofb is 
> mainly ioctl() and mmap() support so we won't lose functionality.
> Using other framebuffer drivers would have the following benefits:
> - - acceleration. Using cache is nice but a blitter is better, 
> especially on slower CPUs.
> - - other resolutions than what OF sets up - not really implemented 
> but it's a possibility
> - - a chance to reset the console in case - for instance - an Xserver 
> crashes and fails to clean up after itself
> 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.
>
> have fun
> Michael
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
>
> iQEVAwUBQfqH8spnzkX8Yg2nAQJWfggAisWt5ui0vkooNZT4rT+kuK4Q3y5qnQub
> tG5JyVP3hTf5CQ9dBQEKudJRaRnpu69aOgS15MiD77gyxG8HSzBUkNRXQ58f1mDA
> U45WAv1FytH8owj5t2YyoMB9bOPIidClLnjLZqzjCl0QihdY7AjLplfehTE+vd2o
> PAt/P5MvTdkcZS82IxGKTI6RfXHL7/N6bvSpIlHAih8Y1zYxwGNPlXVtKW4Qginf
> tMaJqVTJZI/MGhQrUBMA0ZSkVcxoW2A2WsWaQAZysf+89Ejzwb1vOs7cNKIibz2q
> 1xduvvG1cMMiS0SyT5VhkMXS+X+UHQ5Y4EHuIW3urZ7K9s8jhJH+8Q==
> =xTQY
> -----END PGP SIGNATURE-----