pyusb-users — PyUSB users mailing list discussion

Re: [pyusb-users] "large" writes fail?

[Jeffrey N. <jsn...@su...>]

Hi Karl,

Is it possible you're exceeding the default timeout for write() with 
your large data set? I just checked pyusb's source, and it looks like if 
you don't pass a timeout it uses 1000. That would explain why you're 
sending some data, but not all of it.

Try changing self.ep_out.write(data) to self.ep_out.write(data, 
timeout=0) or self.ep_out.write(data, timeout=10000) and see if that helps.

Best Regards,
Jeff

Jeffrey Nichols
Suprock Technologies, LLC
Phone: (603) 479-3408
Fax: (888) 629-4158
www.suprocktech.com

On 8/29/2015 10:17 PM, Karl Palsson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> It's quite possible I'm doing something wrong in my device firmware, but
> I'm not sure how my device side can care, so...
>
> My device firmware is meant to be compatible with the linux gadget zero
> source/sink function, so I should be able to write as much as I like to
> it.  And, mostly, this seems to be true.  I can write 64, 640, 1000,
> 5000, bigger and bigger, but around 400k, it starts to fail the
> assertions.  The exact number of bytes written out is not consistent
> every time, but is around 450000.    What causes this, and is it
> something I'm doing?
>
>      def test_write_perf2(self):
>          ts = datetime.datetime.now()
>          txc = 0
>          data = [x & 0xff for x in range(500 * 1024)]
>          w = self.ep_out.write(data)
>          self.assertEqual(w, len(data), "Should have written all bytes plz")
>          txc += w
>          te = datetime.datetime.now() - ts
>          print("wrote %s bytes in %s for %s kps" % (txc, te, self.tput(txc, te)))
>
>
> Failure
> Traceback (most recent call last):
>    File "/home/karlp/src/libopencm3-examples/tests/gadget-zero/test_gadget0.py", line 172, in test_write_perf2
>      self.assertEqual(w, len(data), "Should have written all bytes plz")
> AssertionError: 455680 != 512000 : Should have written all bytes plz
>
> Failure
> Traceback (most recent call last):
>    File "/home/karlp/src/libopencm3-examples/tests/gadget-zero/test_gadget0.py", line 172, in test_write_perf2
>      self.assertEqual(w, len(data), "Should have written all bytes plz")
> AssertionError: 456896 != 512000 : Should have written all bytes plz
>
>
> Cheers,
> Karl P
>
> - -- 
> Sent using Mailpile, Free Software from www.mailpile.is
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJV4mfFAAoJEBmotQ/U1cr2HZgP/3gGUg4LzudZInQuK/iD+7hi
> YHTlj8f9lT9pi/t26gnZ+wyARI4x5FB6RX3fzxsSYFPsuNMuMAHcixJ4i0cVS5vg
> I+Ys1ztJh8tsdfmeRSLVJIlHvt3h+qWifNHJLJ70T/W739a+3oaw0E0qZ92hqFG+
> vBet5Qf9G0ROhHmdoSKvl506Hsg5gak4oReWflLkS1ebtQD4nT1rTVCD3neGdPeB
> QbCQEeAYfxJ4/tiUrQZ4CciNnqlIQqYV/osbefsFCrBAkxXD61q9GZjWOhP9gJeT
> yzwzarICFihaFuz2gWmTW3wIU3PWi6653Dil/C30bjL59nuIS1X5+tNNxoVyqyUo
> /k2s8LvEkKAls4rW0gptK4RQ3kas0XwKzgCtLWv/9zbd6tVzVtwovvwjFY0GW9yd
> FlotAmK6lyBqa9Am4wTAhnwqdmDRLWpfeBxqUnN1b+Twq/3KCtakV9S/yqhcVTXv
> /tCG68uQcL0+ZsYS0Y6bfrXQu9i3S4ARGgkmZBkAUc08tDMdnNZIvhhE1q5XY8Os
> BI5Xr3AFmRPjxL9w99ILvYoEBBH0mOqc5Kkmg55qkdfCwkUdy07rlYH97tFpL/tE
> J0Ty4t7jcmDrUgPzIECxEyKsfKEEw7cDsxF2uZK1B/cImQwV23ZZUIVfkGY/NtG9
> lfB4Mpkp0sZn+WkVz8d3
> =tLE0
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users

[pyusb-users] "large" writes fail?

