Menu
▾
▴
hpoj-devel — HPOJ development/support list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
(111) |
Oct
(63) |
Nov
(64) |
Dec
(116) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(49) |
Feb
(27) |
Mar
(136) |
Apr
(59) |
May
(122) |
Jun
(72) |
Jul
(167) |
Aug
(77) |
Sep
(103) |
Oct
(128) |
Nov
(86) |
Dec
(87) |
| 2002 |
Jan
(150) |
Feb
(111) |
Mar
(112) |
Apr
(139) |
May
(204) |
Jun
(228) |
Jul
(202) |
Aug
(244) |
Sep
(215) |
Oct
(311) |
Nov
(127) |
Dec
(229) |
| 2003 |
Jan
(252) |
Feb
(119) |
Mar
(163) |
Apr
(166) |
May
(91) |
Jun
(84) |
Jul
(106) |
Aug
(98) |
Sep
(93) |
Oct
(161) |
Nov
(82) |
Dec
(62) |
| 2004 |
Jan
(58) |
Feb
(44) |
Mar
(56) |
Apr
(67) |
May
(50) |
Jun
(57) |
Jul
(20) |
Aug
(25) |
Sep
(33) |
Oct
(35) |
Nov
(61) |
Dec
(95) |
| 2005 |
Jan
(61) |
Feb
(31) |
Mar
(17) |
Apr
(10) |
May
(2) |
Jun
(13) |
Jul
(4) |
Aug
(10) |
Sep
(9) |
Oct
(33) |
Nov
(2) |
Dec
(7) |
| 2006 |
Jan
(11) |
Feb
(3) |
Mar
(3) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Dag N. <da...@ne...> - 2000-12-21 17:40:35
|
Hi, I am the one that had problems with SMP and printing hanging.... Downloaded 0.7 and tried again: Didn't check scanning yet but I still see ptal-printd hanging and becoming unkillable (hang in the driver I presume). The strange thing is that the first printing usually works.... Is there anything I can do to help you (or me) debug this problem ? BRGDS -- Dag Nygren email: da...@ne... Oy NewTech Ab phone: +358 9 8024910 Trasktorpet 3 fax: +358 9 8024916 02360 ESBO GSM: 0400-426312 FINLAND |
|
From: Dag N. <da...@ne...> - 2000-12-21 07:51:22
|
> On Tuesday 19 December 2000 03:07, Timothy Lee wrote: > > >Hiya, all. > > >I'm using hpoj with RedHat 6.2. Instead of activating ptal-printd from > >rc.local, I thought it'd be easier to have a separate init script for it.? > >So I've written up the following script to load ptal-printd as a daemon: > <...> Please Timothy turn off the .x.x.x.x. HTML stuff, now my Exmh will not extract your script wo. a lot of handediting.... BRGDS -- Dag Nygren email: da...@ne... Oy NewTech Ab phone: +358 9 8024910 Trasktorpet 3 fax: +358 9 8024916 02360 ESBO GSM: 0400-426312 FINLAND |
|
From: Joe P. <joe...@sn...> - 2000-12-21 04:25:04
|
On Tuesday 19 December 2000 03:07, Timothy Lee wrote: >Hiya, all. >I'm using hpoj with RedHat 6.2. Instead of activating ptal-printd from >rc.local, I thought it'd be easier to have a separate init script for it.? >So I've written up the following script to load ptal-printd as a daemon: <...> Timothy: I set up your script on my RH6.1 machine to start the ptal-printd daemon at boot. It's working reasonably well. I like the way the startup message is displayed during the boot process. It fits in with the rest of the Redhat system. I wanted to run it a little differently, so I made a couple of changes. Because I wanted to leave the daemon in /usr/local/bin and the .conf file in /usr/local/etc, I had to modify the script to indicate the correct paths. Rather than copying the script to /etc/rc.d/init.d, I created a symlink to its location ( /usr/local/bin ). I guess your script as written would work correctly if I had put all the files where you suggested. There are a couple of additions to the script I'd like to see, if you care to make them. The script reports success even if the daemon doesn't really start. It happened when the paths were incorrect. Add some error control features and/or a message to indicate failure if it occurs. Don't create a lock file unless the daemon sucessfully starts. I think David would like users to be able to start a copy of the daemon, so could you make that easier? /var/lock/subsys is only writable by root, so a user's lock file would need to go somewhere else. Your script is a good idea, I think. -- Joe Piolunek |
|
From: Timothy L. <ti...@wo...> - 2000-12-21 02:05:38
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> David Paschal wrote: <blockquote TYPE=CITE>I'm glad you used the .conf file to allow multiple instances of ptal-printd <br>to be invoked. Hopefully the "killproc" function will be able to handle <br>this properly.</blockquote> Yes, I've tested the init script for multiple instances of ptal-printd, and the <b>killproc</b> function kills them all in one go. <blockquote TYPE=CITE>I probably should fix ptal-printd so it cleans up after itself when getting <br>killed, including deleting the pipe.</blockquote> There's one problem I've found with ptal-printd using the initscript. There is another problem related to the loadable modules. The situation goes likes this: <blockquote>ptal-printd will start with the printer off, but if I try to print, it quits. After reading through the source code, it appears that any manner of error will cause ptal-printd to exit. <p>In my opinion, error conditions should be logged, but the daemon should just continue to run. Otherwise the machine will be left in a broken state, thinking the ptal-printd subsystem is running, when in fact the daemon is long gone. <p>Now the problem with the modules. Let's say that I realized my printer wasn't turned on for ptal-printd and it died. So I turned on the printer, then restarted the ptal-printd daemon. Now try printing -- nope, nothing. And ptal-printd dead again. In fact running <b>hpo devid</b> tells me there are no devices available. <p>I tried this another way: with the printer turned on, run <b>hpo devid</b> to coax both <i>ieee12844.o</i> and <i>ieee12844pp.o</i> to load. Now manually remove <i>ieee12844pp.o</i> with <b>rmmod ieee12844pp</b>. Turn off the printer. Then run <b>hpo devid</b> again. There's a message which reports a device is registered to IEEE12844.4 protocol layer, then <i>hpo</i> fails. <p>My question: is the device list fixed for <i>ieee12844.o</i> during loading, or is it updated dynamically? If not, there'll definitely be a problem with OfficeJets that were not turned on during boot up (must remove modules by hand, or wait for cron to clean up autoload modules).</blockquote> Sorry that I sound like such a nag... <grin> But David, thanks again for the great work on hpoj! <p>And Merry Christmas to you all, of course! <smile> <br> <blockquote>Timothy</blockquote> </html> |
|
From: dmc <dm...@in...> - 2000-12-20 11:02:38
|
NOTE: I do not care about developing this driver, just using it. I
don't currently, and don't plan on reading the hpoj-devel list, as
long as I can print and scan on my PSC500, which I can now do. I'm
just posting this info so other people needn't do the same digging around
that I did.
Despite the release notes that came with 0.7, it appears that 0.7
is not yet compatable with the latest version of 2.4.0-test, namely test12.
I had to change 3 things in ieee12844/ieee12844pp.c to get it to compile
and work.
First I had to add
#define PAR_CONTROL_REVERSE_DATA 0x20
This is not the "right" solution, but it works. I went through old
versions of linux/include/linux/parport.h (or parport_pc.h) and
discovered that PAR_CONTROL_REVERSE_DATA had been
removed. However, the parts of the linux code that used to handle
it, still have a special case for 0x20, I guess in case 3rd party drivers
use it. Thats why I was confident that my solution was adequate
for the timebeing. I'm not a kernel hacker, and I have no interest
in developing this driver, I just wanted it to work for me, so thats
why I didn't investigate into a more proper solution.
Second, I changed
parport_write_econtrol
to
parport_write_control
because I got an unresolved symbol for parport_write_econtrol
during the insmod
Again, a guess, that seems to work for me so far.
Third, and most fundamental, I changed
queue_task (&l->tq, &tq_scheduler);
to
schedule_task(&l->tq);
After a bit of research I discovered that tq_scheduler got nuked
by linux-2.4.0-test12-pre7. The changelog yielded
- pre7:
...
- Andrew Morton: "tq_scheduler" is no more. We have keventd.
...
Not knowing much about kernel internals, I diffed pre6 and pre7
and discovered that every instance of
queue_task(X, &tq_scheduler);
was replaced by either
schedule_task(X)
or
MOD_INC_USE_COUNT;
if (schedule_task(X) == 0)
MOD_DEC_USE_COUNT;
Even though I used the first and it worked, my guess is that the latter
is used for kernel modules, and is therefore more correct. I'll probably
switch to it if I encounter any problems.
Otherwise, I CAN SCAN ON MY PSC500 :). Thanks very much for
not making me regret nuking my windows partition a few weeks ago :)
And I'll eagerly await 0.8 which will have better fixes than my hacks.
-dmc
|
|
From: <pa...@rc...> - 2000-12-20 09:58:39
|
Hi, Timothy. Thanks for providing this. I'm sorry the timing was such that I couldn't get it into 0.7. I'll play around with it in the near future, but in the meantime I would be interested in hearing what others think about it, especially how it works with distributions other than RedHat 6.2. I was going to do something like this eventually, but your implementation is much more clever than anything I would have been able to come up with. :-) I'm glad you used the .conf file to allow multiple instances of ptal-printd to be invoked. Hopefully the "killproc" function will be able to handle this properly. I probably should fix ptal-printd so it cleans up after itself when getting killed, including deleting the pipe. David |
|
From: <pa...@rc...> - 2000-12-20 09:50:54
|
Joe Piolunek wrote: > I got the official 0.7 release from sourceforge today and installed > it. There weren't any problems during the build or installation. > Printing using ptal-printd works well. It's certainly a lot easier to > set up. Congratulations. Hi, Joe. Thanks for the installation report; I'm glad you like it. Also thank you for your contributions to 0.7 as well as your constant willingness to try out bleeding-edge code and give valuable feedback. I'm sorry I wasn't able to fix the "xojpanel no-start" problem for you in this release. I worked on it some last night before starting the release process and found that the failure code path starts at line 1501 in link_receive() in ieee12844.c. It seems to think that the peripheral is sending a command packet with an unknown socket ID pair as part of the command, but I don't yet know at what point during the negotiation sequence it happens. It's obviously a race condition, because I discovered that it doesn't fail if I'm sitting at the computer waiting for it to happen, but as soon as I walk away and let the screensaver (kforest) kick in, it fails left and right, which would explain the high failure rate I previously reported. David |
|
From: Joe P. <joe...@sn...> - 2000-12-20 02:03:08
|
On Tuesday 19 December 2000 05:10, David Paschal wrote: > Hi, > > I am pleased to announce that version 0.7 of the OfficeJet Linux driver > software is now available at http://hpoj.sourceforge.net. Changes include: > > - Numerous bug fixes in the low-level drivers to address scanning lockups, > module unloading, and compatibility with SMP and 2.4 kernels. > - Introduced new "ptal-printd" daemon that greatly simplifies printing > setup. - Updated xojpanel application. > > Please post questions, problem reports, or other feedback to the hpoj-devel > mailing list. Thank you for your interest in this project. > > David Paschal > pa...@rc... > December 19, 2000 > David: I got the official 0.7 release from sourceforge today and installed it. There weren't any problems during the build or installation. Printing using ptal-printd works well. It's certainly a lot easier to set up. Congratulations. -- Joe |
|
From: Timothy L. <ti...@wo...> - 2000-12-19 08:06:27
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<br>David Paschal wrote:
<blockquote TYPE=CITE>
<pre>I committed ptal-printd to CVS and rewrote large portions of PRINT-HOWTO.
The command-line syntax of ptal-printd has changed, and I think I've fixed
the security issues to my liking now. Please try it out and let me know
ASAP if there are any remaining problems.</pre>
</blockquote>
<p><br>Hiya, all.
<p>I'm using hpoj with RedHat 6.2. Instead of activating ptal-printd from
rc.local, I thought it'd be easier to have a separate init script for it.
So I've written up the following script to load ptal-printd as a daemon:
<blockquote><tt>#!/bin/sh</tt>
<br><tt>#</tt>
<br><tt># ptal-printd Startup script for the PTAL-print daemon</tt>
<br><tt>#</tt>
<br><tt># chkconfig: 345 60 60</tt>
<br><tt># description: PTAL permits printing on HP OfficeJet printer connected
\</tt>
<br><tt>#
to a local parallel port, or remotely to an HP JetDirect \</tt>
<br><tt>#
network print server.</tt>
<br><tt># processname: ptal-printd</tt>
<br><tt># config: /etc/ptal-printd.conf</tt>
<p><tt># Source function library.</tt>
<br><tt>. /etc/rc.d/init.d/functions</tt>
<p><tt>RETVAL=0</tt>
<p><tt># See how we were called</tt>
<br><tt>case "$1" in</tt>
<br><tt> start)</tt>
<br><tt> # Start daemon</tt>
<br><tt> if [ ! -f /var/lock/subsys/ptal-printd
]; then</tt>
<br><tt>
echo -n "Starting ptal-printd: "</tt>
<br><tt>
eval `sed -n 's@^\([^#].*\)@\(ptal-printd \1 \&\);@p' /etc/ptal-printd.conf`</tt>
<br><tt>
touch /var/lock/subsys/ptal-printd</tt>
<br><tt>
success "ptal-printd startup"</tt>
<br><tt>
echo</tt>
<br><tt> fi</tt>
<br><tt> ;;</tt>
<br><tt> stop)</tt>
<br><tt> # Stop daemon</tt>
<br><tt> echo -n "Shutting down
ptal-printd: "</tt>
<br><tt> killproc ptal-printd</tt>
<br><tt> RETVAL=$?</tt>
<br><tt> [ $RETVAL -eq 0 ] &&
rm -f /var/lock/subsys/ptal-printd</tt>
<br><tt> echo</tt>
<br><tt> ;;</tt>
<br><tt> status)</tt>
<br><tt> status ptal-printd</tt>
<br><tt> RETVAL=$?</tt>
<br><tt> ;;</tt>
<br><tt> restart|reload)</tt>
<br><tt> $0 stop</tt>
<br><tt> $0 start</tt>
<br><tt> RETVAL=$?</tt>
<br><tt> ;;</tt>
<br><tt> *)</tt>
<br><tt> echo "Usage: $0 {start|stop|restart|reload|status}"</tt>
<br><tt> exit 1</tt>
<br><tt>esac</tt>
<p><tt>exit $RETVAL</tt></blockquote>
The script uses a configuration file <b>/etc/ptal-printd.conf</b>, and
it is of the form:
<blockquote><tt># ptal-printd.conf</tt>
<br><tt>#</tt>
<br><tt># All lines not starting with a '#' are considered command line
parameters</tt>
<br><tt># to ptal-printd.</tt>
<br><tt>#</tt>
<br><tt># Each printer entry should occupy one line.</tt>
<br><tt>#</tt>
<br><tt>mlc:mlcpp0 -like /dev/lp0</tt>
<br><tt>mlc:mlcpp1 -like /dev/lp1</tt></blockquote>
On RedHat systems, the script should be copied under <b>/etc/rc.d/init.d</b>
as <b>ptal-printd</b> and chmod 744, then a <b>chkconfig --add ptal-printd</b>
will enable the daemon for runlevel 3-5.
<p>I've tested it on my system and it works. Perhaps some brave soul
would like to try it on theirs???
<br>
<blockquote>Timothy Lee</blockquote>
</html>
|
|
From: Timothy L. <ti...@wo...> - 2000-12-19 07:58:48
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
David Paschal wrote:
<blockquote TYPE=CITE>
<pre>I committed ptal-printd to CVS and rewrote large portions of PRINT-HOWTO.
The command-line syntax of ptal-printd has changed, and I think I've fixed
the security issues to my liking now. Please try it out and let me know
ASAP if there are any remaining problems.</pre>
</blockquote>
<p><br>Hiya, all.
<p>I'm using hpoj with RedHat 6.2. Instead of activating ptal-printd from
rc.local, I thought it'd be easier to have a separate init script for it.
So I've written up the following script to load ptal-printd as a daemon:
<blockquote><tt>#!/bin/sh</tt>
<br><tt>#</tt>
<br><tt># ptal-printd Startup script for the PTAL-print daemon</tt>
<br><tt>#</tt>
<br><tt># chkconfig: 345 60 60</tt>
<br><tt># description: PTAL permits printing on HP OfficeJet printer connected
\</tt>
<br><tt>#
to a local parallel port, or remotely to an HP JetDirect \</tt>
<br><tt>#
network print server.</tt>
<br><tt># processname: ptal-printd</tt>
<br><tt># config: /etc/ptal-printd.conf</tt>
<p><tt># Source function library.</tt>
<br><tt>. /etc/rc.d/init.d/functions</tt>
<p><tt>RETVAL=0</tt>
<p><tt># See how we were called</tt>
<br><tt>case "$1" in</tt>
<br><tt> start)</tt>
<br><tt> # Start daemon</tt>
<br><tt> if [ ! -f /var/lock/subsys/ptal-printd
]; then</tt>
<br><tt>
echo -n "Starting ptal-printd: "</tt>
<br><tt>
eval `sed -n 's@^\([^#].*\)@\(ptal-printd \1 \&\);@p' /etc/ptal-printd.conf`</tt>
<br><tt>
touch /var/lock/subsys/ptal-printd</tt>
<br><tt>
success "ptal-printd startup"</tt>
<br><tt>
echo</tt>
<br><tt> fi</tt>
<br><tt> ;;</tt>
<br><tt> stop)</tt>
<br><tt> # Stop daemon</tt>
<br><tt> echo -n "Shutting down
ptal-printd: "</tt>
<br><tt> killproc ptal-printd</tt>
<br><tt> RETVAL=$?</tt>
<br><tt> [ $RETVAL -eq 0 ] &&
rm -f /var/lock/subsys/ptal-printd</tt>
<br><tt> echo</tt>
<br><tt> ;;</tt>
<br><tt> status)</tt>
<br><tt> status ptal-printd</tt>
<br><tt> RETVAL=$?</tt>
<br><tt> ;;</tt>
<br><tt> restart|reload)</tt>
<br><tt> $0 stop</tt>
<br><tt> $0 start</tt>
<br><tt> RETVAL=$?</tt>
<br><tt> ;;</tt>
<br><tt> *)</tt>
<br><tt> echo "Usage: $0 {start|stop|restart|reload|status}"</tt>
<br><tt> exit 1</tt>
<br><tt>esac</tt>
<p><tt>exit $RETVAL</tt></blockquote>
The script
<p>hpo...@li... wrote:
<blockquote TYPE=CITE>Send hpoj-devel mailing list submissions to
<br> hpo...@li...urceforge.
<br>To subscribe or unsubscribe via the World Wide Web, visit
<br> <a href="http://lists.sourceforge.net/mailman/listinfo/hpoj-devel">http://lists.sourceforge.net/mailman/listinfo/hpoj-devel</a>
<br>or, via email, send a message with subject or body 'help' to
<br> hpo...@li...
<p>You can reach the person managing the list at
<br> hpo...@li...
<p>When replying, please edit your Subject line so it is more specific
<br>than "Re: Contents of hpoj-devel digest..."
<p> ------------------------------------------------------------------------
<br>Today's Topics:
<p> 1. Re: ptal-printd, and preparing for 0.7 (David Paschal)
<br> 2. 2.2.18 + hpoj0.6 + patch + SMP (Dag Nygren)
<p> ------------------------------------------------------------------------
<p>Subject: Re: [hpoj-devel] ptal-printd, and preparing for 0.7
<br>Date: Mon, 18 Dec 2000 04:52:23 -0800
<br>From: pa...@rc... (David Paschal)
<br>Reply-To: hpo...@li...
<br>To: hpo...@li...
<br>CC: pa...@rc...
<p>Joe Piolunek wrote:
<br>> You mentioned in the README that some security issues need to be
<br>> addressed. If you can make it secure enough, then by all means
add it
<br>> to the next release.
<p>Hi, Joe. I decided to go ahead and add ptal-printd, because in
my experience
<br>printing with hpoj has been a support nightmare without it. :-)
<p>I committed ptal-printd to CVS and rewrote large portions of PRINT-HOWTO.
<br>The command-line syntax of ptal-printd has changed, and I think I've
fixed
<br>the security issues to my liking now. Please try it out and let
me know
<br>ASAP if there are any remaining problems.
<p>On a different matter, I did manage to reproduce the xojpanel "no-start"
<br>problem, with 64 failures in 500 tries, but I haven't yet gotten down
to
<br>root cause. I'll put that down as a TODO for 0.8. :-)
<p>David
<p> ------------------------------------------------------------------------
<p>Subject: [hpoj-devel] 2.2.18 + hpoj0.6 + patch + SMP
<br>Date: Mon, 18 Dec 2000 19:54:38 +0200
<br>From: Dag Nygren <da...@ne...>
<br>Reply-To: hpo...@li...
<br>To: hpo...@li...
<p>Hi,
<p>just installed 2.2.18 here on my SMP machine.
<p>Added hpoj 0.6 + the patch recommended for SMP
<br>on the HpOj web-page.
<p>Some feedback:
<p>1. Scanning is awfully slow
<br>2. Printing worked until I used the ieee12844_print when the
<br> driver froze . It didn't crash the system as when I tested
the
<br> hpoj package (version 0.3) last time though. . :-)
<br>3. The scanned colors seem to be very far from the "real" colors
<br> especially green, which is more dark blue than green.
<p>BRGDS and thanks for patching up HP:s disability to make a Linux
driver
<p>--
<br>Dag Nygren
email: da...@ne...
<br>Oy NewTech Ab
phone: +358 9 8024910
<br>Trasktorpet 3
fax: +358 9 8024916
<br>02360 ESBO
GSM: 0400-426312
<br>FINLAND
<p> ------------------------------------------------------------------------
<br>_______________________________________________
<br>hpoj-devel mailing list
<br>hpo...@li...
<br><a href="http://lists.sourceforge.net/mailman/listinfo/hpoj-devel">http://lists.sourceforge.net/mailman/listinfo/hpoj-devel</a></blockquote>
</html>
|
|
From: PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> - 2000-12-19 00:59:58
|
Hi, Joe. Joe Piolunek wrote: > This release looks like it will be a genuine improvement over > the last one. > Installation and use should be a lot easier. Thanks! I'm glad you like it. Normally I prefer to avoid major last-minute changes like this, but under the circumstances I think it's justified. > When using the recommended options, the security of the pipe > is a lot better. > Logged in as a user, I couldn't send it data directly, but > had to go through > lpr. Good. There were two problems I was trying to prevent by tightening up the permissions on the pipe: arbitrary users' connecting directly to the pipe and dumping extra data to the pipe while somebody else is printing through lpd (thereby mangling the job), and arbitrary users' reading from the pipe and snooping on other users' print jobs. (I'm not sure how Unix named pipes handle the cases of multiple readers or multiple writers.) > Is there any reason for ptal-printd to be started by an > ordinary user? If > not, you may want to install ptal-printd with its permissions > set at 744, the > same as lpd. After installation, I tightened up the > permissions and rebooted. > Everything still works. Is there any reason for ptal-printd not to be started by an ordinary user? It probably won't be useful to most people, but I found it handy while I was developing it. In any case, the normal Unix protection mechanisms should prevent a non-root user from doing anything dangerous with ptal-printd, and the "-pipepath" option lets one specify a different directory from the default of /dev/ptal-printd. Similarly, lpd is prevented from binding to port 515 or writing to /var/spool/lpd when not run by root. I think the only reason not to give world-execute permission would be to reduce confusion for users who inadvertently start it. Malicious users can always build and run their own copy. After all, people can still run ieee12844_print or ptal-connect, which is essentially what ptal-printd does, just in a more useful way. > I got an unexpected result when trying to start ptal-printd > without options > from the command line (as a user). When I used the command > 'ptal-printd &' > the options list was displayed, but the prompt didn't come > back until I typed > ^C. I think this is a feature of bash, not a bug in ptal-printd. When I do this on my system, I get the line showing the job number and process ID followed by a shell prompt, followed by the output from ptal-printd. If you press Enter again you should see a message indicating that the process exited followed by another prompt, just as you saw when you pressed ^C. When I do this multiple times, sometimes the prompt is before the output and sometimes it's afterwards, depending on whether the shell or ptal-printd gets more CPU time. On the other hand, tcsh does this as soon as a background process exits without waiting for you to press Enter. > You may want to add a warning somewhere to not run two > instances of xojpanel > or keep it running while starting a second print job. If I > forget to kill > xojpanel first, ptal-printd dies and won't run again until > xojpanel is also > killed from the command line. That's likely to be a common > annoyance for > users, unless they just decide not to use xojpanel. OK, I'll try to make this clearer. However, I would like to position the "Bugs and TODO" web page to be the official source for this information, since that's the most up-to-date resource, particularly for bugs found after a release or bugs that have patches or workarounds. > I noticed a couple of typos close together in the > PRINT-HOWTO, so I ran the > spellchecker on it. I found a total of only about 3 or 4 > spell/typo errors, > (pretty good for most people). To save you some time, I made > a patch that's > attached below. Thanks! I'm surprised there weren't more typos. It was four in the morning when I wrote that and I was half asleep. :-) I don't agree that "inter-operable" has to be hyphenated, but I changed it anyway to keep spell(1) happy. > Those results are worse than mine. The no-start problem > *itself* isn't a big > one, since it's easy to click again on the icon. Many users > may not even > notice it. In case it happens to affect something else > though, it's better to > find it (and fix if possible) IMHO. I hope it does get fixed > sometime before > 0.8. I'll try to find time to look into it further in the next couple of days, or in the near future at least, but I need to get 0.7 out before the upcoming holidays get in the way. David |
|
From: PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> - 2000-12-19 00:35:26
|
Dag Nygren wrote: > No message at all - well not completely true.. I do have a > message about > a failed autoload of char-major-99. Didn't find the reason > for that though. Strange. I don't know what that is, but it could possibly be lp (which shouldn't be used at the same time anyway). Type "lsmod" to see what kernel modules are loaded at the time. > I don't think I ran anything else, but I will check more > carefully later on. > xojpanel doesn't work with the 1150C I have , so that was not it. > But SANE migth have still been there.... If SANE was still running, then that could definitely cause a problem. > Reading the stuff in the 0.6 disti I just noticed that I > really shouldn't > use ieee12844_print but ptal_print instead (?) I will try that. In 0.6 I wasn't really trying to discourage people from using ieee12844_print, but I am trying to move more in the direction of applications such as ptal-print, which use the new PTAL library. In any case, ieee12844_print vs ptal-print should make no difference in causing or preventing a kernel driver lockup. You could also try the new "ptal-printd" daemon which is now in CVS and will be in 0.7 (which should be out in a day or two). Again, it won't prevent driver lockups, but it makes setting up print queues much easier. > Am I right assuming that the fact that scanning works means that > irq and dma from/to the port works ? Cat'ing /proc/dma doesn't include > the DMA channel I am using ? All of the parallel port signalling is handled by software polling. Interrupts and DMA are not used. David |
|
From: Joe P. <joe...@sn...> - 2000-12-18 21:38:01
|
On Monday 18 December 2000 07:52, David Paschal wrote: <...> > Hi, Joe. I decided to go ahead and add ptal-printd, because in my > experience printing with hpoj has been a support nightmare without it. :-) > This release looks like it will be a genuine improvement over the last one. Installation and use should be a lot easier. > I committed ptal-printd to CVS and rewrote large portions of PRINT-HOWTO. > The command-line syntax of ptal-printd has changed, and I think I've fixed > the security issues to my liking now. Please try it out and let me know > ASAP if there are any remaining problems. When using the recommended options, the security of the pipe is a lot better. Logged in as a user, I couldn't send it data directly, but had to go through lpr. Is there any reason for ptal-printd to be started by an ordinary user? If not, you may want to install ptal-printd with its permissions set at 744, the same as lpd. After installation, I tightened up the permissions and rebooted. Everything still works. I got an unexpected result when trying to start ptal-printd without options from the command line (as a user). When I used the command 'ptal-printd &' the options list was displayed, but the prompt didn't come back until I typed ^C. I added lines to /etc/rc.d/rc.local that insmod the necessary kernel modules and start ptal-printd with your recommend options. The system is able to print after a cold start without needing to do anything additional. You may want to add a warning somewhere to not run two instances of xojpanel or keep it running while starting a second print job. If I forget to kill xojpanel first, ptal-printd dies and won't run again until xojpanel is also killed from the command line. That's likely to be a common annoyance for users, unless they just decide not to use xojpanel. I noticed a couple of typos close together in the PRINT-HOWTO, so I ran the spellchecker on it. I found a total of only about 3 or 4 spell/typo errors, (pretty good for most people). To save you some time, I made a patch that's attached below. > > On a different matter, I did manage to reproduce the xojpanel "no-start" > problem, with 64 failures in 500 tries, but I haven't yet gotten down to > root cause. I'll put that down as a TODO for 0.8. :-) > Those results are worse than mine. The no-start problem *itself* isn't a big one, since it's easy to click again on the icon. Many users may not even notice it. In case it happens to affect something else though, it's better to find it (and fix if possible) IMHO. I hope it does get fixed sometime before 0.8. -- Joe |
|
From: Dag N. <da...@ne...> - 2000-12-18 21:12:02
|
> Hi, Dag. > > > 1. Scanning is awfully slow > We've noticed that scanning is slower on SMP and/or 2.4 than non-SMP 2.2, > but we don't yet know why. OK, hope you find out. It is still usable but.... > > 2. Printing worked until I used the ieee12844_print when the > > driver froze . It didn't crash the system as when I tested the > > hpoj package (version 0.3) last time though. . :-) > Please look in /var/log/messages. Do you see messages such as "mlcpp0: > mlcpp_transmit while TX busy"? This problem has been reported with 2.2.16 > and not (yet) with other versions, so it's good to know if this is the same > problem on a different kernel version. No message at all - well not completely true.. I do have a message about a failed autoload of char-major-99. Didn't find the reason for that though. > On the other hand, if you are printing while running another application > that uses hpoj, such as SANE or xojpanel, then this is a different known > problem which will be fixed eventually, but for now, the workaround is to > only run one thing at a time. I don't think I ran anything else, but I will check more carefully later on. xojpanel doesn't work with the 1150C I have , so that was not it. But SANE migth have still been there.... Reading the stuff in the 0.6 disti I just noticed that I really shouldn't use ieee12844_print but ptal_print instead (?) I will try that. Am I right assuming that the fact that scanning works means that irq and dma from/to the port works ? Cat'ing /proc/dma doesn't include the DMA channel I am using ? > > 3. The scanned colors seem to be very far from the "real" colors > > especially green, which is more dark blue than green. > Which model are you using? Scanning is not an exact science, and sometimes > color correction is necessary. xscanimage, xsane, and GIMP all have various > mechanisms for color correction. As said above. the model is a 1150C. Yep, I figured that from the previous postings on this list, but I thought it was more a matter of the printing process. (Whish I still have to do something about) Dag |
|
From: PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> - 2000-12-18 20:05:07
|
Hi, Dag. Dag Nygren wrote: > just installed 2.2.18 here on my SMP machine. > > Added hpoj 0.6 + the patch recommended for SMP > on the HpOj web-page. > > Some feedback: > > 1. Scanning is awfully slow We've noticed that scanning is slower on SMP and/or 2.4 than non-SMP 2.2, but we don't yet know why. > 2. Printing worked until I used the ieee12844_print when the > driver froze . It didn't crash the system as when I tested the > hpoj package (version 0.3) last time though. . :-) Please look in /var/log/messages. Do you see messages such as "mlcpp0: mlcpp_transmit while TX busy"? This problem has been reported with 2.2.16 and not (yet) with other versions, so it's good to know if this is the same problem on a different kernel version. On the other hand, if you are printing while running another application that uses hpoj, such as SANE or xojpanel, then this is a different known problem which will be fixed eventually, but for now, the workaround is to only run one thing at a time. > 3. The scanned colors seem to be very far from the "real" colors > especially green, which is more dark blue than green. Which model are you using? Scanning is not an exact science, and sometimes color correction is necessary. xscanimage, xsane, and GIMP all have various mechanisms for color correction. David |
|
From: Dag N. <da...@ne...> - 2000-12-18 17:54:41
|
Hi,
just installed 2.2.18 here on my SMP machine.
Added hpoj 0.6 + the patch recommended for SMP
on the HpOj web-page.
Some feedback:
1. Scanning is awfully slow
2. Printing worked until I used the ieee12844_print when the
driver froze . It didn't crash the system as when I tested the
hpoj package (version 0.3) last time though. . :-)
3. The scanned colors seem to be very far from the "real" colors
especially green, which is more dark blue than green.
BRGDS and thanks for patching up HP:s disability to make a Linux driver
--
Dag Nygren email: da...@ne...
Oy NewTech Ab phone: +358 9 8024910
Trasktorpet 3 fax: +358 9 8024916
02360 ESBO GSM: 0400-426312
FINLAND
|
|
From: <pa...@rc...> - 2000-12-18 12:48:29
|
Joe Piolunek wrote: > You mentioned in the README that some security issues need to be > addressed. If you can make it secure enough, then by all means add it > to the next release. Hi, Joe. I decided to go ahead and add ptal-printd, because in my experience printing with hpoj has been a support nightmare without it. :-) I committed ptal-printd to CVS and rewrote large portions of PRINT-HOWTO. The command-line syntax of ptal-printd has changed, and I think I've fixed the security issues to my liking now. Please try it out and let me know ASAP if there are any remaining problems. On a different matter, I did manage to reproduce the xojpanel "no-start" problem, with 64 failures in 500 tries, but I haven't yet gotten down to root cause. I'll put that down as a TODO for 0.8. :-) David |
|
From: PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> - 2000-12-15 02:12:19
|
Hi, Joe. Thanks for your feedback on ptal-printd. Joe Piolunek wrote: > The daemon is indeed very easy to set up and use. It looks > like you're headed > in the right direction with this. Maybe it could become the > solution to many > of the problems we've been having. Are you planning to > eventually use it as a > printer control/communication device? Offhand I can't think of other uses for this concept of using a named pipe to simulate a character device, but if something comes up where it makes sense then I'll consider using it. At one point I had considered making all of the peripheral's services (such as scan, PML, fax send, fax receive) available this way, but I decided it was overkill, since that is what PTAL is for. Of course, the only reason ptal-printd was necessary in the first place is that lpd and friends don't like to talk to anything other than a file. Another "problem" limiting the usefulness of this named pipe scheme is that it doesn't permit bidirectional data flow. Originally I was going to use a Unix-domain socket (which also involves the creation of a special file), but I discovered the hard way that clients can't just open() the file and start write()ing data to it the way one can with a character device or named pipe. In addition to sacrificing bidirectionality, use of named pipes means that ptal-printd can't reliably detect job boundaries for back-to-back jobs for purposes of wrapping each job with UELs (Esc%-12345X) the same way ieee12844_print does. This shouldn't be a problem as long as the filter is configured to add its own end-of-job indicator (EscE), and ptal-printd should notice when the string of jobs is over and send the UEL then. That said, I do want to move more in the direction of user-mode daemons as opposed to kernel-mode drivers to handle the background infrastructure of all-in-one support. In addition to the I/O driver, this could include things like a gateway that forwards received faxes to e-mail, a daemon that waits for and handles a color copy request from the front panel (since the older OfficeJets can't do this standalone), and maybe something that keeps the time in sync. Of course, device control that requires user input would still need to be handled by a foreground application, such as the fancy xojpanel replacement we talked about a while back. > You mentioned in the README that some security issues need to > be addressed. > If you can make it secure enough, then by all means add it to > the next > release. The main security issue I can think of is that there essentially is no access control over which users get to write to the pipe, as opposed to /dev/lpX, which on my system at least is readable and writeable by user root and group daemon, and inaccessible by anyone else. Of course, I wouldn't say that the rest of hpoj is inherently secure, since anybody can access whatever service they want to on the peripheral, so maybe this isn't such a big deal after all. There shouldn't be any danger in buffer overflows or format string vulnerabilities, since all ptal-printd does is relay received data in the same buffer. So you'd probably be OK to start it at boot time, or at least you wouldn't be any worse off than if you started it from the command line. > I printed several pages without trouble. The only problem > encountered so far > was the old one that occurs when xojpanel is running when a > second print job > is requested. Could ptal-printd eventually fix that, if for instance, > xojpanel (or a replacement control GUI) talks to the daemon > instead of the > printer directly? No, that's a driver-level issue (ieee12844.c), which I plan to fix in the future user-mode driver implementation I mentioned earlier. I'm a little afraid to make a lot of changes right now to the kernel drivers due to the risk of breaking things in an environment (kernel mode) of which I have dangerously little knowledge. :-) Of course, I did make a lot of changes to the parallel port signalling in ieee12844pp.c, but I didn't really alter the control flow and interaction with the kernel very much. David |
|
From: Joe P. <joe...@sn...> - 2000-12-14 23:47:42
|
On Thursday 14 December 2000 07:28, David Paschal wrote: > Hi, > > I just posted an experimental daemon that makes it much easier to set up > printing with the hpoj package, by eliminating the need for the > "wrapfilter" hack we all know and love. :-) You can get it from > http://hpoj.sourceforge.net/download.shtml (near the bottom of the page). > Please see the README file in the package for more information. > > I look forward to hearing what people think about this concept. I think > I will leave this out of 0.7 since it's so new and experimental, but I > could be convinced otherwise if people like it well enough and any problems > with it can be fixed in the next couple of days. :-) > > David David: This is good news. The daemon is indeed very easy to set up and use. It looks like you're headed in the right direction with this. Maybe it could become the solution to many of the problems we've been having. Are you planning to eventually use it as a printer control/communication device? You mentioned in the README that some security issues need to be addressed. If you can make it secure enough, then by all means add it to the next release. Here is my experience with ptal-printd so far: It compiled with no warnings or other problems. I will probably set it up to start at boot after you're more certain of its security, but so far, I only ran it from the command line. I printed several pages without trouble. The only problem encountered so far was the old one that occurs when xojpanel is running when a second print job is requested. Could ptal-printd eventually fix that, if for instance, xojpanel (or a replacement control GUI) talks to the daemon instead of the printer directly? -- Joe |
|
From: <pa...@rc...> - 2000-12-14 12:24:41
|
Hi, I just posted an experimental daemon that makes it much easier to set up printing with the hpoj package, by eliminating the need for the "wrapfilter" hack we all know and love. :-) You can get it from http://hpoj.sourceforge.net/download.shtml (near the bottom of the page). Please see the README file in the package for more information. I look forward to hearing what people think about this concept. I think I will leave this out of 0.7 since it's so new and experimental, but I could be convinced otherwise if people like it well enough and any problems with it can be fixed in the next couple of days. :-) David |
|
From: Robert G. B. <rg...@ph...> - 2000-12-13 11:55:40
|
On Tue, 12 Dec 2000, PASCHAL,DAVID (HP-Roseville,ex1) wrote: > Hi. I upgraded a spare PC to SMP and installed RedHat 7 and wanted to share > my experiences with it. > > Once I got them set up, printing and scanning seemed to work, although they > seemed slower on SMP. So far I haven't been able to reproduce Robert's SMP > printing problem, but I was only printing RedHat's ASCII and PostScript test > pages. I did have one locked up print job, but I think that was because I > had a scan session open at the same time, which is a different bug. > > However, I had a hard time getting printing set up initially. RedHat 7 > includes "LPRng" as opposed to "lpr". For some reason, every time I > restarted lpd, it reset the ownership and permissions on the wrapfilter > script in the spool directory, making it non-executable. The original > filter script was not affected, however. Finally I had to just move > wrapfilter somewhere else, like /usr/local/bin, to make it work reliably. > Of course, if I set up multiple queues like this, then I would have to give > different names to each of the wrapfilter scripts. > > Has anybody else run into this problem with RedHat 7, or is there a better > solution to prevent this problem (which appears to be a "security > precaution" that goes too far)? I will update PRINT-HOWTO with this > information. I've had no such problem with RH 6.2. I'm about 2/3 of the way through with grading, but I'm not sure I'll get the 2.2.17smp issue resolved by Friday. The other observation is that smp failure seems to be an issue of probability (opportunity) and overall system activity. Short print jobs (defined in terms of the length of the messages sent, not how long it takes to print them) aren't very likely to cause failure. Try printing large jpegs under varying conditions of CPU load. rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rg...@ph... |
|
From: PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> - 2000-12-13 05:16:17
|
Hi. I upgraded a spare PC to SMP and installed RedHat 7 and wanted to share my experiences with it. Once I got them set up, printing and scanning seemed to work, although they seemed slower on SMP. So far I haven't been able to reproduce Robert's SMP printing problem, but I was only printing RedHat's ASCII and PostScript test pages. I did have one locked up print job, but I think that was because I had a scan session open at the same time, which is a different bug. However, I had a hard time getting printing set up initially. RedHat 7 includes "LPRng" as opposed to "lpr". For some reason, every time I restarted lpd, it reset the ownership and permissions on the wrapfilter script in the spool directory, making it non-executable. The original filter script was not affected, however. Finally I had to just move wrapfilter somewhere else, like /usr/local/bin, to make it work reliably. Of course, if I set up multiple queues like this, then I would have to give different names to each of the wrapfilter scripts. Has anybody else run into this problem with RedHat 7, or is there a better solution to prevent this problem (which appears to be a "security precaution" that goes too far)? I will update PRINT-HOWTO with this information. David |
|
From: Cyrus R. <cy...@er...> - 2000-12-12 18:10:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <499...@xr...>, PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> writes >Hi, Cyrus. modversions.h may get generated when building a custom kernel. >Off the top of my head I don't know what purpose is served by including this >file. Try removing lines that include it and see what happens. I'll try what you have suggested when I boot into Linux. Thanks for your help. Regards, Cyrus > >David > >> -----Original Message----- >> From: Cyrus Razavi [mailto:c....@us...] >> Sent: Saturday, December 09, 2000 6:19 AM >> To: dav...@hp... >> Subject: can't compile officejet drivers >> >> >> David, >> >> I am trying to get my HP OfficeJet G85 to work under Linux. I >> have donwloaded >> the drivers from your site, but I get the following error: >> >> cyrus@era-cadcam:~/hpoj-0.6$ make >> ptal >> make[1]: Entering directory `/home/cyrus/hpoj-0.6/ptal' >> make[1]: Nothing to be done for `release'. >> make[1]: Leaving directory `/home/cyrus/hpoj-0.6/ptal' >> ieee12844 >> make[1]: Entering directory `/home/cyrus/hpoj-0.6/ieee12844' >> gcc -O -I/home/cyrus/hpoj-0.6/include -I/home/cyrus/hpoj-0.6/ptal >> -I/usr/src/linux/include -Wall -Wstrict-prototypes >> -D__KERNEL__ -DMODULE >> -DEXPORT_SYMTAB -c ieee12844pp.c >> ieee12844pp.c:48: linux/modversions.h: No such file or directory >> make[1]: *** [ieee12844pp.o] Error 1 >> make[1]: Leaving directory `/home/cyrus/hpoj-0.6/ieee12844' >> make: *** [release] Error 2 >> cyrus@era-cadcam:~/hpoj-0.6$ >> >> What is the modversions.h that it is looking for? I am >> running a slimline >> install of debian potato and I have installed the Linux >> kernel 2.2.17 source >> in /usr/src/linux. >> >> I would appreciate if you would reply to cy...@er... >> rather than the >> reply-to address specified in the header. >> >> Thanks in advance for your help, >> >> Cyrus Razavi >> >> >> ____________________________________________________________________ >> Get free email and a permanent address at >http://www.netaddress.com/?N=1 - -- ~c -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBOjZpOw14OxsXslqwEQLM8ACgkIpvsG805DI8CjrnhJHoQUhWDM4AoKWI N14sm24bFOO2huBm+G6LyBhB =FVv4 -----END PGP SIGNATURE----- |
|
From: <pa...@rc...> - 2000-12-12 09:33:13
|
Zot O'Connor wrote: > I just got my T45xi working with the command line. Mandrake 7.2 likes > cups a bit more than lpr (as does a fair number of folks apparently). I > am new to cups. Can I use the lpr driver in CUPS, or does the office > jet driver work only with lpr? > > Thanks, so far its worked great (in testing that is :) Hi, Zot. I'm CCing this to hpoj-devel, because somebody else might be able to help you more than I can. I've never used CUPS, so unfortunately I can't give you a definitive answer. If you can somehow trick CUPS into running a command where the print job data is on standard input, then you should be able to do something similar to what most people do with LPD. There is a new and improved version of PRINT-HOWTO which will go into 0.7 soon, but you can get it now from CVS (or by browsing CVS on the web). On the other hand, if CUPS can only print to a device file, then you might be in for a bit of a challenge. I recently came up with an idea that should make printing setup much easier and more generic, and I was going to try to post a prototype to hpoj-devel within the next week. Basically it involves writing a daemon that simulates a "/dev/XXX" file using a socket special file and redirects print job data to the right place. Stay tuned, and you might want to subscribe to hpoj-devel if you aren't already. :-) David |
|
From: <pa...@rc...> - 2000-12-12 09:20:14
|
Hi, Joe. I looked at the debug log you sent me, but I didn't see anything out of the ordinary. I was looking for a line that said "mlcpp_intr ERROR" (with some stuff before and afterwards), and one should see that even if debug messages are turned off. Joe Piolunek wrote: > I rebuilt xojpanel with sleep(6); between the calls that retrieve the > LCD messages. My script then started/killed it with 'sleep 12' > between the execute and kill commands. It still failed to start 9 > times out of 250. That was without any extra ieee12844pp.o options. Could you forward me this script? It's possible that I could duplicate this myself given a large enough sample size. Now that I think about it, I seem to recall having intermittent trouble like this, although I think I had to reload the drivers to make it work. > > I'm not sure why you couldn't add a delay between lines 1 and 2. Did you > > try calling sleep(5 seconds or whatever) in between the two line requests > > in getPrinterLCDMessages? > We might have been having a misunderstanding. Maybe it was only me. > > The sleep() call did cause a delay when I finally tried to introduce one. It > didn't prevent the no-start problem though. This delay was in the context of my question about what happens if the poll timer pops more often than the peripheral is able to keep up, not about the "no start" issue. (regarding the latest CVS code) > The xojpanel "start failures" still occur. I tried connecting the > OfficeJet to the MB-based port instead of the IO card, but there was > no improvement. Rebooting or reinserting the ieee12844 modules has no > effect either. I'm not surprised, since I didn't change anything that would have fixed it. I'll try to look into it this week, but I need to release 0.7 by the beginning of next week or I won't have another chance until January. > The cause of the problem seems to have been introduced after hpoj-0.5. > As a test, I inserted the ieee12844 modules from the 0.5 release. The > no-start problem then disappeared. In /var/log/messages (using > debug=1), lines containing "Got device ID string" are definitely > related to the problem. One such message occurs for each failure to > execute. So you're saying you see this problem even in 0.6, but never in 0.5? That is good to know, since it narrows down the culprit. The only kernel-level change I made in 0.6 that I can think of that could cause a problem is the "udelay(RESET_DELAY)" calls I added to ieee12844pp.c to make the LaserJet 1100A work. You could try commenting them out of s_resetting() and see if that makes the problem go away. David |
28 messages has been excluded from this view by a project administrator.
