hpoj-devel — HPOJ development/support list

Re: [hpoj-devel] Scaling?

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

Bob Paddock wrote:
> I've been trying for some time now to get some thing printed the same scale 
> on my HP710 as what my screen shows.
> 
> For example if I draw a line with Gimp that is one inch long, I want a one 
> inch long line to come out on the paper.  I realize there are aspect ratio 
> differences and other such minutia when going from screen to printer, I'm 
> going by a simple measured line in this case.
...
> Can some one tell me what part of this printer mess would be mucking about 
> with such things?
It's a result of the lack of coordination and calibration between the
different aspects of the display and printing process, including your
monitor's physical size, display resolution, application, ghostscript,
and printer.

> I'm using cups, with the 550C driver/filter,
I don't know if this will help any, but you could try HP's DJ6xx driver,
available from http://hpinkjet.sourceforge.net.  However, since it involves
patching and recompiling ghostscript, I don't know how easy it will be to
integrate it with CUPS.

> and the latest code for ptal-hp 
> from CVS, Mandrake 8.0.
Actually, ptal-hp is just one part of the hpoj package.

> Any recomendations on how to do What You See Is What You get when dealing 
> with graphics?  Specificily printed circuit board art work.
For that you'll probably want to look into some sort of vector graphics
program such as xfig or KIllustrator, and I'm sure there's a GNOME
equivalent to the latter.  IMO raster graphics programs like GIMP may be
more likely to get you into trouble with scaling.

Mind you, I'm not really into graphic arts myself, so my advice in that area
may not be all that helpful.

David

Re: [hpoj-devel] ptal-mlcd ECP changes

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

Bob Paddock wrote in response to me:
> > It would be helpful to know if ptal-mlcd reported any error messages,
> > because chances are that something went wrong at that level.
> 
> Where do I look for those at?  Didn't think the syslog stuff was implimented 
> yet?
Hi, Bob.  If you start ptal-mlcd during your machine's startup sequence,
then ptal-mlcd's messages might be on one of the text-mode consoles.  If you
start ptal-mlcd in a terminal window under X (as I do for development and
testing), then they would be in that window.

Note that as of yesterday's CVS code, ptal-mlcd and ptal-printd both log to
syslog as well as to standard output (whatever that may be).

> CUPS seems to be beast all its own.  Its what I'm use to, is there some thing 
> better out there?
Since I'm not very familiar with CUPS, I don't know if it's better than its
alternatives (plain old lpr/lpd, LPRng, and who knows what else).

David

Re: [hpoj-devel] ptal-mlcd ECP changes

[Bob P. <bpa...@cs...>]

> Bob Paddock wrote:
> > Second scan at -300 came out ok, but it took about 3 minutes to scan it,
> > it was a black and white page, but it was probably still scanned as color
> > since I did change any thing besides adding the -300.
> >
> > I loaded up the out.jpg image with KView then my machine started going so
> > slow it was useless, the mouse moved in great leaps and lunges.  Had to
> > cycle power.  Don't know if this is in any way related to scanning, for
> > the moment lets assume that it was not.  The scan did look fine.
>
> A 300dpi JPEG image requires lots of RAM to process, because I think
> libjpeg insists on decompressing it into RAM.  A high resolution setting
> like 300dpi is overkill for most situations.

I tried 300dpi as the OCR software I use seems to prefer it.

> > Third scan of b&w page in color with the defaults got me:
> > patlChannelRead returns 0!
> > Broken Pipe.
>
> It would be helpful to know if ptal-mlcd reported any error messages,
> because chances are that something went wrong at that level.

Where do I look for those at?  Didn't think the syslog stuff was implimented 
yet?

> > All pages looked like there where twice as long as they should have been
> > when viewing out.jpg in the viewer.  Last half was a blank gray looking
> > thing, probably scanned the color of the unit it self.
>
> That's a known issue (mentioned briefly in SCAN-HOWTO and in the "Bugs and
> TODO" list on the web) 

Yes I did see that, just wanted to be thorow in my report.

> I added an item on the TODO list to work on this before I release 0.8.
> For now, you could try writing a script that calls ptal-hp in a loop.  I
> neglected to document that ptal-hp has different exit codes depending on
> whether the scan was successful and there are (1) or aren't (0) more pages
> to scan.

Thank you.

> >
> > HPOJ:
> >
> > just those five chars.
>
> That's really bizarre.  I guess CUPS has different methods of configuring
> print queues, 

CUPS seems to be beast all its own.  Its what I'm use to, is there some thing 
better out there?

> fails, you can just invoke something like "lpr filename.ps" from a shell
> prompt (or whatever the CUPS equivalent is to lpr).

lpr-cups.

[hpoj-devel] tonight's code changes

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

Hi,

Here's a rundown of the major code changes tonight (it's still night for me,
anyway:-):

1. ptal-mlcd and ptal-printd should now work properly from a hotplug script,
despite the lack of stdin/stdout/stderr file descriptors.

2. ptal-mlcd and ptal-printd now log to syslog in addition to standard output
or standard error, respectively.

3. ptal-printd should be more immune to ptal-mlcd hiccups (such as device
unplugs); previously it could exit due to a "broken pipe" signal.

4. ptal-mlcd will now refuse to start if another instance of ptal-mlcd is
already running using the same PTAL device name (socket).

5. The configure script should now detect QT as installed on Debian systems
(/usr/bin, /usr/lib, and /usr/include/qt).

Allen, #1 through #4 apply especially to you since you use hotplug scripts.
Would you please verify for me that #1 is fixed properly, without having to
use the earlier "</dev/null" workaround?

Obi-Wan, since you reported problem #5 above, would you please verify that
the new configure script properly detects QT on your system, after removing
your earlier tree-of-symlinks workaround?

Of course, even though I asked specific people to verify some of the above
changes, I always welcome breakage reports from anybody.  :-)

David

Re: [hpoj-devel] Comments on parallel performance, questions on USB

[Tim W. <tw...@re...>]

On Sun, May 06, 2001 at 02:08:40PM -0400, rj...@wo... wrote:

> The 2.4 kernel (and 2.2 backports) provide the "ppdev" module for
> implementing customized protocols like 1284.4 in usermode
> applications.  It provides basic building blocks like "negotiate" via
> ioctl()s.  It provides efficient I/O transfer through the ioctl()
> modes and the read()/write() transfers.  I've built customized
> protocols using ppdev and gotten over 350KB/sec transfer rates without
> any special effort.

FWIW, libieee1284 is an attempt to make ppdev easy to use, as well as
falling back to other methods if ppdev isn't available.

Tim.
*/

Re: [hpoj-devel] ptal-mlcd ECP changes

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

Joe Piolunek wrote:
> The messages look slightly familiar, but I don't think they have appeared 
> recently. I seem to recall seeing "exClose" appear at stdout. It may have 
> happened only a couple of times.
exClose() is the function that gets called whenever something goes wrong in
the communication with the peripheral.