[Karl P. <ka...@tw...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It's quite possible I'm doing something wrong in my device firmware, but
I'm not sure how my device side can care, so...

My device firmware is meant to be compatible with the linux gadget zero
source/sink function, so I should be able to write as much as I like to
it.  And, mostly, this seems to be true.  I can write 64, 640, 1000,
5000, bigger and bigger, but around 400k, it starts to fail the
assertions.  The exact number of bytes written out is not consistent
every time, but is around 450000.    What causes this, and is it
something I'm doing? 

    def test_write_perf2(self):
        ts = datetime.datetime.now()
        txc = 0
        data = [x & 0xff for x in range(500 * 1024)]
        w = self.ep_out.write(data)
        self.assertEqual(w, len(data), "Should have written all bytes plz")
        txc += w
        te = datetime.datetime.now() - ts
        print("wrote %s bytes in %s for %s kps" % (txc, te, self.tput(txc, te)))


Failure
Traceback (most recent call last):
  File "/home/karlp/src/libopencm3-examples/tests/gadget-zero/test_gadget0.py", line 172, in test_write_perf2
    self.assertEqual(w, len(data), "Should have written all bytes plz")
AssertionError: 455680 != 512000 : Should have written all bytes plz

Failure
Traceback (most recent call last):
  File "/home/karlp/src/libopencm3-examples/tests/gadget-zero/test_gadget0.py", line 172, in test_write_perf2
    self.assertEqual(w, len(data), "Should have written all bytes plz")
AssertionError: 456896 != 512000 : Should have written all bytes plz


Cheers,
Karl P

- -- 
Sent using Mailpile, Free Software from www.mailpile.is

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJV4mfFAAoJEBmotQ/U1cr2HZgP/3gGUg4LzudZInQuK/iD+7hi
YHTlj8f9lT9pi/t26gnZ+wyARI4x5FB6RX3fzxsSYFPsuNMuMAHcixJ4i0cVS5vg
I+Ys1ztJh8tsdfmeRSLVJIlHvt3h+qWifNHJLJ70T/W739a+3oaw0E0qZ92hqFG+
vBet5Qf9G0ROhHmdoSKvl506Hsg5gak4oReWflLkS1ebtQD4nT1rTVCD3neGdPeB
QbCQEeAYfxJ4/tiUrQZ4CciNnqlIQqYV/osbefsFCrBAkxXD61q9GZjWOhP9gJeT
yzwzarICFihaFuz2gWmTW3wIU3PWi6653Dil/C30bjL59nuIS1X5+tNNxoVyqyUo
/k2s8LvEkKAls4rW0gptK4RQ3kas0XwKzgCtLWv/9zbd6tVzVtwovvwjFY0GW9yd
FlotAmK6lyBqa9Am4wTAhnwqdmDRLWpfeBxqUnN1b+Twq/3KCtakV9S/yqhcVTXv
/tCG68uQcL0+ZsYS0Y6bfrXQu9i3S4ARGgkmZBkAUc08tDMdnNZIvhhE1q5XY8Os
BI5Xr3AFmRPjxL9w99ILvYoEBBH0mOqc5Kkmg55qkdfCwkUdy07rlYH97tFpL/tE
J0Ty4t7jcmDrUgPzIECxEyKsfKEEw7cDsxF2uZK1B/cImQwV23ZZUIVfkGY/NtG9
lfB4Mpkp0sZn+WkVz8d3
=tLE0
-----END PGP SIGNATURE-----

Re: [pyusb-users] Beginner's question

[Tormod V. <lis...@gm...>]

On Tue, Aug 11, 2015 at 10:52 AM, Bomin Nie wrote:
> Sorry, ignore my first question about "import usb.core" does not work.  I
> named my py file as usb.py, and after I renamed it, it's working now.
>
> 2015-08-11 16:46 GMT+08:00 Bomin Nie:
>> Since I got the "import usb.core" working, I then try to find devices.
>> And, I got "NoBackendError".  I then
>>  - downloaded the windows binary from "http://libusb.info/"
>>  - copy "MS64\dll\libusb-1.0.dll" to my
>> "c:\Windows\SysWOW64\libusb-1.0.dll".  My win7 is 64 bit.

This can seem confusing, however when you are on 64-bit Windows,
MS64\dll\libusb-1.0.dll must be copied into C:\Windows\System32 and
(for running 32-bit applications that use libusb)
MS32\dll\libusb-1.0.dll must be copied into C:\Windows\SysWOW64

Which one will be used depends on whether the python that runs is 32
or 64 bit. If you just run python in a command window it will list on
the first line if it is 32 bit, example:
C:\>python
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit
(Intel)] on win32

Note that the above example was run on 64-bit Windows 7, it is just
that the 32-bit python sees a 32-bit emulator environment and
therefore reports "on win32".

>>
>> It still gives me the same error...  What am I supposed to do more?
>>

If the above is not enough, you might find some useful information here:
https://github.com/libusb/libusb/wiki/Windows#How_to_use_libusb_on_Windows

Regards,
Tormod

Re: [pyusb-users] detach kernel driver

[Wander L. C. <wan...@gm...>]

2015-08-09 22:07 GMT-03:00 UNIVERSAL PHONE <uni...@gm...>:
> Hi!!
>
>
> after: "dev.detach_kernel_driver(interface)"
>
>
> i have this error:
>
> usb.core.USBError: could not detach kernel driver from interface 0: No data
> available.....
>

What Operating System and libusb version are you using?



-- 
Best Regards,
Wander Lairson Costa

Re: [pyusb-users] Connection Timed Out

[Wander L. C. <wan...@gm...>]

