RFC: Free Software community-wide Hardware Database project

David Zeuthen david at fubar.dk
Mon Jun 21 13:41:01 PDT 2004

On Mon, 2004-06-21 at 08:57 +1000, Zenaan Harkness wrote:
> > > We, as a community together, might just have a hope of keeping up to
> > > date as compared with the proprietary os's out there, namely MSW*.
> > 
> > Ah, yeah the community thing. Right. I think it would be good to have
> > some kind of "user privilege" rating on the hardware database, karma or
> > something, much the same way that Advogato (when it's up, that is :-)
> > has a model of trust. Helps distribute work among several individuals.
> We have a very small team of three right now.
> Anyone wishing to contribute is very welcome to join, with interest and
> willingness in any of the following areas:
>  - schema review
>  - data locating - finding useful data relating to free software support
> for hardware
>  - data formatting - SQL entry, format conversion scripts, etc
>  - people skills, to diplomatically field contributions from
> manufacturers, VARs and other commercial suppliers, to probe for further
> information and/ or engage them in any discussion that is useful, to us
> as well as them - for example, we are a great place for manufacturers to
> find out information about supporting, contributing or otherwise
> engaging with our community, wrt devices, drivers, etc.

Sounds cool, do you have a mailing list or something?

> > Now, since this is on the HAL mailing list :-), let's discuss how HAL
> > can fit in - I can see HAL both as a consumer and provider of
> > information from/to your repository.
> > 
> > For consuming information, HAL uses what I call "Free Device Information
> Perhaps the "Free" stands Freedom? If so, it might be worthwhile to use
> that word or some other description to clarify your intention.

Yeah, free as in Libre.

> > Now, HAL proper has nothing to do with system policy such as which
> > driver to load, however through the hooks offered by HAL it may makes
> > sense to use it for this if e.g. the OS supports driver binding (e.g.
> > userspace gets to decide what kernel driver to use for a specific
> > device; AFAIK Linux doesn't support this yet?). So, indeed the .fdi file
> > might export the properties 
> > 
> >  info.kernel_module.name = bttv
> >  info.kernel_module.opts = card=5 pll=2
> > 
> > and when the device is discovered, a HAL callout simply does the
> > modprobe thingie that e.g. linux-hotplug and modprobe.conf does on
> > Linux.
> > 
> > The interesting thing is that these properties might stem from a .fdi
> > file where we have more sophisticaed conditionals than just <match> on
> > USB or PCI vendorId/productId, e.g. we merge bttv if we're on Linux 2.6,
> > bttv_some_future_module if on Linux 2.8 and bktv if on FreeBSD (I'm
> > making this up, it's only an example). 
> That's great! As many heads working together, we really do rock!
> > The hardware database should be able to export such .fdi files, that
> > would make hardware detection "just work" without having the user to go
> > and edit /etc/modprobe.conf or what have you. In some distant future,
> > that is :-)
> It looks pretty trivial to me actually. Make that 'relatively near'
> future :)

It would be great to do this, but it might be difficult to get adopted
by distributions; I'm sure some kernel guys have further insights
whether this is a good idea.

> Longer term we will, I'm sure have various submission mechanisms. At the
> start, to make sure the design is robust, the data is clean, and the
> concepts and terminology we use are all clearly described and
> documented, we shall continue with our plan to manually enter stuff. At
> least the first few hundred devices. Or perhaps - at least the first few
> dozens of a good few categories of devices. My desire is a long term one
> - like matured wine or cheese I guess.

Indeed, it sounds very good. 

I'm quite interested device categories, e.g. what the device is (info.
category) and what it does (info.capabilities), after all this is one of
the things that HAL care about in a way [1]; it's definitely something
that should be in the HAL spec so we should probably work together on

Btw, I just made a proposal about that on rhythmbox-devel regarding
iPod's and other media players here in response to Bastien announcing
support for iPod's using HAL:



[1] : Actually HAL doesn't care what values info.capabilities assume, it
just passes it on to desktop environments.

hal mailing list
hal at freedesktop.org

More information about the Hal mailing list