/printf("Checking VID=0x%04x, PID=0x%04x\n", desc.idVendor,
> desc.idProduct);
> if( desc.idVendor == VENDOR_ID &&
> (desc.idProduct == PRODUCT_ID)
> {
> //printf("device found: class=0x%x\n", desc.bDeviceClass);
>
> return 1;
> }
> ret
we are using the brute force method rather
>
> // than open_device_with_vid_pid() because we need the device pointer
>
> // to look at the config descriptor.
>
> for(i = 0; i < cnt; i++){
>
> libusb_device *device = list[i];
>
> if( is_correctdev(device)
gt; close the usb device
> call libusb_exit()
Why do you call libusb_exit() here?
Are you calling libusb functions after libusb_exit()? If yes, then
errors are expected, because you told libusb that you don't need it
anymore by calling libusb_exit().
--
Matthias B
ptions about when to call "handle events". You can also just
>> use a dedicated thread to constantly call "handle events" to get rid
>> of the guessing. I didn't use an extra thread because I already had a
>> poll based event loop in my application.
> I d
en to call "handle events". You can also just
use a dedicated thread to constantly call "handle events" to get rid
of the guessing. I didn't use an extra thread because I already had a
poll based event loop in my application.
--
Matthias Bolte
http://photron.blogspot.c
The [Guidelines for Using
SetupAPI](http://msdn.microsoft.com/en-us/library/windows/hardware/ff545011.aspx)
state that if a SetupAPI function fails then the return value of
GetLastError() must be converted to a HRESULT value with the
HRESULT_FROM_SETUPAPI macro before passing it to FormatMessag
To be sure to get all file descriptors to poll on you should probably use this
sequence of calls:
libusb_init()
libusb_get_pollfds()
libusb_set_pollfd_notifiers()
libusb_get_pollfds() will give you all file descriptors that were created
before you registered your libusb_pollfd_added_cb().
---
Yes, these two patches fix the problem, thanks.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/150#issuecomment-26495583--
October Webinars: Code for Performance
Free Intel
I also noticed that the 64-bit sessionID gets stored in the unsigned long
session_data parameter of the libusb_device struct. First I thought this would
be a problem because the 64-bit value could get truncated, but as recent Macs
are all 64-bit and LP64 is in place there, unsigned long is also
The sessionID value is 64-bit, so print it as 64-bit value and don't
truncate it to 32-bit.
You can merge this Pull Request by running:
git pull https://github.com/photron/libusbx darwin-fix-1
Or you can view, comment on it, or merge it online at:
https://github.com/libusbx/libusbx/pull/153
Well, using UnregisterClassA is dangerous because it requires that the hotplug
thread always exits correctly and that you are not starting a new hotplug
thread before the old one has ended. And this is where the problems are:
In the error path of windows_init you're just terminated the hotplug t
You could use GetClassInfoExA to check if the window class already exist any
only register it if it's not existing yet.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/9#issuecomment-26133039-
o need to remove the -c option from you gcc command because -c
will only compile the source file, but doesn't not link it.
--
Matthias Bolte
http://photron.blogspot.com
--
October Webinars: Code for Performance
Free I
don't call
libusb_free_transfer to free it again. You could also used the
LIBUSB_TRANSFER_FREE_TRANSFER flag instead to make libusb
automatically free the transfer after cb_response_in was called. But
as you don't neither of this the transfer_response_in object leaks.
--
Matthias Bolte
h
The default case in windows_transfer_callback() calls windows_error_str(0)
which will convert the error code returned by GetLastError() to a string.
This currently works because windows_transfer_callback() is either called
with io_result set to NO_ERROR or io_result set to GetLastError().
If windo
I noticed a memory leak after updating to libusb 1.0.16 which added hotplug
support, the leak is also present in the current git version. Basically I see
libusb_device object leaking and tracked this down an unhandled hotplug left
event that was created between my last call to libusb_handle_even
16 matches
Mail list logo