2015-08-11 11:35 GMT-03:00 Johannes Roth <rot...@gm...>:
> Hello,
>
> As a pyusb beginner I'm making my first steps while trying to talk to a
> CY7C68013A USB controller, which in turn should talk to my AD9959.
>
> After some work and usb-sniffing the windows drivers, I'm stuck now, as
> I'm getting time outs. The problem seems to be with with either reading
> or writing (the error is the same). I can read the config, interfaces
> and endpoints from the controller and when trying to read/write from the
> wrong endpoint, it comes up with sensible errors, but not when I'm
> trying to read/write to a proper endpoint. Here's a simple example:
>
> import usb.core
> dev = usb.core.find(idVendor = 0x0456, idProduct = 0xee24)
> cfg = dev[0]
> intf = cfg[(0,1)]
> dev.set_configuration(cfg)
> dev.set_interface_altsetting(interface = 0, alternate_setting = 1)
> usb.util.claim_interface(dev, intf)
> dev.write(0x01,'\x0F\x01')
>
> results in
>
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 878,`
> in write
>      self.__get_timeout(timeout)
>    File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py",
> line 479, in bulk_write
>      data, timeout)
>    File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py",
> line 550, in __write
>      timeout
>    File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py",
> line 379, in _check
>      raise USBError(errmsg, ret)
> usb.core.USBError: [Errno None] Connection timed out
>

This seems to be a device specific issue. However, your code can be simpler:

import usb.core
dev = usb.core.find(idVendor = 0x0456, idProduct = 0xee24)
dev.set_configuration()
dev.set_interface_altsetting(interface = 0, alternate_setting = 1)
dev.write(0x01,'\x0F\x01')

> I'm struggeling to understand why I'm getting the time out and sadly
> can't make any sense of the Google results I'm getting. Any help for a
> beginner is much appreciated!
>
> Cheers,
> Johannes
>
> ------------------------------------------------------------------------------
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users



-- 
Best Regards,
Wander Lairson Costa

Re: [pyusb-users] Problem with Ubuntu 10.04

[Xiaofan C. <xia...@gm...>]

On Sun, Aug 16, 2015 at 10:54 AM, Alan Jhonn Aguiar Schwyn
<al...@ho...> wrote:
> Hi again,
>
> I found the problem. Ubuntu 10.04 has libusb 1-0.0 package version:
> 2:1.0.6-1.
> I made a workarround for get_speed property..
>
> https://github.com/walac/pyusb/pull/109
>
> Someone can check it?
>

Why not just upgrade libusb to the latest release
under Ubuntu 10.04?


-- 
Xiaofan

Re: [pyusb-users] Problem with Ubuntu 10.04

[Alan J. A. S. <al...@ho...>]

Hi again,
I found the problem. Ubuntu 10.04 has libusb 1-0.0 package version: 2:1.0.6-1.The self.lib object has this properties:
['_FuncPtr', '__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattr__', '__getattribute__', '__getitem__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_func_flags_', '_func_restype_', '_handle', '_name', 'libusb_alloc_transfer', 'libusb_attach_kernel_driver', 'libusb_bulk_transfer', 'libusb_claim_interface', 'libusb_clear_halt', 'libusb_close', 'libusb_control_transfer', 'libusb_detach_kernel_driver', 'libusb_exit', 'libusb_fill_iso_transfer', 'libusb_free_config_descriptor', 'libusb_free_device_list', 'libusb_free_transfer', 'libusb_get_bus_number', 'libusb_get_config_descriptor', 'libusb_get_configuration', 'libusb_get_device_address', 'libusb_get_device_descriptor', 'libusb_get_device_list', 'libusb_get_max_iso_packet_size', 'libusb_get_string_descriptor_ascii', 'libusb_init', 'libusb_interrupt_transfer', 'libusb_kernel_driver_active', 'libusb_open', 'libusb_ref_device', 'libusb_release_interface', 'libusb_reset_device', 'libusb_set_configuration', 'libusb_set_debug', 'libusb_set_interface_alt_setting', 'libusb_set_iso_packet_lengths', 'libusb_submit_transfer', 'libusb_unref_device']
I made a workarround for get_speed property..
https://github.com/walac/pyusb/pull/109
Someone can check it?
Regards!
Alan


From: al...@ho...
To: pyu...@li...
Date: Sat, 15 Aug 2015 22:57:08 -0300
Subject: [pyusb-users] Problem with Ubuntu 10.04




Hi,
I now that Ubuntu 10.04 (Lucid) has end their support, but I have to mantaina program for it.The problem I don't know where is, but is a recent change.The tag "1.0.0b2" works fine but the latest commit of master git not works.
This is the error:
>>> d = usb.core.find()Traceback (most recent call last):  File "<stdin>", line 1, in <module>  File "usb/core.py", line 1252, in find    return _interop._next(device_iter(k, v))  File "usb/_interop.py", line 60, in _next    return next(iter)  File "usb/core.py", line 1221, in device_iter    d = Device(dev, backend)  File "usb/core.py", line 728, in __init__    desc = backend.get_device_descriptor(dev)  File "usb/backend/libusb1.py", line 722, in get_device_descriptor    dev_desc.speed = self.lib.libusb_get_device_speed(dev.devid)  File "/usr/lib/python2.6/ctypes/__init__.py", line 366, in __getattr__    func = self.__getitem__(name)  File "/usr/lib/python2.6/ctypes/__init__.py", line 371, in __getitem__    func = self._FuncPtr((name_or_ordinal, self))AttributeError: /lib/libusb-1.0.so.0: undefined symbol: libusb_get_device_speed
Seems that this version of LibUSB has not implemented get_device_speed ??
Regards!
Alan




 		 	   		  

------------------------------------------------------------------------------
_______________________________________________
pyusb-users mailing list
pyu...@li...
https://lists.sourceforge.net/lists/listinfo/pyusb-users 		 	   		  

[pyusb-users] Problem with Ubuntu 10.04

[Alan J. A. S. <al...@ho...>]

Hi,
I now that Ubuntu 10.04 (Lucid) has end their support, but I have to mantaina program for it.The problem I don't know where is, but is a recent change.The tag "1.0.0b2" works fine but the latest commit of master git not works.
This is the error:
>>> d = usb.core.find()Traceback (most recent call last):  File "<stdin>", line 1, in <module>  File "usb/core.py", line 1252, in find    return _interop._next(device_iter(k, v))  File "usb/_interop.py", line 60, in _next    return next(iter)  File "usb/core.py", line 1221, in device_iter    d = Device(dev, backend)  File "usb/core.py", line 728, in __init__    desc = backend.get_device_descriptor(dev)  File "usb/backend/libusb1.py", line 722, in get_device_descriptor    dev_desc.speed = self.lib.libusb_get_device_speed(dev.devid)  File "/usr/lib/python2.6/ctypes/__init__.py", line 366, in __getattr__    func = self.__getitem__(name)  File "/usr/lib/python2.6/ctypes/__init__.py", line 371, in __getitem__    func = self._FuncPtr((name_or_ordinal, self))AttributeError: /lib/libusb-1.0.so.0: undefined symbol: libusb_get_device_speed
Seems that this version of LibUSB has not implemented get_device_speed ??
Regards!
Alan




 		 	   		  

[pyusb-users] Connection Timed Out

[Johannes R. <rot...@gm...>]

Hello,

As a pyusb beginner I'm making my first steps while trying to talk to a 
CY7C68013A USB controller, which in turn should talk to my AD9959.

After some work and usb-sniffing the windows drivers, I'm stuck now, as 
I'm getting time outs. The problem seems to be with with either reading 
or writing (the error is the same). I can read the config, interfaces 
and endpoints from the controller and when trying to read/write from the 
wrong endpoint, it comes up with sensible errors, but not when I'm 
trying to read/write to a proper endpoint. Here's a simple example:

import usb.core
dev = usb.core.find(idVendor = 0x0456, idProduct = 0xee24)
cfg = dev[0]
intf = cfg[(0,1)]
dev.set_configuration(cfg)
dev.set_interface_altsetting(interface = 0, alternate_setting = 1)
usb.util.claim_interface(dev, intf)
dev.write(0x01,'\x0F\x01')

results in

Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 878,` 
in write
     self.__get_timeout(timeout)
   File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py", 
