Re: Geode GX framebuffer driver: Arcom vs. AMD

["Jordan Crouse" <jordan.crouse@amd.com>]

On 14/07/07 17:05 -0400, Andrew Paprocki wrote:
> Tony,
> 
> Do you have the patch working already? I'd love to try this out in the
> meantime on the LX system I am developing with at the moment. I'm
> assuming you worked this into the existing Arcom framework (gxfb) and
> pulled the necessary pieces from the AMD code?

Actually no.  There was enough extra stuff in the lxfb par structure
that I just made it its own driver.  The other two Geode drivers really
try to be more generic then they should be.  There is probably code that
can be shared between the three, but the core is just different enough
that the drivers shouldn't be merged together.

> Also, question for AMD/Jordan.. Is AMD going to provide any
> support/patches for the existing gxfb and this new lxfb? (Maybe
> perhaps an AMD supported DirectFB driver? :))

You asked two different questions.  Yes, we plan to support the gxfb
and lxfb code in the kernel for the foreseeable future.  No, we are not
going to support any additional graphics engines beyond the kernel
framebuffer driver and the X driver.  Sorry.

> If anyone else is interested, I'll get around to making a patch of the
> work I just did to bring the original AMD 2.6.11 framebuffer &
> Cimarron fully up to date with the 2.6.22 tree. If AMD is going to
> continue to maintain their own driver, this will allow the use of an
> up-to-date kernel.

I don't believe we're going to continue maintaining that driver for new
kernels when the lxfb goes into the kernel.  I now really regret using 
Cimarron for that previous driver - that was a combination of laziness
on my part, and a general naivity by AMD as to how the kernel works.  
We soon realized what should have been obvious from the start - a massive
processor specific HAL to support two drivers just doesn't belong in
the kernel.  Thats why we never sent it up, and thats why we wrote
the new lxfb driver.

Jordan