> Nothing like it is in /var/log/messages.
Nothing will show up there because currently ptal-mlcd doesn't use syslog.
I plan to change that eventually.


Bob Paddock wrote:
> Second scan at -300 came out ok, but it took about 3 minutes to scan it, it 
> was a black and white page, but it was probably still scanned as color since 
> I did change any thing besides adding the -300.
> 
> I loaded up the out.jpg image with KView then my machine started going so 
> slow it was useless, the mouse moved in great leaps and lunges.  Had to cycle 
> power.  Don't know if this is in any way related to scanning, for the moment 
> lets assume that it was not.  The scan did look fine.
A 300dpi JPEG image requires lots of RAM to process, because I think libjpeg
insists on decompressing it into RAM.  A high resolution setting like 300dpi
is overkill for most situations.

> Third scan of b&w page in color with the defaults got me:
> patlChannelRead returns 0!
> Broken Pipe.
It would be helpful to know if ptal-mlcd reported any error messages, because
chances are that something went wrong at that level.

> All pages looked like there where twice as long as they should have been when 
> viewing out.jpg in the viewer.  Last half was a blank gray looking thing, 
> probably scanned the color of the unit it self.
That's a known issue (mentioned briefly in SCAN-HOWTO and in the "Bugs and
TODO" list on the web) with certain models, including yours, where the
device doesn't report the image length.  For now, I put in a kludge where
the length equals twice the width, until I can figure out how to parse the
JPEG-compressed data just enough to count the lines so I can write it into
the JPEG header.  That's why you see the large gray area.

> What I could not figure out how to make it do was scan all of the loaded 
> pages?  Having a autofeed scanner is kind-of useless if you have to manually 
> intervene for each page.  Same complaint I have about the HP710 standard 
> windows software (I would not have bought the thing had I known that up 
> front).
I added an item on the TODO list to work on this before I release 0.8.
For now, you could try writing a script that calls ptal-hp in a loop.  I
neglected to document that ptal-hp has different exit codes depending on
whether the scan was successful and there are (1) or aren't (0) more pages
to scan.  I haven't actually tested this, however, so this functionality
will depend on whether each device properly reports whether a new page is
available.  Also, 2 means that there was no page to begin with, 3 means
command-line syntax error, and 4 means some sort of miscellaneous device
error.

> I do have (x)sane 1.0.4/0.76 loaded on here if you want any thing tested.  I 
> use it with my Epson scanner all of the time.
Currently SANE doesn't support your model.  "ptal-hp scan" is a temporary
scanning solution until I can get around to developing a proper SANE backend
that properly supports all of the models.

> This is my printcap file in its entirety:
> 
> HPOJ:
> 
> just those five chars.
That's really bizarre.  I guess CUPS has different methods of configuring
print queues, and this file only exists for compatibility with programs
that read it to try to find out what print queues are available.  Perhaps
the programs that you had trouble with printing got confused by this
minimalist format, and in the interest of "ease-of-use" and hiding complexity
from the user, neglected to provide a more generic way to print.  (I'm just
guessing here, mind you.)

Most Unix programs print by generating PostScript and sending it to the print
spooler.  Often they have some sort of option to save the PostScript to a
file without actually printing it right away.  That way, if all else fails,
you can just invoke something like "lpr filename.ps" from a shell prompt (or
whatever the CUPS equivalent is to lpr).  I frequently "print to a file"
just so I can inspect the output in ghostview before actually printing.

David

[hpoj-devel] Scaling?

[Bob P. <bpa...@cs...>]

I've been trying for some time now to get some thing printed the same scale 
on my HP710 as what my screen shows.

For example if I draw a line with Gimp that is one inch long, I want a one 
inch long line to come out on the paper.  I realize there are aspect ratio 
differences and other such minutia when going from screen to printer, I'm 
going by a simple measured line in this case.

I've tried every thing short of writing raw postscript by hand, and several 
programs, but it seems like what comes out on the paper is always smaller by 
about five to ten percent.

Can some one tell me what part of this printer mess would be mucking about 
with such things?

I'm using cups, with the 550C driver/filter, and the latest code for ptal-hp 
from CVS, Mandrake 8.0.

Any recomendations on how to do What You See Is What You get when dealing 
with graphics?  Specificily printed circuit board art work.

Re: [hpoj-devel] ptal-mlcd ECP changes

[Bob P. <bpa...@cs...>]

> Bob Paddock wrote:
> > I've got a OJ710, on the LPT1 parallel port.  I was under the impression
> > that scanning didn't work yet so I never even tried.  What do you want me
> > to try?
>
> First run "cvs update" from the top-level hpoj directory to ensure you have
> the latest code and documentation, and rebuild if necessary.  SCAN-HOWTO
> should cover what you need to know for scanning.  In your case, you'll want
> to follow the "ptal-hp" section at the end, rather than the SANE section at
> the beginning.

I started with a fresh checkout/build rather than the update.

First scan was a color page, the printer test page that I had made not long 
ago.  Came out fine.  Used the defaults.

Second scan at -300 came out ok, but it took about 3 minutes to scan it, it 
was a black and white page, but it was probably still scanned as color since 
I did change any thing besides adding the -300.

I loaded up the out.jpg image with KView then my machine started going so 
slow it was useless, the mouse moved in great leaps and lunges.  Had to cycle 
power.  Don't know if this is in any way related to scanning, for the moment 
lets assume that it was not.  The scan did look fine.

Third scan of b&w page in color with the defaults got me:
patlChannelRead returns 0!
Broken Pipe.

Scanned next page with no problem.

All pages looked like there where twice as long as they should have been when 
viewing out.jpg in the viewer.  Last half was a blank gray looking thing, 
probably scanned the color of the unit it self.

What I could not figure out how to make it do was scan all of the loaded 
pages?  Having a autofeed scanner is kind-of useless if you have to manually 
intervene for each page.  Same complaint I have about the HP710 standard 
windows software (I would not have bought the thing had I known that up 
front).

I do have (x)sane 1.0.4/0.76 loaded on here if you want any thing tested.  I 
use it with my Epson scanner all of the time.

> > Printing has been working fine for me.
> >
> > I just get confused at times because one program refers to the print que
> > as 'lpr', one as 'hpoj', one as 'default printer'.  Use the wrong one
> > with the wrong program and you get nothing printed.  Nothing really to do
> > with th OJ drivers per'se.  Linux could learn a lot from windows in this
> > area...
>
> When you say "program", are you referring to various application programs
> you're trying to print from?

Yes.

Ran in to a new one just after I posted that message last night.  To get Gimp 
to print I had to put in 'lpr-cups', so that gets me to:

lpr
lpr-cups
"default printer"
hpoj

for four different application programs.  A couple of other programs I just 
gave up on and switched to windows to print stuff because I was in a hurry 
and could not figure out the right magic words.


