Comment 71 for bug 790183

Revision history for this message
In , anarsoul (anarsoul) wrote :

(In reply to comment #33)
> Sorry to take so long to re-submit the patch,
> I'm not familiar with the lib, so takes some time to study it.
>
> For your questions.
> 1. Because you need to wait for completion of these transfers, but probably
> you don't.
> Actually, we don't have to wait.
> When open the device, it won't continue to next state
> if fpi_imgdev_open_complete() is not be called.
> And we call it at open_loop_complete(), so that makes sure the transfers are
> all done. There is no race condition.

OK, you're right

> 2. Please, no workarounds, let's fix an issue instead.
> Okay, I removed them.
> And this issue is not exist as explanation above.

OK

> 3. I guess it doesn't work on second time, because there's no proper deinit
> sequence and device is still in active state.
> I don't know the deinit commands.
> Arseniy, please give me some advice if you know how to get the deinit
> commands.
> BTW, since we don't have the deinit commands, so we call
> libusb_reset_device() every time when we open the device.
> That will probably reset the device and then it can be init again.

Anyway, I'm OK for libusb_reset_device() here for now, but only if someone will continue to investigate how to deinit device properly.

Out of curiosity, is this device available as a standalone USB device?