hpoj-devel — HPOJ development/support list

[hpoj-devel] RE: can't compile officejet drivers

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

Hi, Cyrus.  modversions.h may get generated when building a custom kernel.
Off the top of my head I don't know what purpose is served by including this
file.  Try removing lines that include it and see what happens.

David

> -----Original Message-----
> From: Cyrus Razavi [mailto:c....@us...]
> Sent: Saturday, December 09, 2000 6:19 AM
> To: dav...@hp...
> Subject: can't compile officejet drivers
> 
> 
> David,
> 
> I am trying to get my HP OfficeJet G85 to work under Linux. I 
> have donwloaded
> the drivers from your site, but I get the following error:
> 
> cyrus@era-cadcam:~/hpoj-0.6$ make
> ptal
> make[1]: Entering directory `/home/cyrus/hpoj-0.6/ptal'
> make[1]: Nothing to be done for `release'.
> make[1]: Leaving directory `/home/cyrus/hpoj-0.6/ptal'
> ieee12844
> make[1]: Entering directory `/home/cyrus/hpoj-0.6/ieee12844'
> gcc -O -I/home/cyrus/hpoj-0.6/include -I/home/cyrus/hpoj-0.6/ptal
> -I/usr/src/linux/include -Wall -Wstrict-prototypes 
> -D__KERNEL__ -DMODULE
> -DEXPORT_SYMTAB  -c ieee12844pp.c
> ieee12844pp.c:48: linux/modversions.h: No such file or directory
> make[1]: *** [ieee12844pp.o] Error 1
> make[1]: Leaving directory `/home/cyrus/hpoj-0.6/ieee12844'
> make: *** [release] Error 2
> cyrus@era-cadcam:~/hpoj-0.6$ 
> 
> What is the modversions.h that it is looking for? I am 
> running a slimline
> install of debian potato and I have installed the Linux 
> kernel 2.2.17 source
> in /usr/src/linux.
> 
> I would appreciate if you would reply to cy...@er... 
> rather than the
> reply-to address specified in the header.
> 
> Thanks in advance for your help,
> 
> Cyrus Razavi
> 
> 
> ____________________________________________________________________
> Get free email and a permanent address at 
http://www.netaddress.com/?N=1

Re: [hpoj-devel] preparing for 0.7

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

On Saturday 09 December 2000 21:31, David Paschal wrote:
> Hi,
>
> I've checked into CVS all of the code changes that I needed to make and
> that others have sent me, so I'm close to being ready to release 0.7.
>
> I would like to wait a few more days to see if we can resolve the problem
> Robert reported about printing on 2.2.16-SMP, since 0.7 is supposed to fix
> problems like this.  If it turns out that upgrading to 2.2.17 fixes the
> problem, then maybe I'll just document the issue and release if there isn't
> an easy fix.  My goal is to release this by next weekend if possible.
>
> In the meantime, it would be appreciated if some people could try out the
> latest CVS source and let me know if there are any problems, particularly
> with the new PRINT-HOWTO, xojpanel, or changes to the kernel-mode drivers.
> Those who have already downloaded from CVS and applied patches may need to
> delete the modified trees and download a fresh copy, because the "cvs
> update" command may get confused when it's trying to merge updates into
> locally modified files.  For convenience I added links to the CVS homepage
> (http://www.cvshome.org), where one can learn more about using CVS.
>
> I will also try to test with 2.4.0-test on a uniprocessor PC to see if I
> can reproduce the slow-scan problem that was previously reported.  If
> anybody else can confirm that that is or isn't a problem, that would be
> nice too.
>
> David

David:

I didn't have any problems with the build or install of the project from CVS. 

Printing still works ok.
The PRINT-HOWTO looks as I expected it to.

The xojpanel "start failures" still occur. I tried connecting the OfficeJet 
to the MB-based port instead of the IO card, but there was no improvement. 
Rebooting or reinserting the ieee12844 modules has no effect either.

The cause of the problem seems to have been introduced after hpoj-0.5. As a 
test, I inserted the ieee12844 modules from the 0.5 release. The no-start 
problem then disappeared. In /var/log/messages (using debug=1), lines 
containing "Got device ID string" are definitely related to the problem.  One 
such message occurs for each failure to execute.     

-- 
Joe

Re: [hpoj-devel] preparing for 0.7

[Robert G. B. <rg...@ph...>]

On Sat, 9 Dec 2000, David Paschal wrote:

> Hi,
>
> I've checked into CVS all of the code changes that I needed to make and that
> others have sent me, so I'm close to being ready to release 0.7.
>
> I would like to wait a few more days to see if we can resolve the problem
> Robert reported about printing on 2.2.16-SMP, since 0.7 is supposed to fix
> problems like this.  If it turns out that upgrading to 2.2.17 fixes the
> problem, then maybe I'll just document the issue and release if there isn't
> an easy fix.  My goal is to release this by next weekend if possible.

I'll try to work on this some before then.  I have the printer attached
to a UP system and it works "perfectly" and the suggested fix for the
gamma also works well enough although I'm still having difficulty
getting really crisp colors out even tweaking red, green and blue
separately.  I also discovered that the "file" command in RH 6.2 doesn't
seem to recognize jpegs, which is a bit crazed but easily enough fixed
(add three magic lines to /usr/share/magic).  This explains why my
attempts to print raw jpegs led to printer insanity.

Unfortunately, 2.2.16-3smp appears to be the "currentest" kernel
prebuilt for RH 6.2 as an update, so I have to install 2.2.17 the hard
way.  I've started a 2.2.17 download, but it may be a few days before I
can go through the build and install of the kernel, the build and
install of the ieeexxxx drivers, and the movement of the printer cable
to test it.  My physics students have exams this week and I'll be
grading for days.

   rgb

> In the meantime, it would be appreciated if some people could try out the
> latest CVS source and let me know if there are any problems, particularly
> with the new PRINT-HOWTO, xojpanel, or changes to the kernel-mode drivers.
> Those who have already downloaded from CVS and applied patches may need to
> delete the modified trees and download a fresh copy, because the "cvs update"
> command may get confused when it's trying to merge updates into locally
> modified files.  For convenience I added links to the CVS homepage
> (http://www.cvshome.org), where one can learn more about using CVS.
>
> I will also try to test with 2.4.0-test on a uniprocessor PC to see if I can
> reproduce the slow-scan problem that was previously reported.  If anybody
> else can confirm that that is or isn't a problem, that would be nice too.
>
> David
>
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/mailman/listinfo/hpoj-devel
>

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rg...@ph...

[hpoj-devel] preparing for 0.7

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

Hi,

I've checked into CVS all of the code changes that I needed to make and that
others have sent me, so I'm close to being ready to release 0.7.

I would like to wait a few more days to see if we can resolve the problem
Robert reported about printing on 2.2.16-SMP, since 0.7 is supposed to fix
problems like this.  If it turns out that upgrading to 2.2.17 fixes the
problem, then maybe I'll just document the issue and release if there isn't
an easy fix.  My goal is to release this by next weekend if possible.

In the meantime, it would be appreciated if some people could try out the
latest CVS source and let me know if there are any problems, particularly
with the new PRINT-HOWTO, xojpanel, or changes to the kernel-mode drivers.
Those who have already downloaded from CVS and applied patches may need to
delete the modified trees and download a fresh copy, because the "cvs update"
command may get confused when it's trying to merge updates into locally
modified files.  For convenience I added links to the CVS homepage
(http://www.cvshome.org), where one can learn more about using CVS.

I will also try to test with 2.4.0-test on a uniprocessor PC to see if I can
reproduce the slow-scan problem that was previously reported.  If anybody
else can confirm that that is or isn't a problem, that would be nice too.

David

Re: [hpoj-devel] indentation and such

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

Burkhard Kohl wrote in response to Andreas Fester:
> It looks like I missed the original posting you were answering to. If 
> indent would help to achieve proper indentation, I'd be happy to use
> it.
See http://www.geocrawler.com/lists/3/SourceForge/5745/0/4788297 for the
message from me to which Andreas was replying.

I have checked in the SMP/2.4 changes for the files:
ieee12844/Makefile.in
ieee12844/ieee12844.c
ieee12844/ieee12844pp.c
include/linux/ieee12844.h

After checking in ieee12844.c with the code changes, I ran it through
"indent -kr -i8" to standardize the indentation and checked it in again.
I used two separate checkins to make it easier if anybody ever goes back
and diffs revisions.  I didn't do this to ieee12844pp.c because I need to
selectively re-indent only certain sections.  Let me know if I need to
process this file too.

I'm hoping this re-indention can be a one-time occurrence per file, so I
won't attempt to set it up as a checkin/checkout filter.

David

Re: [hpoj-devel] Ghostscript, Gamma, Color Management

[Robert G. B. <rg...@ph...>]

On Wed, 6 Dec 2000, Gerhard Fuernkranz wrote:

> "Robert G. Brown" wrote:
>
> > I'm going to spend some time trying to fix the printer resolution and
> > gamma problem next.  When I print photos, the gamma is without exception
> > too dark (which isn't the printer per se, which works "perfectly" on a
> > color copy process).  Pictures come out looking muddy and dark.  Even at
> > 300dpi, the printer should be able to do much better, especially on the
> > more expensive smooth finish inkjet photo paper.  I don't know if this
> > is just an incongruity between the cdj550 postscript translator and this
> > printer or if it is a real problem with the printer itself, but I assume
> > the former.
>
> I could obtain reasonable result for printing sRGB (see below) color
> images

<some excellent prose deleted>

> Gerhard

I never did thank you for all of this, but thanks tremendously.  It is
always as useful to know the background you provided as the temporary
fix, so one can fix things that the fix doesn't fix, for example.

It also provides a fairly clear map for those who want to contribute
further (to e.g. SANE or to the manifold printer filter installations)
to follow.  If I understand your explanation correctly the short term
fix for photos (jpegs) is to convert the jpegs to pnm's via e.g. djpeg,
correct the gamma with pnmgamma, convert the result to postscript, and
them send the result to the printer via the cdf550.upp (if possible)
ghostscript driver.  The longer term fix is to determine the appropriate
color transformations required for a given printer device in some sort
of standard form (e.g. relative to sRGB) and then integrate a
transformation engine SOMEWHERE into the scanner/printer path.

Is it safe to assume that the pictures taken by a typical digital camera
these days have color output mapped to sRGB?  I note that for my camera
at least they typically look about correct (reasonable colors and gamma)
on the monitor...

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rg...@ph...

Re: [hpoj-devel] indentation and such

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

Andreas Fester
> Hi,
> 
> > > I introduced quite some tab diffs, because the original source code
> > > did use almost no indentation, making it very hard to read. I use only
> > > tabs (no spaces except accidentally) which should expand to whatever the
> > > editor has been set to. (8 spaces if vi default is used). I am a bit
> 
> Personally, I started to never use tabs. My Editor (and Emacs should
> also be able to handle it that way ;-) ) can be set to use spaces
> instead of tabs, and then also inserts spaces for automatic 
> indentation. The advantage of using spaces only is that it looks the 
> same in every editor, without having to puzzle with tab settings and 
> the like.

Well, first aim should be to make the sources readable and to do 
it in a consistent way.
There exists a CodingStyle guide imn /usr/src/linux/Documentation
which gives precise instructions how to indent. I suggest to use this
document at least for ieee12844 modules.

From my experience tabs are the easiest way to be consistent among
developers (and tabs adhere to the above mentioned guidelines). I think
almost any decent editor will expand one tabstop to an 8char space by 
default, even emacs ;-). Only in case you have played with your editors 
settings you will get a different appearance.
If you are using spaces and you don't check afterwards, you might have
accidentially indented in a way you did not intend to use. I guess that's 
what happend to ieee12844*.c - tabs and spaces mixed.

On the other hand I'd have no trouble to use whatever we agree
upon as long we come to an agreement. For now, the lack of
proper indentation makes reading the sources pretty hard.

> 
> [...]
> > I played around with GNU indent a little tonight, and perhaps the best thing
> > to do is run "indent -kr -i8" on ieee12844.c with your code changes.  It's not
> 

It looks like I missed the original posting you were answering to. If 
indent would help to achieve proper indentation, I'd be happy to use
it.

Burkhard

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

Re: [hpoj-devel] CVS - xojpanel

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

Joe Piolunek wrote:
> The files are on my site now for inclusion in CVS.

Thanks!  I just checked in the new xojpanel and PRINT-HOWTO, and a few other
changes.  I also modified configure.in, configure, Makefile.in, and
apps/xojpanel/Makefile.in to be able to set the pixmap path based on the
installation directory.

David

Re: [hpoj-devel] indentation and such

[Andreas F. <fe...@ep...>]

Hi,

> > I introduced quite some tab diffs, because the original source code
> > did use almost no indentation, making it very hard to read. I use only
> > tabs (no spaces except accidentally) which should expand to whatever the
> > editor has been set to. (8 spaces if vi default is used). I am a bit

Personally, I started to never use tabs. My Editor (and Emacs should
also be able to handle it that way ;-) ) can be set to use spaces
instead of tabs, and then also inserts spaces for automatic 
indentation. The advantage of using spaces only is that it looks the 
same in every editor, without having to puzzle with tab settings and 
the like.

[...]
> I played around with GNU indent a little tonight, and perhaps the best thing
> to do is run "indent -kr -i8" on ieee12844.c with your code changes.  It's not

I think using "indent " would be a convenient way to achieve a somewhat 
consistent code layout. However, you should be aware of some problems
which might occur:
- Developers should *always* run indent with the same parameters before
  checkin; otherwise, you can never make useful diffs between versions.
- The best way would be to install indent as a filter for checkin; 
  I dont know if this is possible at the sourceforge CVS server, and
  some people dont like this either because the code may look 
  different when you check it out again ;-)

Just IMHO ....

Regards

        Andreas

-- 
Andreas Fester       Phone : +(49) 721-6291-0              __  __
EIGNER + PARTNER AG  Fax   : +(49) 721-6291-88            /_  /_/
Ruschgraben 133      EMail : mailto:fe...@ep...        /_  /
D-76139 Karlsruhe    URL   : http://www.ep-ag.com    EIGNER + PARTNER

Re: [hpoj-devel] indentation and such

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

Burkhard Kohl wrote:
> I introduced quite some tab diffs, because the original source code
> did use almost no indentation, making it very hard to read. I use only
> tabs (no spaces except accidentally) which should expand to whatever the 
> editor has been set to. (8 spaces if vi default is used). I am a bit 
> puzzled - when I apply your diff the section where you say the spacing should 
> be right looks awful to me - it misses a lot of identation and it seems there 
> are mostly spaces (not tabs) in front of codelines. 
Hi, Burkhard.  I'm sorry about taking so long to get back with you on this.

Are you sure you don't have your tab stops set to 4?  Some of the changes in
your smp4 patch didn't look right unless I switched to 4 (in vi: ":set ts=4").

I played around with GNU indent a little tonight, and perhaps the best thing
to do is run "indent -kr -i8" on ieee12844.c with your code changes.  It's not
100% the style I use personally, but it's good enough for our purposes since
it cleans up the tab vs space consistency.  If you agree then I will go ahead
and commit this to CVS.  (You can look in the "ptal" directory to see an
example of my coding style, since I wrote all of that code myself.)

If you want I'll run indent on ieee12844pp.c too.  That will be a bit harder
because it screws up the switch blocks where I embed "case XX:" within the
"SET_STATE" macro and I'll have to selectively merge indent's changes.

I'm pretty sure the mailing list by itself doesn't munge tabs to spaces.
The patch to xojpanel I sent out on December 2 had tabs in the attachment,
and the message I got back from the list still had them as tabs.

> I think I know the reason but for tonight I am to tired to come up with
> a patch. Shortly, you added a couple of goto out:'s in mlc_sendmsg() where
> the original code just returned. That results in calls to kfree_skb
> on bufs that might be used later (e.g. after returning -EAGAIN).
Let's not worry about this.  Since your original changes work, I am taking
out my "changes".  If I get a chance later I will go back through and
identify specific places where I had questions and ask you about them.

David

[hpoj-devel] Ghostscript, Gamma, Color Management

[Gerhard F. <ger...@fu...>]

"Robert G. Brown" wrote:

> I'm going to spend some time trying to fix the printer resolution and
> gamma problem next.  When I print photos, the gamma is without exception
> too dark (which isn't the printer per se, which works "perfectly" on a
> color copy process).  Pictures come out looking muddy and dark.  Even at
> 300dpi, the printer should be able to do much better, especially on the
> more expensive smooth finish inkjet photo paper.  I don't know if this
> is just an incongruity between the cdj550 postscript translator and this
> printer or if it is a real problem with the printer itself, but I assume
> the former.

I could obtain reasonable result for printing sRGB (see below) color
images

- by using the cdj550.upp ghostscript driver
  (uniprint driver parametrized for cdj550) and

- by applying a gamma correction (with a gamma in the range 1.0-1.5)
  before sending the image to my OfficeJet 500.
  (Please note, that the the cdj550.upp driver already has a built
  in gamma correction of ca. gamma=2.0)

E.g. "pnmgamma 1.2 <image>.ppm | pnmtops | lpr ..."
               ^^^
               gamma

For me these prints look reasonably, but of course the reproduced colors
are still not exact.

With the cdj550 driver (with no additional gamma correction at all)
printed images will definitely look too dark. I'd try a gamma somewhere
in the range 1.5-3.0 for this driver. Subjectively I think that the
cdj550.upp driver prints somewhat nicer, than the cdj550.

In gs6.01 there also exist new uniprint drivers "cdj690.upp" and
"cdj690ec.upp" (econo fast), but I've never tried them.


But actually you wanted to know some backgrounds:

You will see below, that it is actually neither a problem of ghostscript
nor the printer (except your printer is defective).

Generally the problem is the missing color management. Images you scan
with your scanner are delivered by the scanner in the (device dependent)
color space of the scanner. The printer (in your case ghostscript in
conjunction with the printer) expects, that you send color images to gs,
which are in the (again device and ghostscript dependent) printer color
space.
So in order to reproduce the colors of a scanned image corretly on a
printer you just have to convert the image from the scanner color space 
to the color space of the printer, before you send the image to the
printer.
This is called color management. It converts a device dependent input
color space to a different device dependent output color space by a set
of (sometimes very complex) transformations. It also has to map the
gamut (i.e. the set of reproducible colors) between the devices, because
the printer usually is not able to reproduce all the colors which the
scanner is able to "see".

And even if you simply want to print an image file you have received
from somewhere, then you have to convert the color space of the image to
the printer's color space in order to reproduce the colors correctly on
the printer.  So the resulting colors will not only depend on the
printer's color profile, but in the same way also on the color profile
of the image itself.

This implies that if you want to print an image file, but you don't know
the color profile of this image, then you will never be able reproduce
the original image correctly on the printer, even if you have a
calibrated professional color printer, whose color profile has been
individually measured and calibrated.

The conclution is, that if you directly send an image file to the
printer (without any color transformations) and it does not print as
expected, then this is not necessarily the fault of the printer. The
reason is just that the color profile of the image and the profile of
the printer simply don't match. You can't say, that either the one or
the other profile is wrong, they just don't match and require
transformation.

The Internatioal Color Consortium has established a standardized way and
file format to represent color profiles of devices. These are the so
called ICC profiles (see http://www.color.org).

In order to overcome the problem that each image file requires an
attached color profile specifying the color space of the image, HP and
Microsoft have created a standardized color profile called sRGB.
sRBG is an ICC color profile, which describes a virtual output device,
which properties are close to a common, avarage CRT monitor. The W3C
consortium, for example, also has adapted sRBG as standard color profile
for storing images in the world wide web. This means, that images you
find on web pages are usually assumed to be in the sRGB color space
(except otherwise specified, which is rarely the case).

BTW: You may ask, why the colors of images scanned and/or printed with
Windows often look better than on Linux. Microsoft Windows does have a
color management system integrated into the operating system.
Windows does know how to deal with ICC color profiles and Windows
printer or scanner drivers often also include a color profile
specification for the printer (in conjunction with the supplied driver),
e.g. the profile "\windows\system\color\hpdesk.icm" for HP's ColorSmart
driver for HP deskjets. So even though hpdesk.icm is not calibrated for
each individual printer but only for the "average" printer of the same
model this is still better than having no profile at all.


Here just a few links where you can find more info and more links:

http://www.scarse.org
http://www.scarse.org/links.html
http://www.color.org
http://www.freecolormanagement.com/color/links.html
http://www.littlecms.com
http://www.srgb.com

If you follow all the links (and indirect links and so on) then you will
find out, that color management is actually an extreme complex topic and
that it is much more complex than just setting a single gamma value
correctly. A simple gamma adjustment is only one of the possible color
management transformations, but there exist also other, much more
complicated transformations (matrix, 1D lookup tables, 3D lookup tables,
etc.). And there are so many things to take care of to get the colors
right ...


BTW:
When I think about SANE, then probably I'd appreciate, if I could
specify a (calibrated) ICC profile of the scanner and the ICC profile of
the working space (-> the colorspace in which the scanned image will be
stored or delivered to the SANE application, e.g. typically sRGB)
instead of the three curves, which I will never get right so that all
colors are reproduced correctly.
This would require the inclusion of e.g. scarse/icclib or lcms (see
links above) in SANE and could IMHO be useful.


Gerhard

Re: [hpoj-devel] SMP patches?

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

Robert G. Brown
> On Tue, 5 Dec 2000, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> 
> > Hi, Robert.  It also sounds like an SMP problem to me.  Another thing you
> > could try is to boot the SMP box with the "nosmp" kernel parameter, which
> > puts it into UP mode.  I'll attempt to look into the problem in the near
> > future, but I'll have to dig through a part of the code I'm not currently
> > very familiar with.
> 

Hi Robert,

as one of those two persons being responsible for the 2.4/SMP patch
(although I don't have an SMP box and not very much SMP expertise)
I feel obliged to look into your problem. For now I do not understand
the nature of it - it seems the sendbuffer gets filled without
mlcpp_transmit knowing about it. That's strange because the only
place where sendbuf gets filled is mlcpp_transmit. But we have 
couple of 
	kfree_skb(l->sendbuf); l->sendbuf = NULL;
instructions in different functions. Could there be a need to
make this instruction pair atomic? 

Do you know whether there is a way to arrange for the debug output 
to include CPU-identification?

2.2.16 was known to have some problems. I don't recall wether those
probs where SMP related, but anyhow - would it be possible for
you to try 2.2.17? We have a couple of "works"-reports on 2.2.17
kernels. 


Damcha, any ideas?

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

Re: [hpoj-devel] xojpanel

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

On Tuesday 05 December 2000 19:06, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> Hi, Joe.
>
> Joe Piolunek wrote:
> > There wasn't any real improvement after changing the port
> > type. Without the
> > usenibble=1 option, xojpanel still fails to start 1/25 times
> > averaged over
> > 500 attempts to execute.
>
> That's strange.  So are there any error messages in syslog related to this?
> If I know where it fails, then I might know what needs to be fixed.  You
> could also try adding the "debug=1" parameter when loading ieee12844pp.o.
>

You asked earlier about the circumstances when this happens, but I didn't 
send it. Sorry about that. The no-starts occur seemingly at random without 
any special situation that I can identify.

There don't seem to be any related error messages unless I use debug=1, which 
produces a very large number of them. /var/log/messages receives about 185 
lines every second that xojpanel is running.

Here are a few lines from /var/log/messages that may be helpful. The presence 
of the printer's ID string seems to be related to the number of xojpanel 
no-starts.  It also seems related to the time the no-starts occur, but that's 
hard to be sure of. The device ID is the message that most stands out, but 
there are a lot of messages to look at, and I could have missed something 
more important.

Dec  6 10:39:04 tumbleweed kernel: c4842368: event=9. 
Dec  6 10:39:04 tumbleweed kernel: get_nibble(c4842368): nibble=0x6. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=11. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=6. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=9. 
Dec  6 10:39:04 tumbleweed kernel: get_nibble(c4842368): nibble=0xB. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=11. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=6. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=9. 
Dec  6 10:39:04 tumbleweed kernel: get_nibble(c4842368): nibble=0x3. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=11. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=6. 
Dec  6 10:39:04 tumbleweed kernel: mlcpp0: Got device ID string: 
<MFG:Hewlett-Packard;MDL:OfficeJet Series 
600;CMD:MLC,PCL,PML;CLASS:PRINTER;REV:4.03b;> 
Dec  6 10:39:04 tumbleweed kernel: mlcpp0: usebecp=0. 
Dec  6 10:39:04 tumbleweed kernel: do_neg(c4842368,mode=0x10): in_1284=1, 
neg_mode=0x04. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=23. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=27. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=0. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=2. 


> > cat /proc/parports/0/devices showed this:
> > IEEE1284.4 device
> > lp
>
> I noticed that situation too when playing around with printing the other
> day.  It seems dangerous to me, even though I could still print, so that's
> why I added a note in color_printing.txt recommending to change the port
> from /dev/lpX to /dev/null.
>.

I was able to print before with the two devices on the same port, though it 
seemed like only one device at a time could use the port. The file 
parport.txt in the 2.2.16 kernel documentation seems to say that multiple 
device drivers can co-exist at the same parallel port. They don't seem to be 
able to use the port simultaneously, though.


> (regarding patch's error messages)

> I just looked at a hex dump of the message I got back from the mailing
> list, and I didn't see any null bytes in the message.  Perhaps your mail
> client is adding them when you save attachments?  You could always remove
> the offending character before patching.
>
> Has anybody else seen this problem, where patch complains that "patch
> unexpectedly ends in middle of line"?

Looking at the files with kedit, there was a single space on the last line. 
Removing the space allowed the patches to be applied without errors. I don't 
know how the space got there, but It  may very well be the mailer I use. It's 
the new kmail that's part of kde2. Nearly everything in kde 2.0 is buggy.
>
> I'm not sure why you couldn't add a delay between lines 1 and 2.  Did you
> try calling sleep(5 seconds or whatever) in between the two line requests
> in getPrinterLCDMessages?
>

We might have been having a misunderstanding. Maybe it was only me. 

The sleep() call did cause a delay when I finally tried to introduce one. It 
didn't prevent the no-start problem though.


-- 
Joe

RE: [hpoj-devel] SMP patches?

[Robert G. B. <rg...@ph...>]

On Tue, 5 Dec 2000, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

> Hi, Robert.  It also sounds like an SMP problem to me.  Another thing you
> could try is to boot the SMP box with the "nosmp" kernel parameter, which
> puts it into UP mode.  I'll attempt to look into the problem in the near
> future, but I'll have to dig through a part of the code I'm not currently
> very familiar with.

I rearranged my whole mini-beowulf at home and hung the printer on an
otherwise mostly idle UP node and the TX busy message has gone away.
A regular printer on my SMP box (which was there before the HP came
home) is working fine.  So I really do suspect an SMP-related problem at
this point.

I'm going to spend some time trying to fix the printer resolution and
gamma problem next.  When I print photos, the gamma is without exception
too dark (which isn't the printer per se, which works "perfectly" on a
color copy process).  Pictures come out looking muddy and dark.  Even at
300dpi, the printer should be able to do much better, especially on the
more expensive smooth finish inkjet photo paper.  I don't know if this
is just an incongruity between the cdj550 postscript translator and this
printer or if it is a real problem with the printer itself, but I assume
the former.

> > Any helpful suggestions beyond that would be appreciated, especially
> > from folks who already know why the transmit while TX busy
> > message might
> > be occurring.  I did already note the new requirement that the printer
> > port be configured EPC (mine was SPP in the bios) and reset it but it
> > made no difference.  I'm guessing that was more for scanner function
> > anyway.  This seems like an overrun failure of the plain old printer
> > device.
> Are you able to scan successfully, particularly at higher resolutions which
> cause more data to be transferred for a longer period of time?  Of course,
> that's in the opposite direction, but even then there are small amounts of
> PC-to-printer data being transferred.

Even on the SMP box I scanned a photograph in a maximum resolution
without interruption or crash, but I didn't try several in a row as it
took so long.  However, the probability of an interrupt coming at the
wrong time is very low.  Presuming that what is occurring is like an
interrupt deadlock on an ethernet channel, when the computer is
receiving flow control is basically coming from the printer because it
is typically much slower than the computer.  When the computer is
sending (especially to a slow device) then it can overrun the transmit
and try to send the next (sk?)buffer if the second processor is idle and
not properly locked out.  I actually had more problems when my SMP box
was nearly idle than I did when I was working it and printing at the
same time.

If/when I get printing to work correctly so that we are set up to print
Christmas pictures and cards and so forth, I'll try turning on debug and
hang the printer back on the SMP box to see what happens.  Of course, if
you think that YOU are unfamiliar with the code... it isn't going to be
too likely that I figure out the deadlock, but miracles have happened
before;-)

   rgb

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

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rg...@ph...

[hpoj-devel] CVS - xojpanel

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

David -

I added the copyright notices to the xojpanel source files. I don't have the 
year of Andreas' release, so I gave it as "circa 1998". Not really proper, 
but the best I could do for now. If you want to change the notices in the 
files to indicate a definite year, go ahead. It was probably 1998 or 1999.

I added a thank-you for your patch.

The files are on my site now for inclusion in CVS.


-- 
Joe

RE: [hpoj-devel] SMP patches?

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

Robert G. Brown wrote:
> So I was (and still am) getting the following message from the
> mlcpp_transmit() routine even with the patched driver:
> 
> Dec  1 18:23:30 lucifer kernel: mlcpp0: mlcpp_transmit while TX busy
> 
> I still suspect an SMP problem but I'm not certain.  It could 
> either be
> that having two processors allows a second transmit interrupt to occur
> before the line is fully clean from the first -- not necessarily a
> proper spinlock failure but a mix of spinlock failure and handshaking
> failure.  Or something.  It could also just be some sort of 
> flow control
> failure all by itself -- with megabyte sized images, the 
> printer may be
> trying to say "enough" while it processes what it's got but the flow
> stop may not be getting through.

Hi, Robert.  It also sounds like an SMP problem to me.  Another thing you
could try is to boot the SMP box with the "nosmp" kernel parameter, which
puts it into UP mode.  I'll attempt to look into the problem in the near
future, but I'll have to dig through a part of the code I'm not currently
very familiar with.

> Any helpful suggestions beyond that would be appreciated, especially
> from folks who already know why the transmit while TX busy 
> message might
> be occurring.  I did already note the new requirement that the printer
> port be configured EPC (mine was SPP in the bios) and reset it but it
> made no difference.  I'm guessing that was more for scanner function
> anyway.  This seems like an overrun failure of the plain old printer
> device.
Are you able to scan successfully, particularly at higher resolutions which
cause more data to be transferred for a longer period of time?  Of course,
that's in the opposite direction, but even then there are small amounts of
PC-to-printer data being transferred.

David

RE: [hpoj-devel] xojpanel

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

Hi, Joe.

Joe Piolunek wrote:
> There wasn't any real improvement after changing the port 
> type. Without the 
> usenibble=1 option, xojpanel still fails to start 1/25 times 
> averaged over 
> 500 attempts to execute.
That's strange.  So are there any error messages in syslog related to this?
If I know where it fails, then I might know what needs to be fixed.  You
could also try adding the "debug=1" parameter when loading ieee12844pp.o.

> cat /proc/parports/0/devices showed this:
> IEEE1284.4 device
> lp
I noticed that situation too when playing around with printing the other
day.  It seems dangerous to me, even though I could still print, so that's
why I added a note in color_printing.txt recommending to change the port
from /dev/lpX to /dev/null.

(regarding patch's error messages)
> The trouble seems to have been related the the last line in 
> your patch, which 
> contained only '^@'  . I made my own diff -c  and then using 
> diff, compared 
> your patch and mine.  The difference was a newline at the end 
> of one of the 
> files. Looking at both patches in vim shows '^@'  at the end 
> of your patch, 
> but not at the end of mine. Is the last character something 
> added by your 
> editor?
I just looked at a hex dump of the message I got back from the mailing list,
and I didn't see any null bytes in the message.  Perhaps your mail client is
adding them when you save attachments?  You could always remove the
offending character before patching.

Has anybody else seen this problem, where patch complains that "patch
unexpectedly ends in middle of line"?

> Every time the printer polling timer fires (500ms), it calls 
> getPrinterLcdMessages() which uses some of the original 
> xojpanel code to make 
> a request for each one of the message lines, one immediately 
> after the other. 
> They are separate requests in that sense, but the time 
> interval would be 
> extremely small unless a delay were introduced somewhere 
> outside xojpanel. 
> None of the code I added to xojpanel would create any 
> deliberate delay 
> between asking for line 1 and line 2. I still don't know how 
> the low-level 
> code retrieves the two message lines, but I haven't spent 
> much time looking 
> at it. It probably would be easier to understand if there were more 
> documentation in the code.
What happens is that for each line, getPrinterLCDMessages() calls
PMLGetObjectValue, which sends the request to the peripheral, and then calls
PMLProcess, which sits around and waits for the response.  When PMLProcess
gets the response, it calls XojPanel::processorFunc (which is a callback
function registered at startup by PMLSetup), which saves the string for the
correct line.

I'm not sure why you couldn't add a delay between lines 1 and 2.  Did you
try calling sleep(5 seconds or whatever) in between the two line requests in
getPrinterLCDMessages?

David

Re: [hpoj-devel] new Q about xojpanel

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

On Tuesday 05 December 2000 08:36, Hur...@ao... wrote:
> In a message dated Mon, 4 Dec 2000  5:40:11 PM Eastern Standard Time,
> "PASCHAL,DAVID (HP-Roseville,ex1)" <dav...@hp...> writes:
>
> << You're not going to see an option for hpoj in the control panel (RedHat
> printtool?).  Unfortunately the procedure for setting up printing through
> hpoj is a bit of a hack at the moment.  See the "hpoj documentation offered
> - Comments Please" message sent out on November 30 by Joe Piolunek for a
> good description of how to set it up.  On December 3 I sent out a few
> updates to this file.  This information will be included in 0.7.
>
> Looking back through the messages you have sent out, I don't think you ever
> mentioned what HP all-in-one model you have.  That information could be
> helpful as well.
>
> David
> _______________________________________________

>
> Thanks much.  I will take a look at that message shortly and print it out. 
> Also, I think you are quite right that I have not mentiond which I have. 
> Mine is the OfficeJet 600.
>
> Mike Schauer

Mike -

If you're still having trouble getting xojpanel to run -
 
If you don't have Qt installed, xojpanel won't build.

Check in the hpoj-0.6/apps/xojpanel directory to see if xojpanel actually was 
built. If it was, it may run for you if you change to the 
hpoj-0.6/apps/xojpanel directory first and run it from there. If I don't do 
that, I get errors related to the "lcd.bmp" pixmap not being found. The 
version of xojpanel in that distribution expects lcd.bmp to be found in 
whatever your current directory is.

If you can get it to run from the hpoj-0.6/apps/xojpanel/ directory, here is 
what you can do to run it from another directory, if you want to go to the 
trouble. An improved version of xojpanel will be distributed with the next 
release, which isn't too far in the future.

Choose a directory that you would like lcd.bmp to reside in, creating it if 
necessary. A suggestion is 
/usr/local/share/pixmaps/hpoj 

Copy lcd.bmp from the hpoj-0.6/apps/xojpanel/ directory to that location.
Open the file hpoj-0.6/apps/xojpanel/ojstatus.cpp with a text editor.
Change line 38 from:
LcdPm.load("lcd.bmp");
to:
LcdPm.load("/usr/local/share/pixmaps/hpoj/lcd.bmp");
if you chose that directory.

Rebuild the hpoj package with 'make'.

If you already installed the package, the old xojpanel in the install 
location will need to be deleted or replaced by the new one.

-- 
Joe Piolunek

RE: [hpoj-devel] new Q about xojpanel

[<Hur...@ao...>]

In a message dated Mon, 4 Dec 2000  5:40:11 PM Eastern Standard Time, "PASCHAL,DAVID (HP-Roseville,ex1)" <dav...@hp...> writes:

<< You're not going to see an option for hpoj in the control panel (RedHat
printtool?).  Unfortunately the procedure for setting up printing through
hpoj is a bit of a hack at the moment.  See the "hpoj documentation offered
- Comments Please" message sent out on November 30 by Joe Piolunek for a
good description of how to set it up.  On December 3 I sent out a few
updates to this file.  This information will be included in 0.7.

Looking back through the messages you have sent out, I don't think you ever
mentioned what HP all-in-one model you have.  That information could be
helpful as well.

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

Thanks much.  I will take a look at that message shortly and print it out.  Also, I think you are quite right that I have not mentiond which I have.  Mine is the OfficeJet 600.  

Mike Schauer

[hpoj-devel] Appliance Printing Developer Kit - Release 2.2 (fwd)

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

Hi.  I got this in the mail today and thought others might be interested in
seeing it.

David

------- Forwarded Message


To: Hewlett-Packard's Valued Developer Partners

From: Hewlett-Packard SW Developer Program

Date: December 4, 2000

Subject: Appliance Printing Developer Kit - SDK Release 2.2 

HP announces the release of an updated Software Development Kit (SDK)
Version 2.2 that enables DeskJet printing technology for non-PC appliances.

If you have already taken the first steps with the SDK 1.1 and wish to
update to the latest open source SDK revision 2.2 you can do so today. 

The new SDK includes support for the latest DeskJet series printers, and
offers many new functions and features. For complete product details see the
release notes on the web.

As before, documentation, source code, and e-mail support are available to
help you at no charge. 

So download your copy today by visiting the HP appliance printing
development kit site at:  

http://www.hpapdk.com

Thanks for choosing HP!

Re: [hpoj-devel] xojpanel

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

 On Monday 04 December 2000 05:11, David Paschal wrote:

<...>

> > I'll see what happens after I change the port type to ECP on the IO card
> > the OfficeJet is connected to.
>
> That would be interesting to try.  The bidirectional ECP patch causes the
> parallel port to be used in different ways compared to before (or when
> using usenibble=1).  Is your second parallel port software-configurable, or
> do you have to change jumpers?  If you can't get it working on that port,
> then perhaps you could try swapping ports.
>

I changed the IO card's port type to ECP. The jumpers needed to be moved on 
the card. The reason I installed the card was to add support for a second 
printer. The other printer is connected to a built-in port controlled by the 
BIOS.

There wasn't any real improvement after changing the port type. Without the 
usenibble=1 option, xojpanel still fails to start 1/25 times averaged over 
500 attempts to execute.

Adding the usenibble option is still needed to make xojpanel start reliably 
for me. With it, my script reported two failures in over 2000 attempts to 
execute. Both occurred when I was doing something with another application.

cat /proc/parports/0/devices showed this:
IEEE1284.4 device
lp

which apparently means that both drivers would have access to parport0. I 
added the kernel start-up option  ' append="lp=parport1" ' to /etc/lilo.conf 
that prevents my compiled-in lp from using parport0. Now only 'IEEE1284.4 
device' is reported on that port, but it didn't make any difference to 
xojpanel. It still failed to start about 4% of the time.


> > The patch installed ok, but it gave two error messages:
> > patch unexpectedly ends in middle of line
> > patch unexpectedly ends in middle of line
> >
> > xojpanel compiles runs fine with the patch.
>
> That's strange.  Did you tell your mail client to save the attachment to a
> file, or did you copy and paste (which could cause a problem)?  I just
> looked at a hex dump of the patch file as I sent it out, and there is a
> newline at the end of the file, which is what it could be complaining
> about. Did you double-check the code to make sure it applied the patch
> correctly?
>

I saved it as a file.

The trouble seems to have been related the the last line in your patch, which 
contained only '^@'  . I made my own diff -c  and then using diff, compared 
your patch and mine.  The difference was a newline at the end of one of the 
files. Looking at both patches in vim shows '^@'  at the end of your patch, 
but not at the end of mine. Is the last character something added by your 
editor?

Incidentally, I got the same error when I applied your documentation patch. 
Both patches applied correctly, even with the reported errors.

<...> the wrong message might get to xojpanel
> > first. Could this happen?
>
> Occasionally when I was scrolling through the menus, it looked like it
> updated the two lines in separate polls, which might indicate a race
> condition with the peripheral where it was in the middle of updating the
> LCD as you suggest.  However, it doesn't seem to be a big problem.  My
> concern would be more about what happens if the timer pops again before
> it's done servicing the previous poll.  I think the most optimal behavior
> would be that it ignores timer pops when it's still servicing a previous
> timer pop. A less optimal option would be for it to just queue up poll
> requests.  I think it would be pretty undesirable for it to initiate
> another set of PML transactions before it was done with the last set.
>

Every time the printer polling timer fires (500ms), it calls 
getPrinterLcdMessages() which uses some of the original xojpanel code to make 
a request for each one of the message lines, one immediately after the other. 
They are separate requests in that sense, but the time interval would be 
extremely small unless a delay were introduced somewhere outside xojpanel. 
None of the code I added to xojpanel would create any deliberate delay 
between asking for line 1 and line 2. I still don't know how the low-level 
code retrieves the two message lines, but I haven't spent much time looking 
at it. It probably would be easier to understand if there were more 
documentation in the code.


> > Overhead doesn't seem to be a big problem with xojpanel. It seems to use
> > a lot of memory, but little processor time.
>
> I guess one should expect a fair amount of memory overhead from a GUI
> toolkit such as QT, but it's surprising that it uses more RAM than kwm.
> I would suggest checking all the places where you use "new" to make sure
> that either there's a corresponding "delete" or there doesn't need to be
> one.  I grepped for those strings (with a space after them) and there was
> at least one more new than delete of QString.  Of course I doubt this would
> add a significant amount of overhead, and at least the memory usage doesn't
> appear to grow over time (at least not in the last 15 minutes or so).
>

Most of the program's execution probably takes place in libqt, which seems to 
control or affect memory usage, among other things.  When xojpanel is built 
with Qt 2.x, it uses a lot more memory than if built with Qt 1.x. The docs 
say that qt is able to do some of its own memory clean-up, but I haven't seen 
a complete explanation of this. What it seems like (I might be wrong here) is 
objects created repetitively by 'new' seem to need deletion, but those that 
are only created once and continue to be necessary may not be deletable until 
program termination. When I tried deleting one of those, a segfault occurred. 
I don't have enough information about this. A Qt book is coming soon that may 
help. I have had a different one on order since september, but a recent 
announcement says it won't be published until mid spring. 

I've run xojpanel for several hours at a time after building with qt-1.44 and 
saw no increased memory usage, which seems to indicate that either some of 
the 'new's don't need corresponding 'deletes', or any problem created is 
small. I'll take another look at the undeleted 'new's anyway.


>
> OK, so I will go ahead and start making the changes to support the
> compile-time pixmap path, but I'll wait for your go-ahead to commit it all
> into CVS.  I will take out the changelog file (but reflect it in the
> checkin comments) and remove .directory.  I will include xojpanel.kdelnk in
> the package but probably won't install it anywhere.
>
> David
>

That will be fine.

Probably by tomorrow night (tuesday) I'll have the files on my site with the 
copyright notices added. After that you can put them in CVS whenever you like.

--
Joe

RE: [hpoj-devel] new Q about xojpanel

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

Mike Schauer wrote:
> I think I missed the first question on this subject, but what 
> is xojpanel supposed to do?
Hi, Mike.  xojpanel is a little app that on certain models displays the
contents of the LCD on the front panel.

> On my machine, it will not run.  
> I get an error message that the binary can not be executed, 
> or something like that.
Could you provide the exact error message you get?  Does the binary have
execute permission ("ls -l /usr/local/bin/xojpanel" or wherever you have it
installed)?  Is this installed on an ext2fs partition now?  Does the file
system as a whole allow execute permission?  Make sure there's a "defaults"
or "exec" option and no "noexec" option on the entry for that file system in
/etc/fstab.

> Also, how do I define the hpoj 
> driver as the driver for my printer?  Right now, I have it 
> set up(via the Control Panel) to print as a Deskjet 600C and 
> it is printing just fine.  The Control Panel does not offer 
> the option for the hpoj driver.  I got the software 
> installed, no more errors.  but I don't think it is 
> configured to use that software yet.  Thanks much.
You're not going to see an option for hpoj in the control panel (RedHat
printtool?).  Unfortunately the procedure for setting up printing through
hpoj is a bit of a hack at the moment.  See the "hpoj documentation offered
- Comments Please" message sent out on November 30 by Joe Piolunek for a
good description of how to set it up.  On December 3 I sent out a few
updates to this file.  This information will be included in 0.7.

Looking back through the messages you have sent out, I don't think you ever
mentioned what HP all-in-one model you have.  That information could be
helpful as well.

David

Re: [hpoj-devel] A hack For those of you with external zip drives

[Sammy R. <re...@ca...>]

David Paschal wrote:

> Sammy Redshaw wrote:
> > For those of you linuxers with zip drive if you are running linux
> > mandrake or red hat and only have one parallel port to share your zip
> > drive and printer with use this quick hack to run both devices on the
> > same port
> Hi, Sammy.  Thanks for providing this tip.  Are you plugging the printer into
> the pass-through port on the Zip drive or plugging one device into your PC at

Plugging the printer through  zip 250 drive pass through port only thing is you
can't use both devices at the same time


>
> a time?  I have often heard that one could have problems when connecting a
> printer to a switchbox, Zip drive, or other pass-through device, particularly
> when using advanced protocols such as ECP, because the signals or timing might
> not always get passed through correctly, confusing the PC and/or the printer.
> Perhaps newer Zip drives are better about this.  If it works for you, then
> all the more power to you, but if you ever have problems, then it would be a
> good idea to try it with the printer connected directly to the PC in case
> that was what was causing the problem.
>
> > goto /etc/rc.d/rc.sysinit and write the following lines in
> > after it loads the sound modules or it won't work
> >
> > #load parallel port
> > /sbin/modprobe parport
> > /sbin/modprobe parport_pc
> > /sbin/modprobe parport_probe
> >
> > #load zip drive
> > /sbin/modprobe imm (this for zip250 use the one applicable to zip 100)
> >
> > #load printer
> > insmod  /usr/local/bin/ieee12844.o
> > insmod /usr/local/bin/ieee12844pp.o
> I would also be concerned about having two drivers loaded at the same time
> that try to use the parallel port, particularly if you're scanning an image
> and saving it to your Zip drive.  But again, if this works for you, then
> great.
>
> Another thing to note here is that if you're loading parport_probe and
> ieee12844pp.o at boot time, then you need to make sure your printer is
> connected and powered on at boot time, or you will have to unload and
> reload these drivers later so they will properly detect the printer.
>
> David
>
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/mailman/listinfo/hpoj-devel

[hpoj-devel] new Q about xojpanel

[<Hur...@ao...>]

I think I missed the first question on this subject, but what is xojpanel supposed to do?  On my machine, it will not run.  I get an error message that the binary can not be executed, or something like that.  Also, how do I define the hpoj driver as the driver for my printer?  Right now, I have it set up(via the Control Panel) to print as a Deskjet 600C and it is printing just fine.  The Control Panel does not offer the option for the hpoj driver.  I got the software installed, no more errors.  but I don't think it is configured to use that software yet.  Thanks much.

Mike Schauer
http://mschauer.tripod.com

Re: [hpoj-devel] xojpanel

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

Hi, Joe.

Joe Piolunek wrote:
> Lately the line number reported in the error message has been 263, but that 
> doesn't matter very much now. I'm reasonably certain I found what was causing 
> the problem. In /var/log/messages the OfficeJet is reported as being on an 
> EPP port rather than an ECP, which I thought it was. After I removed the 
> ieee12844pp module and reinserted it with the usenibble=1 option, xojpanel 
> starts every time. I wrote a shell script that would repeatedly start and 
> then kill xojpanel 6 seconds later. It's been through 1000 startups so far 
> without any failures. Previously, one try in 15 starts would fail (rough 
> average).
> I'll see what happens after I change the port type to ECP on the IO card the 
> OfficeJet is connected to. 
That would be interesting to try.  The bidirectional ECP patch causes the
parallel port to be used in different ways compared to before (or when using
usenibble=1).  Is your second parallel port software-configurable, or do you
have to change jumpers?  If you can't get it working on that port, then
perhaps you could try swapping ports.

> The patch installed ok, but it gave two error messages:
> patch unexpectedly ends in middle of line
> patch unexpectedly ends in middle of line
> 
> xojpanel compiles runs fine with the patch.
That's strange.  Did you tell your mail client to save the attachment to a
file, or did you copy and paste (which could cause a problem)?  I just
looked at a hex dump of the patch file as I sent it out, and there is a
newline at the end of the file, which is what it could be complaining about.
Did you double-check the code to make sure it applied the patch correctly?

> Early in development, the printer poll timer controlled scroll speed as well, 
> so to cut down on unnecessary console output during testing, I set it as high 
> as 3000ms (if I remember correctly). Now that the timers are separate, that 
> reason is gone. The poll timer can be set lower than 1000ms. Are there any 
> network delay issues to consider in setting the timer? For instance, if an 
> lcd message is changing in the printer, but it's being polled too often, the 
> wrong message might get to xojpanel first. Could this happen?
Occasionally when I was scrolling through the menus, it looked like it
updated the two lines in separate polls, which might indicate a race
condition with the peripheral where it was in the middle of updating the LCD
as you suggest.  However, it doesn't seem to be a big problem.  My concern
would be more about what happens if the timer pops again before it's done
servicing the previous poll.  I think the most optimal behavior would be
that it ignores timer pops when it's still servicing a previous timer pop.
A less optimal option would be for it to just queue up poll requests.  I
think it would be pretty undesirable for it to initiate another set of PML
transactions before it was done with the last set.

> Overhead doesn't seem to be a big problem with xojpanel. It seems to use a 
> lot of memory, but little processor time.
I guess one should expect a fair amount of memory overhead from a GUI
toolkit such as QT, but it's surprising that it uses more RAM than kwm.
I would suggest checking all the places where you use "new" to make sure
that either there's a corresponding "delete" or there doesn't need to be
one.  I grepped for those strings (with a space after them) and there was
at least one more new than delete of QString.  Of course I doubt this would
add a significant amount of overhead, and at least the memory usage doesn't
appear to grow over time (at least not in the last 15 minutes or so).

> top -p says that most of the time 
> its CPU usage is 0.0%. The timer is set at 500ms for now, though.
OK, that sounds reasonable.

> I'll put a copyright notice in, with credit for anyone who contributed to the 
> remaining parts of the original xojpanel, if the contributors can be 
> identified. If not, I'll give generic credit. It might be important to know 
> the origin of the name 'xojpanel'. Andreas' response should be helpful. 
>
> Hopefully, the copyright issue will be solved soon, so waiting a day or so 
> before committing the new xojpanel code to CVS will probably make one patch 
> unnecessary. 
> 
> Handle the changelog whichever way you think is best.
> 
> You won't need .directory for anything. I probably should have deleted that. 
> lcd.bmp is no longer used or even very usable, due to a size difference. You 
> can leave both of them out.
> 
> A KDE user could copy xojpanel.kdelnk to his/her desktop for a quick way to 
> start the app. Many users may prefer to create their own launchers, but some 
> don't know how, or don't want to go to the trouble. The addition of a GNOME 
> launcher might be nice later on. I have only an older version of GNOME and 
> haven't used it in a while, so I wasn't that interested in making one right 
> away.

OK, so I will go ahead and start making the changes to support the
compile-time pixmap path, but I'll wait for your go-ahead to commit it all
into CVS.  I will take out the changelog file (but reflect it in the checkin
comments) and remove .directory.  I will include xojpanel.kdelnk in the
package but probably won't install it anywhere.

David