hpoj-devel — HPOJ development/support list

Re: [hpoj-devel] xojpanel changes

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

On Fri, May 11, 2001 at 10:53:27AM +0200, Alexander Zimmermann wrote:

> because I don't like to use the "unready", unofficial development
> compiler gcc-2.96 shiped with RH 7.x.

If you know of bugs in the 2.96 compiler, please make sure they are
filed in https://bugzilla.redhat.com/bugzilla so that they can be
fixed (in 2.96 and in the 3.0 branch if the bug appears there too).

Thanks,
Tim.
*/

Re: [hpoj-devel] Next stable release

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

Rainer Dorsch wrote:
> I just seen that OJ6xx scan support is in CVS. I am just wondering, when the 
> next stable release (0.8?) of hopj may be expected.
Hi, Rainer.  As you can see at http://hpoj.sourceforge.net/todo.shtml, there
is still some functionality I need to implement and a number of robustness
and usability issues I need to address before it's ready for another stable
release (0.8).  At the moment my working goal is around the end of July.  I
realize this is a much longer development/release cycle than that between
the last three releases, but there's a lot of new code to stabilize.  In the
meantime, you're certainly welcome to try out the development code in CVS,
especially if you're interested in trying out the new "ptal-hp scan" feature,
which supports scanning on the OfficeJet 600 series, among other models.

David

Re: [hpoj-devel] xojpanel changes

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

Joe Piolunek wrote:
> I made more changes to the xojpanel application that include the ability to 
> change the lcd text color, and many smaller code changes. The format of the 
> devicename string in the titlebar is a little different also.
Hi, Joe.  Thanks for your submission.  I apologize I haven't had a chance to
look at it yet, or at your earlier patch on May 3.  I assume this supercedes
the earlier patch, since you're including all the files.

