hpoj-devel — HPOJ development/support list

[hpoj-devel] ptal-devid checkin and logging fix

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

Hi,

I checked in a new "ptal-devid" application, which is a replacement for
"hpo devid".  Since it uses PTAL, it should work for both USB- and parallel-
connected devices.  Eventually it should also work for JetDirect-connected
devices, but I haven't implemented this functionality in the JetDirect PTAL
provider yet.  I updated the README and INSTALL files to mention this
application.

I also fixed a nasty (and stupid on my part:-) bug I introduced into PTAL
last night when I changed around the error/debug logging functionality,
which caused garbage to be displayed in messages.  When I changed the logging
to use variable-length argument lists, I forgot to change "fprintf" to
"vfprintf".

Running "cvs update" within your sandbox should pick up these changes.

David

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

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

Joe Piolunek wrote:
> The build fails with this output:
> ...
> gcc -I/home/joe/hpoj_proj/CVS/hpoj_CVS_03-10-2001/mlcd 
> -I/home/joe/hpoj_proj/CVS/hpoj_CVS_03-10-2001/mlcd/transport -O -g -Wall 
> -DEX_TRANSPORT_UNIX_PORT -DPAR_PLATFORM_LINUX -DUSB_PLATFORM_NONE -DJD_DEBUG 
> -c -o ExMgr.o ExMgr.cpp
> In file included from 
> /home/joe/hpoj_proj/CVS/hpoj_CVS_03-10-2001/mlcd/ParPort.h:396,
>                  from ExMgr.cpp:1981:
> /usr/include/sys/io.h: In function `void outb(unsigned char, short unsigned 
> int)':
> /usr/include/sys/io.h:98: parse error before `::'
Hi, Joe.  Thanks for the bug report.  I just checked in a change to ParPort.h
to wrap "#include <sys/io.h>" with 'extern "C" { }'.  Try it again after
doing a "cvs update" and see if that fixes the problem.  Perhaps I should go
through and do this around most if not all #includes from C++ files, just to
be on the safe side.

> Can you hold off on checking in the patch I posted recently? I only sent it 
> so you could look at the changes if you wanted to, and see if they work 
> correctly.
> 
> I'd like to modify some of the comments a little more to enable (but not 
> necessarily include) document generation by Doxygen or a similar utility, so 
> there will be at least one more patch, probably applied against the last 
> official release (0.7).
I haven't had a chance to try it out since I pretty much pulled the rug out
from under it by removing ojlib, but I'll wait for your next drop and build
it with 0.7.

> Generated documentation can be a benefit. Would it be a good idea for the 
> entire project?
It might be a good idea for PTAL at least, since other applications need to
be able to interface with it.  I don't know if it's necessary to generate
separate documentation for individual components that don't export their own
interfaces, but of course, it doesn't hurt to have the information in there
one way or another.

David

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

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

On Friday 09 March 2001 09:29 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> Hi,
>
> I'm pleased to announce that the new "ptal-mlcd" I/O driver I've talked a
> lot about lately is now checked into CVS.  In addition to providing a more
> robust I/O infrastructure for the hpoj software, ptal-mlcd now supports USB
> for the OfficeJet G, K, and LaserJet 3200 series.  I would like to invite
> everyone to download the new code from CVS and try it out, particularly
> those who have requested USB support or who have reported problems with the
> old kernel-mode drivers related to SMP machines or particular kernel
> versions.
>
> In addition to the ptal-mlcd addition, I also changed ptal-printd to fork
> into the background by default (unless the "-nofork" switch is given), and
> reorganized the codebase and build process somewhat.
>
> Please let me know on the hpoj-devel mailing list of any problems that you
> find that I may have missed, but also be sure to look at the "Bugs and
> TODO" page (http://hpoj.sourceforge.net/todo.shtml) for information on
> known issues.  In particular, xojpanel is temporarily disabled while I
> finish the new PTAL PML support, and there are currently some performance
> and CPU utilization issues I need to resolve as well.


David:

The build fails with this output:
...
...
gcc -I/home/joe/hpoj_proj/CVS/hpoj_CVS_03-10-2001/mlcd 
-I/home/joe/hpoj_proj/CVS/hpoj_CVS_03-10-2001/mlcd/transport -O -g -Wall 
-DEX_TRANSPORT_UNIX_PORT -DPAR_PLATFORM_LINUX -DUSB_PLATFORM_NONE -DJD_DEBUG 
-c -o ExMgr.o ExMgr.cpp
In file included from 
/home/joe/hpoj_proj/CVS/hpoj_CVS_03-10-2001/mlcd/ParPort.h:396,
                 from ExMgr.cpp:1981:
