Discussion:
Any progress with Mac OS X ?
(too old to reply)
John McNulty
2002-09-19 07:29:08 UTC
Permalink
Hello,

I remember reading a while back about some work taking place on Mac OS
X. I've just switched, and now I'm looking to make use of my K60.

I noticed today that there was an official release of software for the
G55 and G85 on the HP website, updating for v 10.2 .. but nothing for
K60's.

Any pointers please?

John
Robert Monaghan
2002-09-19 08:52:04 UTC
Permalink
Howdy..

I had to hack the make file to compile the release package. I have to submit
diffs to the maintainer, so that he can see what needs to be done. Note: I
only tried this package with the JetDirect print server. There is *no* USB
support for the mac.

Bob..
Post by John McNulty
Hello,
I remember reading a while back about some work taking place on Mac OS
X. I've just switched, and now I'm looking to make use of my K60.
I noticed today that there was an official release of software for the
G55 and G85 on the HP website, updating for v 10.2 .. but nothing for
K60's.
Any pointers please?
John
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
hpoj-devel mailing list
https://lists.sourceforge.net/lists/listinfo/hpoj-devel
Phil Harman
2002-09-20 00:55:01 UTC
Permalink
Bob,

I was waiting to see what the new HP AiO release was like before
diving in. My previous experience was with HP AiO 4.3.5 and Mac
OS X 10.1.5. I now have HP AiO 4.6.2 on Mac OS X 10.2 and I am
very disappointed.

As far as I can tell the HP daemons are still the CPU hogs they
used to be. I see that page zero-fills have increased from 2000
to 4000 per second during printing (that's 16MB / second)! All
I suspect has changed is that Mac OS X has got faster at doing
page zero-fills!!!

I'd like to get my hands on your work (i.e. how to build some
of the HPOJ source under Mac OS X). David has already helped my
with basic USB communication (i.e. I can now handshake with the
G55 using the OS X IOKit USB functions).

My initial goal is to produce a simple filter which is able to
do bulk transfers to the G55 for printing. A longer term goal
would be to get the entire HPOJ suite running, but it seems as
if you may have got us quite a long way towards this already.

Please could you email me your stuff (including any notes)?

Thanks,

Phil
Post by Robert Monaghan
Howdy..
I had to hack the make file to compile the release package. I have to submit
diffs to the maintainer, so that he can see what needs to be done. Note: I
only tried this package with the JetDirect print server. There is *no* USB
support for the mac.
Bob..
Post by John McNulty
Hello,
I remember reading a while back about some work taking place on Mac OS
X. I've just switched, and now I'm looking to make use of my K60.
I noticed today that there was an official release of software for the
G55 and G85 on the HP website, updating for v 10.2 .. but nothing for
K60's.
Any pointers please?
John
Hannes Stein
2002-09-20 03:28:02 UTC
Permalink
Hi,
I remember reading a while back about some work taking place on Mac OS X.
I've just switched, and now I'm looking to make use of my K60.
I used to have my PSC950 connected to an OSX Mac (OSX 10.1.5 - HP Driver 4.
3.5), but it really was no fun at all. The HP-Drivers are veryvery slow,
it was just imposible to print a high-quality document. Most of the
features in the menue where just a kind of dead links (OCR for example),
worked only on Tuesdays (Photocard-reading), or worked - but took a
verylong time. Whe latest Version was just o.k. but only for draft-prints
(Whereas all the other printers in OSX work fine and fast).

So now i switched again to the linux server, having the PSC via hpoj 0.9
and CUPS connected to all Mac boxes (even our old Performa 5200 with an
old OS and no USB works fine!)

If you AIO works fine with linux I would just use netatalk to use the
linux box as a printserver. OSX.2 has a CUPS frontend itself - maybe you
won't need netatalk at all.

Hannes
----------------------------------
Hannes Stein
***@macnews.de
ICQ #118301645
Robert Monaghan
2002-09-20 09:58:04 UTC
Permalink
Post by Phil Harman
Bob,
I was waiting to see what the new HP AiO release was like before
diving in. My previous experience was with HP AiO 4.3.5 and Mac
OS X 10.1.5. I now have HP AiO 4.6.2 on Mac OS X 10.2 and I am
very disappointed.
As far as I can tell the HP daemons are still the CPU hogs they
used to be. I see that page zero-fills have increased from 2000
to 4000 per second during printing (that's 16MB / second)! All
I suspect has changed is that Mac OS X has got faster at doing
page zero-fills!!!
I'd like to get my hands on your work (i.e. how to build some
of the HPOJ source under Mac OS X). David has already helped my
with basic USB communication (i.e. I can now handshake with the
G55 using the OS X IOKit USB functions).
My initial goal is to produce a simple filter which is able to
do bulk transfers to the G55 for printing. A longer term goal
would be to get the entire HPOJ suite running, but it seems as
if you may have got us quite a long way towards this already.
Please could you email me your stuff (including any notes)?
Thanks,
Phil
Not a problem!

I haven't had the time, recently, to work on this project. Especially if it
looked like I would have to go it alone.

Before I start, let me say this. I was extremely surprised how well this
worked. My biggest challenges in getting this to limp along, was getting
ucd-snmp to work. With that, I could connect to a jetdirect 175 server, and
query my PSC750.

Appended to the bottom of this message, are the diffs to get get 0.90 to
work. You'll laugh. You'll cry. Its nothing more than a set of makefile
hacks, and a variable tweak to ExMgr.

Now for the pain.

Get ucd-snmp 4.2.5 to work. Compile it, work through its problems, and
install it into /usr/local.

Next, if you are brave. Download the latest Sane Backend, fix it's quirks
and install it into /usr/local as well.

Next, do the following for hpoj-0.90 (Not the cvs version)

Before you even "use" these diffs, you will need to run a

