headers
Andreas Jellinghaus | 4 Jan 2005 10:13

device <-> name

Hi,

sometimes it is useful to have two processes:
one scanning for new usb devices, and one handling
one of those devices. to do that the first process
needs to pass a string to the second process
with information which device to open.

so what about some usb_device_to_name and
usb_name_to_device functions in libusb?

also some systems already have a notification
mechanism for new devices. it would nice to support
that syntax (on linux the /proc/bus/usb/xxxx/yyyy
pathname provided by hotplug).

what about other operating systems? are there facilities
that can notify you about new devices? freebsd has a usbd,
but I have no idea how it works. what about mac os x?

Regards, Andreas

--

-- 
---------------------[ Ciphire Signature ]----------------------
From: aj <at> ciphirelabs.com signed email body (571 characters)
Date: on 04 January 2005 at 09:14:11 GMT
To:   libusb-devel <at> lists.sourceforge.net
----------------------------------------------------------------
: The message above has been secured using Ciphire Mail.
: Verify this signature and download your free encryption
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arnau Sánchez | 4 Jan 2005 11:34

Troubles with kernel 2.6

Hello,

    I have been using libusb for a while and it has worked perfectly to access a USB device 
with a Debian/kernel 2.4.22/libusb-dev0.1.8-17. 

    Now I have installed a new kernel (2.6.8) and I have a lot of problems: the first access to 
the device works ok but at the next one I get a read error (usb_interrupt_read returns -110). 
Then I completely lose access to the device and have to reset it. 

Perhaps someone know which is the problem... thanks very much

arnau

------------------

That's an example code:

#include <stdio.h>
#include <string.h>
#include <usb.h>
#define BOARD_VENDOR   0x461
#define PRODUCT_VENDOR 0x20

