hpoj-devel — HPOJ development/support list

Re: [hpoj-devel] original HP cable really 1284 compliant ?

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

(In response to Karsten Hilbert's questions)

Hi, Karsten.  Since the G85 works on your brother's laptop, there's probably
nothing wrong with the cable.  It's likely that there's something wrong
with your parallel port (broken or shorted line) which the DeskJet and dot
matrix printer can cope with but the G85 can't.  When you cat something to
/dev/lp0 does the command complete fairly quickly or does it hang
indefinitely?

> I know this is _slightly_ off topic. I just can't think of any
> more variations to try. And it does involve the OfficeJet,
> mainly.
I don't think it's off-topic for this mailing list, but if it's truly a
hardware problem then there's probably not an easy solution, unless you're
really into using logic analyzers and soldering irons.  :-)

> > Which hpoj version are you using?
> plain 0.7, but will try cvs. But the real problem (parport_probe
> not even finding the printer and cat foo > /dev/lp0 not doing
> anythiny) occurs much earlier than hpoj comes in.
It would be useful to try the latest CVS code, since it has a brand-new
low-level driver (ptal-mlcd) that bypasses the kernel for parallel-port
I/O.  Assuming a hardware problem, it probably won't work either, but at
least maybe it will provide some useful diagnostic information.

If you don't mind experimenting with the production server, you could try
connecting the G85 there.  Also, if your 2.2.19 laptop has USB then you
could try using the CVS code (not 0.7) through USB.

> I don't think I need ieee128444.o just for cat'ing, right ? (I
> certainly can't insmod ieee128444pp.o since that needs
> parport_probe working correctly.)
> 
> The problem of not being able to cat to the device isn't hpoj
> related. Neither is the failing parport_probe related with not
> being able to cat to it (?).
Correct.  cating to the device does not depend on parport_probe or
ieee12844*.o.  However, parport_probe, ieee12844pp.o (in 0.7), and
ptal-mlcd (in CVS and upcoming 0.8) need the parallel port to be set in
the BIOS as either ECP or bidirectional=BPP=PS/2, not SPP or EPP.  In your
first message you showed that this was set correctly, but I wanted to make
sure you're aware of it.

David

Re: [hpoj-devel] original HP cable really 1284 compliant ?

[Karsten H. <Kar...@gm...>]

Hi Joe,

> If it was sold as being compliant, then it should be, unless it's defective 
Well, all I know is that it's the cable that came with the
printer. It says HP on it so it's not a cheap replacement by
some OEM or other. Unfortunately, the manuals coming with the
printer are total crap. They really aren't manuals at all
since they don't give _any_ tech detail for the device or
peripherals.

> in some way. Do you have an ms-windows installation that you could use for 
> testing the cable and / or printer? If it all works under ms-windows, then a 
> hardware problem is less likely to be the cause of your trouble.
I don't have any win available for testing. But my brother
tested the unit with his laptop (kernel 2.4.x) and it at least
printed something. However, our production server (and my
laptop where I am currently testing) are running 2.2.x (16/19)
kernels (and for good reason).

Since it sort of worked with the other laptop it is unlikely
to be the cable, I guess. But then that was 2.4.x, too.

> Do you have the printer connected and turned on when the modules are 
> insmodded?
Absolutely :-)  You guys nicely pointed that out in the docs.
Also, it's _not_ on standby while insmodding.

> If you have redhat's 'printtool' installed, can you get any output from that?
No. Suse 6.4  And cat'ing seems more basic to me, too.

> Which hpoj version are you using?
plain 0.7, but will try cvs. But the real problem (parport_probe
not even finding the printer and cat foo > /dev/lp0 not doing
anythiny) occurs much earlier than hpoj comes in.

I don't think I need ieee128444.o just for cat'ing, right ? (I
certainly can't insmod ieee128444pp.o since that needs
parport_probe working correctly.)

The problem of not being able to cat to the device isn't hpoj
related. Neither is the failing parport_probe related with not
being able to cat to it (?).

Using SPP and a stock kernel, no PNP (but parport moduled in)
I can print to a DJ520 but not an OJ G85 (on this laptop,
anyways). Does this mean I have to crap this laptop and look
for another machine for testing ? I have no problems with it
printing to my standard dot matrix either.

Thanks for your help so far,

Karsten
-- 
GPG key ID E4071346 @ certserver.pgp.org
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Re: [hpoj-devel] original HP cable really 1284 compliant ?

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

On Sunday 08 July 2001 08:13 am, Karsten Hilbert wrote:
> Hi,
>
> has anyone here any information on the above question ? 

If it was sold as being compliant, then it should be, unless it's defective 
in some way. Do you have an ms-windows installation that you could use for 
testing the cable and / or printer? If it all works under ms-windows, then a 
hardware problem is less likely to be the cause of your trouble.

It is possible for a cable to have electrical problems ( sometimes it can be 
intermittent ), especially if it has been treated harshly. Any problem with a 
cable means it needs to be replaced. You can usually find them at office 
supply houses or Radio Shack.

Do you have the printer connected and turned on when the modules are 
insmodded?

If you have redhat's 'printtool' installed, can you get any output from that?

Which hpoj version are you using?

I think David can probably give you a better answer regarding software setup, 
if you need it.

-- 
Joe

[hpoj-devel] original HP cable really 1284 compliant ?

[Karsten H. <Kar...@gm...>]

Hi,

has anyone here any information on the above question ? The
reason why I am asking:

OfficeJet G85
Deskjet 520

stock kernel 2.2.19/2.2.16

kernel: parport0: PC-style at 0x378 (0x778), irq 5, dma 0 [SPP,ECP,ECPPS2]
kernel: parport_probe: failed
kernel: parport0: no IEEE-1284 device present.
kernel: lp0: using parport0 (interrupt-driven).

(I know there's something amiss with parport_probe
not detecting the OfficeJet [/proc lists unknown vendor/device]
- but I don't know what.)

Anyways, when attaching the OJ with the original HP parallel cable
I can't get anything at all out of it. No init, no printing,
no nothing. No cat foo > /dev/lp0 (although the modules load
fine). If I do nothing at all except attaching the DJ520 by
unhooking the OJ cable and hooking up a stock parallel cable
connected to the DJ cat and friends work like a charm.

Unfortunately, HP chose to use another form factor for the
printer side parallel connector so I can't switch over cables.

I doubt that it is the HP cable. But why don't I get _any_
output at all when cat'ing to the OJ ? (Not to speak of output
via hpoj drivers since that will require me to get
parport_probe straight, too). I tried all port parameters in
the BIOS (irq, dma, ecp, epp, spp, ps2=bidi). Combinations are
detected by parport_pc just fine but as I said I can't get any
output from the OJ.

I know this is _slightly_ off topic. I just can't think of any
more variations to try. And it does involve the OfficeJet,
mainly.

Thanks for any help,
Karsten
-- 
GPG key ID E4071346 @ certserver.pgp.org
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Re: [hpoj-devel] ptal-init script

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

On Saturday 07 July 2001 06:23 am, David Paschal wrote:
> Joe Piolunek wrote:
> > Your new init system seems to work OK here. The startup commands in
> > ptal-start.conf were appropriate for my RH 6.1+ system, so I just
> > uncommented them.
>
> Hi, Joe.  Thanks for the success report.  Actually I was expecting you'd
> have to modify the ptal-mlcd line, since as I recall you said you connect
> your OfficeJet to an add-in parallel port card.  Perhaps you have things
> jumpered so it's at the "typical" address for an integrated port (0x378)?

The officejet is connected to the add-on i/o card,  which is jumpered to be 
the lowest numbered parport at address 0x378. On this box, the bios remaps 
the MB-based parport to the next available port number and address.


> Actually, if you "cd" into the top-level "hpoj" directory in an existing
> "sandbox", all you have to do is issue the command "cvs update -d", and
> it figures out the "-d:pserver..." stuff from the CVS/Root files.  I know,
> it's confusing with all the parameter letters that mean totally different
> things depending on whether they come before or after the command.
> <plug>  I find the O'Reilly "CVS Pocket Reference" very helpful.  The
> Coriolis book "Open Source Development with CVS" is also good, although
> most of the time the quick reference is more useful to me.  </plug>  The
> "cvs" manual page and web page (http://www.cvshome.org) are also useful
> resources if you don't happen to have any dead-tree documentation handy.

I think I'll be using that method from now on. Thanks.

>
> > Installing the updates should be as painless as possible. I'm not really
> > objecting to the overwrites, but here's what I would consider ideal:
> >
> > Install the new *.conf files only if they didn't previously exist or
> > there is an incompatible format change. Alternatively, if there is a
> > previous installation, the new files could be installed as *.conf_NEW .
>
> That sounds reasonable.  For comparison, upgrades from RPM packages
> typically move the old config file to something like "foo.rpmsave" before
> installing the new file, but I suppose that would be problematic if you
> re-installed multiple times without merging your changes back in each time.

A couple of recent RPM upgrades I installed saved the new config files to 
*.rpmnew , leaving the existing files in place.

> > I have plenty to do myself.  I've been trying finish building my
> > woodstrip-epoxy kayak and get some use out of it before the summer is
> > over.
>
> What?!?  You mean to tell me you're not making it out of concrete?  :-)
> (http://slashdot.org/article.pl?sid=01/07/04/1739229)

I want one I can carry!


-- 
Joe

Re: [hpoj-devel] ptal-init script

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

Joe Piolunek wrote:
> Your new init system seems to work OK here. The startup commands in 
> ptal-start.conf were appropriate for my RH 6.1+ system, so I just uncommented 
> them. 
Hi, Joe.  Thanks for the success report.  Actually I was expecting you'd
have to modify the ptal-mlcd line, since as I recall you said you connect
your OfficeJet to an add-in parallel port card.  Perhaps you have things
jumpered so it's at the "typical" address for an integrated port (0x378)?

> For anyone who is having trouble with the cvs syntax, the command below 
> should get this particular update for you.
> 
> ]$ cvs -z3 -d:pserver:ano...@cv...:/cvsroot/hpoj update 
> -d hpoj
Actually, if you "cd" into the top-level "hpoj" directory in an existing
"sandbox", all you have to do is issue the command "cvs update -d", and
it figures out the "-d:pserver..." stuff from the CVS/Root files.  I know,
it's confusing with all the parameter letters that mean totally different
things depending on whether they come before or after the command.
<plug>  I find the O'Reilly "CVS Pocket Reference" very helpful.  The
Coriolis book "Open Source Development with CVS" is also good, although
most of the time the quick reference is more useful to me.  </plug>  The
"cvs" manual page and web page (http://www.cvshome.org) are also useful
resources if you don't happen to have any dead-tree documentation handy.

> Installing the updates should be as painless as possible. I'm not really 
> objecting to the overwrites, but here's what I would consider ideal:
> 
> Install the new *.conf files only if they didn't previously exist or there is 
> an incompatible format change. Alternatively, if there is a previous 
> installation, the new files could be installed as *.conf_NEW .
That sounds reasonable.  For comparison, upgrades from RPM packages typically
move the old config file to something like "foo.rpmsave" before installing
the new file, but I suppose that would be problematic if you re-installed
multiple times without merging your changes back in each time.

> I have plenty to do myself.  I've been trying finish building my 
> woodstrip-epoxy kayak and get some use out of it before the summer is over.
What?!?  You mean to tell me you're not making it out of concrete?  :-)
(http://slashdot.org/article.pl?sid=01/07/04/1739229)

David

Re: [hpoj-devel] RE: Patch update for 2.4-release kernels

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

Jarl Friis wrote:
> Maybe you should update the information acordingly, instead of "... that
> more recent 2.4.0-test kernels ..." you may write "... that more recent
> 2.4.X kernels ...", since the patch now reflect release kernels.
Done.

Thanks,
David

[hpoj-devel] RE: Patch update for 2.4-release kernels

[Jarl F. <ja...@di...>]

On Fri, 6 Jul 2001, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

> Thanks, Jarl.  It's posted on the web now.  Pretty soon we won't have to
> worry about this, because the CVS code and the upcoming 0.8 release no
> longer have this kind of kernel dependence.

Maybe you should update the information acordingly, instead of "... that
more recent 2.4.0-test kernels ..." you may write "... that more recent
2.4.X kernels ...", since the patch now reflect release kernels.

Jarl

Re: [hpoj-devel] ptal-init script

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

On Friday 06 July 2001 06:57 am, David Paschal wrote:
> Hi,
>
> At long last I have checked in an init script (ptal-init) and its related
> configuration files (ptal-start.conf and ptal-stop.conf).  In addition to
> the standard functionality of starting and stopping ptal-mlcd and
> ptal-printd, ptal-init also has a "setup" (AKA "probe") option to probe
> for USB devices and add commands to ptal-start.conf to start ptal-mlcd and
> ptal-printd.  Since parallel-connected devices cannot reliably be
> discovered in user mode, you'll have to hand-edit ptal-start.conf for
> parallel-connected devices.  However, the "typical" commands are already
> there and commented out, and you'd probably only need to change them if
> your parallel port is at a different base address or if you have multiple
> parallel ports.
>
> I would greatly appreciate everyone's help in testing this and letting
> me know how it works (or doesn't) on different versions of different
> distributions, since currently I've only tested it on RedHat 6.2.

Your new init system seems to work OK here. The startup commands in 
ptal-start.conf were appropriate for my RH 6.1+ system, so I just uncommented 
them. 

Hopefully enough people using other distributions will take the time to test 
the latest update and send a comment on their results.


> Here are the steps you'll need to take to try this thing out:
> - You'll probably need to append the "-d" switch to the "cvs update"
> command, since it's been a while since anything has been in the "scripts"
> directory.

For anyone who is having trouble with the cvs syntax, the command below 
should get this particular update for you.

]$ cvs -z3 -d:pserver:ano...@cv...:/cvsroot/hpoj update 
-d hpoj


> - If you'd like, you can move the two *.conf files to /etc, where they'll
> take precedence over any copies in /usr/local/etc, and won't get
> overwritten on the next "make install".  If anybody objects to this
> overwriting then let me know and I'll try to fix it.

Installing the updates should be as painless as possible. I'm not really 
objecting to the overwrites, but here's what I would consider ideal:

Install the new *.conf files only if they didn't previously exist or there is 
an incompatible format change. Alternatively, if there is a previous 
installation, the new files could be installed as *.conf_NEW .


-- 
Joe

RE: [hpoj-devel] Help, HP PSC-750 USB printer won't work after en abling hot-plug s cripts

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

Hi, Ben.

Ben McCann wrote:
> Yesterday I had my new HP PSC-750 'all-in-one' printer/scanner/copier 
> working after a fashion. I could print to it if I booted my 
> server and 
> the PSC750 in the 'right' order. (I don't really know the 
> right order, 
> but I was able to get everything running). This morning I 
> embarked upon 
> making 'hot-plugging' work because one of the issues I had with the 
> printer is that the 'ptal-printd' process exits when the printer is 
> turned off. 
That would be a bug, not a feature.  Are you sure that you're really running
the latest ptal-printd code from CVS?  If you happened to upgrade from 0.7
or CVS code from around the 0.7 timeframe, then you may be running an old
version of ptal-printd, which had this problem.  Try running "which
ptal-printd" and see if multiple copies come up in different places.  The
old version was installed by default in /usr/local/bin, and now it's
installed in /usr/local/sbin, so that's why I'm asking.  If that doesn't
help, then are any messages logged to /var/log/messages that say why it
exits?  If not, then it might be worth attaching gdb to the running process
and see if it traps any segfaults.

> Finally, I created the following script to start the 
> OfficeJet daemons 
> when the printer comes online (in /etc/hotplug/usb/printer): 
>    #!/bin/sh 
>    # Start the HP Office Jet Daemons 
>    /usr/local/bin/ptal-mlcd usb:0 -hotplug -device /dev/usb/lp0 
>    /usr/local/bin/ptal-printd mlc:usb:0 -like /dev/lp0 & 
My recommendation would be to not start the daemons from a hotplug script,
and instead try out the new method I announced last night
(http://www.geocrawler.com/lists/3/SourceForge/5745/0/6115780) (see below).

...
> Jul  6 07:15:41 canopus ptal-mlcd:  ptal-mlcd: ERROR at 
> ExMgr.cpp:2940, dev=<usb:0>, pid=1203, errno=5         
> llioGetDeviceID: ioctl failed!
> Jul  6 07:15:41 canopus ptal-mlcd:  ptal-mlcd: ERROR at 
> ExMgr.cpp:2351, dev=<usb:0>, pid=1203, errno=25         
> llioOpenOne: llioGetDeviceID(/dev/usb/lp0) failed!
...
> If I manually run ptal-mlcd and then attempt to run 'ptal-hp 
> mlc:usb:0 display' 
> then that also gets timeouts. (That was working yesterday).
I'm not sure what's causing the timeout in getting the device ID or what
would have changed to make this happen.  Maybe there's a race condition in
the kernel where if ptal-mlcd tries to activate too quickly in a hotplug
script, that something in the kernel gets in a bad state such that it won't
work again, even if you try running ptal-mlcd again manually.  I've seen
complete lockups when activating too quickly like this, so it's not too
far-fetched.  To test this hypothesis, try undoing your hotplug changes
(such that the daemons don't get loaded), reboot, make sure the kernel
modules (printer.o, etc.) get loaded, try running ptal-mlcd without the
-hotplug option (i.e. "ptal-mlcd mlc:usb:0 -device /dev/usb/lp0"), and see
if that works.  If so, then you can proceed to try out the new ptal-init
script, especially "ptal-init setup", which probes for USB printers and sets
up the ptal-start.conf file.

David

[hpoj-devel] RE: Patch update for 2.4-release kernels

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

Thanks, Jarl.  It's posted on the web now.  Pretty soon we won't have to
worry about this, because the CVS code and the upcoming 0.8 release no
longer have this kind of kernel dependence.

David

> -----Original Message-----
> From: Jarl Friis [mailto:ja...@di...]
> Sent: Friday, July 06, 2001 2:23 PM
> To: dav...@hp...
> Subject: Patch update for 2.4-release kernels
> 
> 
> After the official release of the 2.4 kernel the patch by 
> Burkhard Kohl is
> no longer feasible.
> 
> Due to a change in include headers hpoj does not compile on
> 2.4.x kernel, the updated patch which just changes one line more than
> Burkhards patch is attached with this mail.
> 
> NOTE: I am curretnly not on the development-list
> 
> Jarl
> 

[hpoj-devel] Help, HP PSC-750 USB printer won't work after enabling hot-plug s cripts

[Mccann, B. E <bm...@en...>]

(Sorry for cross posting)

Yesterday I had my new HP PSC-750 'all-in-one' printer/scanner/copier
working after a fashion. I could print to it if I booted my server and
the PSC750 in the 'right' order. (I don't really know the right order,
but I was able to get everything running). This morning I embarked upon
making 'hot-plugging' work because one of the issues I had with the
printer is that the 'ptal-printd' process exits when the printer is
turned off.

Before getting into the particulars, my system is running a Redhat 6.2
distribution on a 2.2.20pre5 kernel. I did have to edit arch/i386/config.in
to provide an option to enable CONFIG_HOTPLUG. I added:

   if [ "$CONFIG_KMOD" = "y" ]; then
     bool 'Support for hot-pluggable devices' CONFIG_HOTPLUG
   fi

in the loadable modules area of the file. I have installed the latest
usbutils RPM (version 0.8) and I installed the hotplug-2001_04_24-1
hot plug RPM. I also have the latest hpoj package from the CVS
repository at sourceforge.

Finally, I created the following script to start the OfficeJet daemons
when the printer comes online (in /etc/hotplug/usb/printer):

   #!/bin/sh

   # Start the HP Office Jet Daemons
   /usr/local/bin/ptal-mlcd usb:0 -hotplug -device /dev/usb/lp0
   /usr/local/bin/ptal-printd mlc:usb:0 -like /dev/lp0 &

The hotplug logic does run /sbin/hotplug and this script does run, but
I get I/O errors talking to the printer so ptal-mlcd exits:

Jul  6 07:15:35 canopus kernel: usb.c: USB new device connect, assigned
device number 2
Jul  6 07:15:35 canopus kernel: Manufacturer: Hewlett-Packard
Jul  6 07:15:35 canopus kernel: Product: PSC 750
Jul  6 07:15:35 canopus kernel: SerialNumber: MY12DA10CRWB
Jul  6 07:15:35 canopus kernel: printer.c: usblp0: USB Bidirectional printer
dev 2 if 0 alt 0
Jul  6 07:15:35 canopus /sbin/hotplug: arguments (usb) env (ACTION=add
DEVFS=/proc/bus/usb TERM=dumb DEVICE=/proc/bus/usb/001/002 HOSTTYPE=i386
PATH=/bin:/sbin:/usr/sbin:/usr/bin HOME=/ SHELL=/bin/bash DEBUG=yes
INTERFACE=7/1/3 OSTYPE=Linux PRODUCT=3f0/1411/1.0 SHLVL=1 _=/usr/bin/env)
Jul  6 07:15:35 canopus /sbin/hotplug: invoke /etc/hotplug/usb.agent ()
Jul  6 07:15:35 canopus /etc/hotplug/usb.agent: Modprobe and setup printer
for USB product 3f0/1411/0100
Jul  6 07:15:35 canopus /etc/hotplug/usb.agent: Module setup printer for USB
product 3f0/1411/0100
Jul  6 07:15:35 canopus ptal-mlcd:  ptal-mlcd: SYSLOG at ExMgr.cpp:660,
dev=<usb:0>, pid=1203, errno=111 ptal-mlcd successfully initialized.
Jul  6 07:15:41 canopus kernel: usb_control/bulk_msg: timeout
Jul  6 07:15:41 canopus ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:2940,
dev=<usb:0>, pid=1203, errno=5         llioGetDeviceID: ioctl failed!
Jul  6 07:15:41 canopus ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:2351,
dev=<usb:0>, pid=1203, errno=25         llioOpenOne:
llioGetDeviceID(/dev/usb/lp0) failed!
Jul  6 07:15:42 canopus ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:2324,
dev=<usb:0>, pid=1203, errno=25         Couldn't find device!
Jul  6 07:15:42 canopus ptal-mlcd:  ptal-mlcd: FATAL ERROR at ExMgr.cpp:757,
dev=<usb:0>, pid=1203, errno=25         exActivate: Exiting due to
activation failure.

If I manually run ptal-mlcd and then attempt to run 'ptal-hp mlc:usb:0
display'
then that also gets timeouts. (That was working yesterday). 

If it is any help, here is the output of 'dmesg' showing the
timeout messages in the kernel:

usb.c: kmalloc IF c11b0420, numif 1
usb.c: new device strings: Mfr=1, Product=2, SerialNumber=3
usb.c: USB device number 2 default language ID 0x409
Manufacturer: Hewlett-Packard
Product: PSC 750
SerialNumber: MY12DA10CRWB
printer.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0
usb.c: usblp driver claimed interface c11b0420
usb.c: kusbd: /sbin/hotplug add 2
usb.c: kusbd policy returned 0x0
usb_control/bulk_msg: timeout
usb_control/bulk_msg: timeout

Finally, the USB bus appears to be functional because 'lsusb' is
working and it does show the HP printer.

What can I do to debug this problem and get hotplugging and PTAL
to work together correctly? Is there some magic switch for ptal-mlcd?

-Ben McCann

---
Ben McCann                         Enterasys Networks
                                   31 Nagog Park
                                   Acton, MA, 01720
email: bm...@en...       web: www.enterasys.com 
phone: (978) 266-8140              fax: (978) 266-8111

[hpoj-devel] ptal-init script

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

Hi,

At long last I have checked in an init script (ptal-init) and its related
configuration files (ptal-start.conf and ptal-stop.conf).  In addition to
the standard functionality of starting and stopping ptal-mlcd and
ptal-printd, ptal-init also has a "setup" (AKA "probe") option to probe
for USB devices and add commands to ptal-start.conf to start ptal-mlcd and
ptal-printd.  Since parallel-connected devices cannot reliably be
discovered in user mode, you'll have to hand-edit ptal-start.conf for
parallel-connected devices.  However, the "typical" commands are already
there and commented out, and you'd probably only need to change them if
your parallel port is at a different base address or if you have multiple
parallel ports.

I would greatly appreciate everyone's help in testing this and letting
me know how it works (or doesn't) on different versions of different
distributions, since currently I've only tested it on RedHat 6.2.
"make install" installs ptal-init into $prefix/sbin, and it attempts to
create a symlink to it from /etc/rc.d/init.d or /etc/init.d and run
chkconfig to set up the symlinks in the runlevel directories.  Here
are some scenarios that may arise that I'd especially like to know about:

- "/usr/bin/perl" doesn't exist.
- No SysV-style init support at all.
- Init scripts go under /sbin, not /etc.  Is this the case with SuSE?
- chkconfig isn't available, in which case I suppose I'll need to
manually create the symlinks.  :-(
- USB device nodes are somewhere other than /dev/usb/lp*.
- The "subsystem lock file" needs to go somewhere other than
"/var/lock/subsys".
- "It doesn't work" for any other reason, or there's something I did
wrong or neglected to do at all.

Here are the steps you'll need to take to try this thing out:
- You'll probably need to append the "-d" switch to the "cvs update"
command, since it's been a while since anything has been in the "scripts"
directory.
- Re-run the configure script, make, and (as root) "make install".
- Remove any automatic invocations of ptal-mlcd or ptal-printd from other
places, such as rc.local, hotplug scripts, or other init scripts.
- Run "ptal-init setup" if you connect through USB.  It shouldn't hurt
to try this even if you connect through parallel.
- Take a look at /usr/local/etc/ptal-start.conf and ptal-stop.conf, and
edit if necessary (especially if you connect through parallel).  Of
course, adjust "/usr/local" if you passed the "--prefix" option to the
configure script.
- If you'd like, you can move the two *.conf files to /etc, where they'll
take precedence over any copies in /usr/local/etc, and won't get
overwritten on the next "make install".  If anybody objects to this
overwriting then let me know and I'll try to fix it.
- Run "ptal-init start" and make sure the daemons start as expected and
that they work OK.
- Run "ptal-init stop" and make sure the daemons are no longer running
("ps aux|grep ptal" should do the trick).
- Reboot and make sure the daemons start OK, and make sure they start
before whatever print spooler you use (lpd, CUPS, etc.).  For RedHat
7.0/7.1, you can restore the "checkpc" invocation in /etc/init.d/lpd
if you previously removed it, and make sure your startup sequence
doesn't hang.

Some other miscellaneous notes I can think of offhand:

- For USB, I'm now using the scheme I proposed several weeks ago, where
ptal-mlcd is told to try all /dev/usb/lp* and use the one with the right
model string.  That's what "ptal-init setup" actually sets up.

- "ptal-init setup" chooses different default PTAL USB device names
(i.e. "mlc:usb:OfficeJet_G85") than I used to recommend (i.e. "mlc:usb:0").
The script gives you an opportunity to change the suffix if you'd like,
especially if you want to make it shorter.  If you end up going with
different names than before, then of course you'll need to update any
scripts or hp.conf (for SANE) to reflect this change.

- Since "ptal-init setup" invokes ptal-mlcd for each /dev/usb/lp*,
you'll notice lots of error messages in /var/log/messages.

- I haven't updated the documentation yet, since this feature is still
quite new and likely to need some adjustments.  I'm about ready to
attempt to convert everything to better-organized HTML anyway.

- "make install" is much quieter now.

Hopefully this feature will make setting up and starting the daemons much
easier in the long run once it has stabilized.

David

Re: [hpoj-devel] xhpcontrol

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

On Monday 02 July 2001 07:23 am, David Paschal wrote:

<...>
> Hi, Joe.  The screenshot looks very much like what I had in mind.  I'll
> try to get around to looking at the code soon.
>
> > There is also a patch for hpoj/configure.in that will allow the app to be
> > built under hpoj/apps/ .
>
> I assume that's just for convenience of building and installing.
>

I adapted hpoj/configure.in to be used with xhpcontrol. The config* scripts 
should be tested on other systems, but now xhpcontrol can be built outside of 
the hpoj tree. A check for Qt >= 2.0 probably should be added, but the script 
may be good enough for now.


> > There are many parts of the application that need a more experienced
> > coder than me. I can do the "grunt work" of adding the many needed
> > widgets, but the file i/o, plugin architecture, device communication,
> > etc. should be handled by someone with more experience in those areas. 
> > There are also some areas involving Qt that I'm not yet familiar with. If
> > someone wants to and has the ability to help with any of it, It would be
> > fine with me.
>
> I'll see what I can do, but at the moment I'm pretty busy getting things
> ready for 0.8, so I may not be much good for anything else in the meantime.
>

I have plenty to do myself.  I've been trying finish building my 
woodstrip-epoxy kayak and get some use out of it before the summer is over.

-- 
Joe

Re: [hpoj-devel] ptal-hp changes

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

Joe Piolunek wrote:
> System error 9752 seems to appear with a combination of '-jpeg',  '-res' and 
> either '-bw' or '-bwht'.
> 
> Normally I wouldn't use the command strings below: 
> 
> ]$ ptal-hp mlc:par:0 scan -jpeg -bwht -res 300
> or
> ]$ ptal-hp mlc:par:0 scan -jpeg -bw -res 300
> 
> but when I try them as a test, ptal-hp outputs "Setting resolution to 300." , 
> but doesn't begin the scan.  System error 9752 does appear on the 600's LCD 
> immediately in both cases. I also tried it with -res 100, getting the same 
> result.
> 
> Using the same command lines above but without a '-res' option does not 
> result in the system error, but the scan still won't begin.

-jpeg is only valid with -gray and -color, so that's probably what causes
these problems when it's specified with -bw or -bwht.

> These commands work without trouble:
> ]$ ptal-hp mlc:par:0 scan -jpeg -color
> ]$ ptal-hp mlc:par:0 scan -jpeg -gray
> 
> ptal-mlcd and ptal-printd suffered no noticeable problem during any of this. 
> Quite a few messages appeared in syslog though, ending with "ptal-mlcd 
> successfully activated."

The error messages were likely from when the peripheral locked up, and the
"ptal-mlcd successfully activated" message was from when it re-established
communication after you power cycled the peripheral and accessed it again.

David

Re: [hpoj-devel] ptal-hp changes

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

On Tuesday 03 July 2001 08:40 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

> <...>  Do these scan failures happen when you
> use "-color" (the default) or "-gray" with JPEG output?
>
> In general, if ptal-mlcd dies (with a "FATAL ERROR" message or a segfault),
> it would be helpful if you'd let me know, including the relevant error
> messages, so I can try to fix it.  A misbehaving peripheral should only
> cause ptal-mlcd to deactivate, not to exit.

System error 9752 seems to appear with a combination of '-jpeg',  '-res' and 
either '-bw' or '-bwht'.

Normally I wouldn't use the command strings below: 

]$ ptal-hp mlc:par:0 scan -jpeg -bwht -res 300
or
]$ ptal-hp mlc:par:0 scan -jpeg -bw -res 300

but when I try them as a test, ptal-hp outputs "Setting resolution to 300." , 
but doesn't begin the scan.  System error 9752 does appear on the 600's LCD 
immediately in both cases. I also tried it with -res 100, getting the same 
result.

Using the same command lines above but without a '-res' option does not 
result in the system error, but the scan still won't begin.

These commands work without trouble:
]$ ptal-hp mlc:par:0 scan -jpeg -color
]$ ptal-hp mlc:par:0 scan -jpeg -gray

ptal-mlcd and ptal-printd suffered no noticeable problem during any of this. 
Quite a few messages appeared in syslog though, ending with "ptal-mlcd 
successfully activated."

The CVS I'm using is from July 2.

-- 
Joe

RE: [hpoj-devel] hpoj-0.7 and Kernl 2.4

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

Hi, Charlie.  The "warning: control reaches end of non-void function"
messages in the "ptal" directory are actually OK, because they were
functions I hadn't implemented as of version 0.7.

If running "make" in the hpoj-0.7 directory only builds in the ptal
directory, then check the output you got when running "./configure".
Chances are that it couldn't find the kernel source code with the necessary
include files.

The next version (hpoj-0.8, probably early August) will not need any kernel
source code or include files.  If you don't want to go through the hassle of
installing/recompiling kernel source code to make hpoj-0.7 work, then you
could try downloading the development (not quite stable) code in CVS and see
if that works any better for you.  Once 0.8 is released, then you might want
to switch to that stable version, unless you'd prefer to stay on the
"bleeding edge" and continue to download development updates from CVS.

I hope this helps.

David

> -----Original Message-----
> From: dau [mailto:kar...@fe...]
> Sent: Saturday, June 30, 2001 4:09 PM
> To: hpo...@li...
> Subject: [hpoj-devel] hpoj-0.7 and Kernl 2.4
> 
> 
> Hallo,
> 
> Thank you Burkhard Kohl for your help.
> The problem was :
>     Yast2 , and my way to see things, and do them like I saw 
> , I'v done
> before .
> Not all Scr where installted and so the 'build' wasn't. After a few
> houres, I stept to restart my Installation ( even it was a brand new
> Installation )
> 
> But now, having a better installt SuSE 7.2 , and doing things by
> reading,understanding and then doing .
> I saw that the project has problems with ieee12844 on Kernl 2.4
> 
> Is this still reel ?
> 
> I tring now Kernl 2.2.19, but no doesn't work .
> 
> (see hpoj_on_2..2.19)
> 
> where to i wrong
> I compiled old src, to find out  a
>     hpoj-0.4 OK
>     hpoj-0.5 OK
>     and hpoj-0.6 same as     hpoj-0.7
> 
> make install  installes on /usr/local/lib
> libptal.so   (a symlink to libptal.so.0.1)
> libptal.so.0   (a symlink to libptal.so.0.1)
> libptal.so.0.1
> 
> make don't touche the other Makefile's
> 
> Charlie
> 

RE: [hpoj-devel] ptal-hp changes

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

Joe Piolunek wrote:
> The extension rewriting works too. I mistakenly used the 
> wrong extension not 
> too long ago and got a crash that caused the 600's LCD to 
> display a system 
> error message ( SYSTEM ERROR9752 ) that I hadn't seen before. 
>  If I remember 
> correctly, ptal-mlcd died too. I'm glad you fixed it.
> 
> ]$ ptal-hp mlc:par:0 scan -bw -o page1.jpg
> Setting resolution to 300.
> Scanning page 1 to file "page1.pnm".
> Successfully scanned 1 page.

Hi, Joe.  I doubt the wrong extension had anything to do with locking up the
device, because the extension doesn't affect any of the scan settings that
are sent to the device.  I made a note of this new system error code to look
up.

I see you like to use "-bw" a lot.  Do these scan failures happen when you
use "-color" (the default) or "-gray" with JPEG output?

In general, if ptal-mlcd dies (with a "FATAL ERROR" message or a segfault),
it would be helpful if you'd let me know, including the relevant error
messages, so I can try to fix it.  A misbehaving peripheral should only
cause ptal-mlcd to deactivate, not to exit.

David

Re: [hpoj-devel] ptal-hp changes

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

On Monday 02 July 2001 06:27 am, David Paschal wrote:
> Hi,
>
> Tonight's noteworthy changes to ptal-hp include the following:
>
> - Multi-page (batch) scanning is now supported if you give the optional
> "-multi" switch.  By default this outputs to a series of files named
> "out-01.*", "out-02.*", etc., where "*" is either "jpg" or "pnm".  In
> general, if you specify the "-o" switch, a filename like "foo.jpg" will
> be rewritten into the form "foo-01.jpg".  The optional -pagenum and
> -pagenumdigits switches affect the output filenames accordingly.
>

I did several two-page scans with different options. It worked as expected. 

]$ ptal-hp mlc:par:0 scan -bw -multi -pagenum 3 -pagenumdigits 3
Setting resolution to 300.
Scanning page 3 to file "out-003.pnm".
Scanning page 4 to file "out-004.pnm".
Successfully scanned 2 pages.
]$ ls out*
out-003.pnm  out-004.pnm 

Leaving out the '-pagenum' and '-pagedigits' options worked well too.

]$ ptal-hp mlc:par:0 scan -bw -multi
Setting resolution to 300.
Scanning page 1 to file "out-01.pnm".
Scanning page 2 to file "out-02.pnm".
Successfully scanned 2 pages.
]$ ls out*
out-01.pnm  out-02.pnm


> - If you specify "-o" and don't give a file extension, or you give the
> wrong one of ".pnm" or ".jpg" given the compression setting in use, it
> rewrites the extension appropriately.  In any case, the actual filename
> used is now printed on the screen along with the current page number.
> Hopefully nobody will really want to use the wrong extension.  :-)

The extension rewriting works too. I mistakenly used the wrong extension not 
too long ago and got a crash that caused the 600's LCD to display a system 
error message ( SYSTEM ERROR9752 ) that I hadn't seen before.  If I remember 
correctly, ptal-mlcd died too. I'm glad you fixed it.

]$ ptal-hp mlc:par:0 scan -bw -o page1.jpg
Setting resolution to 300.
Scanning page 1 to file "page1.pnm".
Successfully scanned 1 page.
]$

-- 
Joe

RE: [hpoj-devel] Compiler error with GCC 3.0

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

Alexander Zimmermann wrote:
> I just checked out the latest CVS and got a compiler error when
> using GCC 3.0:
> 
> ExMgr.cpp:1160:1: directives may not be used inside a macro argument
> ExMgr.cpp:1160:1: unterminated argument list invoking macro "printf"
> ExMgr.cpp: In member function `void ExMgr::consoleService()':
> ExMgr.cpp:1161: parse error before string constant
> 
> Seems GCC 3.0 doesn't like  #ifdef  in a the  printf , since 
> printf is a
> macro!!!  ( printf(...)  ->  fprintf (stdout, ...) )

Hi, Alexander.  Thanks for reporting that.  It should be fixed in CVS now.

David

Re: [hpoj-devel] ptal-hp changes

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

> I would be especially interested to hear any feedback on the batch scanning
> and extension rewriting changes above, particularly from Bob Paddock, who
> requested the batch scanning.  And of course, let me know if I broke
> anything.  :-)

I'll let you know.  Right now I'm getting the office recarpeted and need to 
move every thing so it might be a week or so.

Thanks for adding it, and fixing the length problem.

[hpoj-devel] Compiler error with GCC 3.0

[Alexander Z. <Ale...@fm...>]

Hello,

I just checked out the latest CVS and got a compiler error when
using GCC 3.0:

ExMgr.cpp:1160:1: directives may not be used inside a macro argument
ExMgr.cpp:1160:1: unterminated argument list invoking macro "printf"
ExMgr.cpp: In member function `void ExMgr::consoleService()':
ExMgr.cpp:1161: parse error before string constant

Seems GCC 3.0 doesn't like  #ifdef  in a the  printf , since printf is a
macro!!!  ( printf(...)  ->  fprintf (stdout, ...) )

Anyone else with similar experiences ?

(GCC 2.95.2 compiles without problems.)

Bye
-- 
Ale...@fm... / There *is* intelligent life on 
http://www.fmi.uni-passau.de/~zimmerma/ Earth, but I leave for Texas on 
for PGP public key finger            / Monday. 
zim...@yo...     / 

Re: [hpoj-devel] xhpcontrol

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

Joe Piolunek wrote:
> I have some code available for an xhpcontrol app. It looks somewhat like what 
> you last requested (sorry it took so long to respond), but does not yet have 
> any useful abilities. It can be downloaded from my site at
> 
> http://pages.cthome.net/jsp/hpoj-linux-gui/index.html . 
Hi, Joe.  The screenshot looks very much like what I had in mind.  I'll
try to get around to looking at the code soon.

> There is also a patch for hpoj/configure.in that will allow the app to be 
> built under hpoj/apps/ .
I assume that's just for convenience of building and installing.

> There are many parts of the application that need a more experienced coder 
> than me. I can do the "grunt work" of adding the many needed widgets, but the 
> file i/o, plugin architecture, device communication, etc. should be handled 
> by someone with more experience in those areas.  There are also some areas 
> involving Qt that I'm not yet familiar with. If someone wants to and 
> has the ability to help with any of it, It would be fine with me.
I'll see what I can do, but at the moment I'm pretty busy getting things
ready for 0.8, so I may not be much good for anything else in the meantime.
:-)

> The package probably isn't ready to be added to the hpoj module in CVS. Would 
> it be a good idea to temporarily add it to the project as a separate CVS 
> module? Can that be done?
As long as you're the main one doing any work on it, it may be easier to
continue to post it on your website.  On the other hand, if/when I or
somebody else starts helping out in a significant way, then it probably would
be useful to add it to CVS and give out checkin access.  I wouldn't necessarily
be opposed to checking it into /hpoj/apps, because I expect that's where it
would go ultimately.  It wouldn't have to be in the build/install sequence
by default, and I could delete it from the tree before tarring it up if
necessary when I make stable releases.  However, before I start giving out
checkin access, I'd like to set up some sort of "hpoj-cvs" mailing list
for notification on CVS checkins, so I can keep up with what others are
doing and vice-versa.

> I'm not sure which versions of Qt will be necessary to build xhpcontrol. 
> Versions below 2.0 won't work.  It probably would be difficult to make the 
> application compatible with 1.x.x. I don't think it would be worth the 
> trouble. 
By the time xhpcontrol is mature I think it will be reasonable to exclude
Qt versions before 2.0, so I'd say don't worry about it.

David

Re: [hpoj-devel] OJ710 vs 0.97?

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

Hi, Bob.

Bob Paddock wrote:
> I've been using the 550 driver with my OJ710.  I didn't see 710 listed in 
> hpinkjet, any reason I should switch?
The hpinkjet documentation and website don't list any of the OfficeJets
currently.  The DJ6xx driver works on the OfficeJet 500, 600, 700, and
PSC 300 series, but only if you have hpinkjet version 0.96 or later.  You
may get somewhat better print quality than cdj550, but if you're happy with
what you've got then I guess there's no pressing need to go to the trouble
to upgrade.

> I've never been able to get GhostScript to build from source.  Always get 
> some kind of error about unknow size of limit in zdev some thing or other.
Doesn't ring a bell for me.  Lately I've found Google to be pretty helpful
in researching compiler warnings/errors like this.

David

[hpoj-devel] ptal-hp changes

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

Hi,

Tonight's noteworthy changes to ptal-hp include the following:

- Multi-page (batch) scanning is now supported if you give the optional
"-multi" switch.  By default this outputs to a series of files named
"out-01.*", "out-02.*", etc., where "*" is either "jpg" or "pnm".  In
general, if you specify the "-o" switch, a filename like "foo.jpg" will
be rewritten into the form "foo-01.jpg".  The optional -pagenum and
-pagenumdigits switches affect the output filenames accordingly.

- If you specify "-o" and don't give a file extension, or you give the
wrong one of ".pnm" or ".jpg" given the compression setting in use, it
rewrites the extension appropriately.  In any case, the actual filename
used is now printed on the screen along with the current page number.
Hopefully nobody will really want to use the wrong extension.  :-)

- Fixed a bug with scanning on the LaserJets 3200 and 1220 with more than
one page in the document feeder, regardless of whether -multi was given.

I would be especially interested to hear any feedback on the batch scanning
and extension rewriting changes above, particularly from Bob Paddock, who
requested the batch scanning.  And of course, let me know if I broke
anything.  :-)

Of course, none of this applies to those of you who have models that scan
with SANE instead of ptal-hp (flatbed OfficeJets plus scrollfed K and V
series).  Those of you with ADF-equipped models in this category could
instead try the "scanadf" SANE frontend at
"http://www.martoneconsulting.com/sane-scanadf.html".  I haven't tried it
personally, so let me know how it goes if any of you have occasion to try it.

David