line 479, in bulk_write
     data, timeout)
   File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py", 
line 550, in __write
     timeout
   File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb0.py", 
line 379, in _check
     raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] Connection timed out

I'm struggeling to understand why I'm getting the time out and sadly 
can't make any sense of the Google results I'm getting. Any help for a 
beginner is much appreciated!

Cheers,
Johannes

Re: [pyusb-users] Beginner's question

[Bomin N. <nie...@gm...>]

Sorry, ignore my first question about "import usb.core" does not work.  I
named my py file as usb.py, and after I renamed it, it's working now.

2015-08-11 16:46 GMT+08:00 Bomin Nie <nie...@gm...>:

> Hi,
>
> I'm not sure if this is the correct place that I shoot my question, if
> it's not, please redirect me to the right place or somewhere I can find the
> answsers
>
> So, I'm on a project to use python to access my usb devices and I'm on
> Window 7.  I downloaded the zip version from
> https://walac.github.io/pyusb/, after which I ran "python setup.py
> install", and then I tried to "import usb.core", but I failed, Well, I can
> see this directory "c:\Python27\Lib\site-packages\usb\", and it has core.py
> in it.  What I'm doing now is copying the "usb" directory to my project
> working directory, and "import usb.core" works....  How should I fix this?
>
> Since I got the "import usb.core" working, I then try to find devices.
> And, I got "NoBackendError".  I then
>  - downloaded the windows binary from "http://libusb.info/"
>  - copy "MS64\dll\libusb-1.0.dll" to my
> "c:\Windows\SysWOW64\libusb-1.0.dll".  My win7 is 64 bit.
>
> It still gives me the same error...  What am I supposed to do more?
>
> --
> Nie Bomin
>



-- 
Nie Bomin

[pyusb-users] Beginner's question

[Bomin N. <nie...@gm...>]

Hi,

I'm not sure if this is the correct place that I shoot my question, if it's
not, please redirect me to the right place or somewhere I can find the
answsers

So, I'm on a project to use python to access my usb devices and I'm on
Window 7.  I downloaded the zip version from https://walac.github.io/pyusb/,
after which I ran "python setup.py install", and then I tried to "import
usb.core", but I failed, Well, I can see this directory
"c:\Python27\Lib\site-packages\usb\", and it has core.py in it.  What I'm
doing now is copying the "usb" directory to my project working directory,
and "import usb.core" works....  How should I fix this?

Since I got the "import usb.core" working, I then try to find devices.
And, I got "NoBackendError".  I then
 - downloaded the windows binary from "http://libusb.info/"
 - copy "MS64\dll\libusb-1.0.dll" to my
"c:\Windows\SysWOW64\libusb-1.0.dll".  My win7 is 64 bit.

It still gives me the same error...  What am I supposed to do more?

-- 
Nie Bomin

[pyusb-users] detach kernel driver

[UNIVERSAL P. <uni...@gm...>]

Hi!!


after: "dev.detach_kernel_driver(interface)"


i have this error:

*usb.core.USBError: could not detach kernel driver from interface 0: No
data available.....*

Re: [pyusb-users] Bug found and patched in util.py

[Wander L. C. <wan...@gm...>]

2015-08-08 22:18 GMT-03:00 Paul Cornelius <pau...@vu...>:
> OK I see.
>
> I thought I had the latest release (1.0.0.a2), which I got from
> sourceforge.  I got to there by following the link on
> http://walac.github.io/pyusb/.  Also I searched exhaustively for anyone
> reporting this bug before diving into the pyusb internals. What did I do
> wrong?
>

The point is that this change was not released yet. When you find a
bug, it is better to check against git HEAD to see if it happens in
the latest code.

