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

Fri May 10 00:58:07 UTC 2013

(answer at bottom)

On Thu, 9 May 2013, Mike Cloaked wrote:

> On Thu, May 9, 2013 at 8:00 PM, Mike Cloaked <mike.cloaked at gmail.com> wrote:
> 
> As above - printer is hooked up to laptop which is then booted -
> scanning works fine. The printer is not set up on that machine. 
> 
> 
> When I plugged the printer back into the desktop after running the laptop
> test the system log contains:
> 
>  May  9 20:02:00 localhost kernel: [83203.611876] usblp 1-4:1.1: usblp0: USB
> Bidirectional printer dev 13 if 1 alt 0 proto 2 vid 0x04E8 pid 0x342B
> May  9 20:02:00 localhost colord: Device added:
> sysfs-Samsung_Electronics_Co.__Ltd.-SCX-4500W_Series
> May  9 20:02:00 localhost systemd[1]: Starting Printer.
> May  9 20:02:00 localhost systemd[1]: Reached target Printer.
> May  9 20:02:00 localhost systemd[1]: Starting Configure Plugged-In
> Printer...
> May  9 20:02:00 localhost systemd[1]: Started Configure Plugged-In Printer.
> May  9 20:02:00 localhost systemd[1]: configure-printer at usb-001-013.service:
> main process exited, code=exited, status=1/FAILURE
> May  9 20:02:00 localhost systemd[1]: Unit
> configure-printer at usb-001-013.service entered failed state.
> 
> So there is a problem though the printer still works fine when sending pages
> to print.
> 
> --
> mike c
> 
> 

This is weird. The "configuration and setup of the printer allegedly 
fails, but it works?

Anyhow, here is what I get from all this:

1. It is a device permissions problem pretty much like what I was 
envisioning.

2. You say it is not recent, but has happened to others before, and is not 
distro-specific. This would be very much in line with (1).

3. As far as testing is concerned, there is a big difference between the 
laptops and the desktop system. The desktop system is hooked to the 
printer by way of the USB, and the laptops are not configured to see an 
attached USB printer, only a networked printer using CUPS (presumably 
accessing the printer through the desktop system, in that case). So there 
is not any conflict for the laptops. 

Do I have all of this right?

It is an interesting problem and does not have an easy solution. That much 
is obvious. But what you have is the old kernelspace-userspace conflict at 
work yet again. It does tend to play merry hell with dual-mode or 
multi-mode USB devices. We obviously need to think of something to handle 
it. But in case that you are wondering how we got into such a mess, do 
realize one thing: this problem arises because Linux makes a rigid 
separation between kernel stuff and user stuff. That rigid separation is 
part of the security model in Linux, and from that point of view is very 
much the right thing to do. Other operating systems which do not trouble 
themselves about such fine points are well known for the consequences to 
their security, too. Thus nobody wants to abandon the separation because 
to abandon it is to abandon the security model. 

You do mention in one of your posts above the following:

[root at home1 scan-debug]# pacman -Ss libusb
core/libusb-compat 0.1.4-2 [installed]
    Library to enable user space application programs to communicate with
USB devices
core/libusbx 1.0.15-1 [installed]
    Library that provides generic access to USB device
extra/libgusb 0.1.6-1 [installed]
    GLib wrapper around libusb1

My setup is slightly different. I am running Slackware and we have two 
packages. The first one is 

libusb-1.0.9-x86_64-1

and the second one is

libusb-compat-0.1.4-x86_64-1

The description of the second Slackware package contains the following 
information:

PACKAGE NAME:     libusb-compat-0.1.4-x86_64-1
COMPRESSED PACKAGE SIZE:     28K
UNCOMPRESSED PACKAGE SIZE:     100K
PACKAGE LOCATION: ./libusb-compat-0.1.4-x86_64-1.txz
PACKAGE DESCRIPTION:
libusb-compat: libusb-compat (Compatibility library for libusb-0.1 apps)
libusb-compat:
libusb-compat: A compatibility layer allowing applications written for 
libusb-0.
1 to
libusb-compat: work with libusb-1.0.  libusb-compat-0.1 attempts to retain 
as much
libusb-compat: ABI and API compatibility with libusb-0.1 as possible.
libusb-compat:
libusb-compat: Homepage:  http://libusb.org

Thus, my version of libusb probably does contain some bells and whistles 
which yours does not. In particular, the stuff about disabling the kernel 
moduld. 

But in fact I myself believe that these new bells and whistles in libusb 
are a patch job at best, so long as one has to replug the hardware after 
using it in "userspace" mode. We are clearly not out of the woods just by 
doing that, and a better cure is needed. I have heard rumors that libusb 
was also going to go the further step of hooking the kernel module back up 
again after the userspace-supported functionality is terminated and the 
program which is doing it is turned off. But I am not sure whether that 
feature is as yet implemented, or whether it will be (I am obviously not 
an insider on the libusb team, any more than I am an insider at SANE).

So, one partial solution might be to upgrade the libusb. And that will 
probably solve some of your problem, but not all of it.

The problem is quite intractable, in fact. It is a general problem, and I 
am not so clever that I can see which way it ought to be handled. There 
have been some case-by-case solutions, of course. 

One of the similar problems is the USB modems (Some cable modems, in 
particular) which are seen by the computer as a mass storage device. Why 
is that? Because the first thing that has to be done in order to run the 
modem is to load firmware onto it. But then the modem is locked as a USB 
mass storage device. So they had to figure out a way to make the mass 
storage driver to let go.

The other one is the one that I know something about, having done both the 
kernel support and the Gphoto support for certain cheap cameras. This is 
not completely solved. I am not completely convinced that the way to solve 
the problem once and for all is to write into each individual kernel 
driver for each individual affected webcam the code to let it be accessed 
as a stillcam (perhaps creating a /dev/stillcam as well as a /dev/video 
interface, and a lock to prevent either of them from being called while 
the other is active) and then rewriting the relevant parts of libgphoto2 
to hook to the kernel module instead of libusb. Some other people involved 
in linux media support believe so, but I am not totally convinced. I think 
that there has to be a more general solution, because this kind of thing 
happens all the time and will happen more and more often. We need more to 
support multi-mode devices as a class, but how?

One thing which impedes a general solution is the problem of someone 
trying to use the two functions at the same time. Think of what might 
happen, even in your situation, if you are running a print job from the 
desk system and you simultaneously try to scan and the scanning were not 
blocked. Or what if it let you scan and let someone else sitting at the 
laptop to send a print job while the scanning is going on? There has to be 
some kind of blocking mechanism, and it has to work and prevent any bad 
thing from happening. Frankly, it is complicated. Hellishly complicated.

So, I have not solved your problems. I suspect that I can't. But perhaps 
if you can see what the problem is you can help, too. Someone has to come 
up with the bright idea and the clever solution, after all.

Cheers,

Theodore Kilgore