hpoj-devel — HPOJ development/support list

Re: [hpoj-devel] (no subject)

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

On Mon, 25 Sep 2000, Erik Hendrix wrote:
> Hi there,
> 
> First of all a big THANK YOU to the developers for this driver.
> 
> But sadly enough, I'm having some problems getting the driver to  work. So 
> if anyone would be so kind to tell me what to do or what I
> did wrong. Thank you.
> 
> I installed :
>    APSFILTER
>    A2PS
>    Ghostscript
>    and offcourse the 0.6 HPOJ driver
> 

I have no experience with apsfilter or a2ps, but maybe someone here who does
could help you.

It would be helpful if you could post back giving some extra information such as
your operating system type and version, and whether or not your printer daemon
is running.

If you are using lpd, find it this way:

]$ pidof lpd

Do you see any error messages at boot? If so, write them down exactly.

Someone will probably be able to help you (at least they'll try), but they seem
to have been very busy lately.

---------
Joe Piolunek

[hpoj-devel] (no subject)

[Erik H. <hen...@ho...>]

Hi there,

First of all a big THANK YOU to the developers for this driver.

But sadly enough, I'm having some problems getting the driver to  work. So 
if anyone would be so kind to tell me what to do or what I
did wrong. Thank you.

I installed :
   APSFILTER
   A2PS
   Ghostscript
   and offcourse the 0.6 HPOJ driver

   The driver seems to be working fine since I can get the status of
   my printer.
   But when I try to print something nothing happens.

   My printcap file is as follow :

          # /etc/printcap
          #
          # Please don`t edit this file directly unless you know what you 
are doing!
          # Be warned that the control-panel printtool requires a very 
strict format!
          # Look at the printcap(5) man page for more info.
          #
          # This file can be edited with the printtool in the control-panel.

          ##PRINTTOOL3## LOCAL
          lp0:
                  :sd=/var/spool/lpd/lp0:
                  :mx#0:
                  :sh:
                  :lp=/dev/lp0:
                  :if=/var/spool/lpd/lp0/wrapfilter:
          # LABEL apsfilter
          # apsfilter setup Fri Sep 22 01:39:21 PDT 2000
          #
          # DON`T DELETE THIS:
          # APS_BASEDIR:/root/linux/rpms/apsfilter
          #
          # APS1_BEGIN:printer1:deskjet::default
          # - don`t delete start label for apsfilter printer1
          # - no other printer defines between BEGIN and END LABEL
          #
          lp|aps1-deskjet--auto-default|Printer1 deskjet  auto default:
              :lp=/dev/lp0:
              :sd=/var/spool/lpd/printer1-deskjet--auto-default:
              :lf=/var/spool/lpd/printer1-deskjet--auto-default/log:
              :af=/var/spool/lpd/printer1-deskjet--auto-default/acct:
              
:if=/root/linux/rpms/apsfilter/filter/aps1-deskjet--auto-default:
              :mx#0:
              :sh:
          raw|aps2-deskjet--raw|Printer1 deskjet  raw:
              :lp=/dev/lp0:
              :sd=/var/spool/lpd/printer1-deskjet--raw:
              :lf=/var/spool/lpd/printer1-deskjet--raw/log:
              :af=/var/spool/lpd/printer1-deskjet--raw/acct:
              :if=/root/linux/rpms/apsfilter/filter/aps2-deskjet--raw:
              :mx#0:
              :sh:
          # APS1_END - don`t delete this END LABEL for printer1



  I created the apsfilterrc.deskjet file in my /etc directory.
  This file contains the following line :
      REMOTE_PRINTER="/usr/local/bin/ieee12844_print"

  I also created the wrapfilter program and made it executable.
  This file is located in : /var/spool/lpd/lp0

  As far as I can see everything is allright. But it isn`t since I
  can`t print. The big question for me now is what did I do wrong?

  Any help is REALLY appreciated.

Thank you.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Re: [hpoj-devel] Fw: Bug report

[Burkhard K. <bu...@bu...>]

> From: "Randy Miller" <mil...@ya...>
> To: <hpo...@bs...>
> Sent: Sunday, September 24, 2000 10:51 PM
> Subject: Bug report
> 
> 
> > Hi,
> > I got the following error when I executed 'hpo devid':
> > 
> > Error 0 (system error 107) in file mlccon.c, line 110:
> > Unexpected Error, please post a bug report to
> > hpo...@bs...
> > 
> > Thanks,
> > Randy Miller
> > 
Randy, your bug report has been forwarded to hpo...@li...
which is the new home of the hpoj-devel mailing list. Could you please give
us some more details as 
- which version of hpoj you are using.
- which kernel version
- which hpoj model

Did you take a look at your /var/log/messages file. It should contain
a line from ieee12844[pp].o reporting the state of the driver. Could
you please post that as well.

Burkhard
-- 
Burkhard Kohl			bu...@bu...

Re: [hpoj-devel] Re:[Patch v2] hpoj now running with 2.4 kernel

[Burkhard K. <bu...@bu...>]

damcha wrote:
> Here is the patch which includes both Burkhard's and mine.
> It now compile on 2.4.0-test9. Please report comments in the ML.
> 

I am afraid, but I have to correct my own patch. Although it now
runs, I made an ugly typo and did not get the while-loop right in 
in mlc_recvmsg(). Damcha, would you incorporate my corrections
into your patch? Is it o.k. for you to maintain the kernel
module part of the project? I will send you my corrections with a
separate mail.

I am still concerned about the msghdr flag issue, which I don't
fully understand. 
With the 2.4 kernel we see an MSG_EOR flag set. Does that mean
we have to hand this flag further on to the next layer or does
it mean we are expected to perform some additional action.
As I noticed from Alan Cox comments in socket.[ch] not all
flags which are defined in IEEE1003.1 are implemented, but
later kernel versions might change that. 
Some flags obviously correspond to some service or type 
of service. If these flags are set and we have not implemented
this type of service, what is the correct behaviour.? Just
return with -EOPNOTSUPP? Or might it be appropriate to 
silently ignore some flags? 
O
I have to admit, that I don't know much about sockets and
their represation within the kernel. 

Furthermore I am wondering about the correct handling of the
DONTWAIT flag. nonblock is set to 0 unconditionally, but 
obviously we should accept this flag. On the other hand 
what sense does it make to accept a flag and ignore it?
On the other hand I have never seen the DONTWAIT flag being
set, does it mean, we can savely reject it?

Burkhard
-- 
Burkhard Kohl			Tel/FAX: +49 30 698 15 905
Melchiorstr. 8			bu...@bu...
10179 Berlin			

Re: [hpoj-devel] (Unofficial patch) 2nd patch to hpoj for 2.4

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

da...@cy... said:
> I'm sorry everybody but Burkhard's new patch didn't make its way into
> my mailbox when I posted mine. 

My bad.  The mailing list was configured not to allow postings greater than
40KB.  I didn't check my e-mail until later in the day, when I found the
notices about both of your messages' getting held for approval.  Sorry about
that!  For now it's set to "unlimited".

Many thanks to both of you for working on these problems.  Since I have
neither 2.4 (yet) nor SMP, let me know when you think it's stable and I'll
do some testing with 2.2 and put out another release.

BTW, there is still another problem with the kernel drivers which causes
more-or-less random lockups of the client process, for example, when doing
a large scan.  If you're able to do anything about that or even just have
any ideas on what could be causing it, it would be much appreciated too.  :-)

