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: Bill W. <wo...@ne...> - 2001-05-31 17:22:17
|
"Soren Andersen" <so...@wo...> writes:
> Bob Paddock wrote:
> > Your next problem is figuring out your print ques. LPD or CUPS?
> > I spent almost a sold week reading documentation before getting this stuff
> to
> > work.
>
> Only one week!?! ;-) It seems that i started reading about CUPS and all at
> least 3 weeks ago ;-).
Funny that this very same thing was discussed on debian-user a
couple of weeks ago. I got (network) printing working yesterday in
about 5 minutes. Here's the magic fairy dust:
http://localhost:631/admin/
This is documented in:
http://localhost:631/sam.html#4_2
There's an additional package called cupsomatic-ppd with some
additional PostScript Printer Descriptions.
--
Bill Wohler <wo...@ne...> http://www.newt.com/wohler/ GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.
|
|
From: Obi-Wan <bv...@in...> - 2001-05-31 16:47:53
|
>> Both ptal-mcld and ptal-print dump copious amounts of debugging info
>> to the shell, even with the stock install (./configure --without-usb).
>
> Is there any reason why you used the "--without-usb" switch? There's nothing
> wrong with using it, of course, but if you found a build problem that needs
> it as a workaround then I'd like to fix it.
My old box doesn't have USB support. I conjectured that using that flag
might make my compiles faster and/or my binary smaller.
BTW, for you Debian types out there, I had to make one little hack to
make hpoj recognize the QT stuff. The deb for QT puts the includes
in /usr/include/qt (not a bad idea, since there are dozens of them),
but the libs & binaries in /usr/lib & /usr/bin. The hpoj configure
script expects all three subdirs to be under the same parent dir. I
had to create a new directory named /usr/qt and inside that create
symlinks to /usr/bin, /usr/lib, and /usr/include/qt for the bin, lib,
and include subdirs, respectively. The stock hpoj configure script
now finds /usr/qt all on its own, and compiles in support for it.
# mkdir /usr/qt
# cd /usr/qt
# ln -s /usr/bin
# ln -s /usr/lib
# ln -s /usr/include/qt include
>> So much so that it overflowed my scrollback buffer. Before I send
>> thousands of lines of useless stuff to the list, is there anything
>> in particular that you'd like to see?
>
> Well, not knowing what's on the menu, it's hard to know what to order. :-)
> For starters, you could run the "script" command and invoke ptal-mlcd and
> ptal-printd (after making sure any old instances are killed off). Then try
> printing something that causes the error messages to spew. Once it has
> quieted down, you can exit the shell spawned by script and send the
> resulting "typescript" file. If it's really big you can send it just to me
> (both to dav...@hp... and pa...@rc...), but other than that we
> can keep this discussion on the mailing list.
I had the foresight to leave my PSC 500 on when I came to work today,
so I tried to scan something just now. I was fiddling with rc scripts,
so I killed & restarted ptal-mlcd & ptal-printd numerous times this
morning. Here's what's currently running:
> psg ptal
root 12720 0.0 2.4 1768 740 pts/15 S 11:18 0:00 /usr/local/sbin/ptal-mlcd par:psc500 -alias mlcpp0
root 12722 0.0 1.2 1244 392 pts/15 S 11:18 0:00 /usr/local/sbin/ptal-printd mlc:par:psc500 -like /dev/lp0
I redirected output to a log file when I launched them. When I run
scanimage -d hp:mlc:par:psc500 --test
I get this to stdout from scanimage:
> scanimage -d hp:mlc:par:psc500 --test
ptalChannelOpen(chan=0x08054678): provider failed open!
ptalChannelOpen(chan=0x08054678): provider failed open!
scanimage: open of device hp:mlc:par:psc500 failed: Error during device I/O
and this in the ptal-mlcd log file:
---------
ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<par:psc500>, pid=12720, errno=11
Reply timer popped on port=0, count=1!
ptal-mlcd: ERROR at ExMgr.cpp:872, dev=<par:psc500>, pid=12720, errno=11
exClose(reason=0x3002)
---------
Curiously, ptal-devid also fails now. It worked last night:
> ptal-devid mlc:par:psc500
ptalMlcDeviceGetDeviceIDString(dev=par:psc500): unsuccessful status=13!
ptalDeviceGetDeviceIDString(dev=mlc:par:psc500) failed!
The same errors are dumped to the ptal-mlcd log file.
I can't power cycle my PSC or restart my computer remotely (won't boot
automatically at the moment), so who knows what state either of them
is really in right now. I'll try more from home some evening soon.
--
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
|
|
From: Allen B. <ba...@lo...> - 2001-05-31 14:38:58
|
David Paschal wrote: > > Specifically, I added a "-hotplug" switch, which tells ptal-mlcd to > "activate" (establish communication with the peripheral) right away at > startup, and to attempt to re-activate after a deactivation (loss of > communication with the peripheral, which could be caused by an unplug or > power-down of the peripheral or by a protocol error). If an activation > or re-activation ever fails (presumably due to an unplug or power-down), > then ptal-mlcd exits. I tried unplugging and replugging my USB cable a few times and it seems to work OK. (Subject to my USB hardware performing properly; I'm afraid my 3 year old DELL Dimension is wearing out.) The only problem I have with this setup is that my hotplug script starts both ptal-mlcd and ptal-printd, but only ptal-mlcd exits automatically. So, each replug starts another ptal-printd. Would it be possible for ptal-printd to receive notification from ptal-mlcd that ptal-mlcd is shutting itself down? > I also haven't yet fixed the bug related to the lack of standard > input/output/error file descriptors when run from a hotplug script, so > the "</dev/null" workaround is still necessary. Would it be practical to add a SYSLOG output option to your utilities? On another subject altogether: should 'ptal-hp scan' work with the G85? I get the error message: Scan upload state is 2 (i=11)! Thanks, Allen |
|
From: <pa...@rc...> - 2001-05-31 09:00:56
|
Ben "Obi-Wan" Hollingsworth wrote: > Well, I grabbed the CVS tree at about 5pm CDT Wednesday and installed it. > Scanning now works great. Printing doesn't work at all, using either > /dev/lp0 or /dev/ptal-printd/mlc_par_psc500. :-( > > Given the choice, I'd prefer to have a printer. Hang in there, Ben. There's got to be a way to get both working. :-) > Both ptal-mcld and ptal-print dump copious amounts of debugging info > to the shell, even with the stock install (./configure --without-usb). Is there any reason why you used the "--without-usb" switch? There's nothing wrong with using it, of course, but if you found a build problem that needs it as a workaround then I'd like to fix it. > So much so that it overflowed my scrollback buffer. Before I send > thousands of lines of useless stuff to the list, is there anything > in particular that you'd like to see? Well, not knowing what's on the menu, it's hard to know what to order. :-) For starters, you could run the "script" command and invoke ptal-mlcd and ptal-printd (after making sure any old instances are killed off). Then try printing something that causes the error messages to spew. Once it has quieted down, you can exit the shell spawned by script and send the resulting "typescript" file. If it's really big you can send it just to me (both to dav...@hp... and pa...@rc...), but other than that we can keep this discussion on the mailing list. David |
|
From: <pa...@rc...> - 2001-05-31 08:44:38
|
Hi, I just checked in some changes to ptal-mlcd that should hopefully make it work better when invoked from USB hotplug scripts. I would appreciate any feedback on these changes, particularly from you "hotpluggers" out there. :-) Specifically, I added a "-hotplug" switch, which tells ptal-mlcd to "activate" (establish communication with the peripheral) right away at startup, and to attempt to re-activate after a deactivation (loss of communication with the peripheral, which could be caused by an unplug or power-down of the peripheral or by a protocol error). If an activation or re-activation ever fails (presumably due to an unplug or power-down), then ptal-mlcd exits. WARNING: I crashed my computer several times while developing this feature. I'm not 100% sure, but it appeared to happen when trying to re-open /dev/usb/lpX too soon after the deactivation while the kernel was still handling the unplug event. I added a 1-second delay before the re-open when using the "-hotplug" switch, and that seemed to make the problem go away. However, it would be a good idea to save your work and sync your disks when playing around with this feature, just in case. Of course, due diligence is always in order when testing pre-release software such as this, as Joe Piolunek so eloquently pointed out recently. :-) Another potential problem here is that if you unplug and replug too quickly (more quickly than 1-2 seconds), you might end up with two instances of ptal-mlcd trying to use the same Unix-domain socket and USB device node, and chances are that they'll break each other. I added this to my TODO list to revisit. I also haven't yet fixed the bug related to the lack of standard input/output/error file descriptors when run from a hotplug script, so the "</dev/null" workaround is still necessary. David |
|
From: Obi-Wan <bv...@in...> - 2001-05-31 08:29:48
|
> Hi, "Obi-Wan". :-) Since you're running "unstable" Debian, then perhaps
> you should try "unstable" hpoj from CVS. It has a new user-mode I/O driver
> (ptal-mlcd), which I expect will either work better or at least will provide
> better diagnostics.
Well, I grabbed the CVS tree at about 5pm CDT Wednesday and installed it.
Scanning now works great. Printing doesn't work at all, using either
/dev/lp0 or /dev/ptal-printd/mlc_par_psc500. :-(
Given the choice, I'd prefer to have a printer.
Both ptal-mcld and ptal-print dump copious amounts of debugging info
to the shell, even with the stock install (./configure --without-usb).
So much so that it overflowed my scrollback buffer. Before I send
thousands of lines of useless stuff to the list, is there anything
in particular that you'd like to see?
--
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
|
|
From: <pa...@rc...> - 2001-05-30 23:11:58
|
Ben "Obi-Wan" Hollingsworth wrote in response to me:
> > Note that once you have the hpoj software running, you should print to
> > /dev/ptal-printd/XXXXXX ("XXXXXX" varies between hpoj-0.7 and hpoj-CVS)
> > instead of /dev/lp0.
>
> Uh... OK. Why?
Because /dev/lp0 goes directly to the parallel port, bypassing (and probably
conflicting with) ptal-mlcd, which is also trying to drive the parallel port.
The "ptal-printd" daemon, mentioned in PRINT-HOWTO, provides a similar
interface to /dev/lp0, although with a different path, and routes the print
job data through ptal-mlcd.
David
|
|
From: Obi-Wan <bv...@in...> - 2001-05-30 23:00:47
|
> Hi, "Obi-Wan". :-) Since you're running "unstable" Debian, then perhaps
> you should try "unstable" hpoj from CVS. It has a new user-mode I/O driver
> (ptal-mlcd), which I expect will either work better or at least will provide
> better diagnostics.
I'll give that a shot in upcoming days.
> Note that once you have the hpoj software running, you should print to
> /dev/ptal-printd/XXXXXX ("XXXXXX" varies between hpoj-0.7 and hpoj-CVS)
> instead of /dev/lp0.
Uh... OK. Why?
--
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
|
|
From: <pa...@rc...> - 2001-05-30 20:17:24
|
Ben "Obi-Wan" Hollingsworth wrote:
> Printing to /dev/lp0.
>
> There are a number of related entries in a number of different log
> files, but I was messing with the config all night, and this was a
> few days ago, so I don't remember which messages apply to my current
> configuration. I'll try it again tonight (hopefully) and see what
> the logs turn up.
>
> This is a Debian 2.2 (unstable) distribution, BTW.
Hi, "Obi-Wan". :-) Since you're running "unstable" Debian, then perhaps
you should try "unstable" hpoj from CVS. It has a new user-mode I/O driver
(ptal-mlcd), which I expect will either work better or at least will provide
better diagnostics.
Note that once you have the hpoj software running, you should print to
/dev/ptal-printd/XXXXXX ("XXXXXX" varies between hpoj-0.7 and hpoj-CVS)
instead of /dev/lp0.
> I would also like to add that I think this HP/Linux co-venture for
> drivers is awesome. I bought my PSC 500 some time ago, against the
> advice of some who knew better than I, and I had been regretting it
> almost from day one because scanning didn't work & printing was crappy.
> With the new HPIJS driver, printing is now great, and I anticipate
> scanning will work equally well before long.
Thanks for your comments. I'm glad that you're now happy with your PSC 500
(pending further setup of scanning, of course).
> I wish I had the time
> to code to the project. I've got the skills, but not the time.
Even if you don't have time for coding, any testing/feedback you can give
on the development code in CVS will be extremely valuable as I prepare for
the next stable release (0.8) in the next few months.
David
|
|
From: Obi-Wan <bv...@in...> - 2001-05-30 19:59:24
|
OK, I'm on the devel list now.
>> # hpo get OID_STATUS_MSG_LINE1_PART1
>> Error 0 (system error 110) in file mlccon.c, line 263:
>> Unexpected Error, please post a bug report to hpo...@so...
>>
>> # hpo devid
>> Error 5 (system error 110) in file mlccon.c, line 93:
>> Connection to peripheral lost
> ...
>> printing works fine using lprng / DJ8xx / HPIJS,
>> so I know the device is hooked up OK.
>
> Hi, Ben. Do any error messages appear in syslog (/var/log/messages) when
> you do this? Also, when you print using the hpijs DJ8xx driver, are you
> printing to /dev/lp0 or /dev/ptal-printd/mlc_mlcpp0?
Printing to /dev/lp0.
There are a number of related entries in a number of different log
files, but I was messing with the config all night, and this was a
few days ago, so I don't remember which messages apply to my current
configuration. I'll try it again tonight (hopefully) and see what
the logs turn up.
This is a Debian 2.2 (unstable) distribution, BTW.
I would also like to add that I think this HP/Linux co-venture for
drivers is awesome. I bought my PSC 500 some time ago, against the
advice of some who knew better than I, and I had been regretting it
almost from day one because scanning didn't work & printing was crappy.
With the new HPIJS driver, printing is now great, and I anticipate
scanning will work equally well before long. I wish I had the time
to code to the project. I've got the skills, but not the time.
-- 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
|
|
From: Soren A. <so...@wo...> - 2001-05-30 19:25:01
|
Bob Paddock wrote:
> Your next problem is figuring out your print ques. LPD or CUPS?
> I spent almost a sold week reading documentation before getting this stuff
to
> work.
Only one week!?! ;-) It seems that i started reading about CUPS and all at
least 3 weeks ago ;-).
> Windows is in no danger as long as things are this hard to set up in Linux
> land.
*Printing* in Linux is definitely a non-user-friendly thing, still. But to
be fair, this specific project (hpoj) is new and being under such active
development it isn't surprising that the documentation is incomplete. On the
larger scale, tho, the LPD/CUPS decision is a PITA. Maybe in a little while
there will emerge a rough majority opinion about which standard to base many
distros on. That would be a Good Thing. It *should* be a part of basic setup
and it should be automated better.
Thanks for your input --
Soren Andersen
|
|
From: <pa...@rc...> - 2001-05-30 18:59:53
|
Ben "Obi-Wan" Hollingsworth wrote: > Per the instructions in the error message: > > # hpo get OID_STATUS_MSG_LINE1_PART1 > Error 0 (system error 110) in file mlccon.c, line 263: > Unexpected Error, please post a bug report to hpo...@so... > > # hpo devid > Error 5 (system error 110) in file mlccon.c, line 93: > Connection to peripheral lost ... > printing works fine using lprng / DJ8xx / HPIJS, > so I know the device is hooked up OK. Hi, Ben. Do any error messages appear in syslog (/var/log/messages) when you do this? Also, when you print using the hpijs DJ8xx driver, are you printing to /dev/lp0 or /dev/ptal-printd/mlc_mlcpp0? David |
|
From: PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> - 2001-05-30 01:27:17
|
Joe Piolunek wrote: > It works fine now for me as well. > > Regarding the configure script: For a while now, it has been > outputting a > slightly confusing line when the --without-snmp option is chosen: > > "checking for snmp.h... no. Try "./configure --with-snmp=<dir>"" > > It doesn't cause any problem, but would be simpler to just > not check for > snmp-related files, etc. if the user chooses --without-snmp? I suppose that would make more sense from the user's perspective. I did it the way I did to provide a more realistic simulation for what would happen if the test were enabled but the files weren't found. David |
|
From: Joe P. <joe...@sn...> - 2001-05-30 01:19:08
|
On Tuesday 29 May 2001 08:40 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote: > After testing with RedHat 7.1, it turns out I didn't quite get it right the > first time. I just checked in a new configure script that handles the > config.cache interaction, and it works fine for me now, both with and > without -lcrypto. > It works fine now for me as well. Regarding the configure script: For a while now, it has been outputting a slightly confusing line when the --without-snmp option is chosen: "checking for snmp.h... no. Try "./configure --with-snmp=<dir>"" It doesn't cause any problem, but would be simpler to just not check for snmp-related files, etc. if the user chooses --without-snmp? -- Joe |
|
From: Joe P. <joe...@sn...> - 2001-05-30 00:54:59
|
On Tuesday 29 May 2001 03:29 am, David Paschal wrote: > Hi, > > I checked in a fix to the configure script that detects newer SNMP packages > which need "-lcrypto" on the linker command line in addition to "-lsnmp". > Joe, since this was a problem for you could you verify that configure and > make work for you now? I can't accurately test this on my system at home > since I don't have libcrypto, much less a libsnmp that requires it. > > It would probably be a good idea to run "make distclean", or at least > delete the file "config.cache", before re-running the configure script. > > David A simple "./configure" will now allow the package to build on my system, but LIBSNMP_CMDLINE remains empty. Luckily I don't need it, but someone else may. Here are some of the things I tried and the results: ]$ ./configure creating cache ./config.cache checking for user-mode parallel-port support... LINUX checking for ability to include <sys/io.h> in C++ code... no checking for user-mode USB support... LINUX checking for snmp.h... /usr/include/ucd-snmp checking for snmp_open in -lsnmp... no checking for snmp_open in -lsnmp... (cached) no checking for QT... /usr/local/qt For some reason, the second "AC_CHECK_LIB(snmp,snmp_open," never gets executed, even after the first fails. At the end of configuration, LIBSNMP_CMDLINE is empty. This is echoed to the console: LIBRARY_CMDLINE = -L/home/joe/CVS/hpoj_copy/ptal -L/usr/local/qt/lib LIBSNMP_CMDLINE = QT_MOC = /usr/local/qt/bin/moc **************************** When I replace the string "snmp_open" with "nonexistent_function" in the first AC_CHECK_LIB (and run autoconf), it will fail and the second AC_CHECK_LIB is then executed: ]$ ./configure creating cache ./config.cache checking for user-mode parallel-port support... LINUX checking for ability to include <sys/io.h> in C++ code... no checking for user-mode USB support... LINUX checking for snmp.h... /usr/include/ucd-snmp checking for nonexistent_function in -lsnmp... no checking for snmp_open in -lsnmp... yes checking for QT... /usr/local/qt libcrypto is added in this case. This line is output near the end of ./configure: LIBSNMP_CMDLINE = -lsnmp -lcrypto ******************* When I replace the first "AC_CHECK_LIB(snmp,snmp_open," with "AC_CHECK_LIB(ptal,main," configure reports: checking for snmp.h... /usr/include/ucd-snmp checking for main in -lptal... yes checking for QT... /usr/local/qt It then sets LIBSNMP_CMDLINE to: LIBSNMP_CMDLINE = -lsnmp -- Joe |
|
From: PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> - 2001-05-30 00:42:11
|
After testing with RedHat 7.1, it turns out I didn't quite get it right the first time. I just checked in a new configure script that handles the config.cache interaction, and it works fine for me now, both with and without -lcrypto. David > -----Original Message----- > From: pa...@rc... [mailto:pa...@rc...] > Sent: Tuesday, May 29, 2001 12:30 AM > To: hpo...@li... > Cc: pa...@rc... > Subject: [hpoj-devel] -lsnmp and -lcrypto fix > > > Hi, > > I checked in a fix to the configure script that detects newer > SNMP packages > which need "-lcrypto" on the linker command line in addition > to "-lsnmp". > Joe, since this was a problem for you could you verify that > configure and > make work for you now? I can't accurately test this on my > system at home > since I don't have libcrypto, much less a libsnmp that requires it. > > It would probably be a good idea to run "make distclean", or > at least delete > the file "config.cache", before re-running the configure script. > > David > > > _______________________________________________ > hpoj-devel mailing list > hpo...@li... > http://lists.sourceforge.net/lists/listinfo/hpoj-devel > |
|
From: Bob P. <bpa...@cs...> - 2001-05-30 00:34:42
|
> If there is anyone who has set up the print daemon on Debian and knows what > I need to do with the /etc/init.d and all that mess (it appears that I have > to become a Deep Linux Wizard to get this set up???) could you please offer > me your recipie or advice. I have already invested so much time in this, I > would offer to write up something to add to the package documentation if my > ensuing results seem useful to recount to others. I know that felling all to well, right or wrong this is what I did, and it works for me: I put these two lines near the top of /etc/rc.d/rc.local in my Mandrake 8.0 system: /usr/local/sbin/ptal-mlcd par:hpoj -device /dev/lp0& /usr/local/sbin/ptal-printd mlc:par:hpoj -like /dev/lp0& Where I refer to my HP710 as 'hpoj', change it to what ever suites you. Your next problem is figuring out your print ques. LPD or CUPS? I spent almost a sold week reading documentation before getting this stuff to work. Windows is in no danger as long as things are this hard to set up in Linux land. |
|
From: Soren A. <so...@wo...> - 2001-05-29 23:12:28
|
Greetings List, I am a new user of the hpoj software which I built from source yesterday. Thanks for developing this software. I have used ptal-mlcd and associated utilities to demonstrate to myself that I can connect to and print simple jobs to my OfficeJet 6xx parallel-port machine. But I am struglling greatly with translating the documentation for the print daemon, which appears to be based on a RedHat installation with its bsd-style init routines (???) to a sysvinit style as used in recent Debian GNU/Linux systems. Folks on the #Debian channel at irc.debian.org were only moderately helpful as they themselves were unclear about what it is that needs to be done. If there is anyone who has set up the print daemon on Debian and knows what I need to do with the /etc/init.d and all that mess (it appears that I have to become a Deep Linux Wizard to get this set up???) could you please offer me your recipie or advice. I have already invested so much time in this, I would offer to write up something to add to the package documentation if my ensuing results seem useful to recount to others. Thank you, Soren Andersen |
|
From: <pa...@rc...> - 2001-05-29 07:28:58
|
Hi, I checked in a fix to the configure script that detects newer SNMP packages which need "-lcrypto" on the linker command line in addition to "-lsnmp". Joe, since this was a problem for you could you verify that configure and make work for you now? I can't accurately test this on my system at home since I don't have libcrypto, much less a libsnmp that requires it. It would probably be a good idea to run "make distclean", or at least delete the file "config.cache", before re-running the configure script. David |
|
From: <pa...@rc...> - 2001-05-29 07:28:39
|
Joe Piolunek wrote: > It works fine for me, David. I had eight xojpanels running at the same time, > each showing the lcd contents of my parport connected 600. Hi, Joe. Thanks for the success report. > As the number of simultaneous instances increased, scrolling slowed for all > to the point where it seemed very slow. Would that be related to the > "blocking api" ? Yes, that would be the culprit. ptal-mlcd services each PML session in a round-robin fashion, so a client such as xojpanel might block waiting for several other sessions to get serviced before it gets its reply. David |
|
From: Joe P. <joe...@sn...> - 2001-05-28 14:46:28
|
On Sunday 27 May 2001 09:22 pm, David Paschal wrote: > Hi, > > I just checked in some changes to ptal-mlcd to support PML multiplexing. > This means that it is now possible to run multiple applications > simultaneously that use PML on the same device, including xojpanel, > ptal-hp, and ptal-pml. Currently the limit is 8 PML sessions per device, > but this is easy to change in the code if necessary. The new "-nopml" > switch for ptal-mlcd turns this capability off, reverting to the former > limit of 1 PML session at a time. > > Since this enhancement involved some tricky changes to the ptal-mlcd code > paths for channel opens and closes and for data transfer in both > directions, it could use as much testing as possible. :-) > > David It works fine for me, David. I had eight xojpanels running at the same time, each showing the lcd contents of my parport connected 600. As the number of simultaneous instances increased, scrolling slowed for all to the point where it seemed very slow. Would that be related to the "blocking api" ? -- Joe |
|
From: <pa...@rc...> - 2001-05-28 01:21:34
|
Hi, I just checked in some changes to ptal-mlcd to support PML multiplexing. This means that it is now possible to run multiple applications simultaneously that use PML on the same device, including xojpanel, ptal-hp, and ptal-pml. Currently the limit is 8 PML sessions per device, but this is easy to change in the code if necessary. The new "-nopml" switch for ptal-mlcd turns this capability off, reverting to the former limit of 1 PML session at a time. Since this enhancement involved some tricky changes to the ptal-mlcd code paths for channel opens and closes and for data transfer in both directions, it could use as much testing as possible. :-) David |
|
From: <pa...@rc...> - 2001-05-26 09:13:29
|
Hi, I just checked in some PTAL changes to enable PML, device ID retrieval, and service name lookup for JetDirect-connected peripherals. PML and device ID require libsnmp (but I haven't yet fixed the "-lcrypto" problem). This means that the following functionality is (or should be:-) now supported with JetDirect-connected peripherals: - ptal-connect -service <serviceName> - ptal-devid - ptal-pml - ptal-hp (including scanning for the LaserJet 1100A, 1220, and 3200) - xojpanel (but not yet for the LaserJets) In fact, since JetDirect supports PML multiplexing, you can run multiple instances of xojpanel and/or other PML clients (such as ptal-pml and ptal-hp) for the same device simultaneously. This doesn't yet apply to locally- connected peripherals (i.e. using ptal-mlcd), but I'm working on that right now. Since I only changed JetDirect-specific code, I shouldn't have broken anything with local (ptal-mlcd) connections, but if anybody notices any breakage then of course let me know. :-) Unfortunately sourceforge's shell servers are down "until further notice", so I can't log in to update the web page and indicate these new developments. David |
|
From: Obi-Wan <bv...@in...> - 2001-05-26 06:13:10
|
I forgot to mention that printing works fine using lprng / DJ8xx / HPIJS,
so I know the device is hooked up OK. dll.conf contains only "net" and "hp".
# cat /etc/sane.d/hp.conf
mlc:mlcpp0
option connect-ptal
# lsmod
Module Size Used by
ieee12844pp 15520 0
ieee12844 13008 1 [ieee12844pp]
parport_probe 3520 0
(parport and parport_pc are compiled into the kernel)
> Per the instructions in the error message:
>
> # hpo get OID_STATUS_MSG_LINE1_PART1
> Error 0 (system error 110) in file mlccon.c, line 263:
> Unexpected Error, please post a bug report to hpo...@so...
>
> # hpo devid
> Error 5 (system error 110) in file mlccon.c, line 93:
> Connection to peripheral lost
>
> # cat /proc/parport/0/autoprobe
> CLASS:PRINTER;
> MODEL:PSC 500;
> MANUFACTURER:HEWLETT-PACKARD;
> DESCRIPTION:Hewlett-Packard PSC 500;
> COMMAND SET:MLC,PCL,PML,SCL;
>
> # scanimage -V
> scanimage (sane-backends) 1.0.4
>
> # uname -a
> Linux tatooine 2.2.16 #7 Thu Aug 31 02:09:34 CDT 2000 i586 unknown
>
> Anything else you need from me, email direct. I'm not on the devel list.
>
> -- 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
>
--
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
|
|
From: Obi-Wan <bv...@in...> - 2001-05-26 06:07:39
|
Per the instructions in the error message:
# hpo get OID_STATUS_MSG_LINE1_PART1
Error 0 (system error 110) in file mlccon.c, line 263:
Unexpected Error, please post a bug report to hpo...@so...
# hpo devid
Error 5 (system error 110) in file mlccon.c, line 93:
Connection to peripheral lost
# cat /proc/parport/0/autoprobe
CLASS:PRINTER;
MODEL:PSC 500;
MANUFACTURER:HEWLETT-PACKARD;
DESCRIPTION:Hewlett-Packard PSC 500;
COMMAND SET:MLC,PCL,PML,SCL;
# scanimage -V
scanimage (sane-backends) 1.0.4
# uname -a
Linux tatooine 2.2.16 #7 Thu Aug 31 02:09:34 CDT 2000 i586 unknown
Anything else you need from me, email direct. I'm not on the devel list.
-- 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
|
28 messages has been excluded from this view by a project administrator.
