On Thu, Mar 30, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> Also I'm not sure about expectations for 2.4 usbdevfs, so I'll
> just point out a few things that caused trouble when I started
> to use devfs:
>
> - Needing root access is just the **wrong** answer.
>
> It should be _easy_ to have desktop tools both scan a
> USB and claim access to unclaimed interfaces.
>
> If I can plug and unplug the device, I should be able
> to access it logically too (not just physically), with
> the same permissions (normal user, physical access to
> what passes for the "machine room").
>
> I'm seeing how "mount -o devmode=0666 /proc/bus/usb"
> behaves. Of course it should at last be getting read
> access always (including GET_DESCRIPTOR and GET_STATUS,
> which need write permissions!). I'll see how also
> having "write" permission affects interactions with
> other driver software, in kernel or in other processes.
I'm readying my patch to load and bind USB drivers from userspace and
much of the infrastructure is there to track mode changes on a per device
basis and restore those when the device is plugged in again (no matter
what it's USB bus id is). As well as an option to explicitily set
devices by their idVendor/idProduct should solve this problem.
I plan on working on this after I get the previously mentioned patch
ready and released.
> - Everything in /proc/bus/usb/devices should be visible
> through the .../XXX/YYY files, but I don't know that
> it's all available there yet.
>
> If it is, I'm just not sure how to find it all. For
> example, the interface binding ioctls don't have a
> "say who's bound it" mode, just a "bind it now". I'll
> hope that most of the "T:" line is hub info that I've
> not parsed yet.
Yes, much of the T: line is hub info and probably isn't useful.
I've added an ioctl() to determine the currently bound driver in the
previously mentioned patch.
The only thing I can think off the top of my head which isn't readily
available would be the bandwidth numbers. Is this useful to anyone in
userspace?
Oh, and the speed of the device. I'll add this as well.
> - Hmm, the devfs include file isn't <linux/usbdevfs.h>
> but is "/usr/src/linux/drivers/usb/...h" ... if it's
> going to become very official, that must change. (I
> noticed that the current rio500 tools ship have their
> own copy of this kernel header file ... ugh.)
>
> The last of these should be a simple patch.
I have to agree. libusb and my devfs patch both have their own headers.
It would be convenient to have this in include/linux. We don't need
everything in usbdevice_fs.h IIRC, nor do we need anything in the
existing usb.h. Perhaps we can merge together the parts which userspace
are interested in and move the kernel specific stuff elsewhere?
> In general, I think that devfs hasn't been getting enough
> use for its feature set to be considered mature enough to
> be called complete.
>
> Next on my agenda: look at how interrupt endpoints get
> passed through devfs. There wouldn't be anything written
> on this, would there?
There's a generic URB interface to usbdevfs which would do this. That is
for asynchronous transfers. Or, if you want to do it synchronously, you
can overload the Bulk transfer (since Interrupt and Bulk transfers are
identical on the wire).
I dunno if the usbguide has any info on it.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