David

[hpoj-devel] Re:[Patch v2] hpoj now running with 2.4 kernel

[damcha <da...@cy...>]

Here is the patch which includes both Burkhard's and mine.
It now compile on 2.4.0-test9. Please report comments in the ML.


On dim, 24 sep 2000 17:12:18 Burkhard Kohl wrote:
> Hello everyone,
> 
> this patch is intended to make hpoj run under 2.4 kernel versions.
> It removes a bug from the mlc_sendmsg call in ieee12844.c module,
> which prevented a successfull write to the hpoj device,
> fixes the layout of the mlc_proto_ops structure in ieee12844pp,
> replaces the start/end_bh_atomic primitives to allow for use of 
> their 2.4 counterparts and sets the __SMP__ define depending 
> on the setting in /usr/include/linux/config.h so it is in alingment
> with the kernel configuration in /usr/src/linux. 
> 
> I you want to force an particular __SMP__ setting independantly
> of any kernel configuration, you have to edit the Makefile
> in ieee hpoj-0.6/ieee12844 and uncomment on of the FORCE_SMP
> line at top of the file.
> 
> I'd like to ask everybody with a 2.4 kernel to test this code and
> report succes or failure to this list.
> 
> Burkhard

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+) s: a-- C++ UL+++ P+>++ L+++ E(+) W++ N+ o? K- w-- O? M V?
PS++ PE- Y+ PGP t+ 5 X++ R(+) tv-(+) b+ DI D++ G e+++ h--- r++ y+++*
------END GEEK CODE BLOCK------
					 See http://www.geekcode.com

Re: [hpoj-devel] (Unofficial patch) 2nd patch to hpoj for 2.4

[damcha <da...@cy...>]

Hello,

I'm sorry everybody but Burkhard's new patch didn't make its way into my
mailbox when I posted mine.

Please don't use mine, I'll post a new one wich contains both Burkhard's
modifications and mine.

Damcha
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+) s: a-- C++ UL+++ P+>++ L+++ E(+) W++ N+ o? K- w-- O? M V?
PS++ PE- Y+ PGP t+ 5 X++ R(+) tv-(+) b+ DI D++ G e+++ h--- r++ y+++*
------END GEEK CODE BLOCK------
					 See http://www.geekcode.com

[hpoj-devel] Fw: Bug report

[Brian R. <br...@bs...>]

----- Original Message ----- 
From: "Randy Miller" <mil...@ya...>
To: <hpo...@bs...>
Sent: Sunday, September 24, 2000 10:51 PM
Subject: Bug report


