Run USB as an idle task instead of a custom FD-based GSource #242
Conversation
| @@ -137,13 +137,17 @@ SR_API GSList *sr_buildinfo_libs_get(void) | |||
| glib_binary_age, glib_interface_age)); | |||
| l = g_slist_append(l, m); | |||
|
|
|||
| #ifdef CONF_ZLIB_VERSION | |||
There was a problem hiding this comment.
These missing ifdefs caused me some issues when building the code, they really should be here
| @@ -874,22 +874,6 @@ static void LIBUSB_CALL receive_transfer(struct libusb_transfer *transfer) | |||
| resubmit_transfer(transfer); | |||
| } | |||
|
|
|||
| static int receive_data(int fd, int revents, void *cb_data) | |||
There was a problem hiding this comment.
With this change, drivers no longer need to implement callbacks if all they are doing is calling libusb_handle_events_timeout(). I tried to update a few of them, but frankly IDK if I have the time & energy to update all of them.
|
Nothing useful to add; I really appreciate your efforts on this and thought it worth mentioning! |
|
Thanks @multiplemonomials for providing a possible solution for this incompatibility. I tried it as well and it seems to work for me at least for sampling rates up to 4MHz with the fx2 driver. For long recording times the chances, that sampling doesn't finish, increases. I assume, that timing of critical USB routines is border line. Keep up the good work and let's keep fingers crossed, that we soon have again a working release of PV on Windows. |
|
Thanks for working on this! Do you consider this change set ready for merging? |
|
I'd really like for someone with understanding of sigrok architecture to comnent on whether this is the "right" way to do it... but it seems like several people have tested it with different hardware and it's worked fine, so that's good. In particular I am worried that blocking the GSource from executing other things could have other bad effects. Do you know if that's a concern? |
|
Not directly related to this PR, but really just a sanity check for me... A colleague and I each have a Kingst LA2016 which are working with the currently nightly branch. I haven't gone through various build histories to see what might have changed (although I did have a quick look at the change log), but it definitely wasn't working the previous time I had tried it (february). |
|
I also had this problem a few months back but it seems to be solved in the nightly build. I am using one of the cheap Saleae clones. |
This PR is my best attempt to restore compatibility with USB devices on Windows. I described my basic approach here in detail. To briefly summarize, this PR sets it up so that the USB event source works as an idle source that continually polls libusb rather than as a custom FD GSource that tries to expose libusb's file descriptors to glib. The file descriptor method is complex and seems like it will probably be a non-starter on Windows (unless one were to go ham and implement another thread that monitors libusb and then exposes semaphores to glib...).
What I can say about this method is that it works, more or less. On my machine, with my fx2lafw based analyzer and sigrok + pulseview built from source in MSYS2:
I don't know exactly why 2MHz is the limit, and am unsure if it's an inherent limitation of the hardware and/or Windows, or if there's something not quite right about my implementation. Also, a bigger potential issue is that, since GLib does not implement any sort of round robin scheduling, and the USB source has a blocking poll method, no other event sources will be able to execute in that SR session's main loop until the USB capture is done. Frankly, I don't know sigrok well enough to know if that's an issue or not -- someone more familiar will have to weigh in.
But, for now, this fix seems like a step in the right direction, at least.