./configure --with-cups-backend=/usr/libexec/cups/backend
--with-sane-backend=/usr/local/lib/sane --with-snmp=/usr/local/bin

line to generate the Makefiles. These Makefiles should also be "backed up"
incase my diff fails.

If everything runs correctly, apply the diffs. (Note: these diffs are
incomplete. All these diffs do, is get a functional copy of hpoj compiled.
Doing a make install "sort of" works, but then you have to hand create all
the hardlinks for the different version numbers of the dylibs.)

Essentially, after installation, I could manually fire off a ptal-init
setup, give it my jetdirect ip address, and setup the printer. No problems
at all. Next run a "ptal-init start" and you are in business.

I could run the ptal-hp display, and see that the message is "Power Save
On."

As for actually scanning and printing.. Heheh, that has yet to actually
work. I haven't given this all that much time right now to verify that the
package works. Jetdirect connectivity is really encouraging! But it is still
a long way off from a working driver.

My thougths:

This package *badly* needs to use libtool.
This package also needs to know which OS it is on, so that CPP flags can be
introduced to handle platform spectific includes, etc..
(in a nutshell, the configure system needs heavy modification)

Libusb would be nice, but if you have some work invested in direct usage of
the IOKit API, continue with that. One less Opensource package to download
and install, before hpoj, the better.

(Someone would have to download and install ucd-snmp, sane, and libusb,
*before* hpoj, and then afterwards, a sane frontend, or a twain-sane bridge,
ghostscript, and the hp bubblejet drivers.)

Let me know what you guys think!


Bob..


(P.S. Here are the diffs. There might be some "garbage" in here to,
involving the config.cache, etc..)


-- snip --