> and the default printer (if no "-P<queue>" is
> specified) is normally the first entry in /etc/printcap.  (I realize this
> isn't very intuitive.)

This is my printcap file in its entirety:

HPOJ:

just those five chars.

Re: [hpoj-devel] ptal-mlcd ECP changes

[Joe P. <joe...@sn...>]

On Saturday 02 June 2001 07:22 pm, David Paschal wrote:
<...>
> Sorry, I should have been more specific about the problem I was fixing,
> which involved getting the following error messages from ptal-mlcd:
>
> lookupChannel(port=0,psid=4,ssid=4): invalid!
> sendError(port=0,MLC): error=0x07.
> reverseDataReceived(pBdr=0x08068DC0): null TCD!
> exClose(reason=0x3007)
>

The messages look slightly familiar, but I don't think they have appeared 
recently. I seem to recall seeing "exClose" appear at stdout. It may have 
happened only a couple of times. Nothing like it is in /var/log/messages.

-- 
Joe

Re: [hpoj-devel] ptal-mlcd ECP changes

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

Joe Piolunek wrote:
> While testing the new CVS today, my 600 locked up occasionally with the 
> "SYSTEM ERROR2252" message displayed. One time ( that I noticed) ptal-hp 
> returned this message: "ptalChannelRead returns 0! Broken pipe". All of the 
> lockups ( 3 times today ) happened while scanning at -res 150. That may be 
> because I made more scan attempts at that resolution. In total I made about 
> 35 scans, at least 5 at each resolution that the 600 supports.
Sorry, I should have been more specific about the problem I was fixing, which
involved getting the following error messages from ptal-mlcd:

lookupChannel(port=0,psid=4,ssid=4): invalid!
sendError(port=0,MLC): error=0x07.
reverseDataReceived(pBdr=0x08068DC0): null TCD!
exClose(reason=0x3007)

I still need to look into those "system errors".

Bob Paddock wrote:
> I've got a OJ710, on the LPT1 parallel port.  I was under the impression that 
> scanning didn't work yet so I never even tried.  What do you want me to try?
First run "cvs update" from the top-level hpoj directory to ensure you have
the latest code and documentation, and rebuild if necessary.  SCAN-HOWTO
should cover what you need to know for scanning.  In your case, you'll want
to follow the "ptal-hp" section at the end, rather than the SANE section at
the beginning.

> Printing has been working fine for me. 
> 
> I just get confused at times because one program refers to the print que as 
> 'lpr', one as 'hpoj', one as 'default printer'.  Use the wrong one with the 
> wrong program and you get nothing printed.  Nothing really to do with th OJ 
> drivers per'se.  Linux could learn a lot from windows in this area...
When you say "program", are you referring to various application programs
you're trying to print from?  lpr is the command used to print something
from the shell command line, and some applications force you to compose
your own lpr line in their "print" dialog box.  The queue name (lpr "-P"
switch) is up to you, and the default printer (if no "-P<queue>" is
specified) is normally the first entry in /etc/printcap.  (I realize this
isn't very intuitive.)

David

Re: [hpoj-devel] T45 printing problem, missing modules?

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

Malcolm Mallardi wrote:
> My suspicion is: in my hpoj source tree (gleaned from the sourceforge 
> CVS server) has the ieee12844/ subdirectory, but the only contents are 
> the CVS/ subtree.  My experiance with previous versions (I've been 
> following the project off and on since 0.4) has been that there was 
> sourcecode for a pair of kernel modules there.  Could it be that the CVS 
> server is not distributing them properly?  I suspect that my problem may 
> be stemming from this.

Hi, Malcolm.  The "ieee12844" directory no longer exists in CVS.  The
kernel-mode drivers were replaced with the "ptal-mlcd" user-mode driver
after 0.7.  See the INSTALL file for more information.  You can use the
"cvs update -P" (capital "P" for "prune") command in the hpoj directory
to remove empty directories like this and ensure you have the latest code.

I should also point out to you that scanning is now supported with the
"ptal-hp" command in CVS; see SCAN-HOWTO for more information.

David

Re: [hpoj-devel] ptal-mlcd ECP changes

[Bob P. <bpa...@cs...>]

> I made some changes to ptal-mlcd affecting which IEEE1284 (parallel) modes
> are now used for communicating with certain OfficeJets:
> 1. 500, 600, PSC300, 700, T series: bounded ECP mode forward and reverse,

> A while back I asked if anybody else had seen this problem, and IIRC nobody
> responded except for Joe Piolunek, saying he had never seen it.

> #2 should hopefully make ptal-mlcd work reliably(?) with these older
> models, although I won't officially consider them supported unless people
> who have them help test the CVS code and let me know how well it works.

I've got a OJ710, on the LPT1 parallel port.  I was under the impression that 
scanning didn't work yet so I never even tried.  What do you want me to try?

Printing has been working fine for me. 

I just get confused at times because one program refers to the print que as 
'lpr', one as 'hpoj', one as 'default printer'.  Use the wrong one with the 
wrong program and you get nothing printed.  Nothing really to do with th OJ 
drivers per'se.  Linux could learn a lot from windows in this area...

Re: [hpoj-devel] ptal-mlcd ECP changes

[Joe P. <joe...@sn...>]

On Saturday 02 June 2001 06:20 am, David Paschal wrote:
> Hi,
>
> I made some changes to ptal-mlcd affecting which IEEE1284 (parallel) modes
> are now used for communicating with certain OfficeJets:
> 1. 500, 600, PSC300, 700, T series: bounded ECP mode forward and reverse,
> 2. C2890A, LX, 300 series: regular ECP mode forward, nibble mode reverse.
>
> #1 should fix fairly repeatable ptal-hp scan failures I saw, where the
> scan aborted in the middle and ptal-hp exited with a "Broken pipe" error.
> A while back I asked if anybody else had seen this problem, and IIRC nobody
> responded except for Joe Piolunek, saying he had never seen it.

While testing the new CVS today, my 600 locked up occasionally with the 
"SYSTEM ERROR2252" message displayed. One time ( that I noticed) ptal-hp 
returned this message: "ptalChannelRead returns 0! Broken pipe". All of the 
lockups ( 3 times today ) happened while scanning at -res 150. That may be 
because I made more scan attempts at that resolution. In total I made about 
35 scans, at least 5 at each resolution that the 600 supports.

-- 
Joe

[hpoj-devel] T45 printing problem, missing modules?

[Malcolm M. <ma...@mi...>]

Heyla, Folks.  I've been trying to get my OfficeJet T45 to print in 
Linux for a while, and have always had a little trouble configuring the 
drivers.

Here's my setup at the moment:

Slackware Linux 7.1
kernel 2.4.5
qt 1.45
XFree86 4.0.3
hpoj CVS package
My T45 is supposedly on /dev/lp0
I ran ptal-printd with the options of mlc:par:0 -like /dev/lp0 and
I've run the apsfilter setup program, and set up all the printcap 
entries to use it, at the deskjet 550 drivers as stated in the PRINT-HOWTO.

The problem I have is that whenever I attempt to print, ptal-printd 
returns an error:

ptalMlcConnect(dev=par:0): error connecting socket, errno=2!
ptalChannelOpen(chan=0x0804A4F8): provider failed open!


My suspicion is: in my hpoj source tree (gleaned from the sourceforge 
CVS server) has the ieee12844/ subdirectory, but the only contents are 
the CVS/ subtree.  My experiance with previous versions (I've been 
following the project off and on since 0.4) has been that there was 
sourcecode for a pair of kernel modules there.  Could it be that the CVS 
server is not distributing them properly?  I suspect that my problem may 
be stemming from this.
-- 
Malcolm D. Mallardi - Dark Freak At Large
"Lose all confidence, at your expense, your courage swallowed up!"
AOL: Nuark  UIN: 11084092 Y!: Magamo Jabber: Nu...@ja...
http://ranka.2y.net/~magamo/index.htm

[hpoj-devel] ptal-mlcd ECP changes

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

Hi,

I made some changes to ptal-mlcd affecting which IEEE1284 (parallel) modes
are now used for communicating with certain OfficeJets:
1. 500, 600, PSC300, 700, T series: bounded ECP mode forward and reverse,
2. C2890A, LX, 300 series: regular ECP mode forward, nibble mode reverse.

#1 should fix fairly repeatable ptal-hp scan failures I saw, where the
scan aborted in the middle and ptal-hp exited with a "Broken pipe" error.
A while back I asked if anybody else had seen this problem, and IIRC nobody
responded except for Joe Piolunek, saying he had never seen it.

#2 should hopefully make ptal-mlcd work reliably(?) with these older models,
although I won't officially consider them supported unless people who have
them help test the CVS code and let me know how well it works.

On a related note, ptal-mlcd now displays a warning message when it detects
a parallel port that isn't configured for ECP or bidirectional capability.
Hopefully that will take a lot of the guesswork out of troubleshooting a
relatively frequent source of problems with ptal-mlcd.  This warning is
suppressed if the "-porttype spp" switch is given.

David

RE: [hpoj-devel] ptal-mlcd and hotplug scripts

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

Allen Barnett wrote:
> I "fixed" this problem by commenting the 'checkpc' command out of the
> lpd init script. There's definitely a race condition between the
> execution of the runlevel init scripts and the startup of the 
> kernel USB
> hub daemon and the subsequent execution of hotplug scripts; the kernel
> printer module may not even be loaded when the lpr init 
> script executes.
That's one way to fix the problem, but I don't want to require users to
perform that level of hacking to get things to work.

> So, starting and stopping ptal-printd should probably be the
> responsibility of the printing system, not the hotplugging system. Can
> one ptal-printd process tolerate the stopping and restarting of
> ptal-mlcd?
I think it can as long as it doesn't have an open connection to ptal-mlcd.
If it does then it will probably die from a broken-pipe signal when it tries
to write more data to the socket.  Thanks for asking this question and
making me realize this problem, which is now on my TODO list to fix.

> OTOH, how about adding the ability of ptal-mlcd to execute a 
> script when
> it starts and stops? It  could start and stop ptal-printd and 
> enable and
> disable print queues and so on. 
I thought about that, but dynamically creating and deleting print queues
could prove to be rather difficult, given the variety of print systems out
there.  One possibility would be to have "template" queues, where the device
node is set to /dev/null and an indication its target device (PTAL device
name or USB vendor/product IDs) could be encoded into the queue name.
ptal-mlcd could invoke a sub-hotplug script that would start ptal-printd and
then copy the template queue into an actual queue for that device.  Unplug
might not be as reliable, though, because ptal-mlcd could crash or be killed
without having a chance to run the "shutdown" script (which would somehow
kill ptal-printd and remove the hotplugged-device queue).  Another problem
with this scheme is that lpd (or whatever) would probably need to be
restarted after mucking around with /etc/printcap, and this might upset a
pending print job on another queue.  An init script would also need to be
run at startup before LPRng in case the system crashed and there are
leftover hotplug queues.  So in any case, I think there are a lot of holes
that would need to be plugged in this scheme before it's feasible.

David

RE: [hpoj-devel] hi

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

Paresh Patel wrote:
> I have deployed a linux based kiosk with netscape browser. Since this
> kiosk is to be used for
> public access and also user can printout certain information.
> The problem is how do i avoid the pop dialogue box of netscape browser
> popping up when i give the print comand. Which is basically 
> the standard
> dialog box asking for the nos of pages to printed , nos of copies etc.
>  I need to avoid this dilog box since i dont want any one to fire
> multiple copies.
> so can i some how eliminate or hide thios box and directly 
> the neter or
> the ok commnd is activated and by default  parametrs in the box are
> taken which is only 1 copies

Hi, Paresh.  This is more of a Netscape issue than an OfficeJet issue.  I
don't know offhand of a way to disable the print dialog box, but I seem to
recall that Netscape used to provide some sort of customization kit for
sites that wanted to lock down their browser interface, for example to
prevent entry of arbitrary URLs.  You could try searching around on
http://www.netscape.com to see if they still offer this kit, but in any
case, you could always just hack the source code to Mozilla
(http://www.mozilla.org), the open-source descendant of Netscape.

David

Re: [hpoj-devel] ptal-mlcd and hotplug scripts

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

"PASCHAL,DAVID (HP-Roseville,ex1)" wrote:
> 
> Hi, Allen.
> 
> Allen Barnett wrote:
> > Would it be possible for ptal-printd to
> > receive notification from ptal-mlcd that ptal-mlcd is shutting itself
> > down?
> That's a bit of a problem.  From what I've heard, systems running LPRng hang
> unless ptal-printd is running at startup.

I "fixed" this problem by commenting the 'checkpc' command out of the
lpd init script. There's definitely a race condition between the
execution of the runlevel init scripts and the startup of the kernel USB
hub daemon and the subsequent execution of hotplug scripts; the kernel
printer module may not even be loaded when the lpr init script executes.

>  One solution may be to:
> - run ptal-printd from an init script (before LPRng is initialized),
> - load ptal-mlcd from a hotplug script (if not from an init script), and
> - use a descriptive PTAL device name like mlc:usb:hpojg85 instead of the
> uncreative mlc:usb:X that I typically use that corresponds to the
> /dev/usb/lpX in use.

OK. I didn't realize that 'X' was arbitrary.

So, starting and stopping ptal-printd should probably be the
responsibility of the printing system, not the hotplugging system. Can
one ptal-printd process tolerate the stopping and restarting of
ptal-mlcd?

OTOH, how about adding the ability of ptal-mlcd to execute a script when
it starts and stops? It  could start and stop ptal-printd and enable and
disable print queues and so on. 

Thanks,
Allen

[hpoj-devel] hi

[Mr. P. P. <com...@bo...>]

I have deployed a linux based kiosk with netscape browser. Since this
kiosk is to be used for
public access and also user can printout certain information.
The problem is how do i avoid the pop dialogue box of netscape browser
popping up when i give the print comand. Which is basically the standard
dialog box asking for the nos of pages to printed , nos of copies etc.
 I need to avoid this dilog box since i dont want any one to fire
multiple copies.
so can i some how eliminate or hide thios box and directly the neter or
the ok commnd is activated and by default  parametrs in the box are
taken which is only 1 copies


Regards
Paresh

Re: [hpoj-devel] hpo bug (sane 1.0.4)

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

Ben "Obi-Wan" Hollingsworth wrote:
> I did make a fresh reboot of my system & the PSC500 earlier this evening
> (before I read your message about checking the BIOS).  Without checking
> anything, I printed a few pages & it worked fine.  No errors in my stdout
> logs.  I brought up xsane to test that.  Grabbing a preview worked, but
> was dreadfully slow.  Note that I'm on a P90 & at the same time I was
> listening to a RealAudio station & actively web browsing.  Still, it
> seemed slower than it should have been.  Attempting to scan a color image
> to disk at 150 dpi cranked away for a good long while, then flagged an
> xsane error window (something related to opening the output file)
...
> The stdout log then got gobs of output, which I've included below.
...
> ptal-mlcd: ERROR at ParPort.cpp:163, dev=<par:psc500>, pid=139, errno=11
> statusWaitSetClear(event=23) timed out!
> 
> ptal-mlcd: ERROR at ExMgr.cpp:2131, dev=<par:psc500>, pid=139, errno=11
> llioService: llioForwardToReverse failed!
...
> ParPort:
> portType=1
...
> forwardMode=0x10
> reverseMode=0x00

Hi, Ben.  Based on the above excerpts of your error log, I can tell that
your parallel port is not set to ECP or bidirectional ("BPP" or "PS/2").
Try it again once you get a chance to reboot and change the BIOS setting.
For now I don't think it will be necessary to mess with the debug console.
This exact same failure on the PSC 500 has been reported to me before, and
it was fixed by enabing bidirectional ECP signaling, which requires a
parallel port setting of ECP or BPP.  This should also improve the speed
somewhat, with further speed improvements on my long-term TODO list.

David

Re: [hpoj-devel] hpo bug (sane 1.0.4)

[Obi-Wan <bv...@in...>]

>> and this in the ptal-mlcd log file:
>> 
>> ---------
>>    ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, 
>> dev=<par:psc500> , pid=12720, errno=11
>>    Reply timer popped on port=0, count=1!
>> 
>>    ptal-mlcd: ERROR at ExMgr.cpp:872, dev=<par:psc500> , 
>> pid=12720, errno=11
>>    exClose(reason=0x3002)
>
> That's not good.  :-)  Occasionally I've managed to get the R series and PSC
> 500 into a bad state, where the LCD scrolls the message "turn the power off
> and back on again".  I wonder if that's what happened here?  But in that
> case I would have expected a different error.  Anyway, I'm just thinking
> aloud here.

LCD looked fine when I got home.

> Another thing that comes to mind is to make sure that your parallel port is
> configured in your BIOS setup for preferably ECP, or PS/2 (aka BPP)
> otherwise, but not EPP.  Also, make sure you're using a good parallel cable
> and that the device is connected directly to your computer without any
> switchboxes or other pass-through devices, such as Zip drives.

Good cable.  No pass-through devices.  I'll check the BIOS next time
the system is down.

> Here's another thing you can try, but probably not until you get home and
> make sure the device is in a good state.  Add the "-nofork" switch to
> ptal-mlcd, and it will give you a debug console.  Use the "log" command to
> enable debug logging ("nolog" turns off the debug messages).  Then use the
> "activate" command to make it start trying to talk to the peripheral.  When
> the messages stop spewing, use the "dump" command, which displays the state
> of the internal data structures.  Wait about 20 seconds to see if you get
> the "reply timer popped" message.  If that doesn't happen, then in another
> window try ptal-devid (this should work if you've gotten this far).  After
> this point try printing and scanning (separately) and see what happens.  You
> can press control-C to kill ptal-mlcd.

On my list...

I did make a fresh reboot of my system & the PSC500 earlier this evening
(before I read your message about checking the BIOS).  Without checking
anything, I printed a few pages & it worked fine.  No errors in my stdout
logs.  I brought up xsane to test that.  Grabbing a preview worked, but
was dreadfully slow.  Note that I'm on a P90 & at the same time I was
listening to a RealAudio station & actively web browsing.  Still, it
seemed slower than it should have been.  Attempting to scan a color image
to disk at 150 dpi cranked away for a good long while, then flagged an
xsane error window (something related to opening the output file), and
the shell said this:

   > xsane
   ptalChannelOpen(chan=0x080E6500): provider failed open!
   ptalMlcChannelOpen(chan=0x080E6500): read(openReply) returns 0!
   ptalChannelOpen(chan=0x080E6500): provider failed open!

The stdout log then got gobs of output, which I've included below.

-- 
Ben "Obi-Wan" Hollingsworth                             ob...@je...
   The stuff of earth competes for the allegiance I owe only to the
     Giver of all good things, so if I stand, let me stand on the
       promise that You will pull me through.  -- Rich Mullins
------------------------- Achilles tendon - cut here -------------------------

ptal-mlcd: ERROR at ParPort.cpp:163, dev=<par:psc500>, pid=139, errno=11
statusWaitSetClear(event=23) timed out!

ptal-mlcd: ERROR at ExMgr.cpp:2131, dev=<par:psc500>, pid=139, errno=11
llioService: llioForwardToReverse failed!

ptal-mlcd: ERROR at ExMgr.cpp:872, dev=<par:psc500>, pid=139, errno=11
exClose(reason=0x0010)

ptal-mlcd: ERROR at ParPort.cpp:163, dev=<par:psc500>, pid=139, errno=11
statusWaitSetClear(event=23) timed out!

ptal-mlcd: ERROR at ExMgr.cpp:2131, dev=<par:psc500>, pid=139, errno=11
llioService: llioReverseToForward failed!

ptal-mlcd: ERROR at ExMgr.cpp:872, dev=<par:psc500>, pid=139, errno=11
exClose(reason=0x0010)

ptal-mlcd: ERROR at transport/ExMlcTransport.cpp:1059, dev=<par:psc500>, pid=139, errno=11
reverseDataReceived_ts(port=0,channel=2): not open!

ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:1632, dev=<par:psc500>, pid=139, errno=11
sendError(port=0,MLC): error=0x07.

ptal-mlcd: ERROR at ExMgr.cpp:872, dev=<par:psc500>, pid=139, errno=11
exClose(reason=0x3007)

ptal-mlcd: ERROR at transport/ExMlcTransport.cpp:1059, dev=<par:psc500>, pid=139, errno=11
reverseDataReceived_ts(port=0,channel=2): not open!

ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:1632, dev=<par:psc500>, pid=139, errno=11
sendError(port=0,MLC): error=0x07.

ptal-mlcd: ERROR at ExMgr.cpp:872, dev=<par:psc500>, pid=139, errno=11
exClose(reason=0x3007)

ptal-mlcd: ERROR at transport/ExMlcTransport.cpp:1059, dev=<par:psc500>, pid=139, errno=11
reverseDataReceived_ts(port=0,channel=2): not open!

ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:1632, dev=<par:psc500>, pid=139, errno=11
sendError(port=0,MLC): error=0x07.

ptal-mlcd: ERROR at ExMgr.cpp:872, dev=<par:psc500>, pid=139, errno=11
exClose(reason=0x3007)

ptal-mlcd: ERROR at transport/ExMlcTransport.cpp:1621, dev=<par:psc500>, pid=139, errno=11
handleInitReply(port=0): ignoring extra InitReply!

ptal-mlcd: ERROR at transport/ExMlcTransport.cpp:1621, dev=<par:psc500>, pid=139, errno=11
handleInitReply(port=0): ignoring extra InitReply!

ptal-mlcd: ERROR at transport/ExMlcTransport.cpp:1621, dev=<par:psc500>, pid=139, errno=11
handleInitReply(port=0): ignoring extra InitReply!




************************************************
************************************************
************************************************





ExMgr:
gDebugFlag=0
pBufferPool: available#=10, size=4102, requested#=230, allocated#=12
initialized=1
nofork=0
activateAtStartup=0
argc=0
fd=3: r=1, w=0, x=0
fd=6: r=1, w=0, x=0
fdCount=7
exState=2
exActivateCount=6
exCloseCount=5
exCloseReason=0x3007
exReactivateFlag=0
noDot4=0
enablePmlMultiplexing=1
sleepBeforeOpen=0
tryDot4=0
tryMlc=1
miser=0
pFreeMsgPool: depth=2
pPendingMsgQueue: depth=0
pActiveTimerQueue: depth=1
pPeriodicTimerQueue: depth=1
select timeout: sec=0, usec=50000, infinite=0
consoleAllowRemote=0
consoleOldStdin=4
consoleOldStdout=5
consoleIsRemote=0
socketSuffix=<par:psc500>
socketAliasSuffix=<mlcpp0>
socketName=</dev/ptal-mlcd/par:psc500>
socketAliasName=</dev/ptal-mlcd/mlcpp0>
socketFd=3
pmlTransportSession=8
pmlCurrentSession=-1
pmlLastSession=31
sessionInWrite=0
llioName=<>
llioOverrideDeviceID=<>
llioFd=-1
llioDummyFd=-1
llioPollState=0
llioLastHitTime=991380275
llioForwardBdrQueue: depth=0
llioDeviceID=<MFG:HEWLETT-PACKARD;MDL:PSC 500;CMD:MLC,PCL,PML,SCL;CLS:PRINTER;DES:Hewlett-Packard PSC 500;CMT:OFFICEJET PRO;SERN:SGH02EGRMLWZ;VSTATUS:$HB0$FC0,ff,DN,IDLE,CUT;LSS:01;LDF:1;LDE:1;>
baseLow=0x378
baseHigh=0x778
portType=0x000

ParPort:
portType=1
debug=0
setupDelay(0)={tv_sec=0,tv_usec=100}
strobeDelay(1)={tv_sec=0,tv_usec=0}
holdDelay(2)={tv_sec=0,tv_usec=100}
ecpSetupDelay(3)={tv_sec=0,tv_usec=0}
ecpPostHtrDelay(4)={tv_sec=0,tv_usec=10000}
signalTimeout(5)={tv_sec=0,tv_usec=100000}
busyTimeout(6)={tv_sec=1,tv_usec=0}
reversePollRate(7)={tv_sec=0,tv_usec=10000}
dead=0
currentMode=0x10
currentChannel=0
htrCount=4
forwardMode=0x10
reverseMode=0x00
channel=77
status       =0x7F
control      =0xED
ECP config A =0x00
ECP config B =0x00
ECP control  =0xE6

Transport:
this=0x08067838
port=0
pMgr=0x08066CB8
pPhysicalPort=0x08066CB8
forwardTransactionCounter: current=16, initial=16, low=15, high=16, max=16
channelCount=17
channelArray=0x08067A28
channelArray[0]=0x08067A70
channelArray[1]=0x08067D68
channelArray[2]=0x08067F68
channelArray[3]=0x08068168
channelArray[4]=0x08068368
channelArray[5]=0x08068568
channelArray[6]=0x08068768
channelArray[7]=0x08068968
channelArray[8]=0x08068B68
channelArray[9]=0x08068D68
channelArray[10]=0x08068F68
channelArray[11]=0x08069168
channelArray[12]=0x08069368
channelArray[13]=0x08069568
channelArray[14]=0x08069768
channelArray[15]=0x08069968
channelArray[16]=0x08069B68
overheadBufferCount=0
pNextTransport=0x00000000
pForwardDataTimer=0x08067900 (count=0)
pForwardDataTimeoutMsg=0x080678D0
reverseDataBufferCount=180
reverseDataBufferSize=4102
maxForwardBdrsPerTransaction=4
nextChannelToAllocate=17
nextBlockedChannel=-1
lookupQueue: depth=0, peek=0x00000000
----------------
pForwardHeaderPool=0x08067940
mlcChannelArray=0x08067A28
pCommandChannel=0x08067A70
grcState=0
reverseDataStopped=0
tryDot4=0
tryPreDot4=0
tryMlc=1
requestedRevision=0x03
revision=0x03
maxRemoteSockets=32
remsock[0]: state=2, socketID=1, fwdPS=134, revPS=134

Command channel:
this=0x08067A70
port=0
channel=0
localSocket=0
pTransport=0x08067838
pMgr=0x08066CB8
pPhysicalPort=0x08066CB8
openingAnySetFlags=0x0010
closingAnySetFlags=0x0124
flags=0x0003
countOpen=0
countOpenFailure=0
pService=0x00000000
scd=0x00000000
forwardDataPriority=0
minBuffersRequired=0
benefitOfMoreBuffers=0
reverseDataBufferSize=4102
bufferCount=3
remoteSocket=0
maxForwardDatalen=58
maxReverseDatalen=58
countForwardData=4
countReverseData=7
countReverseBuffers=7
countReverseBufferReturns=2
lastReverseBuffer=0x00000000
currentForwardBuffer=0x00000000
currentGrabbedCredit=-1
currentGrabbedTransaction=-1
----------------
pMlcTransport=0x08067838
pCommandChannel=0x08067A70
disableCreditCommands=1
pForwardCreditRequestTimer=0x08067C08
pForwardCreditRequestMsg=0x08067BD8
pReverseCreditHeartbeatTimer=0x08067C70
pReverseCreditHeartbeatMsg=0x08067C40
musherFirstCreditRequestDelay=2
musherNextCreditRequestDelay=5
gusherFirstCreditRequestDelay=5
gusherNextCreditRequestDelay=10
miserFirstCreditRequestDelay=0
miserNextCreditRequestDelay=2
gusherPiggybackCreditCount=1
gusherCreditCount=2
miserCreditRequestCount=2
workaroundReverseCreditLoss=0
maxForwardPacketSize=64
maxReversePacketSize=64
forwardCreditRequest=16
forwardMaxOutstandingCredit=1
forwardCredit: current=1, initial=1, low=0, high=1, max=65535
lastCreditRequestGotUsNowhere=0
reverseMaxOutstandingCredit=1
reverseBuffersPerPacket=1
uncreditedBuffers=0
reverseCreditToGrant=1
reverseCredit: current=1, initial=1, low=1, high=2, max=65535
countSendPiggybackCredit=4
countHandlePiggybackCredit=7
countSendCredit=0
countHandleCredit=0
countHandleCreditAfterCreditRequest=0
countSendCreditRequest=0
countHandleCreditRequest=0
countSendEmptyCreditRequestReply=0
countHandleEmptyCreditRequestReply=0
isGusher=1
----------------
pForwardCommandPool=0x08067CA8
pForwardNonconsumingQueue=0x08067CC8
pForwardReplyQueue=0x08067CD8
pForwardRequestQueue=0x08067CE8
forwardRequestCredit: current=1, initial=1, low=0, high=1, max=65535
pCommandReplyTimer=0x08067D28 (count=1)
pCommandReplyTimeoutMsg=0x08067CF8
allowErrorPackets=1
lastPsid=0
lastSsid=0

Session 0: type=command
	state=4
	fd=6
	scdlink=9
	pLookup=0x08067368
	outstandingForwardBdrCount=2
	pReverseBdrQueue: depth=0
	tcd=0x00000000
	pCommandBdr=0x080732A8
	pmlTrapsRegistered=0

Session 8: type=transport
	state=6
	fd=-1
	scdlink=-1
	pLookup=0x08067668
	outstandingForwardBdrCount=0
	pReverseBdrQueue: depth=0
	tcd=0x08067D68
	pCommandBdr=0x00000000
	pmlTrapsRegistered=0

Transport channel for session 8:
this=0x08067D68
port=0
channel=1
localSocket=128
pTransport=0x08067838
pMgr=0x08066CB8
pPhysicalPort=0x08066CB8
openingAnySetFlags=0x0010
closingAnySetFlags=0x0124
flags=0x0003
countOpen=1
countOpenFailure=0
pService=0x08066CB8
scd=0x00000008
forwardDataPriority=0
minBuffersRequired=10
benefitOfMoreBuffers=1
reverseDataBufferSize=4102
bufferCount=12
remoteSocket=1
maxForwardDatalen=128
maxReverseDatalen=128
countForwardData=0
countReverseData=0
countReverseBuffers=0
countReverseBufferReturns=0
lastReverseBuffer=0x00000000
currentForwardBuffer=0x00000000
currentGrabbedCredit=-1
currentGrabbedTransaction=-1
----------------
pMlcTransport=0x08067838
pCommandChannel=0x08067A70
disableCreditCommands=0
pForwardCreditRequestTimer=0x08067EC8
pForwardCreditRequestMsg=0x08067E98
pReverseCreditHeartbeatTimer=0x08067F30
pReverseCreditHeartbeatMsg=0x08067F00
musherFirstCreditRequestDelay=2
musherNextCreditRequestDelay=5
gusherFirstCreditRequestDelay=5
gusherNextCreditRequestDelay=10
miserFirstCreditRequestDelay=0
miserNextCreditRequestDelay=2
gusherPiggybackCreditCount=1
gusherCreditCount=2
miserCreditRequestCount=2
workaroundReverseCreditLoss=0
maxForwardPacketSize=134
maxReversePacketSize=134
forwardCreditRequest=16
forwardMaxOutstandingCredit=65535
forwardCredit: current=4, initial=4, low=4, high=4, max=65535
lastCreditRequestGotUsNowhere=0
reverseMaxOutstandingCredit=0
reverseBuffersPerPacket=1
uncreditedBuffers=0
reverseCreditToGrant=0
reverseCredit: current=12, initial=12, low=12, high=12, max=65535
countSendPiggybackCredit=0
countHandlePiggybackCredit=0
countSendCredit=0
countHandleCredit=0
countHandleCreditAfterCreditRequest=0
countSendCreditRequest=0
countHandleCreditRequest=0
countSendEmptyCreditRequestReply=0
countHandleEmptyCreditRequestReply=0
isGusher=-1

Session 9: type=transport
	state=4
	fd=-1
	scdlink=0
	pLookup=0x00000000
	outstandingForwardBdrCount=0
	pReverseBdrQueue: depth=0
	tcd=0x08067F68
	pCommandBdr=0x00000000
	pmlTrapsRegistered=0

Transport channel for session 9:
this=0x08067F68
port=0
channel=2
localSocket=129
pTransport=0x08067838
pMgr=0x08066CB8
pPhysicalPort=0x08066CB8
openingAnySetFlags=0x0010
closingAnySetFlags=0x0124
flags=0x0001
countOpen=0
countOpenFailure=0
pService=0x08066CB8
scd=0x00000009
forwardDataPriority=0
minBuffersRequired=10
benefitOfMoreBuffers=1
reverseDataBufferSize=4102
bufferCount=11
remoteSocket=0
maxForwardDatalen=0
maxReverseDatalen=0
countForwardData=0
countReverseData=0
countReverseBuffers=0
countReverseBufferReturns=0
lastReverseBuffer=0x00000000
currentForwardBuffer=0x00000000
currentGrabbedCredit=-1
currentGrabbedTransaction=-1
----------------
pMlcTransport=0x08067838
pCommandChannel=0x08067A70
disableCreditCommands=0
pForwardCreditRequestTimer=0x080680C8
pForwardCreditRequestMsg=0x08068098
pReverseCreditHeartbeatTimer=0x08068130
pReverseCreditHeartbeatMsg=0x08068100
musherFirstCreditRequestDelay=2
musherNextCreditRequestDelay=5
gusherFirstCreditRequestDelay=5
gusherNextCreditRequestDelay=10
miserFirstCreditRequestDelay=0
miserNextCreditRequestDelay=2
gusherPiggybackCreditCount=1
gusherCreditCount=2
miserCreditRequestCount=2
workaroundReverseCreditLoss=0
maxForwardPacketSize=0
maxReversePacketSize=0
forwardCreditRequest=16
forwardMaxOutstandingCredit=65535
forwardCredit: current=0, initial=0, low=0, high=0, max=65535
lastCreditRequestGotUsNowhere=0
reverseMaxOutstandingCredit=65535
reverseBuffersPerPacket=0
uncreditedBuffers=11
reverseCreditToGrant=0
reverseCredit: current=0, initial=0, low=0, high=0, max=65535
countSendPiggybackCredit=0
countHandlePiggybackCredit=0
countSendCredit=0
countHandleCredit=0
countHandleCreditAfterCreditRequest=0
countSendCreditRequest=0
countHandleCreditRequest=0
countSendEmptyCreditRequestReply=0
countHandleEmptyCreditRequestReply=0
isGusher=-1




************************************************





ptal-mlcd: FATAL ERROR at transport/ExTransport.cpp:428, dev=<par:psc500>, pid=139, errno=11

RE: [hpoj-devel] hpo bug (sane 1.0.4)

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

Ben "Obi-Wan" Hollingsworth wrote:
> My old box doesn't have USB support.  I conjectured that 
> using that flag
> might make my compiles faster and/or my binary smaller.
It prevents a very small amount of code from being compiled, but I don't
think that the time/space savings is enough to be worth the trouble of
typing an extra parameter on the ./configure command line.  But do as you
wish.  :-)

> BTW, for you Debian types out there, I had to make one little hack to
> make hpoj recognize the QT stuff.  The deb for QT puts the includes
> in /usr/include/qt (not a bad idea, since there are dozens of them),
> but the libs & binaries in /usr/lib & /usr/bin.  The hpoj configure
> script expects all three subdirs to be under the same parent dir.
Thanks for pointing that out.  I added this to my TODO list.

> I had the foresight to leave my PSC 500 on when I came to work today,
> so I tried to scan something just now.  I was fiddling with 
> rc scripts,
> so I killed & restarted ptal-mlcd & ptal-printd numerous times this
> morning.  Here's what's currently running:
> 
>    > psg ptal
>    root     12720  0.0  2.4  1768  740 pts/15   S    11:18   
> 0:00 /usr/local/sbin/ptal-mlcd par:psc500 -alias mlcpp0
>    root     12722  0.0  1.2  1244  392 pts/15   S    11:18   
> 0:00 /usr/local/sbin/ptal-printd mlc:par:psc500 -like /dev/lp0
That looks fine, although the "-alias mlcpp0" isn't really necessary unless
you're upgrading from a previous version of hpoj and don't want to
reconfigure SANE or whatever for the new device name format.

...
> and this in the ptal-mlcd log file:
> 
> ---------
>    ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, 
> dev=<par:psc500>, pid=12720, errno=11
>    Reply timer popped on port=0, count=1!
> 
>    ptal-mlcd: ERROR at ExMgr.cpp:872, dev=<par:psc500>, 
> pid=12720, errno=11
>    exClose(reason=0x3002)
That's not good.  :-)  Occasionally I've managed to get the R series and PSC
500 into a bad state, where the LCD scrolls the message "turn the power off
and back on again".  I wonder if that's what happened here?  But in that
case I would have expected a different error.  Anyway, I'm just thinking
aloud here.

Another thing that comes to mind is to make sure that your parallel port is
configured in your BIOS setup for preferably ECP, or PS/2 (aka BPP)
otherwise, but not EPP.  Also, make sure you're using a good parallel cable
and that the device is connected directly to your computer without any
switchboxes or other pass-through devices, such as Zip drives.

Here's another thing you can try, but probably not until you get home and
make sure the device is in a good state.  Add the "-nofork" switch to
ptal-mlcd, and it will give you a debug console.  Use the "log" command to
enable debug logging ("nolog" turns off the debug messages).  Then use the
"activate" command to make it start trying to talk to the peripheral.  When
the messages stop spewing, use the "dump" command, which displays the state
of the internal data structures.  Wait about 20 seconds to see if you get
the "reply timer popped" message.  If that doesn't happen, then in another
window try ptal-devid (this should work if you've gotten this far).  After
this point try printing and scanning (separately) and see what happens.  You
can press control-C to kill ptal-mlcd.

David

RE: [hpoj-devel] ptal-mlcd and hotplug scripts

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

Hi, Allen.

Allen Barnett wrote:
> I tried unplugging and replugging my USB cable a few times 
> and it seems
> to work OK. (Subject to my USB hardware performing properly; 
> I'm afraid
> my 3 year old DELL Dimension is wearing out.) The only problem I have
> with this setup is that my hotplug script starts both ptal-mlcd and
> ptal-printd, but only ptal-mlcd exits automatically. So, each replug
> starts another ptal-printd. Would it be possible for ptal-printd to
> receive notification from ptal-mlcd that ptal-mlcd is shutting itself
> down?
That's a bit of a problem.  From what I've heard, systems running LPRng hang
unless ptal-printd is running at startup.  One solution may be to:
- run ptal-printd from an init script (before LPRng is initialized),
- load ptal-mlcd from a hotplug script (if not from an init script), and
- use a descriptive PTAL device name like mlc:usb:hpojg85 instead of the
uncreative mlc:usb:X that I typically use that corresponds to the
/dev/usb/lpX in use.

> Would it be practical to add a SYSLOG output option to your utilities?
I've been thinking along those lines.  I may direct ptal-mlcd's log messages
to syslog regardless, and to standard output if it's available (or to a
remote console instead of stdout if one is open).

> On another subject altogether: should 'ptal-hp scan' work 
> with the G85?
> I get the error message:
> 
> Scan upload state is 2 (i=11)!
No.  "ptal-hp scan" only works on PML (Peripheral Management Language)
scanners (LaserJets and older scrollfed OfficeJets), whereas SANE currently
only works on SCL (Scanner Control Language) scanners (flatbed and newer
scrollfed OfficeJets).  "ptal-hp scan" was basically a quick and dirty hack
so that people with PML scanners wouldn't have to keep waiting for me to
write a proper SANE backend that supports PML scanners.  :-)

David

Re: [hpoj-devel] Re: Installation to Debian2.2 (potato) for hpoj 600 - printd - HELP?

[Bob P. <bpa...@cs...>]

>>    http://localhost:631/admin/
> >
> >   This is documented in:
> >
> >     http://localhost:631/sam.html#4_2
>
> And whose localhost might this be?  My machine doesn't have anything
> listening on port 631.

'localhost' always refers to your own box, IP address 127.0.0.1.

Port 631 is where CUPS lives.  If your not running CUPS then you won't have 
it.

My problem with getting printing to work where compounded by several other 
factors such as my fire wall, it blocked port 631 with no messages, then I 
discovered that I could only get port 631 to work with Netscape, after using 
a different browser for two days,  think that has some thing to do with a 
Java problem.

Re: [hpoj-devel] Re: Installation to Debian2.2 (potato) for hpoj 600 - printd - HELP?

[Obi-Wan <bv...@in...>]

>   Here's the magic fairy dust:
> 
>     http://localhost:631/admin/
> 
>   This is documented in:
> 
>     http://localhost:631/sam.html#4_2

And whose localhost might this be?  My machine doesn't have anything
listening on port 631.

-- 
Ben "Obi-Wan" Hollingsworth                             ob...@je...
   The stuff of earth competes for the allegiance I owe only to the
     Giver of all good things, so if I stand, let me stand on the
       promise that You will pull me through.  -- Rich Mullins