After sr_scpi_source_add() was called, the installed callback is always called with revents=0. A value of G_IO_IN never appears. Setting the timeout to 0 in the sr_scpi_source_add() call results in the callback never being called. This indicates that the event processing is broken somewhere in the USB handling code and data transmission solely relies on timeouts at the moment. Tested using the SCPI backend with yokogawa-dlm (not in repo yet) and rigol-ds.
IIRC, that is because scpi_usbtmc_libusb is currently implemented using libusb synchronous API. It would need to be converted to libusb asynchronous API to generate events on libusb_pollfd. (But if we ever switch to one thread per device, asynchronous API would probably be of no use, so I do not know if it is worth doing)
I think at the moment this is worth doing. Device threads are still a pipedream at this point. Even if we implement them, we won't be able to convert all drivers at once, so initially I expect we will be running a thread with the old asynchronous event loop in it. Full conversion would require an overhaul of the internal SCPI API anyway.