/usr/include/sys/io.h: In function `void outb(unsigned char, short unsigned 
int)':
/usr/include/sys/io.h:98: parse error before `::'
/usr/include/sys/io.h: In function `void outb_p(unsigned char, short unsigned 
int)':
/usr/include/sys/io.h:104: parse error before `::'
/usr/include/sys/io.h: In function `void outw(short unsigned int, short 
unsigned int)':
/usr/include/sys/io.h:111: parse error before `::'
/usr/include/sys/io.h: In function `void outw_p(short unsigned int, short 
unsigned int)':
/usr/include/sys/io.h:118: parse error before `::'
/usr/include/sys/io.h: In function `void outl(unsigned int, short unsigned 
int)':
/usr/include/sys/io.h:125: parse error before `::'
/usr/include/sys/io.h: In function `void outl_p(unsigned int, short unsigned 
int)':
/usr/include/sys/io.h:131: parse error before `::'
make[1]: *** [ExMgr.o] Error 1
make[1]: Leaving directory `/home/joe/hpoj_proj/CVS/hpoj_CVS_03-10-2001/mlcd'
make: *** [all] Error 2

My system is running linux kernel 2.2.16 . The compiler is gcc-2.95.2 . The 
box has one MB-based parport, with a second parport on a separate I/O card.

I tried configuring with and without USB support. USB is disabled in the bios 
at present. I also rmmoded the ieee* modules, removed libptal*, and killed 
ptal-printd before building.

The io.h referred to is from the redhat glibc-devel-2.1.3-22.i386.rpm. Below 
is the section of io.h containing line 98.

extern inline void
outb (unsigned char value, unsigned short port)
{
  __asm__ __volatile__ ("outb %b0,%w1"::"a" (value), "Nd" (port));
}



> (Joe, since you still depend on the old functionality of ojlib to do your
> xojpanel development, you might want to save your old sandbox and create a
> separate one if you want to try out the new code.  Also, I haven't checked
> in your latest xojpanel changes since it currently isn't being built, but I
> can if you're at a stopping place for the time being and would like me to
> check in what you have so far.)

Can you hold off on checking in the patch I posted recently? I only sent it 
so you could look at the changes if you wanted to, and see if they work 
correctly.

I'd like to modify some of the comments a little more to enable (but not 
necessarily include) document generation by Doxygen or a similar utility, so 
there will be at least one more patch, probably applied against the last 
official release (0.7).

Generated documentation can be a benefit. Would it be a good idea for the 
entire project?

-- 
Joe

[hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

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

Hi,

I'm pleased to announce that the new "ptal-mlcd" I/O driver I've talked a
lot about lately is now checked into CVS.  In addition to providing a more
robust I/O infrastructure for the hpoj software, ptal-mlcd now supports USB
for the OfficeJet G, K, and LaserJet 3200 series.  I would like to invite
everyone to download the new code from CVS and try it out, particularly
those who have requested USB support or who have reported problems with the
old kernel-mode drivers related to SMP machines or particular kernel
versions.

In addition to the ptal-mlcd addition, I also changed ptal-printd to fork
into the background by default (unless the "-nofork" switch is given), and
reorganized the codebase and build process somewhat.

Please let me know on the hpoj-devel mailing list of any problems that you
find that I may have missed, but also be sure to look at the "Bugs and TODO"
page (http://hpoj.sourceforge.net/todo.shtml) for information on known
issues.  In particular, xojpanel is temporarily disabled while I finish the
new PTAL PML support, and there are currently some performance and CPU
utilization issues I need to resolve as well.

To get the code out of CVS, follow the instructions in the "CVS" section at
http://hpoj.sourceforge.net/download.shtml.

(Joe, since you still depend on the old functionality of ojlib to do your
xojpanel development, you might want to save your old sandbox and create a
separate one if you want to try out the new code.  Also, I haven't checked
in your latest xojpanel changes since it currently isn't being built, but I
can if you're at a stopping place for the time being and would like me to
check in what you have so far.)

At this point I think it's safe to cease further development on the
"ieee12844*.c" kernel-mode drivers, since ptal-mlcd is designed to address
many of the limitations of the old drivers.  I'd like to take this
opportunity to thank Burkhard and Damien for their efforts in maintaining
that code recently, as well as Gerhard and Roger for developing it
originally and in cooperation with Andreas for starting this project in the
first place.

I look forward to the bug reports.  Enjoy!  :-)

David

RE: [hpoj-devel] problem with hp officejet g85

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

Manfred Gehrke wrote:
> i run hp officejet g85 under suse 7.0 (2.2.16 kernel)
> 
> scanimage scanimage -d hp:mlc:mlcpp0 --test
> 
> fails with following log messages:
> 
>   scanimage -d hp:mlc:mlcpp0 --test
...
> [hp] hp_get_dev: New device mlc:mlcpp0, connect-ptal, scsi-request=0
> [hp] sanei_hp_device_new: mlc:mlcpp0
> ptalMlcDeviceOpen(name=<mlcpp0>): found matching dev=0x080508F0.
> ptalChannelAllocate(dev=0x080508F0): chan=0x080549E8.
> ptalChannelSetRemoteService(chan=0x080549E8,serviceType=2,sock
> etID=0,serviceName=<>)
> ptalMlcChannelOpen(chan=0x080549E8): error creating socket!
> ptalChannelOpen(chan=0x080549E8): provider failed open!
...
> do i have something installed wrong, or are some access 
> rights to be set?

Hi, Manfred.  Did you remember to insmod all the necessary kernel-mode
drivers (parport, parport_pc, parport_probe, ieee12844.o, ieee12844pp.o)?  I
think the "error creating socket" would indicate that at least ieee12844.o
was missing.

David

[hpoj-devel] problem with hp officejet g85

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

hi, 

i run hp officejet g85 under suse 7.0 (2.2.16 kernel)

scanimage scanimage -d hp:mlc:mlcpp0 --test

fails with following log messages:

  scanimage -d hp:mlc:mlcpp0 --test
[sanei_debug] Setting debug level of hp to 12.
[hp] sane_init called
ptalInit(): debug level set to 2.
ptalInit()
ptalDeviceProbe: dev=<mlc:mlcpp0>.
ptalDeviceAdd(provider=<mlc>,name=<mlcpp0>): dev=0x080508F0.
ptalDeviceProbe: dev=<mlc:mlcpp1>.
ptalDeviceAdd(provider=<mlc>,name=<mlcpp1>): dev=0x08050918.
[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 <#scsi HP>
[hp] hp_read_config: processing line <#/dev/scanner>
[hp] hp_read_config: processing line <mlc:mlcpp0>
[hp] hp_read_config: processing line <option connect-ptal>
[hp] hp_read_config: processing line <>
[hp] hp_read_config: attach mlc:mlcpp0
[hp] hp_get_dev: New device mlc:mlcpp0, connect-ptal, scsi-request=0
[hp] sanei_hp_device_new: mlc:mlcpp0
ptalMlcDeviceOpen(name=<mlcpp0>): found matching dev=0x080508F0.
ptalChannelAllocate(dev=0x080508F0): chan=0x080549E8.
ptalChannelSetRemoteService(chan=0x080549E8,serviceType=2,socketID=0,serviceName=<>)
ptalMlcChannelOpen(chan=0x080549E8): error creating socket!
ptalChannelOpen(chan=0x080549E8): provider failed open!
[hp] hp_nonscsi_device_new: SCL reset failed
[hp] scsi_close: closing fd -1
ptalChannelClose(chan=0x080549E8)
ptalChannelClose(chan=0x080549E8): not open!
[hp] hp_get_dev: New device mlc:mlcpp0, connect-ptal, scsi-request=0
[hp] sanei_hp_device_new: mlc:mlcpp0
ptalMlcDeviceOpen(name=<mlcpp0>): found matching dev=0x080508F0.
ptalMlcChannelOpen(chan=0x080549E8): error creating socket!
ptalChannelOpen(chan=0x080549E8): provider failed open!
[hp] hp_nonscsi_device_new: SCL reset failed
[hp] scsi_close: closing fd -1
ptalChannelClose(chan=0x080549E8)
ptalChannelClose(chan=0x080549E8): not open!
scanimage: open of device hp:mlc:mlcpp0 failed: Error during device I/O
[hp] sane_exit called
[hp] sane_exit will finish

do i have something installed wrong, or are some access rights to be set?

any suggestions?

thanks in advance

manfred

[hpoj-devel] RE: RPM driver for PSC 500

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

Hi, Julian.  I'm CCing the hpoj-devel mailing list, because that's the best
forum for this question.

What particular compile errors are you having?

At the moment there's no pre-compiled RPM available that I know of.  I'm
getting ready to check in a new I/O driver and various cleanups to the build
process during the next few days, so you could try that to see if it works
any better for you.  Just be sure you're subscribed to the two mailing lists
so you'll hear about it.  :-)

David

> -----Original Message-----
> From: Julian Coccia [mailto:jc...@op...]
> Sent: Monday, February 19, 2001 11:07 AM
> To: dav...@hp...; ger...@mc...;
> br...@bs...
> Subject: RPM driver for PSC 500
> 
> 
> Hi there !
> 
> I've been trying to install the HP PSC 500 scanner driver for 
> linux, but 
> I can't get it to work. For some reason I get errors when trying to 
> compile it.
> 
> Do you guys have a pre-compiled version, or an RPM ? I'm 
> using Mandrake 
> 7.2
> 
> Thanks a lot
> Julian Coccia
> 

RE: [hpoj-devel] Kernel 2.4.1 module: PATCH

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

Hi, Mika and Burkhard.

If nothing works unless you use the "usenibble=1" option, then the parallel
port may not be configured for bidirectional ("BPP" or "PS/2") or ECP.  If
it's set to unidirectional ("SPP") or EPP, then try changing it in the BIOS
setup to see if that fixes the problem.

My changes to ieee12844pp.c in 0.7 were partially to address the event 9 (if
I remember correctly) problem you're seeing here, but the tradeoff is that
the parallel port needs to be bidirectional or ECP.

David

> -----Original Message-----
> From: Burkhard Kohl [mailto:bu...@bu...]
> Sent: Wednesday, March 07, 2001 2:11 PM
> To: Mika Saari
> Cc: hpo...@li...
> Subject: Re: [hpoj-devel] Kernel 2.4.1 module: PATCH
> 
> 
> Mika, I've have forwarded your mail to David.
> 
> At the moment I don't understand your problem - it looks
> like the devices stops talking to your host after successfully
> starting to scan.
> 
> Are you running an SMP kernel? In that case you might want to
> try a uniprocessor kernel first - espially if you happen to 
> have just one processor in your box. (Many distributitions)
> come with SMP kernels which is not always the best choice.
> 
> Without seeing the debug output from ieee12844pp.o I it's
> impossible to determine exactly what happens. 
> Please load the modules with Parameter "debug=2".
> 
> This produces a huge amount of messages in /var/log/messages
> and some might even get lost because of the high rate at
> which debug messages are created. Therefore it might be 
> necessary to uncomment the linebuf define in line 73 of 
> ieee12844pp.c. 
> 
> Send the debug output directly to me, not to the list. 
> 
> Mika Saari
> > Hello,
> > 
> >     Sorry again I should read the documentation better the 
> usenibble=1 was
> > mentioned there. I added the parameter to ieee12844pp 
> module and the scanner
> > started the scanning (which it didn't do earlier) but after 
> first part of
> > scanning it stopped and gave this error message (everything 
> like it come to the
> > screen)
> > 
> > ----------------------------------------
> > [root@unicorn /root]# insmod parport
> > Using /lib/modules/2.4.2/kernel/drivers/parport/parport.o
> > [root@unicorn /root]# insmod parport_pc
> > Using /lib/modules/2.4.2/kernel/drivers/parport/parport_pc.o
> > [root@unicorn /root]# insmod /usr/local/lib/ieee12844.o
> > IEEE1284.4 protocol layer for Linux installed
> > [root@unicorn /root]# insmod /usr/local/lib/ieee12844pp.o 
> usenibble=1
> >    ieee12844pp: IEEE1284.4 device found on parport0:
> >    HEWLETT-PACKARD OFFICEJET PRO 1150C;
> >    device registered to IEEE1284.4 protocol layer as link mlcpp0
> > 
> > [root@unicorn /root]# scanimage --test &> debug.txt
> > PAR_WAIT_SET_CLEAR(l=d9991abc,set=0x0000,clear=0x0040): 
> timed out waiting for
> > event=9!
> > mlcpp0: mlcpp_intr ERROR -110
> >   state=5 event=9 reset=7 recv=3 rcv=0 send=2
> > mlc: mlcpp0: link error -110
> > [root@unicorn /root]# 
> PAR_WAIT_SET_CLEAR(l=d9991abc,set=0x0098,clear=0x0040):
> > timed out waiting for event=23!
> > ----------------------------------------
> > 
> > I also enclose the debug.txt with this mail, hope it helps.
> > 
> 
> Burkhard
> -- 
> Burkhard Kohl			bu...@bu...
> 
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/lists/listinfo/hpoj-devel
> 

Re: [hpoj-devel] new I/O driver coming soon (second try)

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

Daniel Gun wrote:
> From: pa...@rc... (David Paschal)
> >I haven't had a chance to try it out yet.  At the very least, the DeskJet
> 895C
> >driver should work with the OfficeJet R and T series, and the DeskJet 970C
> >driver should work with the OfficeJet G and K series.  I'm guessing that
> the
> >DeskJet 600-series driver should work with the OfficeJet [567]00 series,
> but
> >I don't know for sure at the moment.
> 
> How about the PSC500?

The PSC500 should work with the DeskJet 895C driver as well.

David

Re: [hpoj-devel] new I/O driver coming soon (second try)

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

From: pa...@rc... (David Paschal)
>Joe Piolunek wrote:
>> I didn't see support for officejets mentioned in hpinkjet web pages. Will
>> they be supported by the new inkjet drivers?
>I haven't had a chance to try it out yet.  At the very least, the DeskJet
895C
>driver should work with the OfficeJet R and T series, and the DeskJet 970C
>driver should work with the OfficeJet G and K series.  I'm guessing that
the
>DeskJet 600-series driver should work with the OfficeJet [567]00 series,
but
>I don't know for sure at the moment.

How about the PSC500?

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

Re: [hpoj-devel] Kernel 2.4.1 module: PATCH

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

Mika, I've have forwarded your mail to David.

At the moment I don't understand your problem - it looks
like the devices stops talking to your host after successfully
starting to scan.

Are you running an SMP kernel? In that case you might want to
try a uniprocessor kernel first - espially if you happen to 
have just one processor in your box. (Many distributitions)
come with SMP kernels which is not always the best choice.

Without seeing the debug output from ieee12844pp.o I it's
impossible to determine exactly what happens. 
Please load the modules with Parameter "debug=2".

This produces a huge amount of messages in /var/log/messages
and some might even get lost because of the high rate at
which debug messages are created. Therefore it might be 
necessary to uncomment the linebuf define in line 73 of 
ieee12844pp.c. 

Send the debug output directly to me, not to the list. 

Mika Saari
> Hello,
> 
>     Sorry again I should read the documentation better the usenibble=1 was
> mentioned there. I added the parameter to ieee12844pp module and the scanner
> started the scanning (which it didn't do earlier) but after first part of
> scanning it stopped and gave this error message (everything like it come to the
> screen)
> 
> ----------------------------------------
> [root@unicorn /root]# insmod parport
> Using /lib/modules/2.4.2/kernel/drivers/parport/parport.o
> [root@unicorn /root]# insmod parport_pc
> Using /lib/modules/2.4.2/kernel/drivers/parport/parport_pc.o
> [root@unicorn /root]# insmod /usr/local/lib/ieee12844.o
> IEEE1284.4 protocol layer for Linux installed
> [root@unicorn /root]# insmod /usr/local/lib/ieee12844pp.o usenibble=1
>    ieee12844pp: IEEE1284.4 device found on parport0:
>    HEWLETT-PACKARD OFFICEJET PRO 1150C;
>    device registered to IEEE1284.4 protocol layer as link mlcpp0
> 
> [root@unicorn /root]# scanimage --test &> debug.txt
> PAR_WAIT_SET_CLEAR(l=d9991abc,set=0x0000,clear=0x0040): timed out waiting for
> event=9!
> mlcpp0: mlcpp_intr ERROR -110
>   state=5 event=9 reset=7 recv=3 rcv=0 send=2
> mlc: mlcpp0: link error -110
> [root@unicorn /root]# PAR_WAIT_SET_CLEAR(l=d9991abc,set=0x0098,clear=0x0040):
> timed out waiting for event=23!
> ----------------------------------------
> 
> I also enclose the debug.txt with this mail, hope it helps.
> 

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

[hpoj-devel] xojpanel patch(es), new pixmap

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

David:

I've attached a tarball that includes a new pixmap and the changes to 
xojpanel.

The changes to xojpanel include:

All of the pixmaps now are compiled into the binary. The 'configure' script 
can be changed to remove references to the default pixmap path.

The lcd font used will now be the local system default unless the user 
specifies a different one near the top of ojstatus.cpp . The font size can be 
changed there also.

The pixmap file "hpoj_lcdmon.xpm" replaces "ojforlinux.xpm".

The size of the resulting binary is now around 220K depending on how it's 
built. Running 'strip' on it reduces its size more than 50%, possibly due to 
empty space in the graphics (not sure).

-- 
Joe

Re: [hpoj-devel] xojpanel compiled-in pixmaps

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

Joe Piolunek wrote:
> I put up three new xojpanel screenshots. They are stacked on the page in 
> reversed order of my preference (favorite is on the bottom). I'll probably 
> use the bottom one, but haven't quite decided.
> 
> Comments are welcome. The URL is above.
Hi, Joe.  I like the third one too.  My second preference would be the
first one.

Thanks,
David

Re: [hpoj-devel] xojpanel compiled-in pixmaps

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

On Monday 05 March 2001 08:13 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
<...>
> > I put a couple of xojpanel screenshots on my site with
> > different versions of
> > the graphic. I'm not totally pleased with either one of them,
> > but you can
> > take a look. I'll probably try out some different fonts, etc.
> > to see if the
> > appearance can be improved a little more.
> >
> > http://pages.cthome.net/jsp/hpoj-linux-gui/index.html
>
> I think either one is fine.  Personally I would sort of lean towards the
> first one with the smaller font for the second line, but perhaps you could
> try squeezing the letters in a bit more (the way it is with the larger
> font).


I put up three new xojpanel screenshots. They are stacked on the page in 
reversed order of my preference (favorite is on the bottom). I'll probably 
use the bottom one, but haven't quite decided.

Comments are welcome. The URL is above.

-- 
Joe

Re: [hpoj-devel] xojpanel compiled-in pixmaps

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

On Monday 05 March 2001 08:13 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

<...>
> In order to avoid having to hack the .xpm files, perhaps you could use a
> trick similar to what I did in ptal-mlcd, something like the following:
>
> #define static static const
> #include <foo1.xpm>
> #include <foo2.xpm>
> // etc.
> #undef static

It works. Thanks very much, David.


> > ojstatus.cpp: In method `void XojPanel::createInterface()':
> > ojstatus.cpp:160: passing `char **' as argument 1 of
> > `QPixmap::QPixmap(const
> > char **)' adds cv-quals without intervening `const'
> > make: *** [ojstatus.o] Error 1
>
> Strange -- I haven't the slightest idea what "cv-quals" means.  I'm only
> familiar with the situation where the compiler complains when you pass a
> const pointer to a function that takes a non-const pointer, which can be
> fixed either by adding the const in a typecast, or by adding "const" to the
> function prototype.

