--Signature_Sun__5_Jun_2005_23_28_24_-0400_Z_=dSmpDp8oaIDe5
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

so, now that X with sunffb seems stable I did some digging to figure out
what's up with DRI. Looks bleak - apparently nobody bothered with it in
the last five years. I couldn't find anything about it besides some
rather uninformed posts on Linux mailing lists. ("don't bother" and
worse)
Anyway, after some digging in dri.freedesktop.org I found a very short
notice saying 'Creator3D and Elite3D cards are sort of supported, the
driver reportedly has serious issues'. That's it. I guess the 'serious
issues' is the memory thrashing bug in cfb32 we just got rid of.
Then I had a look at their cvs repository - lo and behold, there are a
few files beginning with ffb, written by some Dave Miller, this name
also appears in the sunffb driver ( and there's a list of names printed
on the Creator's PCB, one is DaveM ). Seems pretty much Linux-specific,
but if we can get the rest of the drm ( direct rendering manager, not
what /you/ think ) stuff to compile it shouldn't be too hard to port the
ffb-specific stuff, it's not that much.

I think we should find an agreement how to add drm functionality to
existing drivers as soon as possible. I'd prefer something like this:
ffb*	at mainbus?=20
drm* at ffb?

where drm would be kind of fb on drugs, contains the
hardware-independent stuff and the display driver implements what's
hardware-specific, more or less like we already do with fb, wsdisplay
and so on - define a bunch of hook functions. The problem with this is
that NetBSD/i386 and /macppc don't use hardware-specific display
drivers. On macppc I did some hacking to use the same display drivers as
sparc64 ( namely machfb ) instead of ofb and wrote another one for my
Voodoo3, since both platforms have sort of compatible firmware that
wasn't really hard.

This leaves the questions...
- is that at all feasible? Is a bunch of hooks enough? Maybe Tonnerre
can comment on this
- what do we do with macppc and i386? Add hardware-specific display
drivers? Seems necessary for this kind of stuff, I doubt anyone would
want drm-support for all kinds of different graphics chips duplicated in
vga(4), ofb(4) and card-specific drivers.
The nice thing about this approach would be...
- it can be implemented step by step, even as LKM(s).
- vga and ofb can still act as catch-all when no hardware-specific
driver claims the display device.=20
- people who don't want direct rendering support just use vga instead of
- say - radeonfb.

Or we could put the hardware-specific drm stuff into even more devices:
vga*	at pci?=20
drm* at vga?
radeondrm* at drm?
... but that seems odd and counterintuitive. When a driver can support
direct rendering it should be in the driver itself IMHO.

Comments?

have fun
Michael

--Signature_Sun__5_Jun_2005_23_28_24_-0400_Z_=dSmpDp8oaIDe5
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)

iQEVAwUBQqPC2cpnzkX8Yg2nAQLWLQgArcRT1UzYLoHmXqaNtor+Hv0d3Vaa8HSr
drCp6t1XdR2xIn3MEOkdfGVYKX9dKtmXqtr0U5mc/TBQVMajXy/+a9EfbQ82oW8K
5rdiugJH3Oau4wmq7brzXYUd4+Rb8IZVZPAcBVKkTM1iCjENaTqGPrrLUk3An8vo
pJrL89lEmXOGPGSZ+qGradNtKwKa3OyBdSAvLBB3TlLnZgQEkB+wQCAc6f00i/Jt
rEJfAsh7GF0mAE4QE7/PB1yvvUHoz72V88rFcBvkXB5mpXOlPT6lbBkmvh4B2I+C
czDCVEgtjKxWnsUCUr98tojXvKVAA5LGaKMwH2QF0n89OXYsarHnZA==
=Z1e/
-----END PGP SIGNATURE-----

--Signature_Sun__5_Jun_2005_23_28_24_-0400_Z_=dSmpDp8oaIDe5--