hpoj-devel

RE: [hpoj-devel] USB Cold Plug Etc.

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Hi, Allen.

Allen Barnett wrote:
> I cold started my machine this morning and was surprised to 
> see that the
> USB printer.o module was not 'cold plugged' as the machine 
> booted. If I
> pull the USB plug and reinsert it, the printer.o module is 
> loaded OK (by
> /sbin/hotplug?), after which ptal-mlc and ptal-printd can be 
> started OK.
> Is there a patch to the USB printer.c module for the G85 (or similar)
> which can cause it to be loaded at boot time? (There's some 
> info in the
> hotplug README about using the 'usbmodules' command if a module is not
> loading at boot time. Is this the way to go?)
I don't think the problem is in printer.c.  The "hot-plugging" section of
the FAQ page at http://www.linux-usb.org mentions the term "cold-plugging",
which is what you're having a problem with, but I can't find any specific
information about it.  It sounds like you're reading the right information,
though, so run whatever commands you need to in order to make it work.  :-)
I personally avoid the whole mess by insmoding all the necessary modules at
startup.

> I was also wondering what the status of FAXing to and from 
> the PC. Soon?
> Possible?
As far as I know, fax-receive isn't supported in the G or K series firmware,
so it won't be possible to support it in software either (but fax-send is
possible).  I need to finish implementing PML (see below) before I can
implement broader scanning support or faxing/copying support where possible.
I may provide some quick-and-dirty PML scanning/faxing/copying utilities to
help test the PML support and get that functionality working before I start
writing a fancier implementation.

> I was also wondering about the 'Scan To' button on the front 
> panel. Can
> this be programmed?
Theoretically yes, but I'll have to do some research to find out exactly how
to do it.  I do know it involves PML, especially PML traps.

> And yet another dumb question: what are 'PML' and 'MFPDTF' 
> mentioned on
> the TODO page at hpoj.sourceforge.net?
Not a dumb question at all.  I should explain it better on the web.  PML
stands for Peripheral Management Language, and is a datagram request/reply
management protocol similar to SNMP.  xojpanel (currently disabled in CVS)
uses PML to get the contents of the LCD.  Scanning (non-SCL), faxing, and
copying use PML to set various options, like color depth and resolution and
to start/stop the operation.  PML traps are a mechanism for the peripheral
to notify the host when the value of an object changes so the host doesn't
have to constantly poll.  MFPDTF stands for Multi-Function Peripheral Data
Transfer Format and defines a packet format for scan/fax/copy data.  There's
a small amount of information about these topics under the now outdated
documentation section on the web page.  If you're interested I can forward
you some more information provided by HP, with the stipulation that you
can't re-distribute the documents themselves.

David

Re: [hpoj-devel] USB Cold Plug Etc.

[<pa...@rc...>]

Hi, Allen.

Allen Barnett wrote in response to me:
> >  If you're interested I can forward
> > you some more information provided by HP, with the stipulation that you
> > can't re-distribute the documents themselves.
> Sure, I'd like to see them. Is a more formal arrangement necessary?
No, just keep the already-mentioned rules in mind (which didn't come from me).
I'll send the documents out separately.

> With respect to PML traps: Is it necessary that the kernel interface
> support poll()/select()? I had an e-mail exchange with Tim Waugh a while
> ago about the possiblilty of adding this to the line printer (lp)
> device. He said it was trivial to add, but most parallel port devices
> didn't implement the necessary behavior properly. So, I was wondering if
> a poll()/select() interface was necessary (or perhaps I really mean to
> say: optimal), are USB devices more likely to work properly?
ptal-mlcd drives the parallel port directly, bypassing the kernel, so poll()
and select() support is irrelevant.  For USB it does use a /dev/usb/lp*
device driver and relies on select() in that case.  However, there were some
bugs in the select support and reverse (peripheral-to-host) data reading
functionality.  My fixes went into 2.4.2 and will go into 2.2.19, which is
why I indicated those were the minimum supported versions.

The low-level reverse data support is critical to a much greater extent than
just supporting PML traps, which are just data packets going over the PML
channel.  Multiple channels can be open and transferring data in either or
both directions.  The command channel is open all the time to allow data
channels to be opened or closed and to send credits back and forth.  See the
MLC and 1284.4 (http://hpoj.sourceforge.net/links.shtml) specs for more
information.

> FWIW, I recompiled the basic USB driver (usbcore.o) as a module
> instead of having it built into the kernel. The printer module is now
> loaded automatically (along with the drivers for anything else plugged
> in) when hotplug is started. 
I'm glad it's working for you now.  I can see how there could be a problem
because some things are compiled in and others are modular.  I would expect
that it would also work if everything were compiled into the kernel, but
all-modular is more flexible, and that's what I usually prefer for myself.

David

Re: [hpoj-devel] USB Cold Plug Etc.

[Allen B. <ba...@lo...>]

"PASCHAL,DAVID (HP-Roseville,ex1)" wrote:
> > And yet another dumb question: what are 'PML' and 'MFPDTF'
> > mentioned on
> > the TODO page at hpoj.sourceforge.net?
... interesting details deleted ...
>  If you're interested I can forward
> you some more information provided by HP, with the stipulation that you
> can't re-distribute the documents themselves.

Sure, I'd like to see them. Is a more formal arrangement necessary?

With respect to PML traps: Is it necessary that the kernel interface
support poll()/select()? I had an e-mail exchange with Tim Waugh a while
ago about the possiblilty of adding this to the line printer (lp)
device. He said it was trivial to add, but most parallel port devices
didn't implement the necessary behavior properly. So, I was wondering if
a poll()/select() interface was necessary (or perhaps I really mean to
say: optimal), are USB devices more likely to work properly?

Thanks,
Allen

Re: [hpoj-devel] USB Cold Plug Etc.

[Allen B. <ba...@lo...>]

FWIW, I recompiled the basic USB driver (usbcore.o) as a module instead
of having it built into the kernel. The printer module is now loaded
automatically (along with the drivers for anything else plugged in) when
hotplug is started.

Allen

"PASCHAL,DAVID (HP-Roseville,ex1)" wrote:
> Allen Barnett wrote:
> > I cold started my machine this morning and was surprised to see that the
> > USB printer.o module was not 'cold plugged' as the machine booted. If I
> > pull the USB plug and reinsert it, the printer.o module is loaded OK (by
> > /sbin/hotplug?), after which ptal-mlc and ptal-printd can be started OK.
> > Is there a patch to the USB printer.c module for the G85 (or similar)
> > which can cause it to be loaded at boot time? (There's some info in the
> > hotplug README about using the 'usbmodules' command if a module is not
> > loading at boot time. Is this the way to go?)
> I don't think the problem is in printer.c.  The "hot-plugging" section of
> the FAQ page at http://www.linux-usb.org mentions the term "cold-plugging",
> which is what you're having a problem with, but I can't find any specific
> information about it.  It sounds like you're reading the right information,
> though, so run whatever commands you need to in order to make it work.  :-)
> I personally avoid the whole mess by insmoding all the necessary modules at
> startup.
>