[sane-devel] Help needed diagnosing strange failure to scan with Samsung SCX-4500W

Ralph Little skelband at gmail.com
Mon Oct 2 06:13:55 BST 2023


Hi,

On Sun, Oct 1, 2023 at 4:56 AM ValdikSS via sane-devel <
sane-devel at alioth-lists.debian.net> wrote:

> On 07.05.2013 00:12, Mike Cloaked wrote:
> > I have a strange scanner failure to try to resolve, and I am hoping that
> > an expert on this list may be able to help me fix the problem.
> >
> > I have a Samsung SCX-4500W multifunction printer that is plugged in to
> > the usb port of my main machine running arch linux x86_64.  The printer
> > part works fine with the Splix driver, but the scanner fails to work.
> >
> > When I unplug the device and plug it into a laptop running arch linux,
> > it works fine. On a second laptop also running arch linux the scanner
> > functions also work fine (xsane). However plugging the same device back
> > in to my main desktop the scanner fails to work.
> >
> >
> > scanimage -L works the first time I issue the command but then
> > subsequently fails:
> >
> > scanimage -L
> > device `xerox_mfp:libusb:001:006' is a Samsung Samsung SCX-4500W Series
> > multi-function peripheral
> >
> > scanimage -L
> >
> > No scanners were identified.
>
> Hello. I know this issue is 10 years old, but I fixed it.
> It seems that this device has some bugs in USB stack implementation. I
> have SCX-4521F with the same issue, it works for me on one laptop with
> USB3 port (and only after explicit port reset!) but not on another with
> USB2.
>
> It seems that the device hangs if ENDPOINT HALT CLEAR is performed on
> its out endpoint, which is explicitly sent by the backend.
> If this command is not sent, the device works reliably.
>
> https://gitlab.com/sane-project/backends/-/issues/706
>
> Another workaround is to send CLEAR_TT_BUFFER command to the hub (which
> USB3 stack already does).
>

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?

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.

Please let me know if there are any users who would be prepared to test
this change!

I have not heard anything from the backend maintainer for a couple of years
so I'm not sure if he is still active,

Cheers,
Ralph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20231001/840c4f3a/attachment.htm>


More information about the sane-devel mailing list