Kevyn-Alexandre Paré wrote: > > Data never becomes available. > > The application asks the device to send data, when the application > > knows that data is supposed to be available in the device. > > Agree, in my case I send data to an FPGA and I'm always expecting to > receive data from it. The application send the data to the device > and expect data back.
All right, but until the application tries to receive data, the device has no way of indicating that it has data to send. > My loop event doesn't need to manage these fds by it's self but > simply call libusb_handle_events(). Then libusb will call my > callback function, that I register with libusb_fill_bulk_transfer. > In the callback I will manage what I want to do depending on the > status?!?! Correct. You add the fds from libusb to your own set of fds, and you call libusb_handle_events() when poll() returns because of an event on any of the libusb fds. > >> A A Proposition could be that libusb support nice API to > >> distinguish them??: > > > > No, the fd:s from libusb are opaque. > > Could you explain what you mean by opaque? Opaque is the opposite of transparant. In the context of data structures this means that you do not know what is "inside" the data structure. In the case of fds you know that they will be fd numbers, here opaque means that you do not know what any event on any fd means. > > It's a common misunderstanding that devices can communicate with the > > application without them being asked to transfer any data. > > This is not my case, I'm always sending data to the device and then > expecting data from it. The device can anyway *not* send to the application *before* the application asks for data. //Peter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
