[Libusb-devel] Re: [gphoto-devel] comments on libusb

[Johannes E. <joh...@er...>]

On Mon, Jan 15, 2001, Greg Troxel <gd...@fn...> wrote:
> Sorry - I didn't see the libusb mailing list note until after I had
> read the mail.  Feel free to forward either of my notes to the libusb
> list if you think it is helpful, and I'll join those two also, and
> direct anything beyond this to the usb list.
> 
>   > In debug mode, it would be nice if all errors are fprintf'd to stderr.
> 
> 	if (usb_debug >= 2)
> 	  fprintf(stderr, "usb_find_devices_on_bus: Couldn't open %s\n",
> 		  filename);
> 
>   Or are you talking about something else?
> 
> I meant that, but freebsd.c didn't do this uniformly; my patches help
> a bit in this direction.

Ahh, I realized afterwards that you may have meant the error macros as
well.

>   Not really, since all transfers write data to the device. Think of
>   control transfers. I'd rather it open every device with read and write
>   perms since that's really the only sane mode for how the API is
>   designed.
> 
>   However, the Linux USB API does differentiate between RDWR opens and
>   RDONLY opens, however it's usually useless to the client.
> 
> From reading the freebsd driver, it seems that when opening an
> endpoint for bulk transfers, it is meaningful to do only reads (ep 3
> vs 4 for the camera), and control transfers seem to happen on a
> different driver.  It may well be that in practice unless one has rw
> access to all endpoints the odds of losing are high.  (FreeBSD has
> separate special files for the various endpoints.)

Technically, when you claim an interface, you get all of the endpoints
for that interface.

There's only one shared endpoint, and that's the default control endpoint.
I find it interesting that FreeBSD lets endpoints within an interface be
claimed seperately.

>   > Why does the usb_bulk_write have return values different from
>   > write(2)?  Why not -1/errno on failure and #bytes on success?
> 
>   Because it can't happen. On error, we'll actually write some data to the
>   device, but we need to return -1 to designate an error occured.
> 
> I was thinking that if one is only able to do a partial write it is
> still useful to inform the caller how many bytes were successfully
> written.  But I have no specific case where all-or-nothing semantics
> are problematic.

I agree. I think we should change the API slightly to allow for
reporting the information back.

>   > Is there any way to clear an alternate interface?
> 
>   Clear? What do you mean by clear?
> 
> If one has 'set' an alternate interface (which I don't understand),
> how does one 'undo' that setting operation, to get back to the state
> before the set call?

You can determine what the alternate setting it before you set it and
then when you're done, set it back to the old value, but in general,
it's not very useful.

The driver knows what the alternate settings mean and what they should
be set to. I'll add a call to get the alternate setting nonetheless.

JE