diff -r hpoj-0.90.original/Makefile hpoj-0.90/Makefile
75c75
< libdir_program=lib/hpojip/libhpojip.so.*.* lib/ptal/libptal.so.*.*
lib/sane/libsane-hpoj.so.*.*
---
Post by Phil Harman
libdir_program=lib/hpojip/libhpojip.*.*.dylib lib/ptal/libptal.*.*.dylib
lib/sane/libsane-hpoj.*.*.dylib
82,84c82,84
< CUPS_BACKEND_DIR=
< SANE_BACKEND_DIR=
< SANE_ETC_DIR=
---
Post by Phil Harman
CUPS_BACKEND_DIR=/usr/libexec/cups/backend
SANE_BACKEND_DIR=/usr/local/lib
SANE_ETC_DIR=/usr/local/etc/sane.d
107c107
< $(LN_S) -f lib$$comp*.so.*.*
$(libdir)/$$file ; \
---
Post by Phil Harman
$(LN_S) -f lib$$comp*.*.dylib
$(libdir)/$$file ; \
158,160c158,160
< if ! test -L $(SANE_BACKEND_DIR)/libsane-hpoj.so.1 ;
then \
< echo "Setting libsane-hpoj.so symlink." ; \
< $(LN_S) -f $(libdir)/libsane-hpoj.so
$(SANE_BACKEND_DIR)/libsane-hpoj.so.1 ; \
---
Post by Phil Harman
if ! test -L $(SANE_BACKEND_DIR)/libsane-hpoj.1.dylib ;
then \
Post by Phil Harman
echo "Setting libsane-hpoj.dylib symlink." ; \
$(LN_S) -f $(libdir)/libsane-hpoj.dylib
$(SANE_BACKEND_DIR)/libsane-hpoj.1.dylib ; \
183,184c183,184
< if ! test -L $(SANE_BACKEND_DIR)/libsane-hpoj.so.1 ;
then \
< echo "As root, please run the command \"ln
-sf $(libdir)/libsane-hpoj.so $(SANE_BACKEND_DIR)/libsane-hpoj.so.1\"." ; \
---
Post by Phil Harman
if ! test -L $(SANE_BACKEND_DIR)/libsane-hpoj.1.dylib ;
then \
Post by Phil Harman
echo "As root, please run the command \"ln -sf
$(libdir)/libsane-hpoj.dylib $(SANE_BACKEND_DIR)/libsane-hpoj.1.dylib\"." ; \
diff -r hpoj-0.90.original/apps/cmdline/Makefile
hpoj-0.90/apps/cmdline/Makefile
9c9
< CFLAGS=-O -Wall -g -DHAVE_SNMP
-I/Users/bob/Development/hpoj-0.90.original/include
-I/usr/local/include/ucd-snmp
-L/Users/bob/Development/hpoj-0.90.original/lib/hpojip
-L/Users/bob/Development/hpoj-0.90.original/lib/ptal
-L/Users/bob/Development/hpoj-0.90.original/lib/sane
-DVAR_RUN_PREFIX="\"/var/run\""
---
Post by Phil Harman
CFLAGS=-O -Wall -g -DHAVE_SNMP -I/Users/bob/Development/hpoj-0.90/include
-I/usr/local/include/ucd-snmp -L/Users/bob/Development/hpoj-0.90/lib/hpojip
-L/Users/bob/Development/hpoj-0.90/lib/ptal
-L/Users/bob/Development/hpoj-0.90/lib/sane -DVAR_RUN_PREFIX="\"/var/run\""
Only in hpoj-0.90/apps/cmdline: hpojip-test
Only in hpoj-0.90/apps/cmdline: ptal-connect
Only in hpoj-0.90/apps/cmdline: ptal-device
Only in hpoj-0.90/apps/cmdline: ptal-devid
Only in hpoj-0.90/apps/cmdline: ptal-hp
Only in hpoj-0.90/apps/cmdline: ptal-photod
Only in hpoj-0.90/apps/cmdline: ptal-pml
Only in hpoj-0.90/apps/cmdline: ptal-print
Only in hpoj-0.90/apps/cmdline: ptal-printd
diff -r hpoj-0.90.original/apps/xojpanel/Makefile
hpoj-0.90/apps/xojpanel/Makefile
6,7c6,7
< LFLAGS = -L/Users/bob/Development/hpoj-0.90.original/lib/hpojip
-L/Users/bob/Development/hpoj-0.90.original/lib/ptal
-L/Users/bob/Development/hpoj-0.90.original/lib/sane -lptal
< CFLAGS = -O -Wall -g -I/usr/X11R6/include
-I/Users/bob/Development/hpoj-0.90.original/include
-I/usr/local/include/ucd-snmp
---
Post by Phil Harman
LFLAGS = -L/Users/bob/Development/hpoj-0.90/lib/hpojip
-L/Users/bob/Development/hpoj-0.90/lib/ptal
-L/Users/bob/Development/hpoj-0.90/lib/sane -lptal
Post by Phil Harman
CFLAGS = -O -Wall -g -I/usr/X11R6/include
-I/Users/bob/Development/hpoj-0.90/include -I/usr/local/include/ucd-snmp
diff -r hpoj-0.90.original/config.status hpoj-0.90/config.status
5c5
< # on host Robert-Monaghans-Computer.local.:
---
7c7
< # ./configure --with-cups-backend --with-sane-backend=/usr/local/lib/sane
--with-snmp=/usr/local/bin
---
Post by Phil Harman
# ./configure --with-snmp=/usr/local/include/ucd-snmp
--with-cups-backend=/usr/libexec/cups/backend --with-sane-backend=/usr/local/lib
17,18c17,18
< echo "running ${CONFIG_SHELL-/bin/sh} ./configure --with-cups-backend
--with-sane-backend=/usr/local/lib/sane --with-snmp=/usr/local/bin
--no-create --no-recursion"
< exec ${CONFIG_SHELL-/bin/sh} ./configure --with-cups-backend
--with-sane-backend=/usr/local/lib/sane --with-snmp=/usr/local/bin
--no-create --no-recursion ;;
---
Post by Phil Harman
echo "running ${CONFIG_SHELL-/bin/sh} ./configure
--with-snmp=/usr/local/include/ucd-snmp
--with-cups-backend=/usr/libexec/cups/backend --with-sane-backend=/usr/local/lib
--no-create --no-recursion"
Post by Phil Harman
exec ${CONFIG_SHELL-/bin/sh} ./configure
--with-snmp=/usr/local/include/ucd-snmp
--with-cups-backend=/usr/libexec/cups/backend --with-sane-backend=/usr/local/lib
--no-create --no-recursion ;;
80,81c80,81
< s%@INCLUDE_CMDLINE@%-I/Users/bob/Development/hpoj-0.90.original/include
-I/usr/local/include/ucd-snmp%g
< s%@LIBRARY_CMDLINE@%-L/Users/bob/Development/hpoj-0.90.original/lib/hpojip
-L/Users/bob/Development/hpoj-0.90.original/lib/ptal
-L/Users/bob/Development/hpoj-0.90.original/lib/sane%g
---
-I/usr/local/include/ucd-snmp%g
-L/Users/bob/Development/hpoj-0.90/lib/ptal
-L/Users/bob/Development/hpoj-0.90/lib/sane%g
83,85c83,85
< s%@CUPS_BACKEND_DIR@%%g
< s%@SANE_BACKEND_DIR@%%g
< s%@SANE_ETC_DIR@%%g
---
diff -r hpoj-0.90.original/configure hpoj-0.90/configure
1414c1414
< ( foo=`sane-config --ldflags` ) 2>/dev/null
---
Post by Phil Harman
( foo=`/usr/local/bin/sane-config --ldflags` ) 2>/dev/null
1434c1434
< for file in $dir/libsane-dll.so* ; do
---
Post by Phil Harman
for file in $dir/libsane.* ; do
Only in hpoj-0.90: cups-path.txt
diff -r hpoj-0.90.original/lib/hpojip/Makefile hpoj-0.90/lib/hpojip/Makefile
7,9c7,9
< SONOVER=lib$(BASENAME).so
< SOSHORT=$(SONOVER).$(MAJORVER)
< SOLONG=$(SOSHORT).$(MINORVER)
---
Post by Phil Harman
SONOVER=lib$(BASENAME).dylib
SOSHORT=lib$(BASENAME).$(MAJORVER).dylib
SOLONG=lib$(BASENAME).$(MAJORVER).$(MINORVER).dylib
30c30
< CFLAGS=-O -Wall -g -DHAVE_SNMP
-I/Users/bob/Development/hpoj-0.90.original/include
-I/usr/local/include/ucd-snmp
-L/Users/bob/Development/hpoj-0.90.original/lib/hpojip
-L/Users/bob/Development/hpoj-0.90.original/lib/ptal
-L/Users/bob/Development/hpoj-0.90.original/lib/sane
---
Post by Phil Harman
CFLAGS=-O -Wall -g -DHAVE_SNMP -I/Users/bob/Development/hpoj-0.90/include
-I/usr/local/include/ucd-snmp -L/Users/bob/Development/hpoj-0.90/lib/hpojip
-L/Users/bob/Development/hpoj-0.90/lib/ptal
-L/Users/bob/Development/hpoj-0.90/lib/sane
33c33
< $(CC) $(CFLAGS) -DHPOJIP_INTERNAL -fPIC -c -o $@ $<
---
45c45
< $(CC) $(CFLAGS) -shared -Wl,-soname,$(SOSHORT) -o $(SOLONG)
$(SOCOMPS) -lc -lm
---
Post by Phil Harman
$(CC) $(CFLAGS) -dynamiclib -install_name
/usr/local/bin/$(SOLONG) -o $(SOLONG) $(SOCOMPS) -lc -lm
diff -r hpoj-0.90.original/lib/ptal/Makefile hpoj-0.90/lib/ptal/Makefile
7,9c7,9
< SONOVER=lib$(BASENAME).so
< SOSHORT=$(SONOVER).$(MAJORVER)
< SOLONG=$(SOSHORT).$(MINORVER)
---
Post by Phil Harman
SONOVER=lib$(BASENAME).dylib
SOSHORT=lib$(BASENAME).$(MAJORVER).dylib
SOLONG=lib$(BASENAME).$(MAJORVER).$(MINORVER).dylib
21c21
< CFLAGS=-O -Wall -g -DHAVE_SNMP
-I/Users/bob/Development/hpoj-0.90.original/include
-I/usr/local/include/ucd-snmp
-L/Users/bob/Development/hpoj-0.90.original/lib/hpojip
-L/Users/bob/Development/hpoj-0.90.original/lib/ptal
-L/Users/bob/Development/hpoj-0.90.original/lib/sane
-DVAR_RUN_PREFIX="\"/var/run\""
---
Post by Phil Harman
CFLAGS=-O -Wall -g -DHAVE_SNMP -I/Users/bob/Development/hpoj-0.90/include
-I/usr/local/include/ucd-snmp -L/Users/bob/Development/hpoj-0.90/lib/hpojip
-L/Users/bob/Development/hpoj-0.90/lib/ptal
-L/Users/bob/Development/hpoj-0.90/lib/sane -DVAR_RUN_PREFIX="\"/var/run\""
24c24
< $(CC) $(CFLAGS) -fPIC -c -o $@ $<
---
36c36
< $(CC) $(CFLAGS) -lsnmp -lcrypto -shared
-Wl,-soname,$(SOSHORT) -o $(SOLONG) $(SOCOMPS) -lc
---
Post by Phil Harman
$(CC) $(CFLAGS) -lsnmp -lcrypto -dynamiclib -install_name
/usr/local/lib/$(SOLONG) -o $(SOLONG) $(SOCOMPS) -lc
diff -r hpoj-0.90.original/lib/sane/Makefile hpoj-0.90/lib/sane/Makefile
7,9c7,9
< SONOVER=lib$(BASENAME).so
< SOSHORT=$(SONOVER).$(MAJORVER)
< SOLONG=$(SOSHORT).$(MINORVER)
---
Post by Phil Harman
SONOVER=lib$(BASENAME).dylib
SOSHORT=lib$(BASENAME).$(MAJORVER).dylib
SOLONG=lib$(BASENAME).$(MAJORVER).$(MINORVER).dylib
20c20
< CFLAGS=-O -Wall -g -DHAVE_SNMP
-I/Users/bob/Development/hpoj-0.90.original/include
-I/usr/local/include/ucd-snmp
-L/Users/bob/Development/hpoj-0.90.original/lib/hpojip
-L/Users/bob/Development/hpoj-0.90.original/lib/ptal
-L/Users/bob/Development/hpoj-0.90.original/lib/sane
---
Post by Phil Harman
CFLAGS=-O -Wall -g -DHAVE_SNMP -I/Users/bob/Development/hpoj-0.90/include
-I/usr/local/include/ucd-snmp -L/usr/local/lib
-L/Users/bob/Development/hpoj-0.90/lib/hpojip
-L/Users/bob/Development/hpoj-0.90/lib/ptal
-L/Users/bob/Development/hpoj-0.90/lib/sane
23c23
< $(CC) $(CFLAGS) -fPIC -c -o $@ $<
---
35c35
< $(CC) $(CFLAGS) -lptal -lhpojip -shared
-Wl,-soname,$(SOSHORT) -o $(SOLONG) $(SOCOMPS) -lc
---
Post by Phil Harman
$(CC) $(CFLAGS) -dynamiclib -install_name
/usr/local/lib/$(SOLONG) -o $(SOLONG) $(SOCOMPS) -lptal -lhpojip -lc
diff -r hpoj-0.90.original/mlcd/ExMgr.cpp hpoj-0.90/mlcd/ExMgr.cpp
1244c1244,1245
< socklen_t remoteAddrLen,localAddrLen;
---
Post by Phil Harman
//socklen_t remoteAddrLen,localAddrLen;
unsigned int remoteAddrLen,localAddrLen;
1333c1334,1335
< socklen_t remoteAddrLen;
---
Post by Phil Harman
//socklen_t remoteAddrLen;
unsigned int remoteAddrLen;
PASCHAL,DAVID (HP-Roseville,ex1)
2002-09-20 19:22:02 UTC
Permalink
Post by Phil Harman
My initial goal is to produce a simple filter which is able to
do bulk transfers to the G55 for printing. A longer term goal
would be to get the entire HPOJ suite running, but it seems as
if you may have got us quite a long way towards this already.
Hi, Phil. This won't be very "simple", due to the requirement of
implementing the IEEE 1284.4 transport protocol and credit management.
That's what everything in mlcd/transport is for. :-)

David
PASCHAL,DAVID (HP-Roseville,ex1)
2002-09-20 19:49:01 UTC
Permalink
Post by Robert Monaghan
Before you even "use" these diffs, you will need to run a
./configure --with-cups-backend=/usr/libexec/cups/backend
--with-sane-backend=/usr/local/lib/sane --with-snmp=/usr/local/bin
line to generate the Makefiles.
It may not be that simple, because I see there's a change to the configure
script in your diff. You may need to run the configure script first to get
the Makefiles, then apply the patch, then run the configure script again
"for real".
Post by Robert Monaghan
This package *badly* needs to use libtool.
This package also needs to know which OS it is on, so that
CPP flags can be
introduced to handle platform spectific includes, etc..
(in a nutshell, the configure system needs heavy modification)
It's on the TODO list. I've got a lot of learning to do first, though. :-)
Post by Robert Monaghan
Libusb would be nice, but if you have some work invested in
direct usage of
the IOKit API, continue with that. One less Opensource
package to download
and install, before hpoj, the better.
I'm working on libusb support right now. I would prefer not to incorporate
IOKit-specific stuff.

David
Robert Monaghan
2002-09-21 13:01:03 UTC
Permalink
On 9/20/02 7:48 PM, "PASCHAL,DAVID (HP-Roseville,ex1)"
Post by PASCHAL,DAVID (HP-Roseville,ex1)
Post by Robert Monaghan
Before you even "use" these diffs, you will need to run a
./configure --with-cups-backend=/usr/libexec/cups/backend
--with-sane-backend=/usr/local/lib/sane --with-snmp=/usr/local/bin
line to generate the Makefiles.
It may not be that simple, because I see there's a change to the configure
script in your diff. You may need to run the configure script first to get
the Makefiles, then apply the patch, then run the configure script again
"for real".
Oops!! I missed that step. Thanks for point that out.
Post by PASCHAL,DAVID (HP-Roseville,ex1)
Post by Robert Monaghan
This package *badly* needs to use libtool.
This package also needs to know which OS it is on, so that
CPP flags can be
introduced to handle platform spectific includes, etc..
(in a nutshell, the configure system needs heavy modification)
It's on the TODO list. I've got a lot of learning to do first, though. :-)
I've never used libtool, either. I'll start reading about it, and take a
crack at a configure script.
Post by PASCHAL,DAVID (HP-Roseville,ex1)
Post by Robert Monaghan
Libusb would be nice, but if you have some work invested in
direct usage of
the IOKit API, continue with that. One less Opensource
package to download
and install, before hpoj, the better.
I'm working on libusb support right now. I would prefer not to incorporate
IOKit-specific stuff.
Fine with me! I don't use USB myself.. :)