> Hi,
> I got the following error when I executed 'hpo devid':
> 
> Error 0 (system error 107) in file mlccon.c, line 110:
> Unexpected Error, please post a bug report to
> hpo...@bs...
> 
> Thanks,
> Randy Miller
> 
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.yahoo.com/
> 

[hpoj-devel] (Unofficial patch) 2nd patch to hpoj for 2.4

[damcha <da...@cy...>]

Hello,

WARNING: this is an unofficial non stable development patch, please don't use
it unless you want to help develop hpoj.

I modified the sources from the patch burkhard gave us because they didn't work
with 2.4.0-test8.
put_user_ret, get_user_ret, copy_to_user_ret and copy_from_user_ret don't exist
anymore, and I moved the x_spin_lock_bh, x_spin_unlock_bh and spinlock.h
includes inside ieee1284.c and ieee1284pp.c (not very beautiful, but when you compile
ojlib for example, which includes ieee1284.h, it includes itself the headers
from /usr/include/linux/ and not from the kernel sources, which may be from
different kernel issue. In my case they are from 2.2.15, which means it made lot of
errors...)

Still have a few work to do on the sources, but I have to sleep a little :) so
I deliver this patch in case some of you want to look at it.

Btw, the patch is against hpoj 0.6 not patched.

Damcha
-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+) s: a-- C++ UL+++ P+>++ L+++ E(+) W++ N+ o? K- w-- O? M V?
PS++ PE- Y+ PGP t+ 5 X++ R(+) tv-(+) b+ DI D++ G e+++ h--- r++ y+++*
------END GEEK CODE BLOCK------
					 See http://www.geekcode.com

[hpoj-devel] RE: no OJ printers listed in apsfilter

[Erick C. <ec...@ar...>]

sorry make that an OJ700.  if I pick the OJ600 from the list it complains:

: your gs version doesn't have
: driver hpdj compiled in...
:
: select another driver
: or build a new gs version
: with complete or customized
: driver support"

since the "driver" is ieee12844_print (or the wrapfilter), how can I rebuild
gs to compile the driver in?  can anyone help?

thx - e

-----Original Message-----
From: Erick Calder [mailto:ec...@ar...]
Sent: Sunday, September 24, 2000 11:26 AM
To: 'hpo...@li...'
Subject: no OJ printers listed in apsfilter


I'm trying to install apsfilter but it needs to configure a printer.  I have
an OJ600 which is not on the list.  I cannot continue unless I pick a
printer but anything I pick would be wrong.  where do I go from here?

I've installed the OJ drivers and created a "wrapfilter" as suggested in the
the PRINT-HOWTO.  I have Ghostscript installed and am running on RH 6.2

thx - e

-----Original Message-----
From: Erick Calder [mailto:ec...@ar...]
Sent: Monday, September 04, 2000 11:30 AM
To: 'hpo...@li...'
Subject: filters & "no daemon present"


