ok, clear, so the example I used is not really the best example there is I guess.
I was able to do some transfers to the device in linux now, but only when using libusb_bulk_transfer rather than libusb_interrupt_transfer. I am not sure if I really understand the difference between those 2. But sometimes the transfer seems to time out: libusb: 0.868902 debug [usbi_handle_transfer_completion] transfer 0x657678 has callback 0x4049c6 libusb: 0.868908 debug [bulk_transfer_cb] actual_length=0 libusb: 0.869801 debug [submit_bulk_transfer] need 1 urbs for new transfer with length 2 libusb: 0.869850 debug [libusb_submit_transfer] arm timerfd for timeout in 500ms (first in line) libusb: 0.869866 debug [libusb_handle_events_timeout_completed] doing our own event handling libusb: 0.869871 debug [handle_events] poll() 3 fds with timeout in 60000ms libusb: 1.370557 debug [handle_events] poll() returned 1 libusb: 1.370642 debug [handle_events] timerfd triggered libusb: 1.370651 debug [disarm_timerfd] libusb: 1.370667 debug [libusb_cancel_transfer] libusb: 1.869915 debug [libusb_handle_events_timeout_completed] doing our own event handling libusb: 1.869977 debug [handle_events] poll() 3 fds with timeout in 60000ms libusb: 1.869992 debug [handle_events] poll() returned 1 libusb: 1.870005 debug [reap_for_handle] urb type=3 status=-2 transferred=0 libusb: 1.870012 debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1 libusb: 1.870018 debug [handle_bulk_completion] abnormal reap: urb status -2 libusb: 1.870022 debug [handle_bulk_completion] abnormal reap: last URB handled, reporting libusb: 1.870027 debug [usbi_handle_transfer_cancellation] detected timeout cancellation libusb: 1.870032 debug [disarm_timerfd] libusb: 1.870039 debug [usbi_handle_transfer_completion] transfer 0x6de278 has callback 0x4049c6 libusb: 1.870044 debug [bulk_transfer_cb] actual_length=0 libusb: 1.871203 debug [libusb_close] libusb: 1.871240 debug [usbi_remove_pollfd] remove fd 14 libusb: 1.871294 debug [libusb_unref_device] destroy device 1.1 libusb: 1.871301 debug [libusb_unref_device] destroy device 2.1 libusb: 1.871305 debug [libusb_unref_device] destroy device 2.2 libusb: 1.871310 debug [libusb_unref_device] destroy device 2.3 libusb: 1.871313 debug [libusb_unref_device] destroy device 2.9 libusb: 1.871351 debug [libusb_unref_device] destroy device 2.13 libusb: 1.871356 debug [libusb_exit] Under Windows this never seems to happen. Doe this ring any bells? Best regards Wim -----Original Message----- From: Tim Roberts [mailto:t...@probo.com] Sent: vrijdag 15 februari 2013 19:53 To: libusbx-devel@lists.sourceforge.net Subject: [SPAM] - Re: [Libusbx-devel] [SPAM] - Re: opening generic device EP in bulk transfer - difference between Linux and Windows - Email found in subject - Email found in subject - Email found in subject - Email found in subject Wim De Kimpe wrote: > Another question: if kernel attach and detach only has effect in > Linux, why does libusb_kernel_driver_active(handle,0) > return true on Windows? Shouldn't it return false then? It's not a Boolean. It returns LIBUSB_ERROR_NOT_SUPPORTED. If you're checking for zero/not-zero, that will compare as true. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. ------------------------------------------------------------------------------ The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel ------------------------------------------------------------------------------ The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