> I also changed some of the filenames to those that I think make more sense 
> based on their contents and the application. Makefile.in is modified to 
> correspond to the new filenames.
While you're at it, I'm wondering if it would be feasible to combine the two
.cpp files into a single xojpanel.cpp, and rename the .h file to xojpanel.h.
It would make things a little more compact and less spread out.  I don't
know if there is some technical reason (i.e. Qt restriction) why the main()
function needs to be in a separate file from the classes, but I suppose it
was done that way originally to pave the way for something larger like the
xhpcontrol application we've talked about.  In the latter case, I think it's
safe to combine xojpanel/*.cpp for now, because it may be better to write
xhpcontrol from scratch anyway, using xojpanel as an example where
appropriate.

> I didn't know if I could make a reliable patch to send, so I tarred up all of 
> the modified files. I'm hoping filenames in CVS can be changed without 
> causing problems.
It's a matter of removing the old files and adding the new.  Of course, the
old files aren't really deleted, but rather moved into the "attic" directory,
which you can see in various parts of the codebase if you browse the CVS
repository on the web.

David

Re: [hpoj-devel] OfficeJet T45xi

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

aw...@aw... wrote:
> Hello.  We have purchased the Office Jet T45xi and have never been able to
> get it to print in color.  What is wrong???
> 
> Thank You,
> Cathy
> Awanita Staff

Hi, Cathy.  Based on what you've said, I can't give you any useful advice.
For starters it would be helpful to know the following things:

- What sort of system (and operating system) are you using?

- What steps have you taken so far to get you to where you are now?

- What print driver are you using?

Even though I have no information about your situation, one "gotcha" I can
think of offhand is that if you're printing from Netscape, and possibly
other applications, the Print dialog box has a selection for printing in
color or black&white.  So even if your printer is correctly configured to
print in color, you can't print in color if your application isn't.

David

Re: [hpoj-devel] Officejet G95 via Jetdirect questions

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

Michael Dikkema wrote:
> Hi, I installed the hpoj software from CVS yesterday, and I haven't been
> able to get anything working. The documentation mentions nearly nothing
> about jetdirect. I can't figure out if I need ptal-mcld or just
> ptal-printd or neither, considering the rm= line in printcap allows me to
> print blank pages at least.
Hi, Michael.  I'll try to make all this clearer when I reorganize the
documentation in the near future.  The PRINT-HOWTO does mention JetDirect,
including the "rm=" and "rp=" fields when you're not using RedHat printtool.
You don't need either ptal-mlcd or ptal-printd.

> I've also installed ghostscript with hpijs, but I can't figure out how
> that fits in either. I'm not running redhat, nor do I have printtool. I
> basically need the lines in printcap that are relevant to getting gs
> working.
At the moment, I'm not really sure how to do this without RedHat printtool,
but you can probably gleam the necessary information out of the Linux
Printing HOWTO (http://www.linuxprinting.org) and the hpijs documentation.
Try searching around in the hpinkjet help forum and posting a help request
if you don't find what you're looking for.  I do know that for the OfficeJet
G series you use the DJ9xx (not DJ9xxVIP) driver.  Alternatively, you could
start with the standard ghostscript cdj550 (DeskJet 550) driver, which you
should be able to accomplish just from reading the Linux Printing HOWTO and
using "rm=" and "rp=".  Once you get that working, then you can move up to
DJ9xx.

David

Re: [hpoj-devel] xojpanel changes

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

On 10 May, Joe Piolunek wrote:
> If as you reported earlier, the problem with using gcc-2.95.2 on your
> system stems from incompatible libraries, I don't know what I can do
> as a workaround.

You probably can do nothing! And you also shouldn't care about it.
I've got problems on my system only due to my pighead, because I don't
like to use the "unready", unofficial development compiler gcc-2.96
shiped with RH 7.x. Keep your attention on more urgent things.

-- 
Alexander

Re: [hpoj-devel] ptal-hp scan changes (T series now supported!)

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

Hi, Joe.

Joe Piolunek wrote:
> I'm happy to see color scanning begin to work.
...
> Some of the defaults work well. Using the command "ptal-hp mlc:par:0 scan 
> -length 1110" produced a 100x100 color scan that didn't quite match the size 
> of the original, but was close.
> 
> The scanned pages never seem to display or print at the original 
> size (either too small or too large). For pc-assisted copying, would 
> automatic scaling be needed?
If none of the device-native resolutions are quite right, then scaling might
need to be done.  However, if the hpinkjet driver is really capable of 300
dpi the way it claims, then it seems to me that you should be able to scan
and print at that resolution and not need any scaling.  What threshold of
resolutions did you observe between too small and too large?

> The color scans always seem somewhat grainy, even at -res 200. My system 
> doesn't handle color 300x300 scans well, so I haven't tried it again.
I've scanned on many different devices in my testing but haven't been paying
much attention to the image quality.  Here are some thoughts off the top of
my head:

- Depending on what you're scanning, especially at a higher resolution
you might end up seeing the dithering that was used when the page was
originally printed.

- It's possible that the scanning hardware on an older model like the 600
doesn't have quite as good clarity as a more recent model (but I don't know
for sure).  There might be some image processing that can be done in software
to improve this, but IMO this is best left to dedicated IP tools like GIMP.
Of course, a copy app might need to do something like this automatically.

- There is a "sharpening coefficient" PML object on some models which may
make a difference.  However, my sources indicate that it was first supported
on the PSC 300 series, which came out after the OfficeJet 600 series.  Try
"ptal-pml mlc:par:0 get 1.2.2.1.15" and see if you get an error back.  If
not, then try hacking a different value into "int sharpeningCoefficient=0x37;"
in ptal-hp, since I haven't yet made it adjustable on the command line.

- This probably isn't the right answer, but the scanner strip might be in
need of cleaning.  Just be careful not to damage anything if you try to clean
it.

> When trying to scan with "-res 200" , the printer often quits near the end of 
> the scan and displays the LCD message "SYSTEM ERROR2252". I think it also 
> happened once at -res 150. After power cycling the printer, it is able to 
> scan again, but only after resetting  its clock. I used ptal-hp to do that.
I've seen problems like this under certain circumstances.  I'll need to
research this to find out what's causing it.  From your description it sounds
like it's repeatable but doesn't happen every time.

> When opening out.jpg in gimp, an error message often appears that is similar 
> to  "Corrupt JPEG data: 8472 extraneous bytes before marker 0xd9". The number 
> of extraneous bytes varies, but the message always ends in '0xd9'.
That's because the length you specified was too short, and it truncated the
image.  However, it's probably OK if you're not missing anything important
at the end.

David

Re: [hpoj-devel] xojpanel changes

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

On Thursday 10 May 2001 03:25 am, Alexander Zimmermann wrote:

<...>
> > If you get a chance, try it and let us know the results.
>
> Same procedure as last time: it compiles both with gcc-2.95.2 and
> gcc-2.96, but it core dumps afterwards when compiled with gcc-2.95.2 and
> works perfectly with gcc-2.96  :-|

Thanks, Alexander. I'm glad it works when built with the standard compiler, 
at least.

If as you reported earlier, the problem with using gcc-2.95.2 on your system 
stems from incompatible libraries, I don't know what I can do as a 
workaround. AFAIK, in order to use that compiler reliably on RH 7.x, you 
would need to use 2.95.2 to recompile much of  your system from SRPMs.

-- 
Joe

[hpoj-devel] Next stable release

[Rainer D. <ra...@ra...>]

Hello,

I just seen that OJ6xx scan support is in CVS. I am just wondering, when the 
next stable release (0.8?) of hopj may be expected.

Thanks.

Rainer.

Re: [hpoj-devel] xojpanel changes

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

On  9 May, Joe Piolunek wrote:
> Alexander: 
> 
> If you get a chance, try it and let us know the results.

Same procedure as last time: it compiles both with gcc-2.95.2 and
gcc-2.96, but it core dumps afterwards when compiled with gcc-2.95.2 and
works perfectly with gcc-2.96  :-|

-- 
Ale...@fm... / The last thing one knows in
http://www.fmi.uni-passau.de/~zimmerma/ constructing a work is what to
for PGP public key finger            / put first.   -- Blaise Pascal 
zim...@yo...     / 

[hpoj-devel] xojpanel changes

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

David:

I made more changes to the xojpanel application that include the ability to 
change the lcd text color, and many smaller code changes. The format of the 
devicename string in the titlebar is a little different also.

I also changed some of the filenames to those that I think make more sense 
based on their contents and the application. Makefile.in is modified to 
correspond to the new filenames.

I didn't know if I could make a reliable patch to send, so I tarred up all of 
the modified files. I'm hoping filenames in CVS can be changed without 
causing problems.

ojstatus.cpp has many changes, mostly small.
ojstatus.h replaces ojmanager.h (minor changes).
main.cpp replaces ojmanager.cpp (minor changes).
xojpanel/Makefile.in is modified to correspond to the new filenames.


Alexander: 

If you get a chance, try it and let us know the results.


The tarball is attached.

-- 
Joe

[hpoj-devel] OfficeJet T45xi

[awanita <aw...@aw...>]

I am unable to get my color printer to print in color.  What is wrong?

Thanks
Cathy
Awanita Staff

[hpoj-devel] cathy@awanita.org

[awanita <aw...@aw...>]

Hello.  We have purchased the Office Jet T45xi and have never been able to
get it to print in color.  What is wrong???

Thank You,
Cathy
Awanita Staff

[hpoj-devel] Officejet G95 via Jetdirect questions

[Michael D. <mj...@so...>]

Hi, I installed the hpoj software from CVS yesterday, and I haven't been
able to get anything working. The documentation mentions nearly nothing
about jetdirect. I can't figure out if I need ptal-mcld or just
ptal-printd or neither, considering the rm= line in printcap allows me to
print blank pages at least.

I've also installed ghostscript with hpijs, but I can't figure out how
that fits in either. I'm not running redhat, nor do I have printtool. I
basically need the lines in printcap that are relevant to getting gs
working.

Any help would be appreciated, please send directly to me as I'm not on
the list.

Thanks!

,.;::
: Michael J. Dikkema
| Systems / Network Admin - Internet Solutions, Inc.
; mj...@so...   (204) 982-1060
',.

Re: [hpoj-devel] ptal-hp scan changes (T series now supported!)

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

On Sunday 06 May 2001 09:21 am, David Paschal wrote:
> Hi,
>
> I just checked in more changes for ptal-hp scan.  In particular, the
> OfficeJet T series is now supported.  In fact, between ptal-hp and SANE,
> there is now scanning support for every OfficeJet since (and including)
> the 500 series, and for every LaserJet MFP (except the 3100 and 3150).
>
> Other changes worth noting:
>
> - The default scan mode is now color for devices that support it, and gray
> otherwise.  (The 500 series now always outputs .pnm, not .jpg, as default.)
>
> - The default resolution is automatically changed to 300 when doing black
> and white scans on the OfficeJets (and also gray on the 500 series), to
> keep the device from hanging.
>
> - A checkin several days ago caused problems with scanning on pre-T-series
> OfficeJets.  That bug should be fixed now.
>
> - The JPEG improper length bug is still present for the OfficeJet 600, 700,
> and PSC 300.  However, I added a "-length" switch so one can override the
> default (too long) length of twice the width.  Keep in mind that on a
> scrollfed device, the length may vary between scans, even slightly for the
> same document.  I realize this isn't an optimal solution for this problem,
> but it's better than nothing while I look into a proper solution.
>

I'm happy to see color scanning begin to work.

Here are some of the results of the testing I did with the 600 using US 
letter-size (8.5x11) paper:

These combinations of -res and -length options (determined with the 
cursor-coordinate display in gimp) work fairly well with the 600.

-res 100 -length 1110
-res 150 -length 1680
-res 200 -length 2250

Some of the defaults work well. Using the command "ptal-hp mlc:par:0 scan 
-length 1110" produced a 100x100 color scan that didn't quite match the size 
of the original, but was close.

The scanned pages never seem to display or print at the original 
size (either too small or too large). For pc-assisted copying, would 
automatic scaling be needed?

The color scans always seem somewhat grainy, even at -res 200. My system 
doesn't handle color 300x300 scans well, so I haven't tried it again.

When trying to scan with "-res 200" , the printer often quits near the end of 
the scan and displays the LCD message "SYSTEM ERROR2252". I think it also 
happened once at -res 150. After power cycling the printer, it is able to 
scan again, but only after resetting  its clock. I used ptal-hp to do that.

When opening out.jpg in gimp, an error message often appears that is similar 
to  "Corrupt JPEG data: 8472 extraneous bytes before marker 0xd9". The number 
of extraneous bytes varies, but the message always ends in '0xd9'.

-- 
Joe

Re: [hpoj-devel] testing with T65

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

On Monday 07 May 2001 07:43 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> Gerard H. Pille [mailto:gh...@sk...] wrote:
<...>
> > Even after dusting, xojpanel was still better
> > readable than the actual display.  I suppose this will
> > improve in later
> > releases.  Still, the feeling I had when I saw there was something at
> > the other end of the parallel cable, will only be surpassed when
> > intelligent life will be found on earth.
>
> Joe Piolunek (who qualifies as "intelligent life on earth") deserves the
> credit for improving the xojpanel application.
>

Thank you both very much. I nominate the dolphins. It took a surprisingly 
long time to write this, due to the need to stop and dab my eyes. 

-- 
Joe

RE: [hpoj-devel] testing with T65

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

Gerard H. Pille [mailto:gh...@sk...] wrote:
> Finally, the days of scanning with HP Officejet T65 are neigh.
> 
> David, if you weren't so ugly, I could kiss you.
Be careful about translating colloquial expressions like this.  Such a
remark might be perfectly acceptable in some cultures/languages, but here in
the U.S. it would be considered an insult.  Of course, I'm sure you didn't
mean it that way, so I'll let it slide.  :-)

> After recompiling a 2.4.4 kernel without parport, xojpanel appeared,
> showing almost exactly what was on the Officejet's display 
> itself.  Only
> the dust was lacking.
Come over to my house and you can have some of my dust.  :-)

> Even after dusting, xojpanel was still better
> readable than the actual display.  I suppose this will 
> improve in later
> releases.  Still, the feeling I had when I saw there was something at
> the other end of the parallel cable, will only be surpassed when
> intelligent life will be found on earth.
Joe Piolunek (who qualifies as "intelligent life on earth") deserves the
credit for improving the xojpanel application.

> But I am less lucky with scanimage, it hangs after:
...
> I am running a 2.4.4
> SMP kernel on a Abit VP6 with two Intel 866Mhz PIII's.  CVS hpoj dates
> from yesterday, and I'm using sane-backends-1.0.4.  Had to specify
> --with-ptal=/usr/local and --enable-shared allthough these 
> are supposed
> to be default.  Otherwise sane configure did not find -lptal  
> (there is
> no libptal.a and configure runs a test compiling -static).
> 
> Come on David, I know you can do it.
Scanning on the T series is not yet supported by SANE.  For now, use the
"ptal-hp" command-line application, which is part of the hpoj package in
CVS.  To do a color scan, just insert your document and run the command
"ptal-hp mlc:par:0 scan".  Append the "-help" switch for a list of options.

I will look into the problem with configuring SANE with PTAL.  What
distribution and version are you using?  I've had library problems on RedHat
7.1, and this may be a similar issue.

David

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

[<rj...@wo...>]

On  7 May, Joe Piolunek wrote:
> On Sunday 06 May 2001 02:08 pm, rj...@wo... wrote:
> 
> <...>
>> I am planning to attach a G55 to a headless Linux box that hides under
>> a desk.  I have no need or desire for cute display stuff.  It will
>> get in the way.  
> 
> 
> I don't think anyone has claimed that the xojpanel app is particularly 
> important in itself. You never *have to* run it. You can avoid building it by 
> specifying '--without-qt' at configure time.
> 
I didn't mean to imply that someone claimed it was required.  It was
that you need to read the code to figure out whether and when it is
required.

> If you are instead referring to a future "xhpcontrol" application, do you 
> mean that you would need a command-line version?
> 
In my opinion, all applications should have a command-line version if
possible. The wonders of scripting are manyfold, and there are always
times when setting up a GUI is inconvenient at best.  When dealing with
remote support it is often difficult to get more than an terminal
emulation session over to their system.  

In one case that I know, the decision to support only an HTML GUI access
for service resulted in the requirement for a site visit.  The site
visit would cost as much as the equipment.  So the "broken" (actually
misconfigured) equipment was returned for a full refund as inherently
defective.

> My opinion of GUI applications in general is that they should look nice, and 
> there should be more of them, particularly if we want to attract the average 
> desktop user to "free" operating systems.
> 

Yes indeed.  There are also times where cute graphics are appropriate.
Absence of a friendly GUI capability is just as big a mistake as absence
of a command-line version.  They are both needed, just at different
times for different reasons.

R Horn

RE: [hpoj-devel] (no subject)

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

jc...@ru... wrote:
...
> Redhat 7.1 w/ 2.4.3 kernel
...
> Downloaded the 0.7 hpoj.
...
> ieee12844pp.c: In function `ecp_fwd_to_rev':
> ieee12844pp.c:549: warning: implicit declaration of function
> `parport_write_econtrol'
> ieee12844pp.c:553: `PARPORT_CONTROL_DIRECTION' undeclared 
> (first use in
> this function)
> ieee12844pp.c:553: (Each undeclared identifier is reported only once
> ieee12844pp.c:553: for each function it appears in.)
> ieee12844pp.c: In function `ecp_rev_to_fwd':
> ieee12844pp.c:644: `PARPORT_CONTROL_DIRECTION' undeclared 
> (first use in
> this function)
> ieee12844pp.c: In function `mlcpp_intr':
> ieee12844pp.c:1199: `tq_scheduler' undeclared (first use in 
...
> Any idea what does this mean? Thanks.

Hi.  You need to download and apply the patch referenced at
http://hpoj.sourceforge.net/todo.shtml that fixes some problems with 2.4.

David

[hpoj-devel] testing with T65

[Gerard H. P. <gh...@sk...>]

Finally, the days of scanning with HP Officejet T65 are neigh.

David, if you weren't so ugly, I could kiss you.

After recompiling a 2.4.4 kernel without parport, xojpanel appeared,
showing almost exactly what was on the Officejet's display itself.  Only
the dust was lacking.  Even after dusting, xojpanel was still better
readable than the actual display.  I suppose this will improve in later
releases.  Still, the feeling I had when I saw there was something at
the other end of the parallel cable, will only be surpassed when
intelligent life will be found on earth.

hp-devid reports:
# ptal-devid mlc:par:0
ptalInit(): debug level set to 2.
ptalInit()
ptalDeviceAdd(provider=<mlc>,name=<par:0>): dev=0x08049A18.
MFG:Hewlett-Packard;MDL:OfficeJet T
Series;CMD:MLC,PCL,PML;CLASS:PRINTER;DESCRIPTION:Hewlett-Packard
OfficeJet T Series;VSTATUS:$HB0$FC0,FF,DN,IDLE,CUT;
ptalDone()
ptalDeviceDelete(dev=0x08049A18)
ptalDeviceClose(dev=0x08049A18)


But I am less lucky with scanimage, it hangs after:

-- # scanimage -v -d hp:mlc:par:0
[sanei_debug] Setting debug level of hp to 128.
[hp] sane_init called
ptalInit(): debug level set to 2.
ptalInit()
[hp] sane_init will finish with Success
[hp] sane_open called
[hp] hp_read_config: hp backend v0.93 starts reading config file
[hp] hp_read_config: processing line <mlc:par:0>
[hp] hp_read_config: processing line <option connect-ptal>
[hp] hp_read_config: attach mlc:par:0
[hp] hp_get_dev: New device mlc:par:0, connect-ptal, scsi-request=0
[hp] sanei_hp_device_new: mlc:par:0
ptalDeviceAdd(provider=<mlc>,name=<par:0>): dev=0x08054618.
ptalChannelAllocate(dev=0x08054618): chan=0x080546B8.
ptalChannelSetRemoteService(chan=0x080546B8,serviceType=2,socketID=0,serviceName=<>)
[hp] scsi_flush: writing 2 bytes:
[hp]  0x0000  1B 45                                            .E
ptalChannelOpen(chan=0x080546B8): fd=5.
ptalChannelWrite(chan=0x080546B8,buffer=0x08053DE6,count=2)
ptalChannelWrite(chan=0x080546B8,buffer=0x08053DE6,count=2) returns 2.
[hp] scsi_flush: writing 7 bytes:
[hp]  0x0000  1B 2A 73 32 35 37 45                             .*s257E
ptalChannelOpen(chan=0x080546B8): already open (fd=5).
ptalChannelWrite(chan=0x080546B8,buffer=0x08053DE6,count=7)
ptalChannelWrite(chan=0x080546B8,buffer=0x08053DE6,count=7) returns 7.

I'm attaching strace output from the same session.  I am running a 2.4.4
SMP kernel on a Abit VP6 with two Intel 866Mhz PIII's.  CVS hpoj dates
from yesterday, and I'm using sane-backends-1.0.4.  Had to specify
--with-ptal=/usr/local and --enable-shared allthough these are supposed
to be default.  Otherwise sane configure did not find -lptal  (there is
no libptal.a and configure runs a test compiling -static).

Come on David, I know you can do it.


Gerard H. Pille

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

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

On Sunday 06 May 2001 02:08 pm, rj...@wo... wrote:

<...>
> I am planning to attach a G55 to a headless Linux box that hides under
> a desk.  I have no need or desire for cute display stuff.  It will
> get in the way.  


I don't think anyone has claimed that the xojpanel app is particularly 
important in itself. You never *have to* run it. You can avoid building it by 
specifying '--without-qt' at configure time.

If you are instead referring to a future "xhpcontrol" application, do you 
mean that you would need a command-line version?

My opinion of GUI applications in general is that they should look nice, and 
there should be more of them, particularly if we want to attract the average 
desktop user to "free" operating systems.

-- 
Joe

[hpoj-devel] (no subject)

[<jc...@ru...>]

Greeting,
=20
The machine is:
=20
PIII w/ 512M RAM
Redhat 7.1 w/ 2.4.3 kernel
HP OfficeJet R80
=20
Downloaded the 0.7 hpoj. When I tried to compile with
=20
root@rehat hpoj-0.7]# ./configure --without-snmp
Omit a lot of stuff)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Configuration done.  Created Makefiles using the following substitutions:
  prefix            =3D /usr/local
  MAIN_MAKE_SUBDIRS =3D ptal ieee12844 ojlib apps
  APPS_MAKE_SUBDIRS =3D cmdline print xojpanel
  bindir_program    =3D ptal/ptal-connect ptal/ptal-printd scripts/addcr
scripts/addpjl apps/cmdline/hpo apps/print/ieee12844_print
apps/xojpanel/xojpanel
  libdir_program    =3D
  libdir_data       =3D ieee12844/ieee12844.o ieee12844/ieee12844pp.o
  includedir_data   =3D ptal/ptal.h
  DEFINES_CMDLINE   =3D -DHAVE_MLC
  INCLUDE_CMDLINE   =3D -I/home/jcai/hpoj-0.7/include
-I/home/jcai/hpoj-0.7/ptal -I/usr/src/linux-2.4.3/include
-I/usr/lib/qt-2.3.0/include
  LIBRARY_CMDLINE   =3D -L/home/jcai/hpoj-0.7/ojlib
-L/home/jcai/hpoj-0.7/ptal -L/usr/lib/qt-2.3.0/lib
  LIBSNMP_CMDLINE   =3D
  LINUX_VERSION     =3D 2.4.3
  QT_MOC            =3D /usr/lib/qt-2.3.0/bin/moc
=20
[root@redhat hpj-0.7]make
(Omit a lot of stuff)
make[1]: Entering directory `/home/jcai/hpoj-0.7/ieee12844'
>ieee12844.ver
gcc -E -O -I/home/jcai/hpoj-0.7/include -I/home/jcai/hpoj-0.7/ptal
-I/usr/src/linux-2.4.3/include -I/usr/lib/qt-2.3.0/include -Wall
-Wstrict-prototypes -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB  -D__GENKSYMS__
ieee12844.c | \
/sbin/genksyms -k 2.4.3 >ieee12844.ver
gcc -O -I/home/jcai/hpoj-0.7/include -I/home/jcai/hpoj-0.7/ptal
-I/usr/src/linux-2.4.3/include -I/usr/lib/qt-2.3.0/include -Wall
-Wstrict-prototypes -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB  -c
ieee12844pp.c
ieee12844pp.c: In function `ecp_fwd_to_rev':
ieee12844pp.c:549: warning: implicit declaration of function
`parport_write_econtrol'
ieee12844pp.c:553: `PARPORT_CONTROL_DIRECTION' undeclared (first use in
this function)
ieee12844pp.c:553: (Each undeclared identifier is reported only once
ieee12844pp.c:553: for each function it appears in.)
ieee12844pp.c: In function `ecp_rev_to_fwd':
ieee12844pp.c:644: `PARPORT_CONTROL_DIRECTION' undeclared (first use in
this function)
ieee12844pp.c: In function `mlcpp_intr':
ieee12844pp.c:1199: `tq_scheduler' undeclared (first use in this function)
make[1]: *** [ieee12844pp.o] Error 1
make[1]: Leaving directory `/home/jcai/hpoj-0.7/ieee12844'
make: *** [release] Error 2
=20
Any idea what does this mean? Thanks.




-----------------------------------------------
Runbox Mail Manager - www.runbox.com
Free online email application

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

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

On Mon, May 07, 2001 at 03:04:07AM -0700, David Paschal wrote:

> I expect there will be risk areas where ppdev may not satisfy all of
> my requirements, like proper bounded ECP support, sending ECP
> channel addresses, and other things that must correctly go over the
> wire to ensure proper communication with the device.  However, I
> suppose I can try to fix any such problems myself and submit them to
> Tim Waugh for inclusion into future kernel versions/backports,
> similar to what I did with fixing bugs in the USB printer.c code.

Indeed; it doesn't do BECP yet, although ECP channels should work.

Tim.
*/

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

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

