(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
