Re: [Utopia] Roadmap to Utopia

On Fri, 2004-04-23 at 12:09 -0400, Bill Nottingham wrote:
> When you get to things like USB multi-format readers, this gets
> tricky. Unless you're keying off the filesystem labels.
> You can also do tricks hoping the LUN is specific for a particular
> format. Erp, going into too many technical details.

I had hoped the LUN was specific, hence this file for the particular
brand of the card-reader I'm using

 <match key="info.bus" string="usb">
  <match key="usb.vendor_id" int="0x0424">
   <match key="usb.product_id" int="0x20fc">
    <merge key="" type="string">compact_flash</merge>
    <merge key="" type="string">memory_stick</merge>
    <merge key="" type="string">smart_media</merge>
    <merge key="" type="string">sd_mmc</merge>

Either way we don't really need this information; it's nice-to-have not
need-to-have. If we don't have it then we just display a dull icon -
much like other OS'es. And if someone find better way to discover stuff
like this we just put it in HAL and then everything just works.

> > What I was thinking was really along this use case: I turn off my PC and
> > plug in a PCI-based TV receiver card and subsequently reboot my
> > computer. This device needs to be configured with user input like tuner
> > model, frequency range etc - stuff the system cannot figure out itself -
> > unfortunately..
> In what way can't it figure it out?

Specifically for tv tuner cards, IIRC, you have to give a lot options
when running modprobe on bttv+friends setting card type, tuner model,
PAL/NTSC etc. Of course if the system can figure this out itself, that's

In general, I guess there are at least a few devices that needs some
user input before they are configured to the satisfaction of the user.

> > Now, when is this done? During the boot process (OS-level e.g. kudzu),
> > when a user logs in (GNOME-level) or when an application needs to use
> > the device (app-level)? The smoothest experience IMO is when the user
> > logs in, e.g. GNOME-level.
> True. Especially because those boot-time displays are so ugly. I mean,
> who writes an interface like that? :)

Ok - I'm rehashing my really simple proposal for this:

 1. user adds new hardware and turns on computer

 2. computer boots; specific the hal daemon is started

 3. new device identified; (vendor specific) callout tries to configure
    hardware - needs info and gives up so it writes the property 
    info.require_user_info=true on the HalDevice

 4. gdm is shown; user logs in

 5. gnome-device-manager sees there is a HalDevice with 
    info.require_user_info set to TRUE; puts up a wizard and flashes
    an icon

 6. When the user clicks the icon, a wizard is launched saying
    "device xyz needs configuration"

 7. When pressing OK a (vendor specific) configuration GUI tool is
    launched. This tool writes some values on the HalDevice. Then
    it invokes a, yet to be implemented, method on the hal daemon
    asking it to call out again.

 8. Device is configured through (vendor specific) callout.
    Flashing icon disappears. Everybody is happy

If the device is removed and subsequently inserted again, the hal daemon
can actually remember the settings as they are just properties on the
HalDevice and such an object can persist[1] after a device is removed.

Of course, this facility is optional, sometimes you want the user input
every single time a the device has been inserted (this is not to confuse
with every time the system is booted though).

So with this proposal the Project Utopia stack can invoke the right
stuff at the right time and still allow vendor specific stuff. Or
something :-) Anyway, it's just a proposal but it could be great fun to
implement this..

(Btw, is just me, or is it becoming quite scary with all these
(proposed) layers and callouts everywhere?)


[1] : By setting the property info.persistent to TRUE - dunno if
      it works right now, but that's the general idea.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]