Hi,
On 02/13/2013 02:08 AM, Xiaofan Chen wrote:
> On Tue, Feb 12, 2013 at 6:29 PM, Hans de Goede wrote:
>> LIBUSB_HOTPLUG_EVENT_DRIVERLESS_DEVICE_ARRIVED
>> LIBUSB_HOTPLUG_EVENT_DRIVERLESS_DEVICE_LEFT
>>
>> Event types, and generate those in the driverless case, apps which don't
>> know how to
On 12.2.2013 4.06, "Xiaofan Chen" wrote:
>
>2) The complexity of the event handling, I tend to believe
>this is the main motivation.
>
>To me 2) is really the one major problems for libusb-1.0
>API. Just read the libusbx documentation and you will
>realize that it is not that designed for Windows
On 12.2.2013 12.29, "Hans de Goede" wrote:
>On 02/12/2013 12:54 AM, Pete Batard wrote:
>>
>> Personally, the first thing I want out of hotplug from a libusbx/Windows
>> standpoint is to provide applications with the ability to notify users
>
>We can simply add:
>
>LIBUSB_HOTPLUG_EVENT_DRIVERLESS
On 13.2.2013 0.38, "Nathan Hjelm" wrote:
>
>Using descriptions like "stupid" for the proposed event names does
>nothing to advance the discussion on what the API for libusb 1.0 should
>look like. You, and others, have been given (and still have for a short
>time) an opportunity to help define the
On 12.2.2013 12.29, "Hans de Goede" wrote:
> Currently the following events are defined:
>
>LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED: A device has arrived and is ready to
>use
>LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT: A device has left and is no longer
>available
>
>Not the best names ever, I would have call
Hi to all.My previous experience with USB was PIC 18F4550 and HID device so
sorry if I ask something obvious.
I have a problem with AVR32 UC3A0512 device and Vendor class. Hardware is
EVK1100 clone (WaveShare EVK3A).
I manage to build firmware with AtmelStudio 6 and install driver (libUSBwin32
o
I'm experiencing some unexpected behavior using the function
libusb_bulk_transfer on IN transaction. The version used is 1.0.14.10577
running on windows 7 x64.
Sometimes when the functions returns with timeout I can see some data
written in the buffer correctly but the transferred variable repo
Hi,
On 02/13/2013 10:58 AM, Kustaa Nyholm wrote:
> On 12.2.2013 12.29, "Hans de Goede" wrote:
>
>> On 02/12/2013 12:54 AM, Pete Batard wrote:
>>>
>>> Personally, the first thing I want out of hotplug from a libusbx/Windows
>>> standpoint is to provide applications with the ability to notify user
On 13.2.2013 15.23, "Hans de Goede" wrote:
>
>> In my thinking weather there is a driver or not is
>> logically a property of libusb_device and should
>> be queried from that handle and result in corresponding
>> error (LIBUSB_ERROR_NO_DRIVER) if passed to libusb_open().
>
>Apps which are actually
On Wed, Feb 13, 2013 at 7:45 PM, GORAN RADIVOJEVIC
wrote:
> I have a problem with AVR32 UC3A0512 device and Vendor
> class. Hardware is
> EVK1100 clone (WaveShare EVK3A).
> I manage to build firmware with AtmelStudio 6 and install driver
> (libUSBwin32 or libUSBK). Device is visible by
> Windows w
On 13/02/13 13:02, Ramon Zambelli wrote:
I'm experiencing some unexpected behavior using the function
libusb_bulk_transfer on IN transaction. The version used is
1.0.14.10577 running on windows 7 x64.
Sometimes when the functions returns with timeout I can see some data
written in the buffer c
On Wed, Feb 13, 2013 at 9:02 PM, Ramon Zambelli
wrote:
> Checking with an HW sniffer I see the packet sent from the
> devices correctly.
Could you post the debug log (set LIBUSB_DEBUG
environmental variable to 4) and the HW sniffer
data comparison.
Since you have the HW sniffer, do you notice er
On 13-Feb-13 4:27 PM, Toby Gray wrote:
> I've experienced something similar and it's been on my TODO list for
> many months to have a look at it. Can you try the attached patch? This
> helps in my situation where I see this issue, although I'm still
> seeing some data loss which I've not had tim
GORAN RADIVOJEVIC wrote:
>
> My previous experience with USB was PIC 18F4550 and HID device so
> sorry if I ask something obvious.
> I have a problem with AVR32 UC3A0512 device and Vendor class. Hardware
> is EVK1100 clone (WaveShare EVK3A).
> I manage to build firmware with AtmelStudio 6 and insta
This patch makes sense, and I realize that I wasn't as "careful" as the
libusbx documentation state to not lose any data when I wrote this
section of code.
Thanks to the both of you for both the report and the fix. The patch has
now been applied and pushed.
Regards,
/Pete
-
Looks good to me - pushed.
I added some parenthesis around the new test, as I know some compilers
will complain (possibly in pedantic mode) about ensuring to clarify that
the test is as intended, and not just a result of unexpected operator
precedence.
Regards,
/Pete
PS: I screwed up the tic
I'm sorry, but I don't get why we seem so hell bent (as it looks to me)
on finalizing the API down to its last minute detail, when we still
haven't really figured out how it's going to be implemented across the
major platforms, an more importantly, what that's really gonna mean for
our users.
On 14.2.2013 2.36, "Pete Batard" wrote:
>I'm sorry, but I don't get why we seem so hell bent (as it looks to me)
Well, no, it is just difficult to keep one's hands of the keyboard
when something 'interesting' surfaces. I'm in no hurry with hotplug,
I was just curious and wanted to get reactions
18 matches
Mail list logo