> Thanks,
> Paul Cornelius
>
> On 8/8/2015 12:00 PM, Wander Lairson Costa wrote:
>> Hi,
>>
>> Notice the code the get_string has changed:
>> https://github.com/walac/pyusb/blob/master/usb/util.py#L295-L340
>>
>> 2015-08-08 1:14 GMT-03:00 Paul Cornelius <pau...@vu...>:
>>> I found a bug in usb.util.py in the function get_string.  This function was
>>> failing with an "Overflow" error on my Windows 8.1 machine, using Python 3.3
>>> and libusb-1.0.
>>>
>>> If this function is called with the default value for langid (None), it
>>> first makes a call to get_descriptor to obtain a list of languages supported
>>> by the device.  This second parameter of this function call is the size of
>>> the reply buffer, which was equal to 1024.  But a comment in the libusb-1.0
>>> source (descriptor.c, function libusb_get_string_descriptor_ascii) reads: /*
>>> Some devices choke on size > 255 */.
>>>
>>> And it seems to be true.  When I changed the get_descriptor function call to
>>> reduce the buffer size parameter to 255 the error disappeared.  I also
>>> thought it would be good to limit the size of any buffer passed to
>>> get_string.  My modified function now reads as follows:
>>>
>>> def get_string(dev, length, index, langid = None):
>>>      r"""Retrieve a string descriptor from the device.
>>>
>>>      dev is the Device object to which the request will be
>>>      sent to.
>>>
>>>      length is the length of string in number of characters.
>>>
>>>      index is the string descriptor index and langid is the Language
>>>      ID of the descriptor. If langid is omitted, the string descriptor
>>>      of the first Language ID will be returned.
>>>
>>>      The return value is the unicode string present in the descriptor.
>>>      """
>>>      from usb.control import get_descriptor
>>>      if langid is None:
>>>      # Asking for the zero'th index is special - it returns a string
>>>      # descriptor that contains all the language IDs supported by the device.
>>>      # Typically there aren't many - often only one. The language IDs are 16
>>>      # bit numbers, and they start at the third byte in the descriptor. See
>>>      # USB 2.0 specification section 9.6.7 for more information.
>>>          #
>>>          # Note from libusb 1.0 sources (descriptor.c)
>>>          buf = get_descriptor(
>>>                      dev,
>>>                      255,
>>>                      DESC_TYPE_STRING,
>>>                      0
>>>                  )
>>>          assert len(buf) >= 4
>>>          langid = buf[2] | (buf[3] << 8)
>>>
>>>      lenstr = length * 2 + 2
>>>      if lenstr > 255:
>>>          raise ValueError("String buffer length too long")
>>>      buf = get_descriptor(
>>>                  dev,
>>>                  length * 2 + 2, # string is utf16 + 2 bytes of the
>>> descriptor
>>>                  DESC_TYPE_STRING,
>>>                  index,
>>>                  langid
>>>              )
>>>      return buf[2:].tostring().decode('utf-16-le')
>>>
>>> Paul Cornelius
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> pyusb-users mailing list
>>> pyu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users



-- 
Best Regards,
Wander Lairson Costa

Re: [pyusb-users] Bug found and patched in util.py

[Paul C. <pau...@vu...>]

OK I see.

I thought I had the latest release (1.0.0.a2), which I got from 
sourceforge.  I got to there by following the link on 
http://walac.github.io/pyusb/.  Also I searched exhaustively for anyone 
reporting this bug before diving into the pyusb internals. What did I do 
wrong?

Thanks,
Paul Cornelius

On 8/8/2015 12:00 PM, Wander Lairson Costa wrote:
> Hi,
>
> Notice the code the get_string has changed:
> https://github.com/walac/pyusb/blob/master/usb/util.py#L295-L340
>
> 2015-08-08 1:14 GMT-03:00 Paul Cornelius <pau...@vu...>:
>> I found a bug in usb.util.py in the function get_string.  This function was
>> failing with an "Overflow" error on my Windows 8.1 machine, using Python 3.3
>> and libusb-1.0.
>>
>> If this function is called with the default value for langid (None), it
>> first makes a call to get_descriptor to obtain a list of languages supported
>> by the device.  This second parameter of this function call is the size of
>> the reply buffer, which was equal to 1024.  But a comment in the libusb-1.0
>> source (descriptor.c, function libusb_get_string_descriptor_ascii) reads: /*
>> Some devices choke on size > 255 */.
>>
>> And it seems to be true.  When I changed the get_descriptor function call to
>> reduce the buffer size parameter to 255 the error disappeared.  I also
>> thought it would be good to limit the size of any buffer passed to
>> get_string.  My modified function now reads as follows:
>>
>> def get_string(dev, length, index, langid = None):
>>      r"""Retrieve a string descriptor from the device.
>>
>>      dev is the Device object to which the request will be
>>      sent to.
>>
>>      length is the length of string in number of characters.
>>
>>      index is the string descriptor index and langid is the Language
>>      ID of the descriptor. If langid is omitted, the string descriptor
>>      of the first Language ID will be returned.
>>
>>      The return value is the unicode string present in the descriptor.
>>      """
>>      from usb.control import get_descriptor
>>      if langid is None:
>>      # Asking for the zero'th index is special - it returns a string
>>      # descriptor that contains all the language IDs supported by the device.
>>      # Typically there aren't many - often only one. The language IDs are 16
>>      # bit numbers, and they start at the third byte in the descriptor. See
>>      # USB 2.0 specification section 9.6.7 for more information.
>>          #
>>          # Note from libusb 1.0 sources (descriptor.c)
>>          buf = get_descriptor(
>>                      dev,
>>                      255,
>>                      DESC_TYPE_STRING,
>>                      0
>>                  )
>>          assert len(buf) >= 4
>>          langid = buf[2] | (buf[3] << 8)
>>
>>      lenstr = length * 2 + 2
>>      if lenstr > 255:
>>          raise ValueError("String buffer length too long")
>>      buf = get_descriptor(
>>                  dev,
>>                  length * 2 + 2, # string is utf16 + 2 bytes of the
>> descriptor
>>                  DESC_TYPE_STRING,
>>                  index,
>>                  langid
>>              )
>>      return buf[2:].tostring().decode('utf-16-le')
>>
>> Paul Cornelius
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> pyusb-users mailing list
>> pyu...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>>
>
>

Re: [pyusb-users] Bug found and patched in util.py

[Wander L. C. <wan...@gm...>]

Hi,

Notice the code the get_string has changed:
https://github.com/walac/pyusb/blob/master/usb/util.py#L295-L340

2015-08-08 1:14 GMT-03:00 Paul Cornelius <pau...@vu...>:
> I found a bug in usb.util.py in the function get_string.  This function was
> failing with an "Overflow" error on my Windows 8.1 machine, using Python 3.3
> and libusb-1.0.
>
> If this function is called with the default value for langid (None), it
> first makes a call to get_descriptor to obtain a list of languages supported
> by the device.  This second parameter of this function call is the size of
> the reply buffer, which was equal to 1024.  But a comment in the libusb-1.0
> source (descriptor.c, function libusb_get_string_descriptor_ascii) reads: /*
> Some devices choke on size > 255 */.
>
> And it seems to be true.  When I changed the get_descriptor function call to
> reduce the buffer size parameter to 255 the error disappeared.  I also
> thought it would be good to limit the size of any buffer passed to
> get_string.  My modified function now reads as follows:
>
> def get_string(dev, length, index, langid = None):
>     r"""Retrieve a string descriptor from the device.
>
>     dev is the Device object to which the request will be
>     sent to.
>
>     length is the length of string in number of characters.
>
>     index is the string descriptor index and langid is the Language
>     ID of the descriptor. If langid is omitted, the string descriptor
>     of the first Language ID will be returned.
>
>     The return value is the unicode string present in the descriptor.
>     """
>     from usb.control import get_descriptor
>     if langid is None:
>     # Asking for the zero'th index is special - it returns a string
>     # descriptor that contains all the language IDs supported by the device.
>     # Typically there aren't many - often only one. The language IDs are 16
>     # bit numbers, and they start at the third byte in the descriptor. See
>     # USB 2.0 specification section 9.6.7 for more information.
>         #
>         # Note from libusb 1.0 sources (descriptor.c)
>         buf = get_descriptor(
>                     dev,
>                     255,
>                     DESC_TYPE_STRING,
>                     0
>                 )
>         assert len(buf) >= 4
>         langid = buf[2] | (buf[3] << 8)
>
>     lenstr = length * 2 + 2
>     if lenstr > 255:
>         raise ValueError("String buffer length too long")
>     buf = get_descriptor(
>                 dev,
>                 length * 2 + 2, # string is utf16 + 2 bytes of the
> descriptor
>                 DESC_TYPE_STRING,
>                 index,
>                 langid
>             )
>     return buf[2:].tostring().decode('utf-16-le')
>
> Paul Cornelius
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users
>



-- 
Best Regards,
Wander Lairson Costa

[pyusb-users] AUTO: Guillaume Schatz is out of the office (returning 17.08.2015)

[Guillaume S. <Gui...@po...>]

I am out of the office until 17.08.2015.

I'll respond to your email when I return.
Best regards,
Guillaume



Note: This is an automated response to your message  "[pyusb-users] Bug
found and patched in util.py" sent on 08.08.2015 06:14:35.

This is the only notification you will receive while this person is away.

[pyusb-users] Bug found and patched in util.py

[Paul C. <pau...@vu...>]

I found a bug in usb.util.py in the function get_string.  This function 
was failing with an "Overflow" error on my Windows 8.1 machine, using 
Python 3.3 and libusb-1.0.

If this function is called with the default value for langid (None), it 
first makes a call to get_descriptor to obtain a list of languages 
supported by the device.  This second parameter of this function call is 
the size of the reply buffer, which was equal to 1024.  But a comment in 
the libusb-1.0 source (descriptor.c, function 
libusb_get_string_descriptor_ascii) reads: /* Some devices choke on size 
 > 255 */.

And it seems to be true.  When I changed the get_descriptor function 
call to reduce the buffer size parameter to 255 the error disappeared.  
I also thought it would be good to limit the size of any buffer passed 
to get_string.  My modified function now reads as follows:

defget_string(dev,length,index,langid=None):
r"""Retrieve a string descriptor from the device.

dev is the Device object to which the request will be
sent to.

length is the length of string in number of characters.

index is the string descriptor index and langid is the Language
ID of the descriptor. If langid is omitted, the string descriptor
of the first Language ID will be returned.

The return value is the unicode string present in the descriptor.
"""
fromusb.controlimportget_descriptor
iflangidisNone:
# Asking for the zero'th index is special - it returns a string
# descriptor that contains all the language IDs supported by the device.
# Typically there aren't many - often only one. The language IDs are 16
# bit numbers, and they start at the third byte in the descriptor. See
# USB 2.0 specification section 9.6.7 for more information.
#
# Note from libusb 1.0 sources (descriptor.c)
buf=get_descriptor(
dev,
255,
DESC_TYPE_STRING,
0
)
assertlen(buf)>=4
langid=buf[2]|(buf[3]<<8)

lenstr=length*2+2
iflenstr>255:
raiseValueError("String buffer length too long")
buf=get_descriptor(
dev,
length*2+2,# string is utf16 + 2 bytes of the descriptor
DESC_TYPE_STRING,
index,
langid
)
returnbuf[2:].tostring().decode('utf-16-le')

Paul Cornelius

Re: [pyusb-users] Change suggestion

[Hermann H. <her...@we...>]

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>&nbsp;
<div>
<div name="quote" style="margin: 10px 5px 5px 10px; padding: 10px 0px 10px 10px; border-left-color: rgb(195, 217, 229); border-left-width: 2px; border-left-style: solid; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin: 0px 0px 10px;">
<div>Hello Tormod,<br/>
thank you for your response.</div>

<div>I hope the following remarks will get you further.</div>

<div>&gt; The source revision control system log has taken over this function.</div>

<div>Fine, but it did not help you &#9786;.</div>

<div>&gt;&gt; The original is from walac-pyusb-39816be.</div>

<div>&gt; 39816be is actually the most recent repository revision. There are a<br/>
&gt; lot more changes between 39816be and the files you posted, than in<br/>
&gt; your diff files. And some changes in your diff that are already in the<br/>
&gt; repository.</div>

<div>&gt;&gt; I was astonished to learn, that the sourceforge files are from 2014.</div>

<div>&gt; Which also indicates you were basing it on an older version.</div>

<div>&gt; Thanks for providing the diffs but unfortunately they don&#39;t apply<br/>
&gt; against the latest revision. I spent a lot of time trying to find<br/>
&gt; which revision you had used but was not successful.</div>

