linux-kernel - Re: Geode GX framebuffer driver: Arcom vs. AMD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070718014224.GA19669@cosmic.amd.com>
Date:	Tue, 17 Jul 2007 19:42:24 -0600
From:	"Jordan Crouse" <jordan.crouse@....com>
To:	"Andrew Paprocki" <andrew@...iboo.com>
cc:	"Antonino A. Daplas" <adaplas@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Geode GX framebuffer driver: Arcom vs. AMD

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/