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

Salut,

On Mon, Jun 06, 2005 at 01:20:29AM -0400, Michael wrote:
> > Running DRM on _top_ of a framebuffer device is not exactly easy, and
> > may be undesirable, since the job of DRM is to keep hardware buffers
> > and the GPU registers and all accessible from userland.
>=20
> Not on top - if I understood the drm code at all then there's some
> portion that's device specific and another one that can be shared. I
> would put the part that talks to the hardware into the display driver
> and just attach the shared stuff on top of it, more or less like
> wsdisplay / rasops - the display driver does the gruntwork - mapping
> memory areas and such, while the shared layer sits between
> /dev/drm/card* and the device driver, keeps track of minor device
> numbers and so on so we don't have to replicate this in each and every
> display driver.

You can surely split and change the DRM code I provided you with, but I wish
you good luck maintaining it, because the current form has the advantage
of being shared code between Linux, FreeBSD and us. That's why I would only
dare to add hooks for VGA or a radeonfb-like thingie. While you can refactu=
re
the driver and split it, it's going to be a bit harder to stay in sync with
the official DRM distribution.

As to shared code, that's a bit difficult because of all the defines, most
of the code starts to look different if you have e.g. a card that supports
scatter-gathering, or one that supports using a GART, etc. This is card
specific, and while you could maybe implement runtime checks you should
bear in mind that this will reduce the performance of your rendering driver.
The purpose of DRM is direct rendering - taking a shortcut from graphical
applications to the graphics card's rendering engine.

It's surely possible to do the split you're suggesting, but either you end =
up
still having most of the code specific to the graphics card, or you may
experience a loss of performance. Either way you're going to get out of sync
with the codebase.

On the other hand, we're nerds, and we might not care about the codebase at
all. It's up to you. I'm only suggesting here.

				Tonnerre

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

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

iD8DBQFCo99LXUVlAbfmNMIRAqMeAKChx5oNANt01MzS8C3oCflQ/KHn1QCgpTal
ozfGAUeDniKK5p+kAS6LgA8=
=Ynrx
-----END PGP SIGNATURE-----

--vJguvTgX93MxBIIe--