I found a small number of references to 'cv-quals' in a google / deja.com 
search for the error. It seems to be shorthand for 'const / volatile 
qualifiers'. 

> > In the case of hpoj_mini.xpm, this is the line of code:
> > this->setIcon(QPixmap(hpoj_mini_xpm));
> >
> > For the LCD background pixmap:
> > *lcdPixmap = (QPixmap)hpojlcd_xpm;
>
> I'm assuming these typecasts cause an implicit construction of a QPixmap
> object, taking its input from the XPM string array.

Right.

> I think it would be preferable to avoid hacking/renaming the file, to make
> it easier to change the image.

I agree with that. I didn't know any other way until you suggested the 
'#define' wrapper.

> > I put a couple of xojpanel screenshots on my site with
> > different versions of
> > the graphic. I'm not totally pleased with either one of them,
> > but you can
> > take a look. I'll probably try out some different fonts, etc.
> > to see if the
> > appearance can be improved a little more.
> >
> > http://pages.cthome.net/jsp/hpoj-linux-gui/index.html
>
> I think either one is fine.  Personally I would sort of lean towards the
> first one with the smaller font for the second line, but perhaps you could
> try squeezing the letters in a bit more (the way it is with the larger
> font).

I'll work on it some more.

-- 
Joe

RE: [hpoj-devel] new I/O driver coming soon (second try)

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