int main()
{
 struct usb_bus *bus;
 struct usb_device *dev;
 usb_dev_handle *udev;
 int n, claim = 0, i;
 char buffer[256];
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brandon Philips | 4 Jan 2005 17:27

Re: Troubles with kernel 2.6

Arnau,

The 2.6.8 was well known to have USB problems.  I would recommend
installing the lastest kernel from kernel.org (2.6.10)

-Brandon

On 11:34 Tue 04 Jan     , Arnau S?nchez wrote:
> Hello,
> 
>     I have been using libusb for a while and it has worked perfectly to access a USB device 
> with a Debian/kernel 2.4.22/libusb-dev0.1.8-17. 
> 
>     Now I have installed a new kernel (2.6.8) and I have a lot of problems: the first access to 
> the device works ok but at the next one I get a read error (usb_interrupt_read returns -110). 
> Then I completely lose access to the device and have to reset it. 
> 
> Perhaps someone know which is the problem... thanks very much
> 
> arnau
> 
> ------------------
> 
> That's an example code:
> 
> #include <stdio.h>
> #include <string.h>
> #include <usb.h>
> #define BOARD_VENDOR   0x461
> #define PRODUCT_VENDOR 0x20
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arnau Sánchez | 5 Jan 2005 18:00

Re: Troubles with kernel 2.6

From: "Brandon Philips" <brandon <at> clevercoder.com>

> The 2.6.8 was well known to have USB problems.  I would recommend
> installing the lastest kernel from kernel.org (2.6.10)

Thanks for replying, Brandon... I am using ubuntu, that's why I had a 2.6.8 kernel...
now I have tested 2.6.9 (from debian) and 2.6.10 from www.kernel.org, but the error 
still persists. 

By the way, I have been hacking the code until I got to a solution (really ugly):

(I am using 8 byte-length packets)

- Length parameter of "usb_interrupt_write" must be at least 16 bytes long. This seems 
a bug. 

- First use of "usb_interrupt_write" is annonying, apparently the second half of the 16-bytes
packet is discarded. Then, I have to make a special init to avoid loss of packets.

I think all the problem comes from the fact that the "usb_interrupt_write" needs 16 bytes
while a low-speed USB device use (at maximum) 8 bytes for packet (that is my case).

any ideas? thanks,

arnau

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Erdfelt | 5 Jan 2005 21:00

Re: Perhaps 'myopic' is a better word...

On Sun, Dec 19, 2004, Paul Klissner <Paul.Klissner <at> Sun.COM> wrote:
> I sent email out early this morning claiming libusb 0.8 is fundamentally
> broken. I should scale back that assertion in retrospect, as I think I
> now more fully understand the assumptions under which the 0.8 prototype
> was created.
> 
> Perhaps it is not fair to call libusb 0.8 "broken" for not abstracting
> internal library data away from the client view.  But libusb 0.8 
> significatnly
> constrains it's adaptation to diverse environments by failing to do so.
> Portability is ultimately libusb's biggest appeal to a significant
> percentage of USB application developers with the goal to have our code
> run unchanged on the largest possible number of platforms.
> 
> In libusb 0.8, the assumption seems to be that the library's internal
> view of bus topology (ie. data structures) can only be updated
> synchronously, that is, when the client calls usb_find_busses() and
> usb_find_devices().  With that model locking semantics around
> shared state isn't critical, as all database updates are client driven.
> 
> Such a scheme may be well suited to Linux, but for other platforms,
> the restriction that libusb's database changes are initiated by
> the libusb's client is far from ideal if libusb itself is a client that
> receives hotplug events from its the backend provider, or if the
> client is a multithreaded application wherein multiple threads are
> calling usb_find_*().
> 
> If we provide more abstraction in the API, these issues become moot,
> and can be dealt with by the library through locking. That really
> seems to be the way to go if libusb is to become the Open Source
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Erdfelt | 5 Jan 2005 20:53

Re: device <-> name

On Tue, Jan 04, 2005, Andreas Jellinghaus <aj <at> ciphirelabs.com> wrote:
> sometimes it is useful to have two processes:
> one scanning for new usb devices, and one handling
> one of those devices. to do that the first process
> needs to pass a string to the second process
> with information which device to open.
> 
> so what about some usb_device_to_name and
> usb_name_to_device functions in libusb?
> 
> also some systems already have a notification
> mechanism for new devices. it would nice to support
> that syntax (on linux the /proc/bus/usb/xxxx/yyyy
> pathname provided by hotplug).

There has been some discussions about this in the past, but no real
consensus.

I really want to discourage using path names for devices in libusb, but
I understand that it's useful in cases like Linux hotplug where it's the
only piece of information that can uniquely identify the device.

I'm thinking that adding a new function to find a device by a OS defined
name would provide the functionality you're looking for. It would be
marked as nonportable and have lots of warnings in the documentation
that you probably don't want to use this function.

Does that sound reasonable?

> what about other operating systems? are there facilities
(Continue reading)

Permalink | Reply | 0 comments |
headers
Woody | 8 Jan 2005 02:08
Favicon

-32 on bulk write with new hub?

 The platform is redhat 9 (2.4 kernel).
I have an app that's been running great using libusb 0.1.8, but ran short of
usb ports...

So, I picked up a $20 self powered usb hub.  If I plug the device (x10
Cm15a) into the hub, I get a return of -32 on the call to usb_bulk_write.
If I don't use the hub, the return is OK (#of bytes written).

I have a second device (dallas 1-wire adapter) which also uses the same
libusb and it works fine thru the hub..

Anybody got any idea what what be happening?

The hub is iogear 4 port model guh274.

Thanks in advance

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 1 comment |
headers
Johannes Erdfelt | 8 Jan 2005 02:20

Re: -32 on bulk write with new hub?

On Fri, Jan 07, 2005, Woody <woody <at> usandthem.com> wrote:
>  The platform is redhat 9 (2.4 kernel).
> I have an app that's been running great using libusb 0.1.8, but ran short of
> usb ports...
> 
> So, I picked up a $20 self powered usb hub.  If I plug the device (x10
> Cm15a) into the hub, I get a return of -32 on the call to usb_bulk_write.
> If I don't use the hub, the return is OK (#of bytes written).
> 
> I have a second device (dallas 1-wire adapter) which also uses the same
> libusb and it works fine thru the hub..
> 
> Anybody got any idea what what be happening?
> 
> The hub is iogear 4 port model guh274.

What host controller are you using? Is the device self powered or bus
powered? Is the hub self powered or bus powered?

-32 is EPIPE which is usually returned when the pipe is halted after
the device sent a STALL.

JE

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 0 comments |
headers
Paul Fox | 8 Jan 2005 21:17
Picon
Favicon

remote usb access?


perhaps someone here has an idea.

i have a need for remote access to a usb bus.  the specific
application is using gphoto on a (linux) server to access a
digital camera attached to a (linux) thin-client machine.

the thin client machine has very little in the way of libraries
loaded -- it's based on busybox/uclibc, and while i _could_ build
a copies of gphoto, libgphoto, and libusb to run there, and
operate the remote gphoto from the server, i'd still have issues
of where gphoto is to put the pictures it retrieves from the
camera -- there's no mass storage on the thin-client.

so, i started looking at how to implement some sort of remote
protocol at the bottom end of gphoto.  (this isn't hard -- gphoto
is well-architected, and already supports both usb (via libusb)
and serial camera connections.  adding a connection via tcp
socket is pretty easy.

what's tricky is what to put at the other end of that socket --
i.e., the end at the thin-client.  i had sort of thought that
once i knew which usb device node represented the camera, that i
could just read/write from it.  my first attempt at this gave me
an EINVAL, so i investigated further:  i see that libusb does a
lot more than i thought it did, what with "claiming", and
configuring, and determining interfaces -- none of which i know
anything about.  :-)

what i began to realize is that what i really want is a remote
(Continue reading)

Permalink | Reply | 8 comments |
headers
Brandon Philips | 8 Jan 2005 23:29

Re: remote usb access?

Paul,

How about having the thin client save the files to some type of
networked file system?  Like NFS or SHFS?

http://shfs.sourceforge.net/

-Brandon

On 15:17 Sat 08 Jan     , Paul Fox wrote:
>  
> perhaps someone here has an idea.
> 
> i have a need for remote access to a usb bus.  the specific
> application is using gphoto on a (linux) server to access a
> digital camera attached to a (linux) thin-client machine.
> 
> the thin client machine has very little in the way of libraries
> loaded -- it's based on busybox/uclibc, and while i _could_ build
> a copies of gphoto, libgphoto, and libusb to run there, and
> operate the remote gphoto from the server, i'd still have issues
> of where gphoto is to put the pictures it retrieves from the
> camera -- there's no mass storage on the thin-client.
> 
> so, i started looking at how to implement some sort of remote
> protocol at the bottom end of gphoto.  (this isn't hard -- gphoto
> is well-architected, and already supports both usb (via libusb)
> and serial camera connections.  adding a connection via tcp
> socket is pretty easy.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane