headers
jong jong | 1 Jul 2005 18:48
Picon
Favicon

Compiling problems on libusb-0.1.10a

Hi All,

I try to cross compile libusb-0.1.10a.  I don't have a
cross compiler for c++ code and all I need is C
compiler.
Is there an easy way for me change something in the
configure file to not try to configure for C++
compiling?

Because I don't see an option that I can pass into the
configure to tell it configure only for C compiling.

Thanks

John

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Permalink | Reply | 0 comments |
headers
postmaster | 2 Jul 2005 18:06
Permalink | Reply | 0 comments |
headers
Alain Finckenbein | 6 Jul 2005 16:15
Favicon

interrupt read latency

Hello,

I'm writing you because i have a little problem with the 
usb_interrupt_read function.
I can  read the data from the device, but i have a latency, 
approximately one second between each read.
I read the data 8 octects by 8, and this latency beetween each is 
problematic.
Does someone know the problem?
I send you a sample of my program :

    while (!finish)
          {

            ret = usb_interrupt_read( udev, 0x81, &receive_data[len], 8, 0);

            printf("ret : %d\n", ret);

            if( ret <= 0 || errno != EAGAIN)
              {
            printf("error ret : %d\n", ret);
            printf( "errno = %d\n", errno );
            break;
              }
            else if (ret)
              {
            len += ret;
            printf("ret : %d, len : %d, data : %s\n", ret, len, 
receive_data);
            if (detect_end_cmd(receive_data) == TRUE)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sandro Weiser | 6 Jul 2005 22:38
Picon
Picon

usb_control_msg returns -32

we are developing a driver for shuttle lcd's for lcdproc:
http://www-user.tu-chemnitz.de/~sawei/twiki/bin/view/Projekte/ShuttleLCD

What we do:

usb_init();
  usb_find_busses();
  usb_find_devices();
  busses = usb_get_busses();

  /* on all busses look for Shuttle VFD's */
  p->udh = NULL;
  for (bus = busses; bus != NULL; bus = bus->next) {
    struct usb_device *dev;

    for (dev = bus->devices; dev; dev = dev->next) {
      /* Check if this device is a Shuttle VFD */
      if ( (dev->descriptor.idVendor == shvfdVendor) &&
         (dev->descriptor.idProduct == shvfdProd) ) {

        /* Shuttle VFD found; try to find it's description and serial number 
*/
        p->udh = usb_open(dev);
        if (p->udh == NULL) {
          report(RPT_WARNING, "PT6314: unable to open device");

...

  if (p->udh != NULL) {
    debug(RPT_DEBUG, "PT6314: opening device succeeded\n");
(Continue reading)

Permalink | Reply | 2 comments |
headers
Lonnie Mendez | 7 Jul 2005 13:51
Picon

Re: usb_control_msg returns -32

On Wednesday 06 July 2005 3:38 pm, Sandro Weiser wrote:
> we are developing a driver for shuttle lcd's for lcdproc:
> http://www-user.tu-chemnitz.de/~sawei/twiki/bin/view/Projekte/ShuttleLCD
> 
> What we do:
> 
> usb_init();
>   usb_find_busses();
>   usb_find_devices();
>   busses = usb_get_busses();
> 
>   /* on all busses look for Shuttle VFD's */
>   p->udh = NULL;
>   for (bus = busses; bus != NULL; bus = bus->next) {
>     struct usb_device *dev;
> 
>     for (dev = bus->devices; dev; dev = dev->next) {
>       /* Check if this device is a Shuttle VFD */
>       if ( (dev->descriptor.idVendor == shvfdVendor) &&
>          (dev->descriptor.idProduct == shvfdProd) ) {
> 
>         /* Shuttle VFD found; try to find it's description and serial number 
> */
>         p->udh = usb_open(dev);
>         if (p->udh == NULL) {
>           report(RPT_WARNING, "PT6314: unable to open device");
> 
> ...
> 
>   if (p->udh != NULL) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lonnie Mendez | 7 Jul 2005 14:21
Picon

Re: usb_control_msg returns -32


   Actually, a more useful resource for your device as to the meanings of the get_report/set_report
(since the device is hid based) would be the hid specification.  Specifically, chapter 7 - section 2:

http://www.usb.org/developers/hidpage/  (device class definition)

 -Lonnie

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Permalink | Reply | 0 comments |
headers
Philip Nye | 8 Jul 2005 20:31

libusb on linux

I am struggling with libusb on Linux. The Linux parts of the library 
(usb_os_find_busses, usb_os_find_devices etc.)
obviously rely on a /proc or /sys directory structure to provide much of
the information on USB topology and devices, but the structure these
routines expect does not correspond to the one my Linux box provides.

The routines are very simplistic (and fragile) about the way they
examine those directories and either find nothing or get the answers wrong.

I am running kernel 2.6.11.12 on a fairly standard Pentium 4 box.

My /proc directory doesn't have any sensible USB information. 
/sys/bus/usb just contains two directories "drivers" and "devices", but 
no bus directories - there are individual bus directories in 
/sys/bus/usb/devices but they are mixed up with the devices and their 
content does not correspond to what libusb expects either. All the bus 
and device entries are simply symlinks into /sys/devices/pciXXX anyway.

Any suggestions?

Philip

-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
Permalink | Reply | 1 comment |
headers
Peter Stuge | 8 Jul 2005 21:28

Re: libusb on linux

On Fri, Jul 08, 2005 at 07:31:03PM +0100, Philip Nye wrote:
> My /proc directory doesn't have any sensible USB information. 

This is your problem.

[..]
> Any suggestions?

mount -t usbfs none /proc/bus/usb

//Peter

-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
Permalink | Reply | 0 comments |
headers
Sandro Weiser | 12 Jul 2005 17:00
Picon
Picon

ETIMEDOUT, but command seems to succeed

When writing with libusb and:

int ret = usb_control_msg(udh, USB_DT_HID, USB_REQ_SET_REPORT, 0x0200, 0x01, 
data, 8, shvfdTimeout);

to IF#1, EP#0:
S:  Manufacturer=Shuttle Inc
S:  Product=VFD Module
S:  SerialNumber=V003
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbkbd
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=03(HID  ) Sub=00 Prot=00 Driver=(none)
I:  If#= 2 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=82(I) Atr=03(Int.) MxPS=   1 Ivl=10ms

ret == -110

and syslog says:
Jul 12 16:45:36 vdr4 LCDd: PT6314: writing string "VFD Module" at (0,0)
Jul 12 16:45:36 vdr4 LCDd: PT6314: setting text
Jul 12 16:45:36 vdr4 LCDd: trying to write byte report len=20
Jul 12 16:45:36 vdr4 LCDd: PT6314: Error ETIMEDOUT: Connection timed out
Jul 12 16:45:36 vdr4 LCDd: PT6314: flushed 20 chars at (0,0)
Jul 12 16:45:36 vdr4 kernel: usb 3-1: LCDd timed out on ep0out len=0/8
Jul 12 16:45:36 vdr4 kernel: usb 3-1: usbfs: USBDEVFS_CONTROL failed cmd LCDd 
rq
t 33 rq 9 len 8 ret -110

but the text is displayed, so the command seems to succeed.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Lepple | 12 Jul 2005 17:59
Picon

Re: ETIMEDOUT, but command seems to succeed

On 7/12/05, Sandro Weiser <sandro.weiser <at> gmx.de> wrote:
> When writing with libusb and:
> 
> int ret = usb_control_msg(udh, USB_DT_HID, USB_REQ_SET_REPORT, 0x0200, 0x01,
> data, 8, shvfdTimeout);

Are you sure that these are the exact values the display is expecting?
It almost sounds like the LCD's firmware has a bug. (Bear in mind that
some USB device-side chips expect the firmware to tell them if they
should ACK or NAK a packet.)

What happens if you send two control messages back-to-back? Does the
second message affect the display?

--

-- 
- Charles Lepple

-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
Permalink | Reply | 0 comments |

Gmane