<div>&gt; It would be easy if we knew against which version... Maybe someone<br/>
&gt; familar with the code and its history can figure it out, but I am just<br/>
&gt; a patch fairy.</div>

<div><br/>
Now I am totaly confused.</div>

<div>In preparation of my last mail I reapplied my modifications on the 39816be version<br/>
to avoid any confusion. I clearly stated this.</div>

<div>A comparision of &nbsp;the linenumbers of the diff files and the source files would have verified this.</div>

<div>&nbsp;</div>

<div>Please do the following:</div>

<div>Forget the code example in my first mail, it was not intended as a basis for changes but only as demonstration of the</div>

<div>technique.</div>

<div>Delete the files I dumped on you with my second mail. I do not know the version and nobody needs to</div>

<div>since they are obsolete.</div>

<div>Stop poking around in obsolete files and hunting phantom problems, you are completely off road.</div>

<div>&nbsp;</div>

<div>Find attached the diffs (from 39816be) as suggested.</div>

<div>Sincerely yours<br/>
HH</div>

<div>&nbsp;</div>
</div>
</div>
</div>
</div></div></body></html>

Re: [pyusb-users] Change suggestion

[Tormod V. <lis...@gm...>]

On Wed, Jul 1, 2015 at 9:07 AM, Hermann Hamann wrote:
> Well, identifying the version of a source file would be very easy if you put
> a
> comment at the beginning containing the modification date. Back in the 70s
> we
> were able to fully automate this using available tools (this was not on
> Unix).
> I feel, sed (available since the 70s) could do this for you.

The source revision control system log has taken over this function.

> I finally succeeded in getting a basic understanding of diff, but could not
> find out if patch needs a "diff original modified" or a "diff modified
> original" to work properly.

It should be "original modified" (from to). Please also used "unified"
format for more robust patches (they include some context). The
general diff command that matches the "git diff" output and similar is
"diff -Nurp old new" where old and new also can be directory trees.

> The original is from walac-pyusb-39816be.

39816be is actually the most recent repository revision. There are a
lot more changes between 39816be and the files you posted, than in
your diff files. And some changes in your diff that are already in the
repository.

> I was astonished to learn, that the sourceforge files are from 2014.

Which also indicates you were basing it on an older version.

Thanks for providing the diffs but unfortunately they don't apply
against the latest revision. I spent a lot of time trying to find
which revision you had used but was not successful.

> I hope you can proceed with the modifications. There are 4 lines to change
> and
> 20 lines to insert. Back in the 70s we could do this within 15 minutes.

It would be easy if we knew against which version... Maybe someone
familar with the code and its history can figure it out, but I am just
a patch fairy.

Best regards,
Tormod

Re: [pyusb-users] Change suggestion

[Hermann H. <her...@we...>]

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>
<div name="quote" style="margin: 10px 5px 5px 10px; padding: 10px 0px 10px 10px; border-left-color: rgb(195, 217, 229); border-left-width: 2px; border-left-style: solid; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin: 0px 0px 10px;">
<div>Hi,<br/>
sorry for my late answer.</div>

<div>Well, everyone has to carry his burden, not only maintainers (as opposed to<br/>
Galather 6.2).</div>

<div>My burden is my 99 years old mum, who suffers from dementia and other pains of<br/>
old age and needs attention around the clock.</div>

<div>This leaves me 1 or 2 hours a week for concentrated programming work.<br/>
Furthermore, I have no internet at home and have to ride to the public library<br/>
for net access. I have to ask my neighbor to keep an eye on my mum while I am<br/>
absent.</div>

<div>So I am not keen on spending my sparse time acquiring skills which I do not<br/>
need. I am currently stuck with opening a window on a remote cpu using Tkinter.</div>

<div>This results in&nbsp; very low productivity and sluggish response.</div>

<div>This is not facebook and so I will close this social thread.</div>

<div>----</div>

<div>Well, identifying the version of a source file would be very easy if you put a<br/>
comment at the beginning containing the modification date. Back in the 70s we<br/>
were able to fully automate this using available tools (this was not on Unix).</div>

<div>I feel, sed (available since the 70s) could do this for you.</div>

<div>----</div>

<div>I finally succeeded in getting a basic understanding of diff, but could not<br/>
find out if patch needs a &quot;diff original modified&quot; or a &quot;diff modified<br/>
original&quot; to work properly.</div>

<div>The original is from walac-pyusb-39816be.<br/>
I was astonished to learn, that the sourceforge files are from 2014.</div>

<div>I hope you can proceed with the modifications. There are 4 lines to change and<br/>
20 lines to insert. Back in the 70s we could do this within 15 minutes.<br/>
&nbsp;<br/>
Do not hesitate to contact me if there are any questions left.</div>

<div>Sincerely yours HH</div>

<div>&nbsp;</div>
</div>
</div>
</div>
</div></div></body></html>

Re: [pyusb-users] question

[Jay N. <ja...@ne...>]

Yes the driver is installed on the second PC.




Jay Newens| Product Manager
4023 W. University |  Bldg B | McKinney, TX 75071 
972-347-1766 | www.nemo-q.com

The world is waiting....




-----Original Message-----
From: Xiaofan Chen [mailto:xia...@gm...] 
Sent: Saturday, June 20, 2015 21:13
To: pyu...@li...
Subject: Re: [pyusb-users] question

