HAL 0.1 release

[Eric Gillespie]

David Zeuthen <david at fubar.dk> writes:

> I hope the diagram makes sense. In HAL 0.1 only hot-plugging of
> USB devices is supported, but the idea is to probe devices when
> the daemon, hald, is invoked; hence the use of existing (cross
> OS) libraries like libpci, libusb and so on..

Yeah, that looks good.

> The information to merge is expressed in .fdi files. For instance,
> this[1]
> 
>   # -*- Python -*-
>   #
>   #
> 
>   import hal
> 
>   def device_match_keyboard():
>      p["Vendor"] = "IBM Corp."
>      p["Product"] = "Preferred USB Keyboard"
>      p["Category"] = "Input"
>      p["DeviceInfoFileVendor"] = "Free Desktop Project"
>      p["DeviceInfoFileId"] = "org.freedesktop.Hal.IBMPreferredUSBKeyboard.Key
> board"
>      hal.set_properties(p)
>      hal.match()
> 
>   def device_match_hub():
>      p["Vendor"] = "IBM Corp."
>      p["Product"] = "Preferred USB Keyboard"
>      p["Category"] = "Hub"
>      p["DeviceInfoFileVendor"] = "Free Desktop Project"
>      p["DeviceInfoFileId"] = "org.freedesktop.Hal.IBMPreferredUSBKeyboard.Hub
> "
>      hal.set_properties(p)
>      hal.match()
> 
>   p = hal.get_properties()
>   if p["Bus"]=="usb" and p["usb.idVendor"]=="4b3" and \
>                          p["usb.idProduct"]=="3005":
>      device_match_keyboard()
> 
>   if p["Bus"]=="usb" and p["usb.idVendor"]=="4b3" and \
>                          p["usb.idProduct"]=="3006":
>      device_match_hub()
>       
> is a .fdi file (in python, the old format to be replaced by XML) that
> matches my IBM USB Preferred Keyboard. Note that .fdi files must be able
> to set properties dependent on the OS, XFree86 version and so on.
> 
> Note that the prime user of libhaldeviceinfo is hald (for merging when
> discovering a device), but it could also be a desktop environment
> hardware manager (what I call e.g. gnome_hal_watcher) may want to
> traverse the database of available device info files - this is useful
> when having multiple .fdi files to select or when creating new .fdi
> files based on the users input (the "What did you just plug in?" part
> from Havoc's paper). So, that's why it's abstracted into a library.
> 
> In HAL 0.1, libhaldeviceinfo embeds the python interpreter and traverses
> a set of directories containing .fdi files. The information made
> available for determining when a device matches a .fdi file, is embedded
> in the existing bus properties in the device object (e.g. usb.idVendor
> etc).
> 
> Enough about HAL...
> 
> My understanding that the Discover Library basically does two things
> (please correct me if I'm wrong here)
> 
>  o  Probe all busses e.g. usb, pci
>  o  Merge properties from XML files
> 
> On probing devices, i'd like to retain this in HAL for architectural
> reasons; probing busses (or handling hotplug events) and matching device
> info files are separate things..
> 
> I think the Discover XML data format can be made to work with HAL
> without many changes. For instance this Discover file
> 
>   <device busclass="0300" vendor="1002" model="4654"
>           model_name="Mach64 VT [264VT FT]">
>     <data class="xfree86">
>       <data class="server" version="[4, inf)">
>         <data class="name">XFree86</data>
>         <data class="device">
>           <data class="driver">ati</data>
>         </data>
>       </data>
>       <data class="server" version="(0, 4)">
>         <data class="name">XF86_Mach64</data>
>       </data>
>     </data>
>   </device>
> 
> could, in the context of the HAL spec, look like
> (note: the HAL spec doesn't define the pci.* or XFree86.* yet)

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

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

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

>     <data class="XFree86">
>       <data class="server" version="[4, inf)">
>         <data class="name">XFree86</data>
>         <data class="device">
>           <data class="driver">ati</data>
>         </data>
>       </data>
>       <data class="server" version="(0, 4)">
>         <data class="name">XF86_Mach64</data>
>       </data>
>     </data>
>   </device>

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

--  
Eric Gillespie <*> epg at pretzelnet.org