RFC: Free Software community-wide Hardware Database project

[Zenaan Harkness]

On Mon, 2004-06-21 at 08:23, David Zeuthen wrote:
> However, it sounds like an ambitious project though;

Yes, it will take some time - it'll be a good thing though :)

> Risking a limb here :-), but I can see a few advantages of also
> including listings for closed source operating systems; from the top of
> my head here are some advantages:

This is not something I will personally put time into.

I believe that a comprehensive directory wrt free software will be a
great achievement, of significant utility, and will see widespread
support.

>  1. It gives you more users, thus the hardware database might be
>     populated faster; it's also an incentive for manufactures to 
>     deliver information even though they may not support free software
>     OS'es.

A db with say 90% non-free driver information, although populated, I
would find more disheartening than anything else.

>  2. Developers of Free operating systems can possibly use this
>     information when writing a free software driver

Contact information yes. To know it works on Windows - well, "everything
works on Windows anyway"...

We will gladly accept all submissions for contact information, and the
hardware related to that - that would be most useful. If you have such,
please provide it (we have a first draft schema underway, and contact
info was high on our list).

>  3. A good opportunity for saying this device works better on e.g.
>     Linux or one of the BSD's than on e.g. Windows (you could have
>     quality/performance indicators)

We will gladly accept comparison data, URLs, etc. Anything and
everything that might be useful to free software driver developers, etc,
makes sense to include.

>  4. The neutrality thing, realizing and accepting that there are
>     still closed OS'es around  :-)

And I don't think that will change. Not in the next 15 years anyway...

Neutrality as I find it useful, is that which is in direct relation to
our Free (software) community. If you provide me with data that is
useful to our free software community, I will gladly include it in the
database.

> > 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.

> Btw, someone talked last year about doing this for Fedora, see
> 
>  http://people.ucsc.edu/~maxka/fhp/

Thank you very much for the link!

> but nothing really happened AFAIK.
> 
> 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.

> Files" or .fdi-files. Basically right now this is used to provide
> additional information that cannot be probed from the device, such as
> whether the device is a camera (that is, a real physical camera), a
> music player (and what formats it is able to play, e.g. mp3, wma etc.
> Think of an iPod or a cheapo USB-storage mp3 player) or some card reader
> uses Compact Flash or Smart Media cards. 

This is very useful information.

> Nothing special, but it enables desktops like KDE or GNOME to present a
> better user interface than without it; e.g. suitable icons or ways to
> interact with the device.

The point of HAL, obviously. This is nice.

> It's really simple as well, the .fdi for my camera looks like this
> 
>   <?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
> 
>   <deviceinfo version="0.2">
>     <device>
>       <match key="info.bus" string="usb">
>         <match key="usb.vendor_id" int="0x04a9">
>           <match key="usb.product_id" int="0x3052">
>             <merge key="info.category" type="string">camera</merge>
>             <merge key="info.capabilities" type="string">camera</merge>
>             <merge key="info.persistent" type="bool">true</merge>
>           </match>
>         </match>
>       </match>
>     </device>
>   </deviceinfo>
> 
> So, the database might export a large set of .fdi files and/or provide a
> web service with this information. At some point it would probably be

exactly!

> good to have cryptographic signature on the the .fdi files, your most
> trusted users on the hardware database can then sign and verify that the
> information is correct using some PKI stuff (Indeed, the 'users' may
> also be corporate entities like hw vendors, OS vendors and of course
> individual contributors).

Good idea. This is a very good point. We shall definitely provide signed
data at some point.

> 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 :)

> Some options on how to actually configure the hardware might be missing
> or impossible to figure out, e.g. you'd have to ask the user, or at
> least provide a user interface where he can change it. For example,
> continuing the tv tuner card example, that would be whether the RF
> signal being fed to the card is PAL or NTSC and what MHz range to scan 
> 
> (it wouldn't be enough just checking the timezone and guesstimating,
> since the system used might be in a lab in Europe where a closed NTSC
> broadcast network is being used - I tried that :-).

:)

> I've rambled a bit about that here 
> 
>  http://mail.gnome.org/archives/utopia-list/2004-April/msg00025.html
> 
> where the essence is that the .fdi file can specify what options the
> user interface in e.g. GNOME or KDE need to export. Automated GUI
> dialogs, yeah, uhmm :-)

very nice

> Regarding HAL providing .fdi files my thinking right now is some star
> trek version of hal-device-manager, e.g. 
> 
>  http://freedesktop.org/~david/hal-v4l.png
> 
> will be able to generate a .fdi file given the current configuration of
> the device and how well it works. Then you would simply have a "Submit
> to HW database" button :-)

:)

BTW, all these 1600x1200 screen shots we are getting these days are
making it necessary to move up to 1920, so you don't have to scroll all
the time to see them - of course, getting a 20" (or higher) LCD above
1600 res starts to get just a little pricey :)

> Oh well, hope I didn't ramble too much - the thing is I think this is

Not at all, this is all very interesting stuff (and I see you say the
same in very next line :)

> very interesting; it's much in the line of "Making hardware just work"
> which HAL is trying to solve a tiny bit of (e.g. there's so much work
> left :-). It would be good to see the project you're describing
> happening! It's ambitious, but it can probably be done incrementally, I

Exactly. Incrementally it is happening - we're already underway.

> think providing automated tools for submission of e.g. .fdi files and
> other vital product data may be one of the stepping stones to a
> successful project.

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.

> Thanks,
> David

Thank you very much for your thoughts. Good stuff.

cheers
zen

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal