hpoj-devel — HPOJ development/support list

[hpoj-devel] PSC 500: Scanning problem

[<mal...@t-...>]

Hello,

  I'm new to Linux and to printing under Linux.  I'm not completely sure if 
this is the right place to ask for advice concerning a scanning problem.  For 
work I have to implement a printing strategy for Linux machines so I'm 
presently into looking at how printing is actually done. So here is the 
story.  I recently bought for home a printer.  At home I run Mandrake 7.2 
with the 2.2.17 kernel and KDE 2.0.  I had my eye on this HP PSC 500 
all-in-one device and checked it out to see if it was supported under Linux.  
I was glad to see it was.  So far I'm doing good printings, although there 
are a few things to adjust here and there I think in order to get better 
photo prints. For instance the sky on the photos is rather filled with little 
dark dots which are not there in the first place.  This could be a gamma 
setting?  Also when I print with the standard font and ps setup in Emacs some 
letters, specifically the 'W', comes out darker.

  But the real problem is with scanning.  I would really like to get it 
going.  I have downloaded SANE 1.0.4 and followed the instructions in the 
SCAN-HOWTO file.  One thing that puzzles me is that the SANE docs seems to 
mention exclusively SCSI interfaces, which I obviously don't have. The err 
msg I get is this:

# scanimage --test
scanimage: no SANE devices found   

To get there I do the following.  Here are the basic modules loaded after 
boot up:

# lsmod

Module                  Size  Used by
emu10k1                42480   1  (autoclean)
soundcore               2800   4  (autoclean) [emu10k1]
r128                   63696   6
agpgart                19728   2  [r128]
hisax                 470096   3
isdn                  104208   4  [hisax]
slhc                    4544   1  [isdn]
3c90x                  21472   1  (autoclean)
nls_cp437               3952  12  (autoclean)
vfat                    9408   6  (autoclean)
fat                    30432   6  (autoclean) [vfat]
supermount             14224   2  (autoclean)


Now I fire up the printer interface with a simple script I made in 
/etc/rc.d/init.d/start_printer:

# cat start_printer

insmod parport
insmod parport_pc
insmod parport_probe
insmod /usr/local/lib/ieee12844.o
insmod /usr/local/lib/ieee12844pp.o
/usr/local/bin/ptal-printd mlc:mlcpp0 -like /dev/lp0 & 


... which yields the following results:

# ./start_printer

Using /lib/modules/2.2.17-21mdk/misc/parport.o
Using /lib/modules/2.2.17-21mdk/misc/parport_pc.o
Using /lib/modules/2.2.17-21mdk/misc/parport_probe.o


Now the modules loaded are as follows:

# lsmod

Module                  Size  Used by
ieee12844pp            15808   0  (unused)
ieee12844              13152   1  [ieee12844pp]
parport_probe           3536   0
parport_pc              7568   1
parport                 7744   1  [ieee12844pp parport_probe parport_pc]
emu10k1                42480   1  (autoclean)
soundcore               2800   4  (autoclean) [emu10k1]
r128                   63696   6
agpgart                19728   2  [r128]
hisax                 470096   3
isdn                  104208   4  [hisax]
slhc                    4544   1  [isdn]
3c90x                  21472   1  (autoclean)
nls_cp437               3952  12  (autoclean)
vfat                    9408   6  (autoclean)
fat                    30432   6  (autoclean) [vfat]
supermount             14224   2  (autoclean)  


And here's the output of the hpo devid command:

# ./hpo devid
MFG:HEWLETT-PACKARD;MDL:PSC500;CMD:MLC,PCL,PML,SCL;CLS:PRINTER;DES:Hewlett-Packard 
PSC 500;CMT:OFFICEJET 
PRO;SERN:MYJ0AE33X8WZ;VSTATUS:$HB0$FC0,ff,DN,IDLE,CUT;LSS:01;LDF:1;LDE:1;   


So, why is there no SANE device recognized by the system?


Regards,


Alain

[hpoj-devel] bottom bit of page missing

[Carlos P. <cp...@ro...>]

hi, i seem to be having trouble when printing some specific
printouts with enscript, which i use a lot. i am using the 0.7 with
the init script on 2.2.16-3smp with great success. thanks
to david and joe and tim, and everyone else for the help!

i do not get any more overruns as i used to, it seems.
however, i still get this cropping at the bottom of the page.

if i print this:

123456
123456
123456

with nenscript -2rG, the column with the 1 does not show up.
any ideas on how to configure things so that it prints?
(it is a bit tricky when printing code or travel reservations
not to be able to read the first column :-)

there may be other parts that don't show up in the page, but
i have not tested them.

the redhat 6.2 printtool postscript test page actually shows
all the boxes. the bottom one actually falls right on top
of the column of the "2" in my test page. also in my test page,
the date/time and the page number at the top right (when 
looked in landscape, of course), protrude about 1/3 of the box
outside of the line in the redhat test page.

attached is my test print page.

thanks in advance for any tips/ideas. perhaps this could go to a faq?

-carlos

=====
C. Puchol <cp...@ro...>

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

[hpoj-devel] Problems wih hpoj 635c sourcecode

[Johan L. <j.l...@ch...>]

Hello all,

Recently I downloaded the sourcecode hpoj-0.6 for my
HP OfficeJet for working with it under RH Linux 6.2.

Now I have some problems with the software. I appriciate
some help solving these problems.

Problem 1.

Printqueue stops and LC panel is frozen dead when printing 
more than one job. When killing the xojpanel process 
printing resumes normal operation. I cut out some
messages for successfully loading the ieeedrivers and 
the messages where it goes wrong.

loading...
Dec 29 07:43:54 johan kernel: parport0: PC-style at 0x378 (0x778)
[SPP,ECP,ECPEPP,ECPPS2]                          
Dec 29 07:43:54 johan kernel: parport0: detected irq 7; use procfs to enable
interrupt-driven operation.           
Dec 29 07:43:54 johan kernel: parport0: Printer, Hewlett-Packard OfficeJet
Series 600                              
Dec 29 07:43:54 johan kernel: IEEE1284.4 protocol layer for Linux
installed                                        
Dec 29 07:43:54 johan kernel: ieee12844pp: IEEE1284.4 device found on
parport0:                                    
Dec 29 07:43:54 johan kernel:    Hewlett-Packard OfficeJet Series
600;                                             
Dec 29 07:43:54 johan kernel:    device registered to IEEE1284.4 protocol layer
as link mlcpp0                     

error...
Dec 29 07:58:06 johan kernel: lp0: using parport0
(polling).                                                       
Dec 29 07:58:45 johan kernel: mlc: mlcpp0: Got MLCError
08                                                         
Dec 29 07:58:46 johan lpd[854]: restarting
lp                                                                      


Problem 2.

I'd like to scan with the OfficeJet so I downloaded the
sane sourcecode and applied your patch. I followed your
instructions in the documentation. I discovered the two
lines: "checking for ptal.h... yes" and "checking for
ptalInit in -lptal... yes" while configuring.
When I make a test scan with scanimage --test the following 
errors are reported (I turned on some debug coding):

[johan@johan johan]$ scanimage --test
[sanei_debug] Setting debug level of hp to 128.
[hp] sane_init called
ptalInit(): debug level set to 2.
ptalInit()
ptalDeviceProbe: dev=<mlc:mlcpp0>.
ptalDeviceAdd(provider=<mlc>,name=<mlcpp0>): dev=0x0804E5A8.
ptalDeviceProbe: dev=<mlc:mlcpp1>.
ptalDeviceAdd(provider=<mlc>,name=<mlcpp1>): dev=0x0804E5D0.
[hp] sane_init will finish with Success
[hp] sane_get_devices called
[hp] hp_read_config: hp backend v0.91 starts reading config file
[hp] hp_read_config: processing line <mlc:mlcpp0>
[hp] hp_read_config: processing line <option connect-ptal>
[hp] hp_read_config: attach mlc:mlcpp0
[hp] hp_get_dev: New device mlc:mlcpp0, connect-ptal, scsi-request=0
ptalMlcDeviceOpen(name=<mlcpp0>): found matching dev=0x0804E5A8.
ptalChannelAllocate(dev=0x0804E5A8): chan=0x080526A0.
ptalChannelSetRemoteService(chan=0x080526A0,serviceType=2,socketID=0,serviceName=<>)
[hp] scsi_flush: writing 2 bytes:
[hp]  0x0000  1B 45                                            .E
ptalMlcChannelOpen(chan=0x080526A0): error connecting socket!
ptalChannelOpen(chan=0x080526A0): provider failed open!
[hp] hp_nonscsi_device_new: SCL reset failed
[hp] scsi_close: closing fd -1
ptalChannelClose(chan=0x080526A0)
[hp] sane_get_devices will finish with Success
scanimage: no SANE devices found
[hp] sane_exit called
[hp] sane_exit will finish
[johan@johan johan]$ 

Is there someone who can tell me what is wrong and what
I have to do to solve the problems?

Kind regards,

Johan Laagland,
The Netherlands.

[hpoj-devel] hpoj cmdline problem

[Carl B. P. <cb...@co...>]

Hi there,

I have previously tested an older version of hpoj on a AMD K6 300Mhz and =
a
HP Officejet 590.

Now I have downloaded version hpoj-0.7 and compiled it on a SUSE 6.3 with=

kernel 2.2.18, using the same hw.

Using the hpo to scan, hpo scan bw, it always ended in a segmentation fau=
lt
which annoyed me.

Using gdb, I traced the problem to PMLClose() in  pml.c.

void PMLClose(void)
{
  static trap_t *curtrap;

    /* Unregister all traps */
  while(traps !=3D NULL)
  {
    PMLUnregisterTrap(traps->oid);
    PMLProcess();

    curtrap =3D traps;     <---------- CRASHED HERE!!!
    traps =3D traps->next;
    free(curtrap);
  }

  free(rcv_buf);
  MlcCon_close(connection);
  delete_MlcCon(connection);
}

After the PMLUnregisterTrap(), the traps pointer might be NULL because th=
e
trap might have been free'd.

Adding a test after PMLProcess((), no more segmentation faults appears.

void PMLClose(void)
{
  static trap_t *curtrap;

    /* Unregister all traps */
  while(traps !=3D NULL)
  {
    PMLUnregisterTrap(traps->oid);
    PMLProcess();

    if( traps =3D=3D NULL )    <--- Added
      break;                    <--- Added.
    curtrap =3D traps;
    traps =3D traps->next;
    free(curtrap);
  }

  free(rcv_buf);
  MlcCon_close(connection);
  delete_MlcCon(connection);
}

Now is the problem to figure out how to use the scanned data.
The 590 is not supported by the current SANE interface(ptal-connect) as f=
ar
as I can figure out.

Haven't tried the printing yet as one of the std. HP deskjet drivers
usually works.


Carl B. Pedersen
e-mail: cb...@co...

[hpoj-devel] About initscripts-printd.tgz

[Timothy L. <ti...@wo...>]

Alexander Zimmermann wrote:

> Did I miss something?  Because I don't remember where to get
>
> > Source1: initscripts-printd.tgz
>

The content of initscripts-printd.tgz is:

     etc/rc.d/init.d/ptal-printd
     etc/ptal-printd.conf

Those files were discussed in this mailing list from a week back.  I'm
using tgz in the RPM so the parent directories are created for me when I
unzip them.


     Timothy Lee

[hpoj-devel] Re: ptal-printd init script for RedHat

[DG <dg...@um...>]

From: pa...@rc... (David Paschal)
>> My question: is the device list fixed for ieee12844.o during
>> loading, or is it updated dynamically? If not, there'll definitely
>> be a problem with OfficeJets that were not turned on during boot up (must
>> remove modules by hand, or wait for cron to clean up autoload modules).
>The device list for ieee12844pp (not ieee12844) comes from whatever was
>connected and powered on when parport_probe was loaded.  So if you forgot
>to turn on your peripheral before booting, then you need to unload both
>ieee12844pp.o and parport_probe, then reload parport_probe and
ieee12844p.o.

Does the device try to communicate with the computer when it is turned on? 
If so, the module could look for this signal and add the device when turned
on.

Windows can handle having the device turned on or off arbitrarily.  How is
it done?

--
Daniel
ZZZ-dgun-ZZZ-@-ZZZ-umpire.com-ZZZ
(Remove the Z-'s to reply)
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

[hpoj-devel] using sbindir for ptal-printd and a SuSE-RPM

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

Hi great developers.

I am completely new to this list, so be gentle.

I have downloaded the stable version 0.7, but I consider it relevant to
put the ptal-printd in the sbindir instead of the bindir. I have changed
the Makefile.in, and configure.in, configure accordingly, and made a
diff-file (attacehd)

I am also working on a SuSE-7.0-pro RPM. I am also quite new to RPM
building. It install quite allright, but I am very unsure about the
dependancies, so don't trust them (yet).

The RPM also contains the patch. feel free to put it on the web :-)

I Hope you find it usefull.

Jarl

Re: [hpoj-devel] ptal-printd txt file

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

Richard Phillips wrote:
> I want to capture output of ptal-printd (ptal-printd > foo.txt) but 
> foo.txt never contains any content, whether running as root or user.
> 
> Tried variations with cat and lpr but no luck. Not a serious prob - but 
> any solutions appreciated.

Hi, Richard.  What exactly are you trying to do here?  Normally ptal-printd
doesn't display anything on standard output unless an error occurs.  It
just sits around waiting for data to be written to a pipe and then sends it
to the printer.

David

[hpoj-devel] ptal-printd txt file

[Richard <ric...@bt...>]

I want to capture output of ptal-printd (ptal-printd > foo.txt) but 
foo.txt never contains any content, whether running as root or user.

Tried variations with cat and lpr but no luck. Not a serious prob - but 
any solutions appreciated.

Using hpoj-0.7, seems to have compiled/installed fine on Mandrake 7.2.


Thanks!


Richard Phillips

Re: [hpoj-devel] More details about RedHat SRPM file

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

Timothy,

On 27 Dec, Timothy Lee wrote:
> I've including a copy of the latest SRPM spec file for anyone
> interested.

Did I miss something?  Because I don't remember where to get

> Source1: initscripts-printd.tgz

?

Thanx in advance
-- 
Ale...@fm... / No man is useless who has a
http://www.fmi.uni-passau.de/~zimmerma/ friend, and if we are loved we
for PGP public key finger            / are indispensable.   -- Robert
zim...@yo...     / Louis Stevenson 

[hpoj-devel] Re: More details about RedHat SRPM file

[Timothy L. <ti...@wo...>]

Timothy Lee wrote:

> The RPM now inserts these two entries into conf.modules (or modules.conf
> if it exists):
>
>      alias net-pf-24 ieee12844
>      alias mlclink-mlcpp0 ieee12844
>

Oops....   make the last line "alias mlclink-mlcpp0 ieee12844pp".......
:-)  Sorry.

I've fixed that in my SRPM spec file.


     Timothy

[hpoj-devel] Forking of ptal-printd

[Timothy L. <ti...@wo...>]

David Paschal wrote:

> Would it make more sense to fork or not fork by default
> (changeable by a command-line option)?
>

Umm...  if you intend ptal-printd to be run by regular users, default to
*not* fork.  Saves typing an extra flag.  ;-)

Add an option like -daemon to enable forking of child process, I
suppose.

David Paschal wrote:

> Part of the problem was that it wasn't immediately obvious what the most
> appropriate recovery was for each of the possible errors.  I suppose it's
> OK to exit if an error occurs during startup, for example, failure to create
> the pipe.
>

Yes, I think you can exit upon failing to create the pipe.  As for the
other run-time conditions you mentioned, here are my suggestions:

   * Failure to open the pipe / failure on select () ---- Just discard
     the data
   * Failure to open peripheral ---- can ieee12844pp.o force ieee12844.o
     to re-scan for new peripherals???  If not, I'd say discard the data
   * Failure to write data to the peripheral ---- maybe a retry
     threshold, after which data are discarded?

One more thing, about the ieee12844.c and ieee12844pp.c:  the static
variable *debug* should be initialized to 0.  Most end-users probably
don't want to see messages popping up on their consoles.....  <grin>


     Timothy

[hpoj-devel] More details about RedHat SRPM file

[Timothy L. <ti...@wo...>]

I've including a copy of the latest SRPM spec file for anyone
interested.

Joe Piolunek wrote:

> Re your SRPM - can you make it relocatable?
>

Yes, the resultant RPM file is relocatable.

During installation of the RPM, the user can use the --prefix flag to
adjust the location of the files, eg:

     rpm -U --prefix /usr/local hpoj-0.7-2.rpm

David Paschal wrote:

> One problem I see with this layout is that the $PREFIX/share/pixmaps/hpoj
> directory is missing, which contains pixmaps required by xojpanel.
>

Oops...  I did miss those....  Probably because my PSC500 can't be used
with xojpanel, so I never noticed...  <laugh>

OK, that's fixed.

David Paschale wrote:

> > Note that I've relocated ieee12844.o and ieee12844pp.o to
> > /lib/modules/boot.  This way, they will be picked up by depmod at boot.
> > I'm tempted to insert the *alias* entries into conf.modules for the user
> > during installation, what's your opinion?
> What are the alias entries?
>

The RPM now inserts these two entries into conf.modules (or modules.conf
if it exists):

     alias net-pf-24 ieee12844
     alias mlclink-mlcpp0 ieee12844

These entries correlates to the *ptal-printd.conf* file that comes with
the RPM.  I have left out the alias for parport_lowlevel, since hpoj is
intended to be cross-platform.  The user must add that entry manually,
depending on the machine architecture.

During uninstall, those exact two entries will be removed from
modules.conf.


     Timothy

Re: [hpoj-devel] Color Printing problems solved

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

On Tuesday 26 December 2000 08:03, Rainer Dorsch wrote:
> Hello,
>
> I just wanted to mention, that I solved the color printing problems,
> reported yesterday (stupid problem, someone forgot to remove the foil from
> the newly inserted ink tank).
>
> But in general, the printing quality is somewhat poor. Even for a
> completely bw printout (even ascii without gs), horizontal stripes are in
> the printout. Has anybody seen this problem before?
>
> Thanks
>
> Rainer.

Do the stripes look like they are caused by missing ink, or smeared ink? The 
fixes are different.

If one or more of the nozzles are clogged, (missing ink) it can sometimes be 
fixed by using the 'cleaning' function in the HP windows software. If that 
won't work for you, get a new ink cartridge. Usually the first sign of 
missing ink means that the cartridge will need to be replaced soon.

If you see horizontally smeared or dragged ink, take the ink cartridges out 
and clean under the carriage that holds them. Also check the carriage parking 
area (probably to the right) for ink-soaked debris such as cat hair, lint, 
paper fibers, etc. You need to be careful when cleaning these parts. There is 
help available in the HP windows software.

If you don't have access to the cleaning instructions, here is what you can 
do, but be careful.

Open the cover, wait for the ink carriage to move to the center, then shut 
off and (important for safety) disconnect all wires and cables from the 
printer.

Take out the ink cartridges.

Get some cotton swabs (often sold under the "Q-tip" brand in the US). Dip one 
in warm water, then roll it between your fingers to make sure it can't drip 
or lose fibers inside the printer. Use it to wipe any collected ink or debris 
from around and underneath the ink carriage where the print heads were. 
Repeat until the area is clean. Be careful not to touch any of the electrical 
contacts. On the right (probably), there is a parking area with four small 
rubber parts that may have debris on them. Very gently clean them with the 
damp swabs. Avoid touching the rubber parts with your fingers.

If you accidentally get a drop of water in the printer, don't allow it to 
remain.

-----------------------------------------------------

Here's an odd printer service problem that occurred to me last spring - It's 
not related to your trouble, but I though I'd tell it here.

--
My OfficeJet 600 had some kind of problem that caused the paper to jam every 
time I tried to use the printer.  I barely remembered hearing 'snapping' 
noises coming from the printer a couple of days previously, so I was a little 
worried.

After pulling out the easily removable parts, I could see the the cause. The 
printer was suffering from a 'hardware bug'. Resting against a roller was a 
large (by now dead) hard-bodied beetle.

After a cleanup, the printer works fine.

-- 
Joe Piolunek

[hpoj-devel] Color Printing problems solved

[Rainer D. <rai...@in...>]

Hello,

I just wanted to mention, that I solved the color printing problems, reported 
yesterday (stupid problem, someone forgot to remove the foil from the newly 
inserted ink tank).

But in general, the printing quality is somewhat poor. Even for a completely 
bw printout (even ascii without gs), horizontal stripes are in the printout. 
Has anybody seen this problem before?

Thanks

Rainer.

Re: [hpoj-devel] Color Printing on the 600er series

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

Rainer Dorsch wrote the following excerpts:
> I am running a HPOJ 635
> and did not manage to do color printing.
> All color 
> postscript files end up with being printed black and white, e.g.
> 
> # /usr/bin/gs  -q -dSAFER -dNOPAUSE -r300 -sDEVICE=cdj550 
> -sOutputFile=test.pcl /home/rd/tiger.ps
> #cat test.pcl > /dev/ptal-printd/mlc_mlcpp0

Hi, Ranier.  Try using one of the following parameters: "-dBitsPerPixel=32"
or "-sBitsPerPixel=32".  I'm too accustomed to using RedHat printtool, so I
had to look this up in the ghostscript documentation.

Thank you for providing the Debian startup script.  I'm a little
attachment-impaired at the moment, so I'll take a look at it later.

David

[hpoj-devel] ptal-printd

[Rainer D. <rai...@in...>]

Hello,

just a small comment to the ptal-printd:

- It makes the setup a lot easier

I attached the start/stop file for a Debian Linux system 
(/etc/init.d/ptal-printd).

Links from /etc/rc?.d/ have to be set to start and stop the daemon.

Rainer.

[hpoj-devel] Color Printing on the 600er series

[Rainer D. <rai...@in...>]

Hello,

I am running a HPOJ 635

# hpo devid
MFG:Hewlett-Packard;MDL:OfficeJet Series 
600;CMD:MLC,PCL,PML;CLASS:PRINTER;REV:4.05c;

and did not manage to do color printing. I downloaded the hpoj-0.7 and 
gs-6.50, read the thread 

[Hpoj-devel] color printing in OfficeJets 300/500/600/700 

in the hpoj mailing list in september. And still the same problem. All color 
postscript files end up with being printed black and white, e.g.

# /usr/bin/gs  -q -dSAFER -dNOPAUSE -r300 -sDEVICE=cdj550 
-sOutputFile=test.pcl /home/rd/tiger.ps
#cat test.pcl > /dev/ptal-printd/mlc_mlcpp0

Has anybody ever seen a color output from a hpoj of the 600er series?

Thanks a lot.

Rainer

Re: [hpoj-devel] Source RPM for hpoj-0.7

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

Timothy Lee wrote:
> I've packaged hpoj-0.7 into a SRPM.  It includes the revised version of
> the init script.  After compilation, the layout the of resulting RPM
> will be as follows:
(file list skipped)
One problem I see with this layout is that the $PREFIX/share/pixmaps/hpoj
directory is missing, which contains pixmaps required by xojpanel.

I assume that when one builds an RPM from the SRPM using the instructions you
previously sent me, the configure script is invoked before compiling the
source.  If you're going to install under /usr instead of /usr/local, make
sure you pass the --prefix=/usr option to ./configure to ensure that the
correct pixmap path is specified when xojpanel gets compiled.

Please make sure you make it clear in the SRPM what changes (relative to 0.7)
you made, for example, adding the init script and .conf file.

> Note that I've relocated ieee12844.o and ieee12844pp.o to
> /lib/modules/boot.  This way, they will be picked up by depmod at boot.
> I'm tempted to insert the *alias* entries into conf.modules for the user
> during installation, what's your opinion?
What are the alias entries?

> I'm waiting for more feedback on the init script before finalizing the
> package.  When that's done, I'll post the SRPM in this mailing list, and
> you can put it on CVS.
I don't think it's appropriate to put the SRPM itself in CVS, but I will make
it available from the download page along with the instructions you sent me
on how to build the RPM.

David

Re: [hpoj-devel] ptal-printd init script for RedHat

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

Joe Piolunek wrote:
> I think David would like users to be able to start a copy of the daemon, so 
> could you make that easier? /var/lock/subsys is only writable by root, so a 
> user's lock file would need to go somewhere else.
Although I think it should be OK for non-root users to start ptal-printd,
the init script and .conf file are special in that they indicate the
"official" policy for a system, so I think it's OK that they are root only.

Timothy Lee wrote:
> The script was written with root in mind:  to make administrating the
> system easier.  It doesn't stop the user from running a local copy of
> the darmon.  (But it *will* kill all daemons when stopped.)
In other words, users can run the daemon directly, but not the init script.
If the init script is called to stop ptal-printd, then all instances of the
daemon are killed, even those started without the init script.  Sounds
reasonable to me.

Timothy Lee wrote:
> The script now checks for ptal-printd and the config file before
> launching the daemon and reporting success.  It's hard to check for
> errors because the daemon doesn't fork itself and return.  (Maybe it's a
> feature David will consider adding???  <grin>)
Yes, I'll fix that.  Would it make more sense to fork or not fork by default
(changeable by a command-line option)?

David

Re: [hpoj-devel] 2nd try at RedHat init script

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

On Thursday 21 December 2000 23:05, Timothy Lee wrote:

> > First off, Dag, sorry about the HTML format.
>
> I've made some changes to the script, and this time I'm including it as
> an attachment
> -- hope that solves the problem. 

Timothy: 

Thanks for making the changes to your script. It looks better now, but I 
think I see a (minor) problem with the expected file locations.  If the 
script were being installed as part of a redhat distribution, the expected 
locations would be correct, but to be in compliance with the filesystem 
hierarchy standard, user installed apps should go under /usr/local. 
http://www.pathname.com/fhs/2.0/fhs-4.6.html
It should be easy enough to create symlinks during the install though, so it 
might not be a big deal.

Re your SRPM - can you make it relocatable?


>Guess I'll stick to text format with
> this list just so everyone could read the stuff...  <grin>

My thanks for that too.


> The script now checks for ptal-printd and the config file before
> launching the daemon and reporting success.  It's hard to check for
> errors because the daemon doesn't fork itself and return.  (Maybe it's a
> feature David will consider adding???  <grin>)

You can check if the process got a PID, but that really isn't the best 
solution.

I think David will consider additions to ptal-printd, but we'll have to wait 
for his reply. 

The hpoj project is still in its infancy, really. There are many improvements 
to be made before it approaches the usefulness of the windows officejet 
software.


> The script was written with root in mind:  to make administrating the
> system easier.  It doesn't stop the user from running a local copy of
> the darmon.  (But it *will* kill all daemons when stopped.)

It should work well for that purpose.

-- 
Joe

Re: [hpoj-devel] Re: ptal-printd init script for RedHat (David Paschal)

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

Timothy Lee wrote:
> There's one problem I've found with ptal-printd using the initscript.
> There is another problem related to the loadable modules. The situation
> goes likes this:
> ptal-printd will start with the printer off, but if I try to
> print, it quits. After reading through the source code, it appears
> that any manner of error will cause ptal-printd to exit.
> In my opinion, error conditions should be logged, but the daemon should
> just continue to run. Otherwise the machine will be left in a broken
> state, thinking the ptal-printd subsystem is running, when in fact the
> daemon is long gone.
My fault -- sorry about that.  I'll clean up my sloppiness later.  :-)

