HAL 0.1 release

[David Zeuthen]

On Wed, 2003-10-08 at 21:07, Eric Gillespie wrote:
> >   <device Bus="pci" pci.vendorId="1002" pci.deviceId="4654">
> 
> I don't think having the DTD include attributes here for every
> bus is a good idea.  Simply calling them vendor and model makes
> more sense, i think.
> 

If we are going for the goal of being backwards compatible with the
existing data (which is a nice goal if there are many existing files), I
agree. We could also break compatibility and add some more features,
like the XML schema support suggested by Robert.

I think both options are possible. In the following I refer to
'backwards compaitibility' as A and 'new format' as B.

A: We can make this work. First off all, I'd still like to have
different namespaces for different busses.

The reason is 1) it's more structured; and 2) it will be useful to
separate this so we can support bindings to libhal for OO languages /
libraries, e.g. the Java bindings might give a HalDevice object that
implements the interfaces BusUSB, BusStorage. Same could go for glib.

But since it's only bus-specific information we will match on, we can
agree that

 <device bus="pci" vendor="1002" model="4654">

means that the XML parsing code looks for "pci.vendor" and "pci.model"
because it prefixes the bus variable initially given. I'm happy to
change e.g. pci.deviceId to pci.model to accommodate this.

B: We could do as in A, but it's more visible for the creator of the
file that he is dealing with a PCI device, so I'd rather user
pci:deviceId.

(and I'm happy to rename most of the usb.* and pci.* properties to their
real name).

> >     <data class="Category">Video</data>
> 
> Currently we handle this using the same bus classes used in the
> PCI IDs (and USB, etc.) files.  I think sticking with that is a
> good idea.
> 

Yeah, 'bus class' is much akin to Category. I found it's been useful to
think in terms of three different classifications

 Category    = Storage, Network, Video, Camera etc.

 SubCategory = Magnetic, Optical, Flash, Zip,  # For 'Storage'
               Ethernet, Modem, ATM, ADSL      # For 'Network'
               ,                     # For 'Video' (can't think of any)
               ,                     # For 'Camera' (can't think of any)

 UserCategory = <same as category>

So only Category is mandatory. SubCategory, UserCategory is optional.
The interesting is UserCategory as this is what the UI parts will use. 

One example of where UserCategory is of benefit is to consider digital
camera support on Linux today. So, some cameras appear as usb-storage
and we want to distinguish them on the UI level with an icon.

I think it's useful this way, and it can (almost) be done with both
options A and B. Note that the category / subcategories are not yet
defined and we could do this together.

A: We simply map busclass to the appropriate category / subcategory set

B: Introduce Category, SubCategory, UserCategory through the <data> tags


> >     <data class="Vendor">ATI</data>
> >     <data class="Product">Mach64 VT [264VT FT]</data>
> >     <data class="DeviceInfoFileVendor">SomeVendor</data>
> >     <data class="DeviceInfoFileId">SomeUniqueId</data>
> >     <data class="pci">
> >       <data class="vendorName">ATI</data>
> >       <data class="deviceName">Mach64 VT [264VT FT]</data>
> >     </data>
> 
> All this is redundant; it is already listed in the attributes of
> the <device> element.
> 

Oh yes, this is normally extracted from pci.ids or usb.ids but these
files might not be up to date and more importantly, they are not from
the authoritative source, e.g. the OEM. Also, pci.ids and friends are
not complete.

Specifying this explicitly, is optional, and it overrides the values
that are read from the *.ids files. 

Also note that I explicitly specify Vendor and Product; we might also
make this optional and just take the information from the corresponding
pci and usb vendor, product naming fields. 
Worst case is that the Vendor is "1002" and the Product is "4654", which
is bad enough to get fixed since this will appear in the UI.

In general most of fields that is specified with the data tag should
follow the HAL / Discover specs.
(HAL specifies something for Storage, while Discover specify the XFree86
parts)

Even if not provided, required properties may be auto-guessed (example
with Vendor/Product above).

So, these are just optional parts to, for example, make it easier for
the OEM's to specify the correct name for their device shipped with a
device info file. 

Extending on this, we might, when doing UI parts using HAL, specify a
property where to read a logo from that is displayed in a "Device
Manager". 

I think it's important for free desktops to be friendly to OEM's and
give them one more reason to supply these files we are discussing. I
know there is a Dell logo on the My Computer->Properties page on
Windows.

Okay with you?

> > I'm not pretending this is the only or best solution in using
> > discover, so I'm very happy to continue discussing this.
> 
> No, i also figured that discover's bus scanning code would be of
> no use to HAL.  It sounds like we are very close in agreement on
> how to do this.

Yeah, it seems like it's nitty gritty details we are discussing. This is
a good sign!

On maintaining backwards compatibility (A) or introduce minor changes
(B), I'm cheering for the latter but I can certainly live with the
former. I'm interested in what you and others think about this.

Oh, btw, device properties in HAL are now typed! The types 'string',
'int', 'bool' and 'version' are available. This should make the matching
code somewhat simpler.

Many thanks,
David