Chris Johnson wrote:
> Is there any parallel for the 11xx series?  In particular the 1170.  
> Which printer type should they be considered similar to, if 
> any, and will
> a driver be developed for this machine?

Hi, Chris.  I'm not 100% sure here, but I'm guessing that the OfficeJet
1170/1175 is compatible with the DeskJet 890, and I'm guessing that the
OfficeJet 1150 is compatible with either the DeskJet 850 and/or 870.  I'm
guessing based on the way the compatible ink cartridges correspond.  There
is no mention of any of those DeskJets, so they probably aren't being
addressed, but you could always try the 600- or 800-series drivers anyway.

David

RE: [hpoj-devel] xojpanel compiled-in pixmaps

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

Hi, Joe.

Joe Piolunek wrote:
> There are no errors reported during compilation if I change 
> the pixmaps' 
> internal array declarations. 
> 
> Original declaration inside file hpoj_mini.xpm:
> /* XPM */
> static char * hpoj_mini_xpm[] = {
> <data>
> };
> 
> The 'const' keyword needs to be added to make it work.
> /* XPM */
> static const char * hpoj_mini_xpm[] = {
> <data>
> };

In order to avoid having to hack the .xpm files, perhaps you could use a
trick similar to what I did in ptal-mlcd, something like the following:

