--cf0hFtnykp6aONGL
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Salut,

On Mon, Jun 06, 2005 at 02:13:48AM -0400, Michael wrote:
> True, we'd end up with our own drm code. On the other hand we'd be less
> x86-dependent and it would be easier to add support for new graphics
> devices. On the other hand - there's already plenty of BSD- or
> Linux-specific code, the kernel modules don't share a lot as far as I
> can tell.

The current DRM works with XFree86, X.Org and DirectFB, and as I heard
even the Enlightenment stuff uses it, but I might be wrong there, I
haven't looked at e in quite some years..

> How likely is the drm API to change any time soon? I mean the ioctl()s,
> defines and so on.

It's trying to be stable but it is subject to change.

> Is the current drm code really platform-independent? How much work would
> it be to get the radeon module to work on - say - macppc? Or sparc64?

I can't remember anything arch specific in the code. It just relies on PCI
right now, but you could of course simply introduce SBUS attachment code
in the driver specific code.

> What I'm getting at is - what do you think would be easier to maintain -
> the current drm code with support for i386, macppc and sparc64 frobbed
> into it, with the prospect of adding more platforms, or a (partial)
> re-implementation in NetBSD-style?=20

I think the code does more than you think, and it's easier to cooperate with
its maintainer - Eric Anholt - than to start spitting out NetBSD specific
solutions. If the code turns out not to be portable at some point, we can
still push code through him, but I'll personally choose to cooperate, as
I did in the past.

				Tonnerre

--cf0hFtnykp6aONGL
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCpIjnXUVlAbfmNMIRAsaKAJ4/HkL2ehI0B/IDiqKWlYXQs65fJQCdHtFz
IUOZ3ENYLRKb0+/t1MqurB8=
=qZ08
-----END PGP SIGNATURE-----

--cf0hFtnykp6aONGL--