HAL 0.1 release

[Joe Shaw]

On Thu, 2003-10-09 at 17:14, David Zeuthen wrote:
> It just doesn't seem practical to me to merge this stuff into a single
> namespace even though there is a significant overlap. I'm mean there are
> things in USB that is not in PCI, and vice versa.

I tend to agree that there doesn't seem much reason to do this at the
device info file level.  Having coherent vendor and device names make
sense (when you can get them) at the application and user level (thus
doing it in libhal/hald makes sense to me), but you probably want
maximum flexibility at the lowest level.

> My point is really that if you introduce a new bus, and that doesn't
> really that often, you're bound to introduce new attributes.
> 
> Assuming you want give all these attributes to match on and/or give all
> these attributes to applications/libraries using libhal. I think we
> should indeed give all this information. vendor/class isn't sufficient. 
> 
> I'm specifically thinking that e.g. Dell might want to match on
> subsystemVendorid to provide their own drivers as an OEM.

Agree.

> It's really about giving hints to the desktop environment on how to
> treat the device. This is obviously something we cannot infer from the
> hardware bits, so we might require such data to be merged.

Yes, this is definitely a case where the device info files would be
providing some metadata outside of what's just available from the
hardware.

> I don't know about that - I use libpci for doing it but my understanding
> is that libpci actually uses pci.ids internally. But it's a moot point
> since we agree this comes from the XML files by matching on vendor,
> model.
> 
> So currently in discover the vendor has to provide two XML files, the
> *-device.xml and *-vendor.xml. 
> 
> I think it might be more practical that the vendor ships only one file
> even at the cost of having to merge the property names for each device.

I agree.  If the vendor isn't in the built-in, canonical vendor list,
they'd have to ship that vendor file with all of their device files
anyway, and in that case they might as well include those properties in
the device file itself.

Joe