I'm back.  didn't get very far from last time :( I'm having a problem with
lpd.

root@beowulf:/ # lpc status
lp:
        queuing is enabled
        printing is enabled
        1 entry in spool area
        no daemon present

I found in the Linux Printing HOWTO guide (under the the "lpc and lpq
warning of missing daemons" section)

	http://ftp.yggdrasil.com/bible/howtos/printing.html

that this condition (no daemon present) happens when a filter is broken.
the answer is to "fix" it and restart the daemon.

as I don't have apsfilter installed (do I need to install it?, can I not
just print with ieee12844_print?) my /etc/printcap looks like this:

lp:\
        :sd=/var/spool/lpd/lp:\
        :mx#0:\
        :sh:\
        :lp=/dev/null:\
        :if=/usr/local/bin/ieee12844_print:

I took the PRINT-HOWTO's hint that "of" doesn't work and put it in "if" but
actually I've tried both without results.  Here's proof that _print is
there:

root@beowulf:/usr/local/bin # ls ieee*
-rwxr-xr-x    1 root     root         9552 Sep  3 10:32 ieee12844_print*

any help would be greatly appreciated:

- erick

p.s. uname -a:

Linux beowulf 2.2.14-5.0 #1 Tue Mar 7 20:53:41 EST 2000 i586 unknown

[hpoj-devel] no OJ printers listed in apsfilter

[Erick C. <ec...@ar...>]

I'm trying to install apsfilter but it needs to configure a printer.  I have
an OJ600 which is not on the list.  I cannot continue unless I pick a
printer but anything I pick would be wrong.  where do I go from here?

I've installed the OJ drivers and created a "wrapfilter" as suggested in the
the PRINT-HOWTO.  I have Ghostscript installed and am running on RH 6.2

thx - e

-----Original Message-----
From: Erick Calder [mailto:ec...@ar...]
Sent: Monday, September 04, 2000 11:30 AM
To: 'hpo...@li...'
Subject: filters & "no daemon present"


I'm back.  didn't get very far from last time :( I'm having a problem with
lpd.

root@beowulf:/ # lpc status
lp:
        queuing is enabled
        printing is enabled
        1 entry in spool area
        no daemon present

I found in the Linux Printing HOWTO guide (under the the "lpc and lpq
warning of missing daemons" section)

	http://ftp.yggdrasil.com/bible/howtos/printing.html

that this condition (no daemon present) happens when a filter is broken.
the answer is to "fix" it and restart the daemon.

as I don't have apsfilter installed (do I need to install it?, can I not
just print with ieee12844_print?) my /etc/printcap looks like this:

lp:\
        :sd=/var/spool/lpd/lp:\
        :mx#0:\
        :sh:\
        :lp=/dev/null:\
        :if=/usr/local/bin/ieee12844_print:

I took the PRINT-HOWTO's hint that "of" doesn't work and put it in "if" but
actually I've tried both without results.  Here's proof that _print is
there:

root@beowulf:/usr/local/bin # ls ieee*
-rwxr-xr-x    1 root     root         9552 Sep  3 10:32 ieee12844_print*

any help would be greatly appreciated:

- erick

p.s. uname -a:

Linux beowulf 2.2.14-5.0 #1 Tue Mar 7 20:53:41 EST 2000 i586 unknown

[hpoj-devel] [Patch] hpoj now running with 2.4 kernel

[Burkhard K. <bu...@bu...>]

Hello everyone,

this patch is intended to make hpoj run under 2.4 kernel versions.
It removes a bug from the mlc_sendmsg call in ieee12844.c module,
which prevented a successfull write to the hpoj device,
fixes the layout of the mlc_proto_ops structure in ieee12844pp,
replaces the start/end_bh_atomic primitives to allow for use of=20
their 2.4 counterparts and sets the __SMP__ define depending=20
on the setting in /usr/include/linux/config.h so it is in alingment
with the kernel configuration in /usr/src/linux.=20

I you want to force an particular __SMP__ setting independantly
of any kernel configuration, you have to edit the Makefile
in ieee hpoj-0.6/ieee12844 and uncomment on of the FORCE_SMP
line at top of the file.

I'd like to ask everybody with a 2.4 kernel to test this code and
report succes or failure to this list.

Burkhard
--=20
Burkhard Kohl=09=09=09buk at/auf buks.ipn.de

Re: [hpoj-devel] 2.4.0 kernel issues

[Burkhard K. <bu...@bu...>]

David Paschal
> All I see in your 2.4 debug output is an open of the scan channel immediately
> followed by a close.  I assume this output corresponds to the SANE+PTAL
> output you sent on September 20.  In that case, we saw a successful open,
> and the write() of two bytes (the SCL "Esc-E" reset command) failed (returned
> -1), so the SANE backend had no choice but to give up and close the channel.
> I would suggest examining the code path taken by writes (see mlc_sendmsg()).

David, that set me onto the right track. The culprit was an old bug in
mlc_sendmsg which just happened to remain silent with 2.2 kernel version
because no flag in msghdr->flags was set from the socket layer:

    int nonblock = msg->msg_flags & MSG_DONTWAIT;

    /* XXX currently does not work with poll() */
    nonblock = 0;

    if (debug & 0x02)
        printk ("mlc_sendmsg: %p credit=%d\n", sock, so->mycredit);
    if (msg->msg_flags & ~MSG_DONTWAIT) 
                         ^^^^^^^^^^^^^^
        return = -EOPNOTSUPP;

The code checked for the supplement of MSG_DONTWAIT instead of the
flag itself. As long as no flag was set, all worked well but as 
soon as any flag besides MSG_DONTWAIT is set, the call will fail with
an error return of -95, which is -EOPNOTSUPP. That's exactly 
what happend with a 2.4.0-test kernel, msg_flags was set to 
MSG_EOR, thus revealing this bug.

I' ll be posting my patch seperately, asking everybody with 
a 2.4 kernel to test it out.

I see a lot of "already open" messages from the ptal layer - maybe
we have other problems as well, but "scanimage --test" runs on my 
box now successfully.

BTW: in ieee12844/Makefile.in the "cp" expression to move kernel
modules to the appropriate location was commented out. Was this
done for any particular purpose? I am asking because it meant
that the modules had to be installed by hand.

Burkhard
-- 
Burkhard Kohl			buk at/auf buks.ipn.de

Re: [hpoj-devel] 2.4.0 kernel issues

[damcha <da...@cy...>]

Hello all,

Sorry I've been silent for a few days, but I experienced a major disk crash,
and had to change my HD and reinstall my system...
Almost everything is in place now, and as soon as I can I'll spend a a bit of
my time working on the project.

Damcha

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+) s: a-- C++ UL+++ P+>++ L+++ E(+) W++ N+ o? K- w-- O? M V?
PS++ PE- Y+ PGP t+ 5 X++ R(+) tv-(+) b+ DI D++ G e+++ h--- r++ y+++*
------END GEEK CODE BLOCK------
					 See http://www.geekcode.com

Re: [hpoj-devel] 2.4.0 kernel issues

[Burkhard K. <bu...@bu...>]

David Paschal
> 
> All I see in your 2.4 debug output is an open of the scan channel immediately
> followed by a close.  I assume this output corresponds to the SANE+PTAL
> output you sent on September 20.  In that case, we saw a successful open,
> and the write() of two bytes (the SCL "Esc-E" reset command) failed (returned
> -1), so the SANE backend had no choice but to give up and close the channel.
> I would suggest examining the code path taken by writes (see mlc_sendmsg()).
> Perhaps there's a mismatch in the mlc_proto_ops structure.  You could also
> try hacking the PTAL_LOG_DEBUG statement around line 884 of ptal/ptal.c so
> it also prints the value of errno.
> 
> Looking back at Damcha's original message reporting compile problems with
> 2.4, there were warnings about initializing mlc_proto_ops:
> > ieee12844.c:1541: warning: initialization from incompatible pointer type
> > ieee12844.c:1542: warning: initialization from incompatible pointer type
> > ieee12844.c:1545: warning: initialization from incompatible pointer type
> > ieee12844.c:1547: warning: excess elements in struct initializer
> > ieee12844.c:1547: warning: (near initialization for `mlc_proto_ops')
> Line 1542 is for mlc_sendmsg and 1543 is for mlc_recvmsg, so it's obviously
> a mismatch in this table that's causing writes to fail.
That would be too easy. As I wrote in my posting accompanying my patch
I have already taken care of that. After applying my patch, the module
compiles without any such warnings. I just double checked, all pointer
assignments to the mlc_proto_ops structure are in alignment with 
the definition of this structure in net.h.

Burkhard

-- 
Burkhard Kohl			Tel/FAX: +49 30 698 15 905
Melchiorstr. 8			bu...@bu...
10179 Berlin			

Re: [hpoj-devel] 2.4.0 kernel issues

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

> BTW: David, I have to admit that I don't know very much about the 
> IEEE1284.4 protocol (I am familiar with SPP parports though). Could 
> you suggest a (desirably concise) source for reading?
Hi, Burkhard.  Despite the name, the hpoj software doesn't actually
implement the IEEE 1284.4 transport protocol.  It only implements HP's
MLC protocol, on which 1284.4 is based.  There's a link to the latest
1284.4 draft on the webpage (under "useful links"); you might want to
save a copy of it in case it goes away.  I'll send you and Damcha a
copy of the MLC spec.

IEEE 1284-1994 ("IEEE Standard Signaling Method for a Bidirectional
Parallel Peripheral Interface for Personal Computers") may be ordered
in hardcopy form from the IEEE.  For that matter, you may be able to order
1284.4 as well by now.  It was supposed to have been finished a long time
ago.

All I see in your 2.4 debug output is an open of the scan channel immediately
followed by a close.  I assume this output corresponds to the SANE+PTAL
output you sent on September 20.  In that case, we saw a successful open,
and the write() of two bytes (the SCL "Esc-E" reset command) failed (returned
-1), so the SANE backend had no choice but to give up and close the channel.
I would suggest examining the code path taken by writes (see mlc_sendmsg()).
Perhaps there's a mismatch in the mlc_proto_ops structure.  You could also
try hacking the PTAL_LOG_DEBUG statement around line 884 of ptal/ptal.c so
it also prints the value of errno.

Looking back at Damcha's original message reporting compile problems with
2.4, there were warnings about initializing mlc_proto_ops:
> ieee12844.c:1541: warning: initialization from incompatible pointer type
> ieee12844.c:1542: warning: initialization from incompatible pointer type
> ieee12844.c:1545: warning: initialization from incompatible pointer type
> ieee12844.c:1547: warning: excess elements in struct initializer
> ieee12844.c:1547: warning: (near initialization for `mlc_proto_ops')
Line 1542 is for mlc_sendmsg and 1543 is for mlc_recvmsg, so it's obviously
a mismatch in this table that's causing writes to fail.

David

Re: [hpoj-devel] 2.4.0 kernel issues

[Burkhard K. <bu...@bu...>]

David Paschal
> Hi, Burkhard.
> 
> > If have noticed that some parts of
> > the lp driver have been rewritten. Any comments?
> lp is simply another client of parport and is not used by ieee12844pp.
> However, it might be helpful to study the changes in lp, because that might
> point out what needs to be changed for ieee12844pp, which uses more
> complicated signalling than lp but still faces the same issues about needing
> to poll for a while, delay, poll some more, etc.

That's the point I wanted to indicate. I guess lp is the first source 
to start adapting the ieee12844pp module to the new kernel.

BTW: David, I have to admit that I don't know very much about the 
IEEE1284.4 protocol (I am familiar with SPP parports though). Could 
you suggest a (desirably concise) source for reading?

Burkhard
-- 
Burkhard Kohl			bu...@bu...

[hpoj-devel] Officejet G55 printing

[Erik H. <hen...@ho...>]

Hi there,

First of all a big THANK YOU to the developers for this driver.

Now, I'm having problems to get this to print.

I installed :
APSFILTER
A2PS
Ghostscript
and offcourse the 0.6 HPOJ driver

The driver seems to be working fine since I can get the status of my 
printer.
But when I try to print something nothing happens.

My printcap file is as follow :

# /etc/printcap
#
# Please don't edit this file directly unless you know what you are doing!
# Be warned that the control-panel printtool requires a very strict format!
# Look at the printcap(5) man page for more info.
#
# This file can be edited with the printtool in the control-panel.

##PRINTTOOL3## LOCAL
lp0:\
	:sd=/var/spool/lpd/lp0:\
	:mx#0:\
	:sh:\
	:lp=/dev/lp0:\
	:if=/var/spool/lpd/lp0/wrapfilter:
# LABEL apsfilter
# apsfilter setup Fri Sep 22 01:39:21 PDT 2000
#
# DON'T DELETE THIS:
# APS_BASEDIR:/root/linux/rpms/apsfilter
#
# APS1_BEGIN:printer1:deskjet::default
# - don't delete start label for apsfilter printer1
# - no other printer defines between BEGIN and END LABEL
#
lp|aps1-deskjet--auto-default|Printer1 deskjet  auto default:\
    :lp=/dev/lp0:\
    :sd=/var/spool/lpd/printer1-deskjet--auto-default:\
    :lf=/var/spool/lpd/printer1-deskjet--auto-default/log:\
    :af=/var/spool/lpd/printer1-deskjet--auto-default/acct:\
    :if=/root/linux/rpms/apsfilter/filter/aps1-deskjet--auto-default:\
    :mx#0:\
    :sh:
raw|aps2-deskjet--raw|Printer1 deskjet  raw:\
    :lp=/dev/lp0:\
    :sd=/var/spool/lpd/printer1-deskjet--raw:\
    :lf=/var/spool/lpd/printer1-deskjet--raw/log:\
    :af=/var/spool/lpd/printer1-deskjet--raw/acct:\
    :if=/root/linux/rpms/apsfilter/filter/aps2-deskjet--raw:\
    :mx#0:\
    :sh:
# APS1_END - don't delete this END LABEL for printer1

I created the apsfilterrc.deskjet file in my /etc directory.
This file contains the following line :
REMOTE_PRINTER="/usr/local/bin/ieee12844_print"

I also created the wrapfilter program and made it executable.
This file is located in : /var/spool/lpd/lp0

As far as I can see everything is allright. But it isn't since I can't 
print. The big question now is what is wrong?

Any help is REALLY appreciated.

Thank you.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Re: [hpoj-devel] 2.4.0 kernel issues

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

Hi, Burkhard.

> in order to find a starting point for debugging the modules on a
> 2.4 kernel I loaded the modules with debugging fully turned on
> and ran "scanimage --test". While on 2.2.14 the scan completes
> smoothly I see that on a 2.4 kernel after while only 0 nibbles 
> are read back from the parport. David, if you think you can
> help me interpret that debug log, please give me a note. (About
> 65k data - sorry, I was unsure, which debug levels I could 
> turn off).
Sure, go ahead and send to me (pa...@rc..., not to the mailing list)
the debug output, both from 2.2.x and 2.4.x.  Hopefully I can shed some
light from the protocol standpoint where things are going wrong.  However,
if you're using syslog to capture the output (I don't know of any other way),
there exists the possibility of lost or corrupted messages when the messages
are generated too quickly, so the results may be inconclusive.

> Since the underlying parport and its interface have changed
> quite a bit from 2.2 to 2.4 I suspect that the premature
> link close seen on a 2.4 kernel being caused by some now
> improper handshaking.
Once the peripheral has been detected, all the parallel-port handshaking is
initiated by ieee12844pp, using functions provided by parport to read and
write the registers that map to the control, status, and data lines.  I
doubt a kernel change could break this.  It would be more likely that
something changed about the way the kernel lets drivers (such as ieee12844pp)
poll for a little while, release the CPU, and get rescheduled to poll some
more later.

> If have noticed that some parts of
> the lp driver have been rewritten. Any comments?
lp is simply another client of parport and is not used by ieee12844pp.
However, it might be helpful to study the changes in lp, because that might
point out what needs to be changed for ieee12844pp, which uses more
complicated signalling than lp but still faces the same issues about needing
to poll for a while, delay, poll some more, etc.

David

[hpoj-devel] 2.4.0 kernel issues

[Burkhard K. <bu...@bu...>]

Hi David, Hi Damcha,

in order to find a starting point for debugging the modules on a
2.4 kernel I loaded the modules with debugging fully turned on
and ran "scanimage --test". While on 2.2.14 the scan completes
smoothly I see that on a 2.4 kernel after while only 0 nibbles 
are read back from the parport. David, if you think you can
help me interpret that debug log, please give me a note. (About
65k data - sorry, I was unsure, which debug levels I could 
turn off).

Since the underlying parport and its interface have changed
quite a bit from 2.2 to 2.4 I suspect that the premature
link close seen on a 2.4 kernel being caused by some now
improper handshaking. If have noticed that some parts of
the lp driver have been rewritten. Any comments?

Burkhard
-- 
Burkhard Kohl			bu...@bu...

RE: [hpoj-devel] Revised "gamma.ps info" + screenshot

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

On Wed, 20 Sep 2000, Salkind, Lou wrote:

<...>
> Like Joe, I found that gamma.ps was needed.  Following the instructions on
> http://graphics.stanford.edu/~ericv/gamma/gamma.html, I determined that the
> best gamma for the OfficeJet 720 was about 1 / .475.  In other words,
> instead of using .333 as Joe did, I used .475 instead.
> 
> The colors were still a bit off, though.  In particular, the blue, cyan, and
> pink all looked a bit dark and possibly not quite the right color on a test
> color strip (the Redhat print page).  I'm pretty sure gamma isn't helping
> here, because the colors are being requested to be displayed at full
> intensity.  What is needed is a slightly more sophisticated transformation.
<...>

Lou -

A lower gamma setting will make my 600 print lighter. It may work for you. Try
{0.222 exp} and see what difference it makes (it may be too light). My main
interest is in getting  web pages to print reasonably well.  As a test, I print
a graphic from a web page, then see how closely it matches its appearance on
the monitor. Of course, if the monitor's color settings are way off, this won't
work well.

From another post:
>I like your mockup.

Thanks very much. It still needs a lot of work.

---
Joe

RE: [hpoj-devel] New screenshots + source

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

On Tue, 19 Sep 2000, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> Hi, Joe.  Thanks for putting together the new prototype so quickly.  It's
> very close to what I had in mind.  One comment I'll make right now is that
> we shouldn't restrict phone numbers to the US-style format of 3-digit area
> code and 3+4-digit phone number.  I'd like this software to have world-wide
> appeal, but of course that would also require translation capability, which
> opens another whole can of worms.  :-)
> 

Though I was doing a some things to make internationalization easier, I had no
clue about the phone number difference. The entry field is now a single longer
line. Is that the best way to do it?  If there are other issues like that, let
me know. What I'm doing now is making text label fields longer, by extending
them to the edge of their containing widgets, with the containers themselves
being extra long if practical.

> Before anybody spends too much time on this I probably need to finish my
> current project of adding PML support to PTAL, because that would provide
> the necessary application-level infrastructure to support an application
> like this.  Then it would probably be a good idea to write some simple
> command-line scripts that play around with the various settings that are
> available via PML so that we can better understand the functionality we're
> trying to expose to the user.
> 

I'll spend less time adding widgets, and more improving those I already have.
Let me know if I go astray. Only three screens are mostly complete anyway, all
in the fax settings.  I have a couple of  new screenshots  at:

http://pages.cthome.net/jsp/hpoj-linux-gui/index.html

It builds now too, so if you have the latest Qt and tmake or a similar
utility, you can see how much is done.  The source can be downloaded from
the same page.


Lou wrote:
>I like your mockup.

Thanks.

---------------
Joe

[hpoj-devel] (Unofficial) Patch to hpoj kernel modules.

[Burkhard K. <bu...@bu...>]

This patch tries to address 2.4/SMP related issues for the hpoj
kernel modules. On my 2.4.0-test7 kernel it compiled o.k. but=20
failed on scanning and on printing larger amounts of data.