R Horn (rj...@wo...) wrote:
> I  Parallel interface performance
> 
> A major factor in the poor performance of the new usermode parallel
> interface is the use of usermode itself.  I've been through this
> before.  You cannot get really good performance of ECP in usermode on
> Linux.  Speeds up to 30 KB/sec are easy.  With great difficulty you can
> push it to 60 KB/sec.
> 
> The 2.4 kernel (and 2.2 backports) provide the "ppdev" module for
> implementing customized protocols like 1284.4 in usermode
> applications.  It provides basic building blocks like "negotiate" via
> ioctl()s.  It provides efficient I/O transfer through the ioctl()
> modes and the read()/write() transfers.  I've built customized
> protocols using ppdev and gotten over 350KB/sec transfer rates without
> any special effort.
> 
> There may be some internal reason or Windows port reason for wanting the
> whole thing in usermode, but switching to the use of ppdev lets the
> development of the 1284.4 protocol remain usermode without losing the
> performance of kernel drivers.  It also simplifies extending support
> beyond the generic x86 parallel device world.
Hi.  Thanks for your feedback.  I will probably look into ppdev as an
alternative parallel port interface, particularly if it can give the great
performance gains that you suggest.  I decided to start out with a generic
user-mode driver which is easy to port and won't break when the kernel
changes, but I tried to leave it open to leveraging platform-specific
kernel support when available.  Of course, such optimized support would have
to be optional, so that people aren't tied to specific kernel versions the
way they were with hpoj-0.7 and before, and so there's something to fall
back on if ppdev ever breaks.

I expect there will be risk areas where ppdev may not satisfy all of my
requirements, like proper bounded ECP support, sending ECP channel
addresses, and other things that must correctly go over the wire to ensure
proper communication with the device.  However, I suppose I can try to fix
any such problems myself and submit them to Tim Waugh for inclusion into
future kernel versions/backports, similar to what I did with fixing bugs in
the USB printer.c code.

> II Architecture Documentation
> 
> When you get around to documenting the structure it would help to have
> a high level view of which parts perform what functions.  What is
> mandatory for anything to work.  What are the dependencies.  I know
> that reading the source eventually reveals this, but having a short
> paragraph on each major part would help.
Will do.  I'm planning a major reorganization of the documentation before
I release 0.8.  You might want to keep an eye on it so that when I get
around to it you can help me make sure I properly cover what you want.

> I am planning to attach a G55 to a headless Linux box that hides under
> a desk.  I have no need or desire for cute display stuff.  It will
> get in the way.  What I want is three things:
>  1) a printing daemon with reasonable network status reports.
>     Something like CUPS for instance.
The ptal-printd daemon in hpoj is designed to work with any spooler that can
print to a /dev/lpX style character device.  What sort of "network status
reports" are you looking for?

>  2) Good security.  I do not want anything to run as root.  (With
>     ppdev the entire protocol can run as a spooler ID.  I just need to
>     give that ID permission to read and write the parallel device.)
>     Anything that runs as root requires extensive code review and I do
>     not have unlimited time.
Likewise, with USB, ptal-mlcd needs write access to the /dev/ptal-mlcd
directory and read/write access to /dev/usb/lpX.