#define static static const
#include <foo1.xpm>
#include <foo2.xpm>
// etc.
#undef static

> This is the error reported if I don't modify the pixmap's 
> array declaration:
> ...
> ...
> ojstatus.cpp: In method `void XojPanel::createInterface()':
> ojstatus.cpp:160: passing `char **' as argument 1 of 
> `QPixmap::QPixmap(const 
> char **)' adds cv-quals without intervening `const'
> make: *** [ojstatus.o] Error 1

Strange -- I haven't the slightest idea what "cv-quals" means.  I'm only
familiar with the situation where the compiler complains when you pass a
const pointer to a function that takes a non-const pointer, which can be
fixed either by adding the const in a typecast, or by adding "const" to the
function prototype.

> In the case of hpoj_mini.xpm, this is the line of code:
> this->setIcon(QPixmap(hpoj_mini_xpm));
> 
> For the LCD background pixmap:
> *lcdPixmap = (QPixmap)hpojlcd_xpm;
I'm assuming these typecasts cause an implicit construction of a QPixmap
object, taking its input from the XPM string array.

> To avoid causing confusion, I may be able to simply change 
> the modified 
> pixmaps' filenames to indicate that they are a source of 
> data, not regular 
> pixmaps. A name could be changed from 'hpoj_mini.xpm' to 
> 'hpoj_mini_xpm.data' 
> for example. 
I think it would be preferable to avoid hacking/renaming the file, to make
it easier to change the image.