At the moment I have to determine wether the failure is only=20
due to new kernel structures in 2.4 version kernels or wether
it relates to SMP/locking in 2.2.x kernels as well. Any feedback/
suggestions are welcome.

There is no need to apply this patch to a working 2.2.x kernel
modul. Please do not apply this patch unless you have a special
interest in testing hpoj on a 2.4 and/or a SMP kernel.

Burkhard
--=20
Burkhard Kohl=09=09=09buk at/auf buks.ipn.de

Re: [hpoj-devel] SMP Problems && ojpanel-on-steroids

[Burkhard K. <bu...@bu...>]

PASCHAL,DAVID (HP-Roseville,ex1)
> Hi, Damcha.  Sorry, I forgot you had indicated an interest in working on
> this.  The kernel driver code is begging for a better maintainer than me, so
> thanks for volunteering.  :-)  Burkhard also indicated an interest in this,
> but it sounds like you're more SMP-equipped than he is.  Anyway, I'll let
> the two of you decide how you want to go about working on this, and perhaps
> Gerhard can provide some technical guidance from time to time as well.  I
> shall look forward to your patches.  :-)

Hi David, Hi Damcha,

until now I did a quick and dirty patch to the hpoj kernel modules -
just substituted the xxx_bh_atomic primitives by their 2.4/SMP counter-
parts. I also adjusted the proto_ops struct to the changes which came
with the new 2.3 kernels. (Does someone know the exact 2.3.x version
where these changes were introduced?)
The kernel modules now look for the setting of CONFIG_SMP from 
<linux/config.h> and will define __SMP__ accordingly. Thus the 
modules will be compiled according to the SMP configuration 
of the main kernel.
To override this setting one may define FORCE_SMP with a value of 
"SMP".
(I also adjusted the indentation to make the sources a bit more
readable).