Bob..
Jarl Friis
2002-09-21 14:28:02 UTC
Permalink
Post by Robert Monaghan
On 9/20/02 7:48 PM, "PASCHAL,DAVID (HP-Roseville,ex1)"
Post by PASCHAL,DAVID (HP-Roseville,ex1)
Post by Robert Monaghan
This package *badly* needs to use libtool.
This package also needs to know which OS it is on, so that
CPP flags can be
introduced to handle platform spectific includes, etc..
(in a nutshell, the configure system needs heavy modification)
It's on the TODO list. I've got a lot of learning to do first, though. :-)
I've never used libtool, either. I'll start reading about it, and take a
crack at a configure script.
There is a book about it; "GNU autoconf, automake, and libtool" by
vaughan, et. al. It's not really good, but I find it more usefull than
reading all the man pages for individual programs without describing
the interaction between them, further it seems to be the only book on
the subject.

I have not been able to find a good tutorial on the web about the
subject, so if you find one, please let us all know ;-)

Jarl
David Paschal
2002-09-22 21:56:33 UTC
Permalink
Post by Jarl Friis
There is a book about it; "GNU autoconf, automake, and libtool" by
vaughan, et. al. It's not really good, but I find it more usefull than
reading all the man pages for individual programs without describing
the interaction between them, further it seems to be the only book on
the subject.
Hi, Jarl. Thanks for pointing this out. I actually bought that book a
long time ago to use as a reference for autoconf and had forgotten that
it also covers libtool. I guess it's time to get it back out and read
it cover-to-cover. :-)
Post by Jarl Friis
I have not been able to find a good tutorial on the web about the
subject, so if you find one, please let us all know ;-)
The libtool website (http://www.gnu.org/software/libtool/libtool.html)
has an on-line documentation which seems like it might be useful from
a quick skim the other day.

Did you really mean to reply also to qt-***@trolltech.com?

David
Jarl Friis
2002-09-22 23:26:02 UTC
Permalink
Post by David Paschal
Post by Jarl Friis
There is a book about it; "GNU autoconf, automake, and libtool" by
vaughan, et. al. It's not really good, but I find it more usefull than
reading all the man pages for individual programs without describing
the interaction between them, further it seems to be the only book on
the subject.
Hi, Jarl. Thanks for pointing this out. I actually bought that book a
long time ago to use as a reference for autoconf and had forgotten that
it also covers libtool. I guess it's time to get it back out and read
it cover-to-cover. :-)
Post by Jarl Friis
I have not been able to find a good tutorial on the web about the
subject, so if you find one, please let us all know ;-)
The libtool website (http://www.gnu.org/software/libtool/libtool.html)
has an on-line documentation which seems like it might be useful from
a quick skim the other day.
Thanks.
No, and thanks for letting me know! I am also subscribed to that list
(developing Qt apps), but I better inspect GNUS v5.8.7 (my mail/news
client) to behave well, at least the problem is reproducable.

Jarl
PASCHAL,DAVID (HP-Roseville,ex1)
2002-09-23 17:39:01 UTC
Permalink
Post by Robert Monaghan
Its nothing more than a set of makefile
hacks, and a variable tweak to ExMgr.
...
Post by Robert Monaghan
diff -r hpoj-0.90.original/mlcd/ExMgr.cpp hpoj-0.90/mlcd/ExMgr.cpp
1244c1244,1245
< socklen_t remoteAddrLen,localAddrLen;
---
Post by Phil Harman
//socklen_t remoteAddrLen,localAddrLen;
unsigned int remoteAddrLen,localAddrLen;
1333c1334,1335
< socklen_t remoteAddrLen;
---
Post by Phil Harman
//socklen_t remoteAddrLen;
unsigned int remoteAddrLen;
Hi, Robert. What data type is specified for those parameters on the
"connect", "bind", and "accept" system calls according to the Mac OS X
manual pages? Is it "unsigned int" as you used?

David
Robert Monaghan
2002-09-23 18:41:01 UTC
Permalink
Actually, it should be just int.

There isn't an equivelant in the header files for socklen_t. Or, if you
wish, just do an ifdef to test if socklen_t is available. And if it isn't,
typedef it to "int".

Bob..


On 9/23/02 5:37 PM, "PASCHAL,DAVID (HP-Roseville,ex1)"
Post by PASCHAL,DAVID (HP-Roseville,ex1)
Post by Robert Monaghan
Its nothing more than a set of makefile
hacks, and a variable tweak to ExMgr.
...
Post by Robert Monaghan
diff -r hpoj-0.90.original/mlcd/ExMgr.cpp hpoj-0.90/mlcd/ExMgr.cpp
1244c1244,1245
< socklen_t remoteAddrLen,localAddrLen;
---
Post by Phil Harman
//socklen_t remoteAddrLen,localAddrLen;
unsigned int remoteAddrLen,localAddrLen;
1333c1334,1335
< socklen_t remoteAddrLen;
---
Post by Phil Harman
//socklen_t remoteAddrLen;
unsigned int remoteAddrLen;
Hi, Robert. What data type is specified for those parameters on the
"connect", "bind", and "accept" system calls according to the Mac OS X
manual pages? Is it "unsigned int" as you used?
David
Robert Monaghan
2002-09-23 18:42:02 UTC
Permalink
Incidently,

On the Mac, this is the only real problem with HPOJ.

Bob..




On 9/23/02 5:37 PM, "PASCHAL,DAVID (HP-Roseville,ex1)"
Post by PASCHAL,DAVID (HP-Roseville,ex1)
Post by Robert Monaghan
Its nothing more than a set of makefile
hacks, and a variable tweak to ExMgr.
...
Post by Robert Monaghan
diff -r hpoj-0.90.original/mlcd/ExMgr.cpp hpoj-0.90/mlcd/ExMgr.cpp
1244c1244,1245
< socklen_t remoteAddrLen,localAddrLen;
---
Post by Phil Harman
//socklen_t remoteAddrLen,localAddrLen;
unsigned int remoteAddrLen,localAddrLen;
1333c1334,1335
< socklen_t remoteAddrLen;
---
Post by Phil Harman
//socklen_t remoteAddrLen;
unsigned int remoteAddrLen;
Hi, Robert. What data type is specified for those parameters on the
"connect", "bind", and "accept" system calls according to the Mac OS X
manual pages? Is it "unsigned int" as you used?
David
David Paschal
2002-09-26 00:01:02 UTC
Permalink
It sounds like you wanna give a hand in to port hpoj to use
autoconfig, autoheader, libtool... Sounds really nice of you, please
take advantage of this, David.
I am definitely taking advantage of and grateful for Bob's help in this
area.

David
David Paschal
2002-10-17 12:56:06 UTC
Permalink
I suggest the following patch to help sys-admins and package
maintainers to use sane with the hpoj backend.
I just read that code-freeze for 1.0.9 is today, so in lack of time
before code-freeze I have not been able to test the patch, but as the
change is only comments, it shouldn't be able to destroy anything.
...
+#To use hpoj backend you must install hpoj (from hpoj.sf.net)
+#hpoj
One problem with adding this is that the hpoj installation process
automatically adds an "hpoj" line, so you would end up with a possibly
confusing situation of two such lines, one commented out somewhere in the
middle and another not commented out at or near the end. If it's done
right, a binary package (such as the hpoj packages in Mandrake 9.0) should
be able to do a similar thing, so this doesn't help all that much and
will cause a similar problem of confusion. In any case, the hpoj
documentation explains how to modify this file if necessary, for
example, if the installation process doesn't do the right thing.
To make configure to take an argument '--with-hpoj' that will uncomment
the hpoj backend line. This may help package creators even more.
I think this is more trouble than it's worth. I'm trying to not have
too many functional linkages from SANE to hpoj, because that makes it
harder for me to make changes in hpoj.
Further I suggest the SANE website maintainer to update the
http://www.mostang.com/sane/sane-backends.html
to reflect the changes (to man-pages) announced by David Paschal in
August, i.e. the existence of hpoj and recomend hpoj backend (opposed
to hp backend) for certain HP multifunction devices, but that might
already be planned with the release of 1.0.9.
That will happen automatically with the next SANE release.

David
Jarl Friis
2002-10-18 02:58:01 UTC
Permalink
Post by David Paschal
I suggest the following patch to help sys-admins and package
maintainers to use sane with the hpoj backend.
I just read that code-freeze for 1.0.9 is today, so in lack of time
before code-freeze I have not been able to test the patch, but as the
change is only comments, it shouldn't be able to destroy anything.
...
+#To use hpoj backend you must install hpoj (from hpoj.sf.net)
+#hpoj
One problem with adding this is that the hpoj installation process
automatically adds an "hpoj" line, so you would end up with a possibly
confusing situation of two such lines, one commented out somewhere in the
middle and another not commented out at or near the end. If it's done
right, a binary package (such as the hpoj packages in Mandrake 9.0) should
be able to do a similar thing, so this doesn't help all that much and
will cause a similar problem of confusion.
If it's done really right ;-), a commented line like '#hpoj' is
substituted with an uncommented line like 'hpoj'. Further it doesn't
do anything if hpoj is allready listed in dll.conf

That is what the patch to SuSE RPM sent to
hpoj-***@lists.sourceforge.net does.

Jarl
David Paschal
2002-10-18 04:45:03 UTC
Permalink
Now we are at it, I wonder why in %files section in the spec-file I
don't see any '%dir /dev/ptal-printd' and '%dir /dev/ptal-mlcd'
entries. Shouldn't there be such entries? As far as I know this was a
bug in SuSE 7.3 (and probably also SuSE 8.0)
Hi, Jarl. First of all, in hpoj-0.90 these directories are now
/var/run/ptal-{mlcd,printd}, with a backwards compatibility symlink
/dev/ptal-printd. Second, these directories and symlink are now created
by ptal-init, not the install process. That was to prevent problems if
they weren't created in the install process, or if devfs is in use,
meaning the stuff in /dev is non-persistent.

David
David Paschal
2002-12-10 17:59:02 UTC
Permalink
http://213.237.48.227/~jarl/hpoj/SuSE-8.1/hp-officeJet-0.90-10063.src.rpm
http://213.237.48.227/~jarl/hpoj/SuSE-8.1/hp-officeJet-0.90-10063.i386.rpm
Hi, Jarl. Should I add a link to this at
http://hpoj.sf.net/download-packages.shtml?
After installing the package it will print a message on the console
with instructions of what to do to set up your HPOJ device.
...
The only reason that you must manually do some work after instlalling
the package is that the 'ptal-init setup' requires some interaction.
Any suggestions to run 'ptal-init setup' unattended?
How about a flag such as "--automatic" which probes all devices, uses
default names for everythings, etc. and therefore requires no manual
interaction.
I'll think about it, but several issues come to mind:
- Setting up JetDirect-connected devices requires manually entering the
hostname or IP address.
- There are warning+confirmation messages about probing incorrect parallel
ports and (in CVS) about using printer.c with SMP, and I don't want
"ptal-init setup" to do anything dangerous without the user's approval.
- If the device wasn't powered on and connected when the package was
installed, as is the case when the OS is being loaded in the first place,
or if the user wants to add a new device later, then this won't help and
one will have to run "ptal-init setup" anyway.
- If something goes wrong, then diagnostic information may be missed.
- If the user has additional single-function printers connected, ptal-init
may end up undesirably configuring them.

David
Jarl Friis
2002-12-11 00:09:05 UTC
Permalink
Post by David Paschal
http://213.237.48.227/~jarl/hpoj/SuSE-8.1/hp-officeJet-0.90-10063.src.rpm
http://213.237.48.227/~jarl/hpoj/SuSE-8.1/hp-officeJet-0.90-10063.i386.rpm
Hi, Jarl. Should I add a link to this at
http://hpoj.sf.net/download-packages.shtml?
Well I don't mind. If you think (as I do) this will help people,
please do. But when you change it I have the following comments:
Please emphasize and new an updated (By SuSE) package, and after that
suggest the unofficial RPM package by me. Here a suggestion for a diff
--- download-packages.shtml.org 2002-12-11 08:26:39.000000000 +0100
+++ download-packages.shtml 2002-12-11 08:50:52.000000000 +0100
@@ -187,6 +187,9 @@
</ul>
<li>SuSE 8.1:
<ul>
+ <li>Distributed package (0.90-33): <A href="http://www.suse.de/en/private/products/suse_linux/i386/packages_professional/hp-officeJet.html">info</a>
+<ul>
+<li>Found on CD/DVD-media
<li>hpoj version 0.90.
<li>Package name is <tt>hp-officeJet</tt>.
<li>When setting up CUPS printing, the "ptal" backend does not appear in
@@ -205,10 +208,25 @@
("Problem: libsane-hpoj didn't get installed properly on my system. How can
I fix it manually?") for more information.
</ul>
-<li><a href="ftp://ftp.suse.com/pub/people/freitag/rpms/8.0-i386+kde/">
-Unofficial development packages</a>:
+
+ <li>Updated package by SuSE (0.90-62): <A href="ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/hp-officeJet-0.90-62.i586_en.info">info</a>
<ul>
-<li>hpoj version 0.90.
+<li><a
+ href="ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/hp-officeJet-0.90-62.i586.rpm">Found on FTP. Download.</a>
+<li>Solves most of the above mentioned issues
+<li>Still misses to set up some links to use SANE.
+<li>Does not automatically start ptal daemons when computer is rebooted
+</ul>
+
+ <li>Unofficial updated package by <A href="mailto:***@softace.dk">Jarl Friis</a> (0.90-10063):
+<ul>
+<li><A href="http://213.237.48.227/~jarl/hpoj/SuSE-8.1/">Found on HTTP. Download.</a>
+<li>Makes ptal integrate with SuSE boot concept which ensures
+ startup of ptal daemons at next boot.
+<li>Intergrate with YaST2 graphical runlevel editor.
+
+</ul>
+
</ul>
</ul>
Post by David Paschal
After installing the package it will print a message on the console
with instructions of what to do to set up your HPOJ device.
...
The only reason that you must manually do some work after instlalling
the package is that the 'ptal-init setup' requires some interaction.
Any suggestions to run 'ptal-init setup' unattended?
How about a flag such as "--automatic" which probes all devices, uses
default names for everythings, etc. and therefore requires no manual
interaction.
- Setting up JetDirect-connected devices requires manually entering the
hostname or IP address.
- There are warning+confirmation messages about probing incorrect parallel
ports and (in CVS) about using printer.c with SMP, and I don't want
"ptal-init setup" to do anything dangerous without the user's approval.
- If the device wasn't powered on and connected when the package was
installed, as is the case when the OS is being loaded in the first place,
or if the user wants to add a new device later, then this won't help and
one will have to run "ptal-init setup" anyway.
- If something goes wrong, then diagnostic information may be missed.
- If the user has additional single-function printers connected, ptal-init
may end up undesirably configuring them.
The main audience at the moment for the unattended setup procedure is
for normal desktop people that do not have a system-admin around that
would not be able to interpret warning/error messages anyway and may
not even know what an IP-address is.

My point is; the first version of an unattended setup would only cover
*very* simple environments, where ptal would be able to detect the
device anyway. This is the exact same situations where a Windows
driver does not need a sysadmin around, i.e. the device is turned on
connected to either parallel or USB.

Next step would eventually to install such driver (say in a SuSE
environment) even on systems without a device. In case a device is
connected, it will (as Windows does) dettect it at bootup, set it up,
and it runs... I think this was the goal about plug'n'play in the
first place.

In SuSE there is a program called hwscan that tries to behave like
Windows, it detects new hardware every boot time, it may be worth
to consider how such programs can exploit hpoj to autodetect, and
question (through a gui) about settings.

Jarl
David Paschal
2002-12-19 00:56:03 UTC
Permalink
As you, Jan is using parallel port it doesn't make sense to blaim your
USB hardware, but the point is it may very well be your parallelport
hardware. Try connecting it to USB instead.
...
But all in all I suggest using USB do you have that option? Would you
consider to use that instead?
Jan has an OfficeJet 725, which only has a parallel port. (And hpoj
doesn't support USB-to-parallel converter cables.)

David
David Paschal
2003-01-31 23:28:01 UTC
Permalink
At first place this sounds like a good argument, but then again ... It
is hard to imagine an user application that is a SANE front-end
without actually being considered as one.
...
If/when #2 happens, you might consider shipping the user app,
(technically) being a SANE front-end, with SANE itself, since this app
will then also be able to use other backends than sane-hpoj. Using
/usr/lib/sane/ would then again be reasonable.
Hi, Jarl. The sort of things I have in mind here are more appropriate to
remain part of the hpoj codebase, not SANE. For example, my plan for
fax-receive support is to add the low-level fax-image-aquisition support to
libsane-hpoj and add separate command-line applications/daemons that would
make use of it. Another possible example farther in the future might be
something akin to the all-encompassing "OfficeJet Director" Windows-based
software; there might be a need to incorporate some simple scanning and/or
fax-receive functionality directly into it. In both of these examples, it
might be necessary to take some liberties about extending the SANE backend
API and/or using specific well-known options in order to get everything done,
so these SANE "frontends" would necessarily be hpoj-specific.
At least these are arguments, reasonable or not, but for now I think
there is no reason to change procedure with the risk of introducing
bugs in setup procedure.
I plan to keep it this way in the upstream (source-code) package. Of
course, downstream package maintainers may certainly do it differently
(just as they rightfully install to /usr rather than /usr/local), with
the caveat that I have my reasons for doing it that way, which may become
more improtant in the future.
Also a good idea, but this would probably be a pretty complicated redesign.
Any suggestions on how to design this? :-) I think it would require some
sort of frontend/backend-split architecture.
Let this be a reason for brainstorm; please everyone come up with
features, requirements and expectations on such design/architecture.
One option would be to make the backend a shared library like SANE, but I
don't really want to rewrite all that Perl code into compiled C code and
lose the regular-expression parsing that Perl provides. Another option
would be to split the various operations into separate invocations of the
backend (with command-line parameters and standard output), but the backend
really needs to be able to maintain its own state during the probe/setup
session. I think a more promising option would be to have the backend
be a separate process (started by the frontend) and communicate with the
frontend via standard input/output using some kind of XML format. Or I
could take it one step further and use some kind of CORBA mechanism,
which I could stand to learn more about anyway.

David
Jarl Friis
2003-02-01 01:53:05 UTC
Permalink
Post by David Paschal
Let this be a reason for brainstorm; please everyone come up with
features, requirements and expectations on such design/architecture.
One option would be to make the backend a shared library like SANE, but I
don't really want to rewrite all that Perl code into compiled C code and
lose the regular-expression parsing that Perl provides. Another option
would be to split the various operations into separate invocations of the
backend (with command-line parameters and standard output), but the backend
really needs to be able to maintain its own state during the probe/setup
session. I think a more promising option would be to have the backend
be a separate process (started by the frontend) and communicate with the
frontend via standard input/output using some kind of XML format. Or I
could take it one step further and use some kind of CORBA mechanism,
which I could stand to learn more about anyway.
Would it be an idea to create a directory, say 'hotplug', to the CVS,
with two files, say 'ideas.txt' and 'design.txt' to collect all such
ideas. As a start these files could contain some extracts from this
mailing list archive and urls of the linux hotplug project. You never
know when a hotplug-hacker falls down from heaven and start
contributing ;-)

In general I think such hotplug stuff should be planned for version
2.0, whereas a version 1.0 should focus on stability and usefulness on
a static hardware setup, what do you think?

What are your plans/expectations on version 1.0?
Do you have loose release schedules for release versions, say 0.91,
0.92, 1.0?

Jarl
PASCHAL,DAVID (HP-Roseville,ex1)
2003-02-03 19:39:04 UTC
Permalink
Post by Jarl Friis
Would it be an idea to create a directory, say 'hotplug', to the CVS,
with two files, say 'ideas.txt' and 'design.txt' to collect all such
ideas. As a start these files could contain some extracts from this
mailing list archive and urls of the linux hotplug project. You never
know when a hotplug-hacker falls down from heaven and start
contributing ;-)
IMHO that sort of thing belongs in todo.shtml on the website rather than in
CVS.
Post by Jarl Friis
In general I think such hotplug stuff should be planned for version
2.0, whereas a version 1.0 should focus on stability and usefulness on
a static hardware setup, what do you think?
What are your plans/expectations on version 1.0?
For the time being my version-number strategy is to asymptotically approach
version 1.0, since I expect it to take a fairly long time to reach a
"feature-complete" state that I would consider "1.0" quality.
Post by Jarl Friis
Do you have loose release schedules for release versions, say 0.91,
0.92, 1.0?
I generally don't maintain very firm advance release dates, but for 0.91 I'm
aiming for late July, or earlier if possible. I have done most of the I/O
improvements planned for 0.91, and the remaining big-ticket items are with
libsane-hpoj changes, documentation updates, and a number of miscellaneous
changes (some of which might be forwarded to 0.92 or later).

David

Loading...