Part of the problem was that it wasn't immediately obvious what the most
appropriate recovery was for each of the possible errors.  I suppose it's
OK to exit if an error occurs during startup, for example, failure to create
the pipe.  But there are several causes of error at runtime:
- Failure to open the pipe (possibly because somebody deleted it).
- select() fails on the open pipe (I don't know why).
- Failure to open a connection to the peripheral (such as you described above).
- Failure to write data to the peripheral.

In all four cases there is data that needs to be sent to the peripheral, so
if I fix ptal-printd so it doesn't abort, what do you think I should do with
the data?  I could just discard the data (after logging a message, of course),
or in the case where I can't open the peripheral, I could periodically retry.

Speaking of logging, I probably should use syslog, not just printf.

> My question: is the device list fixed for ieee12844.o during
> loading, or is it updated dynamically? If not, there'll definitely
> be a problem with OfficeJets that were not turned on during boot up (must
> remove modules by hand, or wait for cron to clean up autoload modules).
The device list for ieee12844pp (not ieee12844) comes from whatever was
connected and powered on when parport_probe was loaded.  So if you forgot
to turn on your peripheral before booting, then you need to unload both
ieee12844pp.o and parport_probe, then reload parport_probe and ieee12844p.o.

David

Re: [hpoj-devel] 2nd try at RedHat init script

[Dag N. <da...@ne...>]

ti...@wo... said:
> First off, Dag, sorry about the HTML format.
> I've made some changes to the script, and this time I'm including it
> as an attachment -- hope that solves the problem.  Guess I'll stick to
> text format with this list just so everyone could read the stuff...
> <grin> 

Thanks Timothy,
that was a lot easier.
Actually an HTML message with an attachment would
have been fine as well, but it is usually better to stick
to HTML on Webpages and plain text in emals. ;-)

BRGDS

Dag

[hpoj-devel] Source RPM for hpoj-0.7

[Timothy L. <ti...@wo...>]

David,

I've packaged hpoj-0.7 into a SRPM.  It includes the revised version of
the init script.  After compilation, the layout the of resulting RPM
will be as follows:

     /etc/ptal-printd.conf
     /etc/rc.d/init.d/ptal-printd
     /lib/modules/boot/ieee12844.o
     /lib/modules/boot/ieee12844pp.o
     /usr/bin/addcr
     /usr/bin/addpjl
     /usr/bin/hpo
     /usr/bin/ieee12844_print
     /usr/bin/ptal-connect
     /usr/bin/ptal-print
     /usr/bin/ptal-printd
     /usr/bin/xojpanel
     /usr/doc/hpoj-0.7
     /usr/doc/hpoj-0.7/INSTALL
     /usr/doc/hpoj-0.7/LICENSE
     /usr/doc/hpoj-0.7/PRINT-HOWTO
     /usr/doc/hpoj-0.7/README
     /usr/doc/hpoj-0.7/SCAN-HOWTO
     /usr/include/ptal.h
     /usr/lib/libptal.so
     /usr/lib/libptal.so.0
     /usr/lib/libptal.so.0.1

Note that I've relocated ieee12844.o and ieee12844pp.o to
/lib/modules/boot.  This way, they will be picked up by depmod at boot.
I'm tempted to insert the *alias* entries into conf.modules for the user
during installation, what's your opinion?

I'm waiting for more feedback on the init script before finalizing the
package.  When that's done, I'll post the SRPM in this mailing list, and
you can put it on CVS.


     Timothy Lee

[hpoj-devel] 2nd try at RedHat init script

[Timothy L. <ti...@wo...>]

First off, Dag, sorry about the HTML format.

I've made some changes to the script, and this time I'm including it as
an attachment
-- hope that solves the problem.  Guess I'll stick to text format with
this list just so everyone could read the stuff...  <grin>

Joe Piolunek wrote:

> The script reports success even if the daemon doesn't really start. It
> happened when the paths were incorrect. Add some error control features
> and/or a message to indicate failure if it occurs. Don't create a lock file
> unless the daemon sucessfully starts.
>

The script now checks for ptal-printd and the config file before
launching the daemon and reporting success.  It's hard to check for
errors because the daemon doesn't fork itself and return.  (Maybe it's a
feature David will consider adding???  <grin>)


> I think David would like users to be able to start a copy of the daemon, so
> could you make that easier? /var/lock/subsys is only writable by root, so a
> user's lock file would need to go somewhere else.
>

The script was written with root in mind:  to make administrating the
system easier.  It doesn't stop the user from running a local copy of
the darmon.  (But it *will* kill all daemons when stopped.)


     Timothy Lee