Someone really should look into the locking issue more 
carefully. I guess that spin_lock_bh could be substituted in a 
couple of places with a read_lock_bh or a write_lock_bh with these
primitives being less powerful(i.e. blocking) than locking with a 
spin_lock_bh.

Damcha, I would be glad to see the SMP/locking issues in your hands,
since I neither have a SMP system to test any patches nor am I 
familiar with SMP issues and you really sound like you want to
dig into it. 

With my patch the modules now compile smoothly against a 2.4.0-test7 
kernel and against a 2.2.14 SMP kernel.

But - unfortunately a test with 2.4.0-test7 showed that printing stops 
after a certain amount of data and that scanning failed resetting the 
device. I have attached the debug output from scanimage --test. As it 
stands my simple patch does not run properly on a 2.4.0 kernel and I
have to track down the reasons for failure.

Although it does not really work I thought I am going to post it in
a seperate mail so other people could look into it. I am especially 
curious to know wether the failure is 2.4 or locking related, i.e. 
does it run on a 2.2.x SMP system? 

Burkhard

------- Debug output from scanimage --test:
[sanei_debug] Setting debug level of hp to 128.
[hp] sane_init called
ptalInit(): debug level set to 5.
ptalInit()
ptalDeviceProbe: dev=<mlc:mlcpp0>.
ptalDeviceAdd(provider=<mlc>,name=<mlcpp0>): dev=0x0804E9A0.
ptalDeviceProbe: dev=<mlc:mlcpp1>.
ptalDeviceAdd(provider=<mlc>,name=<mlcpp1>): dev=0x0804E9D8.
[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=0x0804E9A0.
ptalChannelAllocate(dev=0x0804E9A0): chan=0x08052AA8.
ptalChannelSetRemoteService(chan=0x08052AA8,serviceType=2,socketID=0,serviceName=<>)
[hp] scsi_flush: writing 2 bytes:
[hp]  0x0000  1B 45                                            .E
ptalChannelOpen(chan=0x08052AA8): fd=5.
ptalChannelWrite(chan=0x08052AA8,buffer=0x08052276,count=2)
ptalChannelWrite(chan=0x08052AA8,buffer=0x08052276,count=2) returns -1.
[hp] hp_nonscsi_device_new: SCL reset failed
[hp] scsi_close: closing fd 5
ptalChannelClose(chan=0x08052AA8)
[hp] sane_get_devices will finish with Success
lt-scanimage: no SANE devices found
[hp] sane_exit called
[hp] sane_exit will finish

-- 
Burkhard Kohl			bu...@bu...

RE: [hpoj-devel] New screenshot

[Salkind, L. <Lou...@de...>]

I like your mockup.

-----Original Message-----
From: Joe Piolunek [mailto:joe...@sn...]
Sent: Tuesday, September 19, 2000 3:47 PM
To: hpo...@li...
Subject: [hpoj-devel] New screenshot


On Tue, 19 Sep 2000, David Paschal wrote:
<...>
> Thanks for putting this together.  That's a really cute picture!  However,
> a printer with its tongue sticking out isn't quite the emotion I wanted to
> convey here.  :-)
>

