naming of DDXen.

[Egbert Eich]

Adam Jackson writes:
 > On Tuesday 14 June 2005 15:06, Adam Jackson wrote:
 > > This is valid.  I don't know that we really want to fork the entire driver
 > > just to switch AAs.  I'm of the opinion that any forked driver should be
 > > explicitly marked by having a new name from the xorg.conf perspective.
 > >
 > > In other words:
 > >
 > >   driver/xf86-input-mouse
 > >   driver/xf86-video-mga
 > >   driver/xf86-video-matrox

This scheme makes sense. However I would have preferred to
turn the order around (like mga-video-xf86). It may look
awkward but in most cases it is easier to get there using 
tab completion.

 > >
 > > Where the third component directly corresponds to the driver name in
 > > xorg.conf.  It's really not worth considering the kdrive drivers yet since
 > > there is no plan to make kdrive a loadable DDX.
 > >
 > > I plan on doing this tonight so I can set up symlink.sh for the video
 > > drivers too.
 > 
 > And done.  I skipped two directories under hw/xfree86/drivers/, v4l and i2c.  
 > I've never actually seen v4l to work so I have no idea what it should be 
 > classed as.  And i2c I don't know if it's worth our time to split out into 40 
 > submodules, but probably not.

v4l is an independent module that works with any driver that 
supports specific Xv features.
It currently behaves like a driver (it calls AddDriver() and uses
the Probe() function to register itself with the XV extension).
That's probably the only reason why it lives among the drivers.

 > 
 > So, what do we think about the following options?
 > 
 >     xf86-v4l versus xf86-video-v4l
 >     xf86-i2c versus xf86-i2c-*
 > 

What do you plan to put in xf86-i2c? The i2c module in xfree86/i2c
is generic and uniq across all drivers. However contrary to the
v4l module it is not a driver. 
It makes only sense in
an XFree86 DDX context. Why don't we keep these kind of modules
together with the core part of the XFree86 DDX? 

Egbert.