graphics futures - untoasted..

graphics futures - untoasted..

[Dave Airlie]

Hi,
	Okay so now that everybody has nearly all the flames out of their
systems (including myself - I ran a half marathon to take a break :-),

Alan/Linus idea is probably going to be what happens so I thought I'd give
it a fair chance and try and see why we need it...

So what are peoples view on doing the following to the radeon driver after
Alan has showed the code...

We use Alan's framework to setup 3 drivers, radeon common, fb and dri..

The common code is things both fb and dri want to do right now, at the
moment, they both write mmio/plls, have info about card capabilties, wait
for card sync, into the once place, and have the the fb and dri contain
all the unshared code, so we don't get duplication and we don't get
bloating of the fb or drm,

Now I know someone might say that we probably don't need a common layer,
that with Alans scheme the fb can call the drm and the drm the fb, but if
this happens then you start mandating the fb be loaded for certain DRM
things and vice-versa, which to me means you may as well merge them as
otherwise the drivers will start losing features if one side is loaded
without the other and if you have to have both loaded, why wouldn't you
merge em... also having two copies of the really common code is a bit
pointless..

I'll probably do an i830 also, there isn't any fbdev for 2.6 for the i830
at all, so I probably can't step on too many toes :-)

Anyways when Alan posts a working patch, I'll try and come up with
something soon after....

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person

Re: graphics futures - untoasted..

[Alan Cox]

On Llu, 2004-09-13 at 13:10, Dave Airlie wrote:
> So what are peoples view on doing the following to the radeon driver after
> Alan has showed the code...

I've not had time to test it but I just posted the code as-is since
thats probably the best way right now

> Now I know someone might say that we probably don't need a common layer,
> that with Alans scheme the fb can call the drm and the drm the fb, but if
> this happens then you start mandating the fb be loaded for certain DRM
> things and vice-versa,

Agreed - it will depend on the card, and on what makes sense for other
reasons. Memory manager code may also need to be part of that. The code
I posted has no provision for "common" module, but just add it to the
list and it'll hopefully DTRT. Providing the DRI and FB drivers
reference symbols in the common module it'll also autoload properly.

Let me know what you think of the code so far (however bad) and I'll try
and get it ticking nicely.