> I put a couple of xojpanel screenshots on my site with 
> different versions of 
> the graphic. I'm not totally pleased with either one of them, 
> but you can 
> take a look. I'll probably try out some different fonts, etc. 
> to see if the 
> appearance can be improved a little more.
> 
> http://pages.cthome.net/jsp/hpoj-linux-gui/index.html
I think either one is fine.  Personally I would sort of lean towards the
first one with the smaller font for the second line, but perhaps you could
try squeezing the letters in a bit more (the way it is with the larger
font).

David

Re: [hpoj-devel] xojpanel compiled-in pixmaps

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

On Sunday 04 March 2001 07:42 pm, David Paschal wrote:

<...>
> > I'm working on a different 'cover graphic' that can be substituted for
> > the one that reads 'HP OfficeJet for Linux'. The new one reads 'HP
> > OfficeJet LCD Monitor' in the same style and color as the older one. The
> > only change is a substitution of 'LCD Monitor' for 'for Linux'. Which one
> > would be better for the next release, or would something else be more
> > appropriate?
>
> The new one sounds good, since it better conveys the function of xojpanel,
> and it doesn't make it sound Linux-specific.
>
<...>
> If you're not ready to provide the code changes yet, perhaps you could post
> a screenshot on your webpage, which I link to from a couple of places on
> the hpoj website.

I put a couple of xojpanel screenshots on my site with different versions of 
the graphic. I'm not totally pleased with either one of them, but you can 
take a look. I'll probably try out some different fonts, etc. to see if the 
appearance can be improved a little more.

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

>
> BTW, when I check in the new I/O driver I will have to temporarily disable
> xojpanel in the build sequence, since I'm removing ojlib but haven't
> finished the PTAL PML code yet.  You'll probably want to keep your current
> source tree around for now if you decide to try out the new code.  The PML
> support is next on my TODO list, and once I finalize the API then you can
> make those changes too, or I can help out if you'd like.

If I have enough information and it doesn't involve anything too complicated, 
I may be able to do it myself. If I have trouble, I'll let you know.


-- 
Joe

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Chris J. <cjo...@sh...>]

On Sun, 4 Mar 2001, David Paschal wrote:

> Hi, Joe.
> 
> Joe Piolunek wrote:
> > I didn't see support for officejets mentioned in hpinkjet web pages. Will 
> > they be supported by the new inkjet drivers?
> I haven't had a chance to try it out yet.  At the very least, the DeskJet 895C
> driver should work with the OfficeJet R and T series, and the DeskJet 970C
> driver should work with the OfficeJet G and K series.  I'm guessing that the
> DeskJet 600-series driver should work with the OfficeJet [567]00 series, but
> I don't know for sure at the moment.
> 
Is there any parallel for the 11xx series?  In particular the 1170.  
Which printer type should they be considered similar to, if any, and will
a driver be developed for this machine?

Thanks, 
Chris

Re: [hpoj-devel] xojpanel compiled-in pixmaps

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

On Sunday 04 March 2001 19:42, David Paschal wrote:

> > I get compiler errors when using the default *.xpm array declaration. The
> > only way I could make it work was to hand-modify the declaration inside
> > each pixmap.  It was quite simple to do, but is there a better way to
> > #include *.xpm's? It would need to be something that Qt will accept.
>
> That's unfortunate.  What is the exact error you got (perhaps something
> about the "static" keyword?), and what specifically did you have to change
> to make it work?

There are no errors reported during compilation if I change the pixmaps' 
internal array declarations. 

Original declaration inside file hpoj_mini.xpm:
/* XPM */
static char * hpoj_mini_xpm[] = {
<data>
};

The 'const' keyword needs to be added to make it work.
/* XPM */
static const char * hpoj_mini_xpm[] = {
<data>
};