But many officejets _do_ have a big tongue sticking out to catch the paper!
I agree though, that this graphic isn't appropriate for the serious business
app that you seem to be planning. For home users, some graphics would be
nice. If skin support were added some day, stranger things than this could
find
their way onto the main window.

 > I haven't done a lot of serious thinking on the matter yet, but basically
> my vision was to have a list of attached devices (which would probably be
> only one for most people, but many for me:-) on the left side (for
example,
> mlc:mlcpp0, hpjd:my-jdex.my-domain.com:1, etc.), and when you clicked on
> one you would get a bunch of tabbed dialog boxes in the remainder of the
> window, which would provide various status information and control options
> for the selected device.  To list some possibilities by tab:

< much deletion here>
 
> Did I say I haven't thought about this very much?  :-)  In any case, this
> is a lot of functionality, and it would be a good idea to start small.
> I also still need to try to get specs on some things, like how to
determine
> ink/toner levels and clean/align cartridges.
> 
> Does anyone have ideas to add to this wishlist for xojpanel-on-steroids?
> 
> David
> 


It already seems like a bigger project than I imagined it would be. It
probably wouldn't take long to put together a dialog with most of the things
you
mentioned, but I'm not a professional at this, so If there is an experienced
GUI designer involved in the project, that certainly would be the person to
do
it.

If there isn't one available, I'm willing to help with whatever I can. At
the
moment that would be limited to drag-and-drop *.ui creation and
auto-generating a  *.cpp and *.h file from each *.ui, a project file and
Makefile.
That is actually all done easily with the autogeneration tools. Someone with
strong c++ coding skills would need to do the actual implementation
afterwards.

If you decide to use gtk instead of Qt, maybe Qt-generated files or previews
could still be used as a rough guide. 

I have a new screenshot available at

http://pages.cthome.net/jsp/hpoj-linux-gui/hpoj-gui.html

It looks more like what you described. This one is only a designer preview.

---------
Joe

_______________________________________________
hpoj-devel mailing list
hpo...@li...
http://lists.sourceforge.net/mailman/listinfo/hpoj-devel