R7.1 roadmap, and additional goals
libv at skynet.be
Thu Apr 13 20:57:50 PDT 2006
On Fri, Apr 14, 2006 at 12:56:13PM +1000, Dave Airlie wrote:
> yeah I don't agree with Luc on this either, he has "separated" out the
> driver in the unichrome driver but they are still part of the
> unichrome setup, still use via naming,
> I've separated the Sil164 out in my i830 driver (granted by sil164
> driver does very little), but the it doesn't mention I830 at all, and
> doesn't require anything from the i830 driver other than for it to
> load it..
> Some pieces of Lucs API might be worth re-using but I thought it might
> be a bit over complicated in parts, and still too tightly bound to the
> unichrome codebase to be off any use..
It seems that the fact that the string via appears everywhere is the
reason why my abstraction is deemed bad. Most people think it's bad
to not prepend XXX to global functions and structs in drivers, but it's
nothing sed can't handle.
Then there's the fact that it's not poured into modules yet. But what
use is the tiny bit of loader work needed at this point, when there's no
second driver making use of this yet. Because that should be the
criterium for modularity. The last thing we need is more of the "ati
uses it, let's push our lack of abstraction into xfree86/i2c/" kind of
Over complicated? Compared to what's needed for TMDS, sure. But TV
encoders are a whole different ballgame, yet they still need to fit into
the same abstraction. In my view it still lacks a few things, but what's
mainly holding me back is ENOHW.
More information about the xorg