This is the error reported if I don't modify the pixmap's array declaration:
...
...
ojstatus.cpp: In method `void XojPanel::createInterface()':
ojstatus.cpp:160: passing `char **' as argument 1 of `QPixmap::QPixmap(const 
char **)' adds cv-quals without intervening `const'
make: *** [ojstatus.o] Error 1

I'm using gcc-2.95-2.

I think the errors may be due to a requirement of Qt. When I use the contents 
of an #included pixmap, I've been using the internal array name. 

In the case of hpoj_mini.xpm, this is the line of code:
this->setIcon(QPixmap(hpoj_mini_xpm));

For the LCD background pixmap:
*lcdPixmap = (QPixmap)hpojlcd_xpm;

To avoid causing confusion, I may be able to simply change the modified 
pixmaps' filenames to indicate that they are a source of data, not regular 
pixmaps. A name could be changed from 'hpoj_mini.xpm' to 'hpoj_mini_xpm.data' 
for example. 

-- 
Joe

Re: [hpoj-devel] xojpanel compiled-in pixmaps

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

Joe Piolunek wrote:
> I modified the xojpanel code to compile in the *.xpm's instead of loading 
> them at runtime.
Hi, Joe.  Thanks for looking into this.  It will help simplify the build
and install sequence.

> I get compiler errors when using the default *.xpm array declaration. The 
> only way I could make it work was to hand-modify the declaration inside each 
> pixmap.  It was quite simple to do, but is there a better way to #include 
> *.xpm's? It would need to be something that Qt will accept.
That's unfortunate.  What is the exact error you got (perhaps something about
the "static" keyword?), and what specifically did you have to change to make
it work?

> I'm working on a different 'cover graphic' that can be substituted for the 
> one that reads 'HP OfficeJet for Linux'. The new one reads 'HP OfficeJet LCD 
> Monitor' in the same style and color as the older one. The only change is a 
> substitution of 'LCD Monitor' for 'for Linux'. Which one would be better for 
> the next release, or would something else be more appropriate?
The new one sounds good, since it better conveys the function of xojpanel,
and it doesn't make it sound Linux-specific.

> I should be able to make the code and pixmaps available a couple of days 
> after your answer, unless I get lost in a snowdrift. We're expecting a really 
> big storm here on the east coast.
If you're not ready to provide the code changes yet, perhaps you could post
a screenshot on your webpage, which I link to from a couple of places on the
hpoj website.

BTW, when I check in the new I/O driver I will have to temporarily disable
xojpanel in the build sequence, since I'm removing ojlib but haven't finished
the PTAL PML code yet.  You'll probably want to keep your current source tree
around for now if you decide to try out the new code.  The PML support is
next on my TODO list, and once I finalize the API then you can make those
changes too, or I can help out if you'd like.

BTW#2, I think your clock may be set to the wrong time zone (GMT instead of
EST), or else KMail might be getting it wrong in the message header.

David

Re: [hpoj-devel] new I/O driver coming soon (second try)

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

Hi, Joe.

Joe Piolunek wrote:
> I didn't see support for officejets mentioned in hpinkjet web pages. Will 
> they be supported by the new inkjet drivers?
I haven't had a chance to try it out yet.  At the very least, the DeskJet 895C
driver should work with the OfficeJet R and T series, and the DeskJet 970C
driver should work with the OfficeJet G and K series.  I'm guessing that the
DeskJet 600-series driver should work with the OfficeJet [567]00 series, but
I don't know for sure at the moment.

> That might be more acceptable to independant contributors (if any), but each 
> would have his own opinion. Since only a few people have contributed to the 
> project so far, the IP 'transfer' plan may not even need to be applied for 
> lack (or need) of independant contributions. If so, it would make the 
> ownership issue less relevant, as long as the code remains GPL'd.
After thinking about it some more I came to pretty much the same conclusion.
As long as I can sufficiently maintain the code there won't be any need to
accept changes to the leveraged MLC/1284.4 code (which is the only problem
area).  If that ever changes in any way, then the "problem" probably goes
away.  Others may choose to fork their own GPL projects that incorporate
that code, possibly with their own changes, but that's OK as long as they
comply with the GPL.

So I won't worry any more about this issue for now, and instead will
concentrate on finishing the remaining cleanups before checking in the new
code.  :-)

David

[hpoj-devel] xojpanel compiled-in pixmaps

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

David:

I modified the xojpanel code to compile in the *.xpm's instead of loading 
them at runtime. 

I get compiler errors when using the default *.xpm array declaration. The 
only way I could make it work was to hand-modify the declaration inside each 
pixmap.  It was quite simple to do, but is there a better way to #include 
*.xpm's? It would need to be something that Qt will accept.

I'm working on a different 'cover graphic' that can be substituted for the 
one that reads 'HP OfficeJet for Linux'. The new one reads 'HP OfficeJet LCD 
Monitor' in the same style and color as the older one. The only change is a 
substitution of 'LCD Monitor' for 'for Linux'. Which one would be better for 
the next release, or would something else be more appropriate?

I should be able to make the code and pixmaps available a couple of days 
after your answer, unless I get lost in a snowdrift. We're expecting a really 
big storm here on the east coast.

-- 
Joe

Re: [hpoj-devel] new I/O driver coming soon (second try)

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

On Saturday 03 March 2001 01:32, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