>  3) A scan -> email.  This is actually where some of the front panel
>     features could be nice.  If it lists the usernames that are
>     members of a group (e.g. scan users) then the controls on the
>     scanner could be used to select the username.  Then the scan can
>     be turned into a mail attachment and mailed to that user.  (Again
>     avoiding the need for anything to be root.)
After the recent discussion on the "scan to" feature, I started thinking
along these lines of using the Scan To button to scroll through a list of
users and e-mailing the scan to the selected user.  A similar feature could
be used for receiving faxes on models that support this functionality.

> This gives me a nice shared light duty printer/scanner/copier.  Which
> is what the G55 is for.  I'm rummaging around through code and
> emails to figure out how to put this together.
If you don't want to dedicate a whole PC as a print server, you could
consider getting an HP JetDirect print server, such as the new USB 175X,
from which the MLC/1284.4 driver was leveraged and open-sourced for this
project.

> 
> III USB
> 
> How stable is the USB these days?
I've used it quite a bit and found it to be quite stable, as long as you're
running a sufficiently recent kernel version (2.2.19 or 2.4.2) and the
underlying hardware is good.  I've run into major stability problems due to
defective motherboard USB host controllers, which I solved by switching to
a PCI USB add-in card.

> Since I have no desire for cute
> graphics, can I improve stability by leaving out some portions?  I
> understand that part of the stability problem is inherent in some
> buffering bugs internal to the G55.
What buffering bugs are you referring to?

