hplip setup problems
itz at mushinsky.net
Fri Mar 28 09:17:29 PDT 2008
Yes, of course sleep() works. But I am looking for the *proper* way to fix
My questions at this point are:
1. Does USB standard permit these sequential requests, or there should be
some reset/synch mechanism utilized in between? I could also usb_close() and
reopen the device, but is there a softer reset than that? Is the bug really
in hplip, or libusb, or sys/dev/usb?
2. If the driver, libusb and hplip are acting properly, then perhaps the
race condition is inside the device? i.e. it should be ready to accept the
second control msg after the 1st one returned, but for some reason is not
really ready. So then it is the printer that violates the protocol, and
there is nothing to do on our side but sleep(). Or usb_close(), and reopen,
hopefully that will bring the Photosmart to its senses.
I am posting this to freebsd-usb as well, people there are probably better
equipped to answer this.
On Fri, Mar 28, 2008 at 11:42 AM, Anish Mistry <amistry at am-productions.biz>
> On Friday 28 March 2008, you wrote:
> > On Thursday 27 March 2008 10:37:48 you wrote:
> > > On Thursday 27 March 2008, Isaac Mushinsky wrote:
> > > > Anish Mistry (the port maintainer) has answered below. It seems
> > > > that this is a printer defect after all then. I'll try to patch
> > > > the code to fill in the missing serial id with some fake
> > > > string, and shall report if I get the thing to work.
> > > >
> > > > Is the hp backend the only entry point to libusb, or should I
> > > > have to patch libusb? e.g. cups or sane apps, can they call
> > > > libusb directly, or only through hpaio backend? I would rather
> > > > have a patch to hplip distribution only, because libusb
> > > > correctly throws an error code for the missing serial id. But
> > > > if some apps query the device directly, the missing serial id
> > > > may be a problem, they will all have to all be patched
> > > > separately.
> > >
> > > See what you can get to work, and then we can decide on what the
> > > proper fix entails.
> > >
> > > > > It looks like there is some problem with the C42XX printers
> > > > > that is causing the serial numbers to no be reported. I got
> > > > > a similar report about a HP Photosmart C4200 series a couple
> > > > > weeks ago. Unfortunately I'm VERY busy right now. It will be
> > > > > a couple of week before I can dive into the issue. If you do
> > > > > happen to find a solution, please let me know so I can
> > > > > integrate it into the port and notify others. Thanks,
> > > > > --
> > > > > Anish Mistry
> > > > > amistry at am-productions.biz
> > > > > AM Productions http://am-productions.biz/
> > I tried to load hplip into debugger, but if I try to trace the
> > problem, it works! Serial number is read correctly. It also seems
> > to work with a non-SMP kernel (at least the race does not show).
> > The printer has the serial number after all.
> > There appears to be some sort of race condition when calling
> > usb_control_msg for product id and then serial id strings in rapid
> > succession in musb.c. I am not sure how to deal with that yet, but
> > pausing in between the calls is a workaround for now. What can be
> > done in between the calls other than close and reopen the device?
> You could try to call sleep() to see if that fixes it.
> man 3 sleep
> Anish Mistry
> amistry at am-productions.biz
> AM Productions http://am-productions.biz/
More information about the freebsd-questions