On Fri, Jun 19, 2015 at 9:54 AM, Jay Newens <ja...@ne...> wrote:
> Ok,
>
> I have a new problem. I am using libusb-win32-bin-1.2.6.0. I am using 
> the libusb0.dll and libusb0.sys. I am communicating to a ZebraKR403 
> printer checking for the status. On my dev PC this is working and I 
> have packaged my program with py2exe and installed it on my first 
> target PC along with the
> libusb-win32-bin-1.2.6.0 and it is working fine. On my second PC I am 
> getting an error when the program runs.
>
> Traceback (most recent call last):
>   File "ZebraKR403PaperStatus1.0.py", line 1, in <module>
>   File "usb\__init__.pyc", line 97, in <module>
>   File "usb\legacy.pyc", line 29, in <module>
>   File "usb\core.pyc", line 50, in <module>
> ImportError: No module named _objfinalizer
>
>
> The only difference between the PC's is the windows OS, both Windows 
> 7, one
> 64 bit and the one not working is 32 bit. The exe package was created 
> on a
> 32 bit machine with py2exe. Any idea?
>

Did you install the driver on the 2nd PC?


--
Xiaofan

----------------------------------------------------------------------------
--
_______________________________________________
pyusb-users mailing list
pyu...@li...
https://lists.sourceforge.net/lists/listinfo/pyusb-users

Re: [pyusb-users] question

[Xiaofan C. <xia...@gm...>]

On Fri, Jun 19, 2015 at 9:54 AM, Jay Newens <ja...@ne...> wrote:
> Ok,
>
> I have a new problem. I am using libusb-win32-bin-1.2.6.0. I am using the
> libusb0.dll and libusb0.sys. I am communicating to a ZebraKR403 printer
> checking for the status. On my dev PC this is working and I have packaged my
> program with py2exe and installed it on my first target PC along with the
> libusb-win32-bin-1.2.6.0 and it is working fine. On my second PC I am
> getting an error when the program runs.
>
> Traceback (most recent call last):
>   File "ZebraKR403PaperStatus1.0.py", line 1, in <module>
>   File "usb\__init__.pyc", line 97, in <module>
>   File "usb\legacy.pyc", line 29, in <module>
>   File "usb\core.pyc", line 50, in <module>
> ImportError: No module named _objfinalizer
>
>
> The only difference between the PC's is the windows OS, both Windows 7, one
> 64 bit and the one not working is 32 bit. The exe package was created on a
> 32 bit machine with py2exe. Any idea?
>

Did you install the driver on the 2nd PC?


-- 
Xiaofan

Re: [pyusb-users] Change suggestion

[Steven M. <smi...@gm...>]

> On Jun 20, 2015, at 2:10 AM, Tormod Volden <lis...@gm...> wrote:
> 
> On Fri, Jun 19, 2015 at 4:12 PM, Hermann Hamann wrote:
>> I am sorry, but I am too old and too stupid to learn on the fly how to use a
>> github pull request
>> to push some files.
>> 
>> So I use the stone age way to attach the modified files core.py and
>> libusb1.py to this mail, hoping,
>> that some kind soul will find them and treat them as required.
> 
> Hermann,
> 
> What version of pyusb are your changes based on? Without knowing this,
> it is difficult to figure out exactly what are your changes.
> 
> You are giving the maintainer a lot of extra work by just dumping your
> files on him. At least, use a "diff" utility to make a
> machine-readable diff instead. BTW, the original "diff" was made in
> the seventies, so age is no excuse.
> 
> Regards,
> Tormod
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> pyusb-users mailing list
> pyu...@li...
> https://lists.sourceforge.net/lists/listinfo/pyusb-users

Hermann,

Presuming that you used git to clone the source repository there is one of the few basic git commands to get a properly formatted patch that tracks the source revision.

Please use git format-patch to generate diffs based upon the checkout that you worked against.

`git format-patch origin/master`

As for pull requests in github, you are not too stupid nor too old.  Your self deprecation begs for mockery from others.  I accept no ageism, my grandmother was an avid computer user, that was self taught when she was 62, on a 8088 IBM PC clone.

1. Fork the pyusb repository.
2. Commit your changes to a branch in your new fork on your computer.
3. Push your changes to in the forked repository on github.
4. Submit a pull request for that new branch against the pyusb repository.

Please refer to this documentation from github.
https://help.github.com/articles/using-pull-requests/ <https://help.github.com/articles/using-pull-requests/>

Steve

Re: [pyusb-users] Change suggestion

[Tormod V. <lis...@gm...>]

On Fri, Jun 19, 2015 at 4:12 PM, Hermann Hamann wrote:
> I am sorry, but I am too old and too stupid to learn on the fly how to use a
> github pull request
> to push some files.
>
> So I use the stone age way to attach the modified files core.py and
> libusb1.py to this mail, hoping,
> that some kind soul will find them and treat them as required.

Hermann,

What version of pyusb are your changes based on? Without knowing this,
it is difficult to figure out exactly what are your changes.

You are giving the maintainer a lot of extra work by just dumping your
files on him. At least, use a "diff" utility to make a
machine-readable diff instead. BTW, the original "diff" was made in
the seventies, so age is no excuse.

Regards,
Tormod

Re: [pyusb-users] Change suggestion

[Hermann H. <her...@we...>]

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div><br/>
Hi,<br/>
<br/>
Could you please open a Pull Request or, if you are not willing to<br/>
supply a patch, an issue detailing your proposal?<br/>
<br/>
<br/>
<br/>
--<br/>
Best Regards,<br/>
Wander Lairson Costa<br/>
<br/>
------------------------------------------------------------------------------<br/>
Hi,</div>

<div>thank you for your reply.</div>

<div>&nbsp;</div>

<div>I am sorry, but I am too old and too stupid to learn on the fly how to use a github pull request</div>

<div>to push some files.</div>

<div>&nbsp;</div>

<div>So I use the stone age way to attach the modified files core.py and libusb1.py to this mail, hoping,</div>

<div>that some kind soul will find them and treat them as required.</div>

<div>&nbsp;</div>

<div>Sincerely</div>

<div>Hermann Hamann</div>

<div>_______________________________________________<br/>
pyusb-users mailing list<br/>
pyu...@li...<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/pyusb-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/pyusb-users</a></div></div></body></html>