> These seem to be related to
> query traffic, so things like eliminating the front panel emulation
> might help a lot.
You're certainly free not to run xojpanel (the LCD display app) if you don't
want it.  The core drivers and libraries, including ptal-mlcd, ptal-printd,
and libptal, are probably what you'll be most interested in.

> USB is more attractive from a performance and cabling point of view.
> In my case, the headless machine parallel port is already in use for
> something else, but it has spare USB ports.  So I'm gradually working
> along the USB path.
It's certainly worth looking into.

David

Re: [hpoj-devel] Working with SANE and FreeBSD 4.2

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

Stan Barber wrote:
> I was able to take hpoj-0.7 and get it to work pretty much out of the box
> with a network connected officejet G 85. I am delighted about this.
> 
> I have not tried to print yet as I have a priting solution I am currently
> happy with, but I will want to come back when there is a fax solution of some
> kind.
Hi, Stan.  Thanks for the success report.

Just out of curiosity, what version of 'make' do you have on your system?
A while back I tried to compile the development code in CVS on SourceForge's
FreeBSD compile farm box, and ran into lots of problems, mostly due to the
fact that they were using a non-GNU version of 'make', which choked on a lot
of constructs in the makefiles that seem to be GNU-specific extensions.
Eventually I plan to resolve these problems so that the software is as fully
functional as possible on FreeBSD and possibly other BSDs.

Since you mentioned you wanted a fax solution, do you have any thoughts on
what kind of solution you might want and how you might want to go about
interacting with it?  I should note that the G series doesn't support
receiving faxes to the PC AFAIK, so you'll be limited to sending faxes.
I need to do some research on existing fax solutions, such as HylaFax, to
see how they work and whether it would make sense to leverage their
functionality and integrate OfficeJet faxing with them, as was the case with
ghostscript and SANE, or whether I should develop something from scratch,
as was the case with the scanning part of ptal-hp (in CVS). 

Also, it would be greatly appreciated if you don't mind trying out current
development code in CVS on FreeBSD from time to time.  Eventually it will
become version 0.8, and it will be so much the better with feedback on the
development code.

David