<div dir="ltr"><div dir="ltr">Hi,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 1, 2023 at 4:56 AM ValdikSS via sane-devel <<a href="mailto:sane-devel@alioth-lists.debian.net">sane-devel@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 07.05.2013 00:12, Mike Cloaked wrote:<br>
> I have a strange scanner failure to try to resolve, and I am hoping that <br>
> an expert on this list may be able to help me fix the problem.<br>
> <br>
> I have a Samsung SCX-4500W multifunction printer that is plugged in to <br>
> the usb port of my main machine running arch linux x86_64.  The printer <br>
> part works fine with the Splix driver, but the scanner fails to work.<br>
> <br>
> When I unplug the device and plug it into a laptop running arch linux, <br>
> it works fine. On a second laptop also running arch linux the scanner <br>
> functions also work fine (xsane). However plugging the same device back <br>
> in to my main desktop the scanner fails to work.<br>
> <br>
> <br>
> scanimage -L works the first time I issue the command but then <br>
> subsequently fails:<br>
> <br>
> scanimage -L<br>
> device `xerox_mfp:libusb:001:006' is a Samsung Samsung SCX-4500W Series <br>
> multi-function peripheral<br>
> <br>
> scanimage -L<br>
> <br>
> No scanners were identified.<br>
<br>
Hello. I know this issue is 10 years old, but I fixed it.<br>
It seems that this device has some bugs in USB stack implementation. I <br>
have SCX-4521F with the same issue, it works for me on one laptop with <br>
USB3 port (and only after explicit port reset!) but not on another with <br>
USB2.<br>
<br>
It seems that the device hangs if ENDPOINT HALT CLEAR is performed on <br>
its out endpoint, which is explicitly sent by the backend.<br>
If this command is not sent, the device works reliably.<br>
<br>
<a href="https://gitlab.com/sane-project/backends/-/issues/706" rel="noreferrer" target="_blank">https://gitlab.com/sane-project/backends/-/issues/706</a><br>
<br>
Another workaround is to send CLEAR_TT_BUFFER command to the hub (which <br>
USB3 stack already does).<br></blockquote><div><br></div><div>So, according to commentary in the libusb forum, we have had advice that calling usb_clear_halt() when there is no error condition can leads to all sorts of issues and is not recommended. If we were to remove this in the xerox_mfp backend (which would fix the support of this device), are there any users out there that could test with other supported devices?</div><div><br></div><div>It is possible that it was added in the first place to deal with some problematic devices. Having said that, it might also have been added as a "reset the device to make sure there are no problems", and doesn't actually solve any real world devices. I know that a couple of the other backends do the same thing.<br></div><div><br></div><div>Please let me know if there are any users who would be prepared to test this change!</div><div><br></div><div>I have not heard anything from the backend maintainer for a couple of years so I'm not sure if he is still active,<br></div><div><br></div><div>Cheers,</div><div>Ralph<br></div></div></div>