<...>
> Actually, another division within HP is actively preparing
> better inkjet drivers.  I'm not involved with that effort, but I took the
> liberty of forwarding a couple of the relevant messages to several managers
> and engineers who are involved.  It's a work in progress and no code has
> been released yet, but you can get a sneak preview at
> http://hpinkjet.sourceforge.net.  This driver was also demonstrated at
> LinuxWorld Expo last month in the "e-mail garden".  I don't know exactly
> when it will be released, but once I find out that it has been released I'll
> be sure to make it known on the hpoj mailing lists.

I didn't see support for officejets mentioned in hpinkjet web pages. Will 
they be supported by the new inkjet drivers?


> (Bruce) also alluded to another possible strategy, where
> "the contributor grant[s] HP separate and individual copyright, while they
> keep their own copyright to the modification as well.  That means that
> either party can do what they want with the code."  I can look into this if
> people think it's better, but it may take more time to set up and consult
> with the lawyers.
>

That might be more acceptable to independant contributors (if any), but each 
would have his own opinion. Since only a few people have contributed to the 
project so far, the IP 'transfer' plan may not even need to be applied for 
lack (or need) of independant contributions. If so, it would make the 
ownership issue less relevant, as long as the code remains GPL'd.


> So to summarize what I currently have in mind:
>
> The new changes will be released under the GPL (as is the case with the
> existing hpoj code), but with an HP copyright.  The leveraged MLC/1284.4
> portion of ptal-mlcd has to have the HP copyright because I developed it on
> company time for actual products.  The remainder of my changes for the hpoj
> project need to have the HP copyright because I'm now operating on behalf
> of HP, rather than myself, as I was when I first joined this project.  I
> haven't yet decided whether to retroactively change my existing copyrights
> to HP or just apply it to new changes.
>
> For everything in the hpoj codebase other than the leveraged MLC/1284.4
> portion of ptal-mlcd, there will not be any requirement to re-assign
> copyrights or otherwise give up any IP rights.  (I apologize if I offended
> anybody by suggesting this as an option.)

I wasn't offended, just disappointed in HP after having read some of their 
public statements supporting the open source / free software community.

Perhaps in 3-5 years, Linux will become the default OS for most computing 
devices, even the desktop. Linux has nowhere to go but up, whereas windows 
can go almost nowhere but down. HP appears to have the upper hand now 
regarding its products' (lack of) compatibility with Linux, but in the not 
too distant future, HP could find itself needing support from Linux and its 
users.

-- 
Joe

Printerfilter for G85. Was: Re: [hpoj-devel] new I/O driver coming soon (second try)

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

Hi Judd.

So we "meet" again, Judd :-)

I am using SuSE and a G85, and just chose the cdj550 (600dpi) printer in
the yast (a SuSE tool), and everything worked fine. I don't know what kind
of quality I expected since I am not running Windoze and hence couldn't
compare, but it definitely looked good and the margins also seem to be OK,
though I havnt' measured with a ruler. I don't have the device around
anymore since I only had it for a short time to set it up for my mother
(indeed a computer/linux newbie).

I have included what yast added to my /etc/printcap. I have only used
it as the oj printer (second entry), so maybe the other entries are
useless. I'll send you the aps filters private.

Jarl -- The danish translator.


cdj550-ascii|lp10|cdj550-a4-ascii-mono-600|cdj550 a4 ascii mono 600:\
        :lp=/dev/ptal-printd/mlc_mlcpp0:\
        :sd=/var/spool/lpd/cdj550-a4-ascii-mono-600:\
        :lf=/var/spool/lpd/cdj550-a4-ascii-mono-600/log:\
        :af=/var/spool/lpd/cdj550-a4-ascii-mono-600/acct:\
        :if=/var/lib/apsfilter/bin/cdj550-a4-ascii-mono-600:\
        :la@:mx#0:\
        :tr=:cl:sh:sf:
#                                                                                                
oj|cdj550|lp11|cdj550-a4-auto-color-600|cdj550 a4 auto color 600:\
        :lp=/dev/ptal-printd/mlc_mlcpp0:\
        :sd=/var/spool/lpd/cdj550-a4-auto-color-600:\
        :lf=/var/spool/lpd/cdj550-a4-auto-color-600/log:\
        :af=/var/spool/lpd/cdj550-a4-auto-color-600/acct:\
        :if=/var/lib/apsfilter/bin/cdj550-a4-auto-color-600:\
        :la@:mx#0:\
        :tr=:cl:sh:sf:
#                                                                                                
cdj550-mono|lp12|cdj550-a4-auto-mono-600|cdj550 a4 auto mono 600:\
        :lp=/dev/ptal-printd/mlc_mlcpp0:\
        :sd=/var/spool/lpd/cdj550-a4-auto-mono-600:\
        :lf=/var/spool/lpd/cdj550-a4-auto-mono-600/log:\
        :af=/var/spool/lpd/cdj550-a4-auto-mono-600/acct:\
        :if=/var/lib/apsfilter/bin/cdj550-a4-auto-mono-600:\
        :la@:mx#0:\
        :tr=:cl:sh:sf:
#    
cdj550-raw|lp13|cdj550-a4-raw|cdj550 a4 raw:\
        :lp=/dev/ptal-printd/mlc_mlcpp0:\
        :sd=/var/spool/lpd/cdj550-a4-raw:\
        :lf=/var/spool/lpd/cdj550-a4-raw/log:\
        :af=/var/spool/lpd/cdj550-a4-raw/acct:\
        :if=/var/lib/apsfilter/bin/cdj550-a4-raw:\
        :la@:mx#0:\
        :tr=:cl:sh:sf:
#