hpoj-devel — HPOJ development/support list

RE: [hpoj-devel] Thanks to David

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

Hi, Rainer.  I'm glad things are working for you.  However, before you waste
time testing SANE, I should point out that SANE does not yet support
scanning on certain models, including yours (it's on my TODO list).  Also, I
think the OfficeJet 710's highest scanning resolution is 300 DPI, but if you
can prove otherwise then please let me know.  :-)

David

> -----Original Message-----
> From: le...@t-... [mailto:le...@t-...]
> Sent: Friday, June 15, 2001 12:57 PM
> To: hpo...@li...
> Subject: [hpoj-devel] Thanks to David
> 
> 
> Hello David and all,
> 
> you have solved my problems with compiling the hpoj driver. 
> The CVS version 
> works fine with my SuSE 7.2 , kernel 2.4.4-4GB.
> Up to now I have only tested scanning from the commandline 
> (in principle 
> that's all I want) not from SANE. Printing is also working. I 
> have seen that 
> my HP OfficeJet 710 also allows scanning with 600 dpi. 
> When I have some time I will also test SANE.
> 
> Thanks:
> Rainer Lehrig

[hpoj-devel] Thanks to David

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

Hello David and all,

you have solved my problems with compiling the hpoj driver. The CVS version 
works fine with my SuSE 7.2 , kernel 2.4.4-4GB.
Up to now I have only tested scanning from the commandline (in principle 
that's all I want) not from SANE. Printing is also working. I have seen that 
my HP OfficeJet 710 also allows scanning with 600 dpi. 
When I have some time I will also test SANE.

Thanks:
Rainer Lehrig

RE: [hpoj-devel] Re: officejet v40 scanning

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

Hi, Chris.  The cancel button on the scanner definitely won't help, just as
the scan button doesn't help.  If cancelling the scan from SANE (xsane or
xscanimage) causes problems with corrupted or deleted output files, then my
suggestion would be to set the scan window height to a little less than the
length of the page (i.e. 10.9" for an 8.5"x11" page).

David

> -----Original Message-----
> From: Chris Mason [mailto:ma...@su...]
> Sent: Wednesday, June 13, 2001 8:54 AM
> To: hpo...@li...
> Cc: ma...@su...
> Subject: [hpoj-devel] Re: officejet v40 scanning
> 
> 
> 
> [ problems scanning with officejet v40 ]
> 
> > Hi, Chris.  The scan buttons on the device aren't currently 
> supported, so
> > for now scanning can only be initiated from the PC (i.e. 
> SANE).  Be sure
> > to read the sane-hp man page, especially the section on the 
> OfficeJet K
> > series, which also applies to the V series.  It explains 
> the extra steps
> > you need to take in order to scan successfully with these models
> > (clicking on "Change document" and "Unload document" at the 
> right times).
> > With xsane you'll probably need to bring up some sort of "advanced
> > options" window to get to these buttons.
> 
> Thanks, that makes sense.  I can now get a scan started by 
> hitting change
> document and then start.  But, I seem to need a stop button.  Hitting
> cancel in either xsane or xscanimage results in a corrupt 
> image file (xsane
> actually cleans up the tmp file if you hit cancle, I had to 
> copy it out of
> /tmp).  Hitting cancel on the from of the v40 results in xsane or
> xscanimage waiting forever.  Am I missing something?
> 
> -chris

[hpoj-devel] Re: officejet v40 scanning

[Chris M. <ma...@su...>]

[ problems scanning with officejet v40 ]

> Hi, Chris.  The scan buttons on the device aren't currently supported, so
> for now scanning can only be initiated from the PC (i.e. SANE).  Be sure
> to read the sane-hp man page, especially the section on the OfficeJet K
> series, which also applies to the V series.  It explains the extra steps
> you need to take in order to scan successfully with these models
> (clicking on "Change document" and "Unload document" at the right times).
> With xsane you'll probably need to bring up some sort of "advanced
> options" window to get to these buttons.

Thanks, that makes sense.  I can now get a scan started by hitting change
document and then start.  But, I seem to need a stop button.  Hitting
cancel in either xsane or xscanimage results in a corrupt image file (xsane
actually cleans up the tmp file if you hit cancle, I had to copy it out of
/tmp).  Hitting cancel on the from of the v40 results in xsane or
xscanimage waiting forever.  Am I missing something?

-chris

Re: [hpoj-devel] lots of ptal-mlcd fixes

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

Obi-Wan wrote:
> With the stock syslog, splitting into different files is done based
> on the facility and the log level, as specified in your /etc/syslog.conf
> file.
> 
> I guess I feel like I'd rather have all my printer-related messages
> going to the same spot.  LOG_DAEMON is more of a generic catch-all
> facility for use by miscellaneous daemons that don't have their own
> pre-defined facility and don't want to use one of the eight local
> facilities.  Basically, everything except mail, printing, uucp,
> usenet, and cron.  Lprng & its cousins all log to LOG_LPR, so it
> makes sense that the low-level printer drivers log there as well.

Your syslog.conf must split things out more than mine does, because LOG_LPR
for me still ends up in /var/log/messages, which is fine with me.  I changed
the facility setting to LOG_LPR for both daemons, and added a few syslog-only
messages that display when the daemons initialize and when ptal-mlcd
activates.  For ptal-mlcd, I also joined the two lines into one for syslog,
to prevent log messages from separate instances from getting interleaved.
Hopefully everything is to your liking now.  I'm not particularly fond of
having to join the lines, but it needed to be done.

Joe Piolunek wrote:
> This appeared in /var/log/messages, I don't seem to recall any failures 
> occurring at the time, though. Unfortunately, I don't recall exactly what
I 
> was doing that led to the errors being logged. I tried to recreate the
errors 
> with no luck.
> 
> Jun 12 19:05:05 tumbleweed ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:708, 
> dev=<par:0>, pid=1185, errno=11
> Jun 12 19:05:05 tumbleweed ptal-mlcd: fdRegister(invalid fd=-1,r=1,w=0) 
> called from ExMgr.cpp:2056!
I haven't yet determined with 100% certainty why this happens, but I added
an extra error message after this particular failed call that prints out
some interesting variables.  I somehow managed to hit this on the first
try after adding the extra error message, but only once.  In my case, the
extra information was "exContext=4, scd=8, state=5".  Let me know if you
or anybody else sees this again, especially if becomes reproducible.  I'll
try to get to root cause instead of applying a superficial fix that makes
the error go away but doesn't actually fix the underlying problem.

David

Re: [hpoj-devel] lots of ptal-mlcd fixes

[Obi-Wan <bv...@in...>]

>> I also wouldn't mind having it log to the lpr facility 
>> instead of daemon
>> or whatever, since that seems like the most appropriate place.  Others
>> may disagree.
>
> What difference does that make?  Does it cause the messages to get logged
> into a different file (according to rules in /etc/syslog.conf)?  The message
> itself doesn't actually reflect the facility, and it seems to me that
> /var/log/messages is an appropriate file to log into, since that's where the
> kernel messages go (useful for debugging USB plug/unplug issues).

With the stock syslog, splitting into different files is done based
on the facility and the log level, as specified in your /etc/syslog.conf
file.

I guess I feel like I'd rather have all my printer-related messages
going to the same spot.  LOG_DAEMON is more of a generic catch-all
facility for use by miscellaneous daemons that don't have their own
pre-defined facility and don't want to use one of the eight local
facilities.  Basically, everything except mail, printing, uucp,
usenet, and cron.  Lprng & its cousins all log to LOG_LPR, so it
makes sense that the low-level printer drivers log there as well.

Does anyone else care one way or the other about this?  If it's just
me vs the world, I'll shut up.  I've been a professional Unix sysadmin
for about a decade, and one of my pet peeves (especially recently,
but not due to this project) is programs that put their logs where
you'd never expect to find them.  For instance, TCP Wrappers by
default logs to the LOG_MAIL facility.  What the ????  The first
thing I do when I build it on a new machine is change the source
to LOG_LOCAL1 so I can separate the tcpd messages into their own file.
</rant>

-- 
Ben "Obi-Wan" Hollingsworth                             ob...@je...
   The stuff of earth competes for the allegiance I owe only to the
     Giver of all good things, so if I stand, let me stand on the
       promise that You will pull me through.  -- Rich Mullins

RE: [hpoj-devel] Trouble compiling hpoj driver

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

Hi, Rainer.  You may need to recompile your kernel in order to get the
ieee12844/*.c files to compile.  If you don't want to go to that trouble,
then you could try the development code in CVS, which no longer depends on
the kernel for parallel-port I/O.  Also, make sure that you apply the patch
available at http://hpoj.sourceforge.net to fix some problems with the 2.4
kernel, if you haven't done so already.  

David

> -----Original Message-----
> From: le...@t-... [mailto:le...@t-...]
> Sent: Tuesday, June 12, 2001 12:45 PM
> To: hpo...@li...
> Subject: [hpoj-devel] Trouble compiling hpoj driver
> 
> 
> Hello,
> 
> I try to compile the hpoj driver but get errors 
> (modversions.h not found ...).
> Kernel sources are installed.
> 
> My system is:
> SuSE 7.2
> kernel 2.4.4-4GB
> 
> Is there a problem with the kernel version or what else ?
> 
> Yours:
> Rainer Lehrig
> 
> lehrig@nblehrig:~/software/hpoj-0.7 > make
> ptal
> make[1]: Entering directory `/home/lehrig/software/hpoj-0.7/ptal'
> make[1]: Nothing to be done for `release'.
> make[1]: Leaving directory `/home/lehrig/software/hpoj-0.7/ptal'
> ieee12844
> make[1]: Entering directory `/home/lehrig/software/hpoj-0.7/ieee12844'
> gcc -O -I/home/lehrig/software/hpoj-0.7/include 
> -I/home/lehrig/software/hpoj-0.7/ptal -I/usr/src/linux/include 
> -I/usr/lib/qt/include -Wall -Wstrict-prototypes -D__KERNEL__ -DMODULE 
> -DEXPORT_SYMTAB  -c ieee12844pp.c
> In file included from ieee12844pp.c:44:
> /usr/src/linux/include/linux/module.h:21: 
> linux/modversions.h: Datei oder 
> Verzeichnis nicht gefunden
> In file included from /usr/src/linux/include/linux/module.h:261,
>                  from ieee12844pp.c:44:
> /usr/include/linux/version.h:2: #error 
> "======================================================="
> /usr/include/linux/version.h:3: #error "You should not include 
> /usr/include/{linux,asm}/ header"
> /usr/include/linux/version.h:4: #error "files directly for 
> the compilation of 
> kernel modules."
> /usr/include/linux/version.h:5: #error ""
> /usr/include/linux/version.h:6: #error "glibc now uses kernel 
> header files 
> from a well-defined"
> ... and so on
> 
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/lists/listinfo/hpoj-devel
> 

RE: [hpoj-devel] lots of ptal-mlcd fixes

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

Obi-Wan wrote:
> Once I applied Joe's fix so that it would compile, I ran scanimage
> three times in a row.  It passed all tests in about 25 seconds per
> run.  My scanner bed is empty (I'm at work), but scanning a white
> scanner lid seems to work.
Thanks to all who reported the compile error (sorry about that!).  It's
fixed in CVS now, but those of you who modified ExMgr.h should delete that
file before running "cvs update" to prevent a merge conflict.  I guess newer
versions of gcc are stricter about this.

> I also wouldn't mind having it log to the lpr facility 
> instead of daemon
> or whatever, since that seems like the most appropriate place.  Others
> may disagree.
What difference does that make?  Does it cause the messages to get logged
into a different file (according to rules in /etc/syslog.conf)?  The message
itself doesn't actually reflect the facility, and it seems to me that
/var/log/messages is an appropriate file to log into, since that's where the
kernel messages go (useful for debugging USB plug/unplug issues).

Joe Piolunek wrote:
> This appeared in /var/log/messages, I don't seem to recall any failures 
> occurring at the time, though. Unfortunately, I don't recall exactly what
I 
> was doing that led to the errors being logged. I tried to recreate the
errors 
> with no luck.
> 
> Jun 12 19:05:05 tumbleweed ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:708, 
> dev=<par:0>, pid=1185, errno=11
> Jun 12 19:05:05 tumbleweed ptal-mlcd: fdRegister(invalid fd=-1,r=1,w=0) 
> called from ExMgr.cpp:2056!
Thanks for mentioning that.  I think I have an idea about what the problem
is.

David

RE: [hpoj-devel] officejet v40 scanning

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

Hi, Chris.  The scan buttons on the device aren't currently supported, so
for now scanning can only be initiated from the PC (i.e. SANE).  Be sure to
read the sane-hp man page, especially the section on the OfficeJet K series,
which also applies to the V series.  It explains the extra steps you need to
take in order to scan successfully with these models (clicking on "Change
document" and "Unload document" at the right times).  With xsane you'll
probably need to bring up some sort of "advanced options" window to get to
these buttons.

David


> -----Original Message-----
> From: Chris Mason [mailto:ma...@su...]
> Sent: Tuesday, June 12, 2001 9:47 AM
> To: hpo...@li...
> Subject: [hpoj-devel] officejet v40 scanning
> 
> 
> 
> Hello everyone,
> 
> I'm trying to setup scanner support on an officejet v40.  
> I've downloaded
> the hpoj code from CVS (from 6/11/01), and have printing 
> working.  The sane
> backends are compiled/working (v1.0.4 w/ptal support), and 
> xsane can find
> the device and trigger noises from it and such.
> 
> But, when I press the scan button on the front of the v40, it 
> just says
> 'options not set'.  I'm guessing that means the v40 has never 
> been hooked
> up to a windows box and had a destination set.  When I tell 
> xsane to start
> a scan, I immediately get a scan cancelled message on the 
> front of the v40.
> 
> So, is there a way from linux to set the scan destination?
> 
> [ please cc me as I'm not on the list ]
> 
> -chris
> 
> 
> 
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/lists/listinfo/hpoj-devel
> 

Re: [hpoj-devel] lots of ptal-mlcd fixes

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

On Tuesday 12 June 2001 04:58 am, David Paschal wrote:
<...>
>
> There were some pretty far-reaching changes in this checkin, and I somehow
> managed to break a lot of things while making these changes.  :-)  It
> should all be fixed now, but I would appreciate it if people could do some
> print and scan testing and let me know if anything odd happens, such as
> error or fatal error messages, especially about bad states or invalid file
> descriptors passed to fdRegister().
>
> David


This appeared in /var/log/messages, I don't seem to recall any failures 
occurring at the time, though. Unfortunately, I don't recall exactly what I 
was doing that led to the errors being logged. I tried to recreate the errors 
with no luck.

Jun 12 19:05:05 tumbleweed ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:708, 
dev=<par:0>, pid=1185, errno=11
Jun 12 19:05:05 tumbleweed ptal-mlcd: fdRegister(invalid fd=-1,r=1,w=0) 
called from ExMgr.cpp:2056!

-- 
Joe

[hpoj-devel] Trouble compiling hpoj driver

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

Hello,

I try to compile the hpoj driver but get errors (modversions.h not found ...).
Kernel sources are installed.

My system is:
SuSE 7.2
kernel 2.4.4-4GB

Is there a problem with the kernel version or what else ?

Yours:
Rainer Lehrig

lehrig@nblehrig:~/software/hpoj-0.7 > make
ptal
make[1]: Entering directory `/home/lehrig/software/hpoj-0.7/ptal'
make[1]: Nothing to be done for `release'.
make[1]: Leaving directory `/home/lehrig/software/hpoj-0.7/ptal'
ieee12844
make[1]: Entering directory `/home/lehrig/software/hpoj-0.7/ieee12844'
gcc -O -I/home/lehrig/software/hpoj-0.7/include 
-I/home/lehrig/software/hpoj-0.7/ptal -I/usr/src/linux/include 
-I/usr/lib/qt/include -Wall -Wstrict-prototypes -D__KERNEL__ -DMODULE 
-DEXPORT_SYMTAB  -c ieee12844pp.c
In file included from ieee12844pp.c:44:
/usr/src/linux/include/linux/module.h:21: linux/modversions.h: Datei oder 
Verzeichnis nicht gefunden
In file included from /usr/src/linux/include/linux/module.h:261,
                 from ieee12844pp.c:44:
/usr/include/linux/version.h:2: #error 
"======================================================="
/usr/include/linux/version.h:3: #error "You should not include 
/usr/include/{linux,asm}/ header"
/usr/include/linux/version.h:4: #error "files directly for the compilation of 
kernel modules."
/usr/include/linux/version.h:5: #error ""
/usr/include/linux/version.h:6: #error "glibc now uses kernel header files 
from a well-defined"
... and so on

Re: [hpoj-devel] lots of ptal-mlcd fixes

[Obi-Wan <bv...@in...>]

Your change to configure works on Debian now.

> - "scanimage --test" should now work properly on the OfficeJet Pro
> 1150/1170/1175, OfficeJet R series, and PSC 500.  Daniel and Obi-Wan,
> would you please verify that this now works for you, since you both saw
> this failure?

Once I applied Joe's fix so that it would compile, I ran scanimage
three times in a row.  It passed all tests in about 25 seconds per
run.  My scanner bed is empty (I'm at work), but scanning a white
scanner lid seems to work.

> For example, you can kill ptal-mlcd for a specific device by saying something
> like "kill `ptal-connect mlc:par:0 -service PTAL-MLCD-PID`".

The PID line seems to work fine.

> There were some pretty far-reaching changes in this checkin, and I somehow
> managed to break a lot of things while making these changes.  :-)  It should
> all be fixed now, but I would appreciate it if people could do some print
> and scan testing and let me know if anything odd happens, such as error or
> fatal error messages, especially about bad states or invalid file
> descriptors passed to fdRegister().

Printing a small text file seemed to work, meaning I got no errors and
it disappeared from the print queue after a few seconds.  I'll know
when I get home what it generated.

I have yet to get any log messages or stderr/out messages with this
latest CVS version.  Logging a banner at startup would be a nice thing.
I also wouldn't mind having it log to the lpr facility instead of daemon
or whatever, since that seems like the most appropriate place.  Others
may disagree.

-- 
Ben "Obi-Wan" Hollingsworth                             ob...@je...
   The stuff of earth competes for the allegiance I owe only to the
     Giver of all good things, so if I stand, let me stand on the
       promise that You will pull me through.  -- Rich Mullins

Re: [hpoj-devel] lots of ptal-mlcd fixes

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

On Tuesday 12 June 2001 04:58 am, David Paschal wrote:
<...>
> There were some pretty far-reaching changes in this checkin, and I somehow
> managed to break a lot of things while making these changes.  :-)  It
> should all be fixed now, but I would appreciate it if people could do some
> print and scan testing and let me know if anything odd happens, such as
> error or fatal error messages, especially about bad states or invalid file
> descriptors passed to fdRegister().
>
> David


When compiling the latest CVS code, I get the same error Alexander reported 
(compiler: gcc-2.95.2).

make[1]: Entering directory `/home/joe/CVS/hpoj_copy/mlcd'
g++ -I/home/joe/CVS/hpoj_copy/mlcd -I/home/joe/CVS/hpoj_copy/mlcd/transport 
-O -g -Wall
-DEX_TRANSPORT_UNIX_PORT -DPAR_PLATFORM_LINUX -DUSB_PLATFORM_LINUX -DJD_DEBUG 
-DBROKEN_IO_H -c -o ExMgr.o ExMgr.cpp
In file included from 
/home/joe/CVS/hpoj_copy/mlcd/bp/ex/transport/ExTransport.h:26,
from /home/joe/CVS/hpoj_copy/mlcd/bp/ex/transport/ExMlcTransport.h:26,
from ExMgr.cpp:32: /home/joe/CVS/hpoj_copy/mlcd/bp/ex/ExMgr.h: In method 
`char * ExMgr::llioGetDeviceNode()': 
/home/joe/CVS/hpoj_copy/mlcd/bp/ex/ExMgr.h:806:
return to `char *' from `const char *' discards qualifiers
make[1]: *** [ExMgr.o] Error 1
make[1]: Leaving directory `/home/joe/CVS/hpoj_copy/mlcd'
make: *** [all] Error 2

Adding a char* cast in ExMgr.h:806 allowed the build to complete without any 
other trouble.

ExMgr.h:806:
//return llioName?llioName:"";
return llioName?llioName:(char*)"";

-- 
Joe

[hpoj-devel] officejet v40 scanning

[Chris M. <ma...@su...>]

Hello everyone,

I'm trying to setup scanner support on an officejet v40.  I've downloaded
the hpoj code from CVS (from 6/11/01), and have printing working.  The sane
backends are compiled/working (v1.0.4 w/ptal support), and xsane can find
the device and trigger noises from it and such.

But, when I press the scan button on the front of the v40, it just says
'options not set'.  I'm guessing that means the v40 has never been hooked
up to a windows box and had a destination set.  When I tell xsane to start
a scan, I immediately get a scan cancelled message on the front of the v40.

So, is there a way from linux to set the scan destination?

[ please cc me as I'm not on the list ]

-chris

[hpoj-devel] Compiler error in ExMgr.h

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

Hello,

I just checked out the latest CVS and got a compiler error:

g++ -I/hpoj/mlcd -I/hpoj/mlcd/transport -O -g -Wall -DEX_TRANSPORT_UNIX_PORT -DPAR_PLATFORM_LINUX -DUSB_PLATFORM_LINUX -DJD_DEBUG  -c -o ExMgr.o ExMgr.cpp
In file included from /hpoj/mlcd/bp/ex/transport/ExTransport.h:26,
                 from /hpoj/mlcd/bp/ex/transport/ExMlcTransport.h:26,
                 from ExMgr.cpp:32:
/hpoj/mlcd/bp/ex/ExMgr.h: In method `char * ExMgr::llioGetDeviceNode()':
/hpoj/mlcd/bp/ex/ExMgr.h:806: return to `char *' from `const char *' discards qualifiers

I'm running RedHat 7.1 on a Intel dual processor board.
-- 
Ale...@fm... / For every complex problem,
http://www.fmi.uni-passau.de/~zimmerma/ there is a solution that is
for PGP public key finger            / simple, neat, and wrong.   -- H. 
zim...@yo...     / L. Mencken 

Re: [hpoj-devel] tonight's code changes

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

Allen Barnett wrote:
> [Back from a great trip to Bryce and Zion National Parks. Highly
> reccommended! But wear a hat and use lots of sunscreen.]
Hi, Allen.  Welcome back!  I really should get out more often as well, but
lately I've been too busy working on this project to have much of a life.
:-)

> > 2. ptal-mlcd and ptal-printd now log to syslog in addition to standard output
> > or standard error, respectively.
> 
> Seems to work. When the commands start and run OK, there doesn't seem to
> be any output! A test with bad command line arguments did put a line in
> /var/log/messages. Maybe each of the ptal- commands could put a "banner"
> line out to syslog on startup?
Good point.  It would probably be useful to log other interesting events as
well, such as activation attempts.  It's on my TODO list.

> Rapidly pulled and inserted the USB plug 3 times and got these messages
> in /var/log/messages:
> 
> Jun 11 11:06:21 guanaco kernel: usb.c: USB disconnect on device 5
> Jun 11 11:06:22 guanaco ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:2182,
> dev=<usb:0>, pid=3879, errno=19
> Jun 11 11:06:22 guanaco ptal-mlcd: llioService: llioRead returns -1,
> expected=6! 
> Jun 11 11:06:22 guanaco ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:888,
> dev=<usb:0>, pid=3879, errno=25
> Jun 11 11:06:22 guanaco ptal-mlcd: exClose(reason=0x0010)
> Jun 11 11:06:23 guanaco kernel: hub.c: USB new device connect on bus1/1,
> assigned device number 6
> Jun 11 11:06:23 guanaco ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:2095,
> dev=<usb:0>, pid=3879, errno=19
> Jun 11 11:06:23 guanaco ptal-mlcd: llioOpen: open failed!
> Jun 11 11:06:23 guanaco ptal-mlcd:  ptal-mlcd: FATAL ERROR at
> ExMgr.cpp:793, dev=<usb:0>, pid=3879, errno=19
> Jun 11 11:06:23 guanaco ptal-mlcd: exActivate: Exiting due to activation
> failure.
> Jun 11 11:06:23 guanaco kernel: printer.c: usblp0: USB Bidirectional
> printer dev 6 if 0 alt 0
> Jun 11 11:06:24 guanaco kernel: usb.c: USB disconnect on device 6
> Jun 11 11:06:24 guanaco ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:2095,
> dev=<usb:0>, pid=4902, errno=19
> Jun 11 11:06:24 guanaco ptal-mlcd: llioOpen: open failed!
> Jun 11 11:06:24 guanaco ptal-mlcd:  ptal-mlcd: FATAL ERROR at
> ExMgr.cpp:793, dev=<usb:0>, pid=4902, errno=25
> Jun 11 11:06:24 guanaco ptal-mlcd: exActivate: Exiting due to activation
> failure.
> Jun 11 11:06:24 guanaco kernel: hub.c: USB new device connect on bus1/1,
> assigned device number 7
> Jun 11 11:06:24 guanaco kernel: printer.c: usblp0: USB Bidirectional
> printer dev 7 if 0 alt 0
> Jun 11 11:06:25 guanaco kernel: usb.c: USB disconnect on device 7
> Jun 11 11:06:26 guanaco ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:2095,
> dev=<usb:0>, pid=4941, errno=19
> Jun 11 11:06:26 guanaco ptal-mlcd: llioOpen: open failed!
> Jun 11 11:06:26 guanaco ptal-mlcd:  ptal-mlcd: FATAL ERROR at
> ExMgr.cpp:793, dev=<usb:0>, pid=4941, errno=25
> Jun 11 11:06:26 guanaco ptal-mlcd: exActivate: Exiting due to activation
> failure.
> Jun 11 11:06:26 guanaco kernel: hub.c: USB new device connect on bus1/1,
> assigned device number 8
> Jun 11 11:06:27 guanaco kernel: printer.c: usblp0: USB Bidirectional
> printer dev 8 if 0 alt 0
> 
> Is this correct? There was only one instance of ptal-mlcd running after
> all of that
It looks OK to me, but the "startup message" you requested would indeed
make it easier to read.  Were you able to successfully use the device
afterwards?

Note that ptal-mlcd may not work correctly if you unplug/replug when it's
in the middle of transferring data (i.e. printing or scanning), because it
may have trouble re-synchronizing with the peripheral.

> (but there were 4 ptal-printd's, also started by the hotplug script). 
That's to be expected, but it's probably not a good idea for this to happen.
One of these days I'll add a proper init script to make it easy to invoke
this at startup.

I've had an idea brewing in the back of my mind for a while now that might
make it easier to deal with the variable device address due to USB hotplug.
Specifically, I would change ptal-mlcd to accept wildcards for the device
node (-device "/dev/usb/lp*") and strings to search for in the device ID
string, such as the model and possibly serial number.  At activation time,
it would expand the wildcard string (using glob(3)) and open each one and
query the device ID string until it found one that matched.  I could
probably use a SysV-IPC named semaphore to prevent race conditions where
multiple instances of ptal-mlcd are simultaneously looping through trying
to find their respective devices.  This way, I think you could start
ptal-mlcd at startup (along with ptal-printd) and not even worry about
hacking hotplug scripts.  Kludgey but workable, I think.  :-)  It's not
as elegant as the ioctls you added to usbdevfs, but I don't know if that
got incorporated into the kernel code.  What do you think about this
scheme?

David

[hpoj-devel] lots of ptal-mlcd fixes

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

Hi,

Tonight's major ptal-mlcd changes include the following:

- "scanimage --test" should now work properly on the OfficeJet Pro
1150/1170/1175, OfficeJet R series, and PSC 500.  Daniel and Obi-Wan,
would you please verify that this now works for you, since you both saw
this failure?

- Added the following "special" services, which you can access with a
command like "ptal-connect mlc:usb:0 -service <serviceName>":
PTAL-MLCD-CONSOLE -- the debug console, if -remconsole was specified, already
accessible as "-socket -1".
PTAL-MLCD-PID -- the process ID.
PTAL-MLCD-CMDLINE -- the command line parameters.
PTAL-MLCD-DEVNODE -- the assigned /dev/usb/lpX device node, if any.
PTAL-MLCD-DUMP -- a dump of major data structures.
For example, you can kill ptal-mlcd for a specific device by saying something
like "kill `ptal-connect mlc:par:0 -service PTAL-MLCD-PID`".

Lots of miscellaneous code cleanups:
- Fixed the data-flow code paths so channels can't starve each other or
the debug console (if active).
- Cleaned up the warning log messages which sometimes appeared while scanning
on USB.
- All the other gory details can be found in the checkin comments.

There were some pretty far-reaching changes in this checkin, and I somehow
managed to break a lot of things while making these changes.  :-)  It should
all be fixed now, but I would appreciate it if people could do some print
and scan testing and let me know if anything odd happens, such as error or
fatal error messages, especially about bad states or invalid file
descriptors passed to fdRegister().

David

Re: [hpoj-devel] tonight's code changes

[Allen B. <ba...@lo...>]

[Back from a great trip to Bryce and Zion National Parks. Highly
reccommended! But wear a hat and use lots of sunscreen.]

David Paschal wrote:
> 1. ptal-mlcd and ptal-printd should now work properly from a hotplug script,
> despite the lack of stdin/stdout/stderr file descriptors.

Works.

> 2. ptal-mlcd and ptal-printd now log to syslog in addition to standard output
> or standard error, respectively.

Seems to work. When the commands start and run OK, there doesn't seem to
be any output! A test with bad command line arguments did put a line in
/var/log/messages. Maybe each of the ptal- commands could put a "banner"
line out to syslog on startup?

> 3. ptal-printd should be more immune to ptal-mlcd hiccups (such as device
> unplugs); previously it could exit due to a "broken pipe" signal.
> 
> 4. ptal-mlcd will now refuse to start if another instance of ptal-mlcd is
> already running using the same PTAL device name (socket).

Rapidly pulled and inserted the USB plug 3 times and got these messages
in /var/log/messages:

Jun 11 11:06:21 guanaco kernel: usb.c: USB disconnect on device 5
Jun 11 11:06:22 guanaco ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:2182,
dev=<usb:0>, pid=3879, errno=19
Jun 11 11:06:22 guanaco ptal-mlcd: llioService: llioRead returns -1,
expected=6! 
Jun 11 11:06:22 guanaco ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:888,
dev=<usb:0>, pid=3879, errno=25
Jun 11 11:06:22 guanaco ptal-mlcd: exClose(reason=0x0010)
Jun 11 11:06:23 guanaco kernel: hub.c: USB new device connect on bus1/1,
assigned device number 6
Jun 11 11:06:23 guanaco ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:2095,
dev=<usb:0>, pid=3879, errno=19
Jun 11 11:06:23 guanaco ptal-mlcd: llioOpen: open failed!
Jun 11 11:06:23 guanaco ptal-mlcd:  ptal-mlcd: FATAL ERROR at
ExMgr.cpp:793, dev=<usb:0>, pid=3879, errno=19
Jun 11 11:06:23 guanaco ptal-mlcd: exActivate: Exiting due to activation
failure.
Jun 11 11:06:23 guanaco kernel: printer.c: usblp0: USB Bidirectional
printer dev 6 if 0 alt 0
Jun 11 11:06:24 guanaco kernel: usb.c: USB disconnect on device 6
Jun 11 11:06:24 guanaco ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:2095,
dev=<usb:0>, pid=4902, errno=19
Jun 11 11:06:24 guanaco ptal-mlcd: llioOpen: open failed!
Jun 11 11:06:24 guanaco ptal-mlcd:  ptal-mlcd: FATAL ERROR at
ExMgr.cpp:793, dev=<usb:0>, pid=4902, errno=25
Jun 11 11:06:24 guanaco ptal-mlcd: exActivate: Exiting due to activation
failure.
Jun 11 11:06:24 guanaco kernel: hub.c: USB new device connect on bus1/1,
assigned device number 7
Jun 11 11:06:24 guanaco kernel: printer.c: usblp0: USB Bidirectional
printer dev 7 if 0 alt 0
Jun 11 11:06:25 guanaco kernel: usb.c: USB disconnect on device 7
Jun 11 11:06:26 guanaco ptal-mlcd:  ptal-mlcd: ERROR at ExMgr.cpp:2095,
dev=<usb:0>, pid=4941, errno=19
Jun 11 11:06:26 guanaco ptal-mlcd: llioOpen: open failed!
Jun 11 11:06:26 guanaco ptal-mlcd:  ptal-mlcd: FATAL ERROR at
ExMgr.cpp:793, dev=<usb:0>, pid=4941, errno=25
Jun 11 11:06:26 guanaco ptal-mlcd: exActivate: Exiting due to activation
failure.
Jun 11 11:06:26 guanaco kernel: hub.c: USB new device connect on bus1/1,
assigned device number 8
Jun 11 11:06:27 guanaco kernel: printer.c: usblp0: USB Bidirectional
printer dev 8 if 0 alt 0

Is this correct? There was only one instance of ptal-mlcd running after
all of that (but there were 4 ptal-printd's, also started by the hotplug
script). 

Allen

Re: [hpoj-devel] tonight's code changes

[Obi-Wan <bv...@in...>]

> OK, I didn't notice that.  I changed it to -f and checked it in.  Does it
> work for you now?

If that's all you changed, then I can tell you without checking that
it works, since that's what I changed on my end to fix the problem.

> There should be no issues with using hpoj with kernel 2.4.5, but let me know
> if you do find any problems.

Will do.

>>> I take it you haven't tried running
>>> "scanimage --test", because that has a tendency to lock up certain models,
>>> including yours.  I'm working on a fix for that problem right now.
>
> Try running "scanimage --test" multiple times in a row, and that's when
> you'll probably see the problem.

Sure enough, the second time I ran it (with a couple hours of screen
saver running in between), it continued to run with no output after
10 minutes.  strace on the running scanimage says:

   select(6, [5], NULL, NULL, NULL

strace on ptal-mcld dumps these at about 2 selects per second:

   select(8, [3 7], [], NULL, {0, 470000}) = 0 (Timeout)
   time(NULL)                              = 991944622
   select(8, [3 7], [], NULL, {0, 500000}) = 0 (Timeout)
   time(NULL)                              = 991944623
   select(8, [3 7], [], NULL, {0, 500000}) = 0 (Timeout)
   time(NULL)                              = 991944623
   select(8, [3 7], [], NULL, {0, 500000}) = 0 (Timeout)
   time(NULL)                              = 991944624

-- 
Ben "Obi-Wan" Hollingsworth                             ob...@je...
   The stuff of earth competes for the allegiance I owe only to the
     Giver of all good things, so if I stand, let me stand on the
       promise that You will pull me through.  -- Rich Mullins

RE: [hpoj-devel] tonight's code changes

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

Obi-Wan wrote:
> OK, I was wrong in my earlier analysis.  -x follows symlinks just
> fine.  However, shared libs don't have to be executable, and in my
> case, it's not.  See the last line of the 'ls' output above.  -f
> or !-z are probably the best ones to use, but use -e if you wish.
OK, I didn't notice that.  I changed it to -f and checked it in.  Does it
work for you now?

> But there are no problems with running the current CVS tree on 2.4.5,
> right?  I'm currently running 2.2.16.  I want to start fiddling with
> FireWire stuff for my camcorder, which prefers the newer kernels.
There should be no issues with using hpoj with kernel 2.4.5, but let me know
if you do find any problems.

> > I take it you haven't tried running
> > "scanimage --test", because that has a tendency to lock up 
> certain models,
> > including yours.  I'm working on a fix for that problem right now.
> 
> No, I hadn't.  I ran it just now and it took 30 seconds to generate:
> 
> # scanimage --test
> scanimage: scanning image of size 5096x7014 pixels at 1 bits/pixel
> scanimage: acquiring gray frame, 1 bits/sample
> scanimage: reading one scanline, 637 bytes...   PASS
...
> Lest you balk at the time, remember that I'm running a K6-166 
> with 32MB RAM.
Try running "scanimage --test" multiple times in a row, and that's when
you'll probably see the problem.

David

Re: [hpoj-devel] tonight's code changes

[Obi-Wan <bv...@in...>]

>> Close, but not quite.  In configure, line 801 uses -x to check for
>> libqt.so.
>
> You're pretty brave if you're reading the configure script.  :-)

I've been a Unix hacker (in the original sense of the word) for over
a decade.  Shell scripts are nothing.  'truss' and 'strace' are quickly
becoming my favorite tools for debugging 3rd party software.

>> That won't work on Debian because libqt.so is a symlink
>> to libqt.so.2.3.0 (or whatever version you have).  -x fails for
>> symlinks.  I changed it to -f and all is well.
>> 
>> # dir /usr/lib/libqt.so*
>> lrwxrwxrwx    1 root     root           14 May 31 01:06 /usr/lib/libqt.so -> libqt.so.2.3.0
>> lrwxrwxrwx    1 root     root           14 May 31 00:56 /usr/lib/libqt.so.2 -> libqt.so.2.3.0
>> lrwxrwxrwx    1 root     root           14 May 31 00:56 /usr/lib/libqt.so.2.3 -> libqt.so.2.3.0
>> -rw-r--r--    1 root     root      4943852 May 25 02:28 /usr/lib/libqt.so.2.3.0
> 
> That sounds like a bash bug to me, because it's a symlink on my system too
> and -x works fine.  According to the bash man page:
> -e file -- true if file exists.
> -f file -- true if file exists and is a regular file.
> -L file -- true if file exists and is a symbolic link.
> -x file -- true if file exists and is executable.
> Neither -f nor -x claim to either include or exclude symlinks.  Therefore,
> it seems to me that -e (the most permissive of all) would be a safer
> workaround to detect libqt.so.  Let me know if -e works for you, and I'll
> change it to that if it does.

OK, I was wrong in my earlier analysis.  -x follows symlinks just
fine.  However, shared libs don't have to be executable, and in my
case, it's not.  See the last line of the 'ls' output above.  -f
or !-z are probably the best ones to use, but use -e if you wish.

>> I seem to remember seeing somewhere when I was setting up all this
>> printing & scanning stuff that I should used the 2.2.x kernel instead
>> of the 2.4.x kernel.  Is that currently true?  Did it used to be true?
>
> That was true for previous released versions.  Even 0.7 ended up having
> trouble with some last-minute changes in 2.4, but there's a patch available
> to fix that.

But there are no problems with running the current CVS tree on 2.4.5,
right?  I'm currently running 2.2.16.  I want to start fiddling with
FireWire stuff for my camcorder, which prefers the newer kernels.

> I take it you haven't tried running
> "scanimage --test", because that has a tendency to lock up certain models,
> including yours.  I'm working on a fix for that problem right now.

No, I hadn't.  I ran it just now and it took 30 seconds to generate:

# scanimage --test
scanimage: scanning image of size 5096x7014 pixels at 1 bits/pixel
scanimage: acquiring gray frame, 1 bits/sample
scanimage: reading one scanline, 637 bytes...   PASS
scanimage: reading one byte...          PASS
scanimage: stepped read, 2 bytes...     PASS
scanimage: stepped read, 4 bytes...     PASS
scanimage: stepped read, 8 bytes...     PASS
scanimage: stepped read, 16 bytes...    PASS
scanimage: stepped read, 32 bytes...    PASS
scanimage: stepped read, 64 bytes...    PASS
scanimage: stepped read, 128 bytes...   PASS
scanimage: stepped read, 256 bytes...   PASS
scanimage: stepped read, 512 bytes...   PASS
scanimage: stepped read, 1024 bytes...  PASS
scanimage: stepped read, 1023 bytes...  PASS
scanimage: stepped read, 511 bytes...   PASS
scanimage: stepped read, 255 bytes...   PASS
scanimage: stepped read, 127 bytes...   PASS
scanimage: stepped read, 63 bytes...    PASS
scanimage: stepped read, 31 bytes...    PASS
scanimage: stepped read, 15 bytes...    PASS
scanimage: stepped read, 7 bytes...     PASS
scanimage: stepped read, 3 bytes...     PASS

Lest you balk at the time, remember that I'm running a K6-166 with 32MB RAM.

				-- Obi-Wan

-- 
Ben "Obi-Wan" Hollingsworth                             ob...@je...
   The stuff of earth competes for the allegiance I owe only to the
     Giver of all good things, so if I stand, let me stand on the
       promise that You will pull me through.  -- Rich Mullins

Re: [hpoj-devel] Scaling?

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

On Sunday 03 June 2001 06:28 pm, Bob Paddock wrote:
> I've been trying for some time now to get some thing printed the same scale
> on my HP710 as what my screen shows.
>
> For example if I draw a line with Gimp that is one inch long, I want a one
> inch long line to come out on the paper.  I realize there are aspect ratio
> differences and other such minutia when going from screen to printer, I'm
> going by a simple measured line in this case.

I'm not a gimp expert, but some of what I say here may work for you.

The following applies to gimp 1.2.1, but it may be relevant to older versions.

Gimp provides onscreen rulers and guides. If you want the rulers scaled in 
inches, click "File - Preferences - interface - image windows". Unclick "Use 
dot for dot". Click "Show rulers".

If you want to calibrate gimp to more closely match your monitor settings, 
click "File - New File - monitor". Click "manually", select "pixels/inch", 
then click "calibrate". You will see two rulers on the screen that you then 
measure with a handheld measuring device.

These configuration changes seem to apply only to new windows.


> I've tried every thing short of writing raw postscript by hand, and several
> programs, but it seems like what comes out on the paper is always smaller
> by about five to ten percent.
>
> Any recomendations on how to do What You See Is What You get when dealing
> with graphics?  Specificily printed circuit board art work.

Print through gimp's print dialog, rather than from the command line. The 
print dialog contains a print-scaling feature. With it, you can resize the 
image for printing without necessarily affecting the saved image. When I 
tried it, an image that gimp claimed would print at five inches wide 
accurately printed five inches wide on my officejet 600.

You probably should test your settings before starting a big project.

-- 
Joe

Re: [hpoj-devel] tonight's code changes

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

Ben "Obi-Wan" Hollingsworth wrote:
> Close, but not quite.  In configure, line 801 uses -x to check for
> libqt.so.
You're pretty brave if you're reading the configure script.  :-)  That file,
in all of its convoluted glory, is actually generated from configure.in by
autoconf.  The corresponding line number in configure.in is 148.

> That won't work on Debian because libqt.so is a symlink
> to libqt.so.2.3.0 (or whatever version you have).  -x fails for
> symlinks.  I changed it to -f and all is well.  I actually found
> that problem last time I installed, but forgot to mention it.
> 
>    if test -x $dir/bin/moc -a \( -f $dir/include/qmainwindow.h -o -f $dir/include/qt/qmainwindow.h \) -a -x $dir/lib/libqt.so -a -z "$HIDE_QT" ; then
> 
> should be:
> 
>    if test -x $dir/bin/moc -a \( -f $dir/include/qmainwindow.h -o -f $dir/include/qt/qmainwindow.h \) -a -f $dir/lib/libqt.so -a -z "$HIDE_QT" ; then
> 
> because:
> 
> # dir /usr/lib/libqt.so*
> lrwxrwxrwx    1 root     root           14 May 31 01:06 /usr/lib/libqt.so -> libqt.so.2.3.0
> lrwxrwxrwx    1 root     root           14 May 31 00:56 /usr/lib/libqt.so.2 -> libqt.so.2.3.0
> lrwxrwxrwx    1 root     root           14 May 31 00:56 /usr/lib/libqt.so.2.3 -> libqt.so.2.3.0
> -rw-r--r--    1 root     root      4943852 May 25 02:28 /usr/lib/libqt.so.2.3.0

That sounds like a bash bug to me, because it's a symlink on my system too
and -x works fine.  According to the bash man page:
-e file -- true if file exists.
-f file -- true if file exists and is a regular file.
-L file -- true if file exists and is a symbolic link.
-x file -- true if file exists and is executable.
Neither -f nor -x claim to either include or exclude symlinks.  Therefore,
it seems to me that -e (the most permissive of all) would be a safer
workaround to detect libqt.so.  Let me know if -e works for you, and I'll
change it to that if it does.

> I seem to remember seeing somewhere when I was setting up all this
> printing & scanning stuff that I should used the 2.2.x kernel instead
> of the 2.4.x kernel.  Is that currently true?  Did it used to be true?
That was true for previous released versions.  Even 0.7 ended up having
trouble with some last-minute changes in 2.4, but there's a patch available
to fix that.

> Do I need to lay off the weed?
Yes, but not for this reason.  :-)

> Will I run into problems if I install 2.4.5?
ptal-mlcd is completely kernel-independent when using it in parallel-port
mode, because all of the signalling is done in user mode.  Unfortunately,
this does impact performance somewhat, so in the future I will look into
adding optional support for the 2.4 ppdev interface, possibly through the
libieee1284 that Tim Waugh is developing.  (Tim: I apologize for not yet
getting a chance to sit down and write up my wish-list for this.  It's on
my TODO list.)

> Also, am I remembering correctly that I no longer need to use the
> kernel parport stuff, assuming all I use my parallel port for is
> accessing my PSC 500?
That is correct.  However, you can still use the "-device /dev/lp0" switch
for ptal-mlcd to ensure that other processes can't open up the parallel port
and interfere with ptal-mlcd's use of the port.  Alternatively, you could
recompile your kernel without parport support, which would pretty much
guarantee that only ptal-mlcd could access it.

> > I'm about to change my BIOS as we discussed earlier, and I'll let you
> > know how it goes.
> 
> Much faster scanning.  Everythings seems to be working well.  I'll
> let you know if problems arise.
Thanks for the success report.  I take it you haven't tried running
"scanimage --test", because that has a tendency to lock up certain models,
including yours.  I'm working on a fix for that problem right now.

David

[hpoj-devel] 2.4.5 Linux kernel

[Obi-Wan <bv...@in...>]

I seem to remember seeing somewhere when I was setting up all this
printing & scanning stuff that I should used the 2.2.x kernel instead
of the 2.4.x kernel.  Is that currently true?  Did it used to be true?
Do I need to lay off the weed?  Will I run into problems if I install 2.4.5?

Also, am I remembering correctly that I no longer need to use the
kernel parport stuff, assuming all I use my parallel port for is
accessing my PSC 500?

> I'm about to change my BIOS as we discussed earlier, and I'll let you
> know how it goes.

Much faster scanning.  Everythings seems to be working well.  I'll
let you know if problems arise.

				-- Obi-Wan

-- 
Ben "Obi-Wan" Hollingsworth                             ob...@je...
   The stuff of earth competes for the allegiance I owe only to the
     Giver of all good things, so if I stand, let me stand on the
       promise that You will pull me through.  -- Rich Mullins

Re: [hpoj-devel] tonight's code changes

[Obi-Wan <bv...@in...>]

> Here's a rundown of the major code changes tonight (it's still night for me,
> anyway:-):

I've been busy with other stuff for a while.  Just downloaded the
latest at 12:15am CDT Thursday morning.

> 5. The configure script should now detect QT as installed on Debian systems
> (/usr/bin, /usr/lib, and /usr/include/qt).
> 
> Obi-Wan, since you reported problem #5 above, would you please verify that
> the new configure script properly detects QT on your system, after removing
> your earlier tree-of-symlinks workaround?

Close, but not quite.  In configure, line 801 uses -x to check for
libqt.so.  That won't work on Debian because libqt.so is a symlink
to libqt.so.2.3.0 (or whatever version you have).  -x fails for
symlinks.  I changed it to -f and all is well.  I actually found
that problem last time I installed, but forgot to mention it.

   if test -x $dir/bin/moc -a \( -f $dir/include/qmainwindow.h -o -f $dir/include/qt/qmainwindow.h \) -a -x $dir/lib/libqt.so -a -z "$HIDE_QT" ; then

should be:

   if test -x $dir/bin/moc -a \( -f $dir/include/qmainwindow.h -o -f $dir/include/qt/qmainwindow.h \) -a -f $dir/lib/libqt.so -a -z "$HIDE_QT" ; then

because:

# dir /usr/lib/libqt.so*
lrwxrwxrwx    1 root     root           14 May 31 01:06 /usr/lib/libqt.so -> libqt.so.2.3.0
lrwxrwxrwx    1 root     root           14 May 31 00:56 /usr/lib/libqt.so.2 -> libqt.so.2.3.0
lrwxrwxrwx    1 root     root           14 May 31 00:56 /usr/lib/libqt.so.2.3 -> libqt.so.2.3.0
-rw-r--r--    1 root     root      4943852 May 25 02:28 /usr/lib/libqt.so.2.3.0

I'm about to change my BIOS as we discussed earlier, and I'll let you
know how it goes.

				-- Obi-Wan

-- 
Ben "Obi-Wan" Hollingsworth                             ob...@je...
   The stuff of earth competes for the allegiance I owe only to the
     Giver of all good things, so if I stand, let me stand on the
       promise that You will pull me through.  -- Rich Mullins