Re: [Utopia] Non-removable device handling

[David Zeuthen <david fubar dk>]

Hi,

Sorry for the lag,

On Tue, 2004-05-11 at 16:06 +0100, Matthew Garrett wrote:
> Stuff like modem-lights currently does things like run wvdial even if
> that's not the distribution's choice of dialers. What's the right layer 
> to let the desktop interact with hardware that's going to be configured 
> in both a distribution and OS specific way? It's been suggested that 
> there should be some sort of dbus listener that can run OS/distro 
> specific code. This seems attractive to me, especially since it helps 
> deal with awkwardnesses like getting people the ability to dial out 
> without having to give them ridiculous levels of permissions.
> 

To configure the device (and the surrounding system) the plan is to rely
on linux-hotplug, udev on Linux and/or a suitable distro/OS-specific
script in the HAL callout directory. For example, for storage devices on
Linux, linux-hotplug loads the driver, udev names the device and gives
permission to the console user and finally a callout script in HAL
updates the fstab [1]. 

It's important to keep in mind that the result we need to arrive at, for
any device on the system, is to have a sufficient amount of information
such that the application doesn't have to guess or provide nasty drop
down menus where the user selects the device file etc. 

Having more information is of course better. If we know a storage device
handles compact flash it's nice to have a property (storage.media) that
tells this - if we don't know this (for some reason) we just resort to a
dull icon instead.

On using devices, this is either real simple; if all the application
programmer needs is the special device file then he simply asks HAL for
the device he's interested in (he's read the HAL spec so he knows what
to search for) and then he retrieves the device file from a property on
the HAL device.

For more complicated devices like cameras, mp3 players etc. the plan is
to reuse existing (like libgphoto for cameras) or build/motivate people
to build new libraries (like one for mp3 players) that can accept the
UDI (universal device identifier) the app programmer get's from HAL and
then the app programmer can use that library in a painless way :-).

Remember, one of the premises of "Making hardware just work" is to make
it as simple as possible for application programmers to use devices.
Otherwise much UI won't happen. That's also why it's of key importance
to have something like a spec where everything is nicely documented.

So, to return to your question on modems. What needs to be done, IMO, is
to teach HAL about modems, just the same way HAL knows about storage
devices, ethernet devices, input devices, and so on. While doing that it
may be good to think about from where we will get the modem init string
and other required information to configure the device; this could be
merged from .fdi files (thus allowing the OEM to distribute it), some
system-wide file (through a callout) or we could request it from the
user cf. [1]. The init string should be stored in a property on the
device in HAL.

When HAL knows about modems it's probably safe to say that the special
device file (say, modem.device) and init string (say, modem.init_string)
is enough for an application programmer to use the device.

>From here, it would be straightforward to halificate any existing dialer
and presto it would "Just Work" without having to guess at /dev/ttyS0 or
ask the user to provide this information etc. etc.

A more ambitious plan than just enhancing a dialer would of course be to
implement this nice proposal from xdg-list

 http://freedesktop.org/pipermail/xdg/2003-September/002533.html

in a halificated way of course :-)

> (Is this sort of stuff really within the realm of Project Utopia? I'd 
> certainly think of it as "Making hardware just work", but most of the 
> use cases so far have focussed on removable media. I'd argue that we 
> haven't really solved some of the more low-hanging fruit yet, despite it 
> having been there for 10 years or so...)
> 

I certainly think more than handling block devices is in the scope of
Project Utopia and it's sort of happening already - Joe already applied
some magic to gnome-cups-manager, and Robert have been looking at using
the net.ethernet.link property (that tracks whether your transceiver is
connected) to setup/teardown network connections as callouts to hald.

IMHO, it would probably be good though to have a Wiki-page or something
we could put all use-cases and for various devices-types to motivate
some discussion :-)

All this is of course just how I see the challenges - discussion is very
welcome :-)

Hope this helps,
David

[1] : For devices that cannot be auto-configured, here's my proposal on
how to handle them in GNOME

http://lists.gnome.org/archives/utopia-list/2004-April/msg00020.html
http://lists.gnome.org/archives/utopia-list/2004-April/msg00025.html