HAL 0.1 release

David Zeuthen david at fubar.dk
Fri Oct 10 02:06:02 EEST 2003

On Fri, 2003-10-10 at 00:22, Joe Shaw wrote:
> I'm still not sure whether you need "Category".  From 10,000 feet, a
> camera is a camera is a camera, and a lot of the things you do to a
> camera ("import photos") are the same regardless of bustype, etc.

Agree, application programmers should not be bothered with any bus

> But at some point you get down to a level (hopefully a specific library,
> like libgphoto or whatever) that needs to know about hardware details
> anyway.  At that point, the library can get the necessary properties,
> like busclass, /dev location, call other libs like libusb, etc. and do
> the heavy lifting.  

Exactly - I'm pretending that all the bus-specific properties provided 
will make this easy for such libraries. Though, it will be a real
challenge to get buy-in from these libraries to link with libhal so
applications can just pass a HalDevice* object. 
As Havoc points out in his paper, we might initially have to 'break the
abstraction' and pass kernel devices / bus specific properties around to

Note that there aren't libraries for all classes of devices; HID,
Storage specifically is handled by either the base OS through kernel
level drivers or OS / distro specific ways. 

Specifically for storage, this is rather controversial as I in hal 0.1
actually shipped scripts to mount and unmount the storage devices,
completely ignoring /etc/fstab. We might expect distro integration
issues on this one.

> But to the app itself, all it cares about are capabilities.

Agree. Libraries could advertise "can handle devices with these
capabilities". At some point ;-)

> The bottom line is, I don't think we can make "Category" be both general
> enough to be useful on its own (that is, not just another capability),
> but specific enough to contain enough information for low level
> implementation.

Remember (category, subcategory) or bus-class are always derived from
bus-specific properties so low-level implementations does not need this
to work.

There is one special case where the UI will need to know about category,
namely when you draw the device tree. 

I'm assuming that one or more desktop environments would like to draw
the device tree like in windows as seen in e.g. [1], but I don't really
know if this is good UI. 

Nonetheless, we should be able to provide this degree of information,
and my thinking is that desktop environments would choose the icons
based on category and subcategory.

(Oh, and since we also now support the Parent property we can also show
"device by connection" complete with USB hub topology)

> (Maybe we should set up a HAL mailing list?  I think we might be
> flooding xdg-list at this point)

This would actually be a smart move; I guess I'm one of the guilty ones.


[1] :

More information about the xdg mailing list