I did some basic work on factoring out the common code and discussed it
with Thomas Winischhofer (Sis maintainer and driving force behind
mergedfb development).  He is of the opinion that it is still too early
to create a generic API for mergedfb.  There is still no consensus on
what the final look should be and whether or not we have a flexible
enough model right now.  Plus there are some new features in the
pipeline that may require some reworking of the current common code
(absolute offsets and panning domains).  It's more of a pain to have to
constantly update the common code.  So at the moment I guess I'm
inclined to agree.  thoughts?

Alex

--- Michel D�nzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2003-09-10 at 15:46, Alex Deucher wrote:
> > > 
> > > It seems like a lot of cards have this type of capability and
> lots of
> > > drivers are doing this somewhat independently of one another.  Is
> there 
> > > some common code that can be abstracted out?  (Looking quickly
> over 
> > > the code indicates that a big percentage of it looks pretty 
> > > hw-independent).
> > 
> > I agree.  Most of it is HW independant.  This was discussed several
> > times on the xfree86 devel ML, and everyone agrees that it should
> be
> > factored out into common code, however, when that will happen is
> kind
> > of hazy.  I thought about trying to do some of the work myself, but
> I
> > guess we need a consensus on what's the best "mergedfb" API.  the
> usual
> > "5.0" material response.
> 
> As a first step, it shouldn't be too much work factoring out the
> common
> helper functions, possibly into a new module?
> 
> > Everyone is busy, so I don't know when the commom code would be
> > written, much less an API agreed on.  Thomas' sis mergedfb code
> (which
> > my radeon code is based on) is already in the xfree86 tree.  Both
> of
> > our implementations plus the mga driver share the same mergedfb
> options
> > so they are consistent.  
> > 
> > I don't want to write the common code only it have it be a waste of
> > time due to a refactoring of X internals planned for 5.0 or because
> my
> > API is lacking.
> 
> I wouldn't worry too much about 5.x yet, that's still in the distant
> future AFAICT. IMHO the pains that code duplication will cause in the
> meantime (we've seen over and over that even the tiniest duplication
> can
> cause considerable grief) greatly outweigh the potential 'waste' of
> time
> factoring out the common code. (As a side note, I'd expect this to be
> much easier than merging the Radeon 3D drivers :)
> 
> 
> -- 
> Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI
> developer
> Software libre enthusiast  \    
> http://svcs.affero.net/rm.php?r=daenzer
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to