FDI Specification Update?

David Zeuthen david at fubar.dk
Tue Jul 27 13:52:32 PDT 2004


Heya Eric,

On Sat, 2004-07-24 at 20:42 -0700, Eric Butler wrote:
> Sorry it took so long for me to reply, been busy with alot of other stuff.
>
> One of the things I've been thinking about is what does the user want to 
> see when a device is connected. So far, I'm basically thinking of three 
> main different notification types:
> 
> - Internal/Ignored devices: This is basically any device that provides 
> no direct functionality to the user, like an IDE controller
> - Hotplugged devices that do not require user intervention to function: 
> This would be something that is plugged in after the computer is booted 
> (like a mouse or keyboard) that does not require any configuration to 
> function, but the user would still like to see that it was detected 
> (http://extremeboredom.net/images/screenshots/hotwire/nonuser.png).
> - Other hotpluged devices: This would be anything else, such as a 
> webcam, where the device serves no purpose until an application is 
> launched. 
> (http://extremeboredom.net/images/screenshots/hotwire/newdevice.png)//
> 
> This does not have to nessisarally be auto-detected, there's no problem 
> if it's specified in the FDI file and then an "unknown" dialog could be 
> displayed for other devices (URL), but I think it might be important 
> enough to include in the spec (perhaps an entry in info.capabilities?).
> 
> There should be a standard way to mark a device as unsupported by the OS 
> (info.capabilities = "linux_unsupported" or something like that).
> 
> Also, I would like to suggest that FDI files include the device name and 
> vendor along with author to make it possible to present a pretty list of 
> "supported" devices to the user.
> 
> Oh, do we have a planned method to store+retrieve icons for specific 
> device types (that perhaps integrates with the nautilus/gnome-vfs work 
> that has been going on)?
> 
> That's all I can think of right now, I look forward to hearing 
> everyone's comments on all this.
> 

Me too :-) - no, seriously I believe that the UI for dealing with
hardware is important, but it's most probably better discussed on
desktop specific lists (utopia-list at gnome.org for GNOME, don't know the
appropriate lists for other desktops).

I given the subject some thought myself, but I've not yet written
anything down; it would certainly be good to discuss, not at least
because it will help determine what we need from HAL and other places.
In particular wrt. to FDI files.

Another thing is that I think it's a difficult task to work out UI for
dealing with hardware is. I would start by working out high level
requirements for the system in a top-down fashion, e.g. something like:

 - The system must support assisting the user in setting up hardware

 - The system must provide a view of the hardware both by connection
   and by category

 - If a device is unsafe to remove, the system must convey this to
   the user

 - The system must conform to existing industry standards or conventions
   (e.g. if the user puts a USB2.0 highspeed device into a USB1.1
   fullspeed port the user should be alerted)

 - If the device is unknown to the system must inform the user and
   it must assist the user in getting the hardware to work

and so forth [1]. Once there's a consensus of the requirements (they
will be refined and more concrete over time) I think the UI will be
pretty easy to work, at least on a conceptual level.

It would also be good to look at what other desktops are doing in this
area and do a writeup, e.g. much like this paper

 http://people.redhat.com/otaylor/fosdem2003/file-selector.html

that discuss file selectors on Mac OS X and Windows. Only for handling
hardware of course :-)

Hope this helps,
David

[1] : in particular this list is far from complete, there should be some
other requirements IMO like how to deal with .fdi files, device manager
functions, configuration etc. etc.

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal



More information about the Hal mailing list