hpoj-devel — HPOJ development/support list

Re: [hpoj-devel] original HP cable really 1284 compliant ?

[Karsten H. <Kar...@gm...>]

>>> When you cat something to
>> it hangs "indefinitely" (meaning that I gave up waiting ...).
>> What does that tell me ?
> It probably means that the kernel is stuck waiting for a handshake from t=
he
> peripheral acknowledging that it received a byte of data.

> If you're not opposed to opening the laptop, perhaps you could at least
> check the connector for signs of bent pins or other debris that could cau=
se
> lines to be shorted together. =20

> Of course, if it's still under warranty, consider having it serviced prop=
erly
> instead of trying to do it yourself and voiding the warranty.
:-)) I lugged this thing through half of Southeast Asia and
doubt anyone would honor any warranty anymore. However, no
bent pins or shorting debris anywhere to be seen.

Connecting the printer to another machine first did not
produce any results either but after fiddling around with the
cable a little bit it suddenly started printing !?! Seems like
the cable is to blame after all albeit for a different reason.
It does print now (I don't _yet_ need the extended
capabilities of hp-ptal and friends). I'll watch this forum
for when computer-assisted fax becomes available on hp-oj.
Then I could stop running HylaFax :-)

Thanks for you help,
Karsten Hilbert
--=20
GPG key ID E4071346 @ certserver.pgp.org
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Re: [hpoj-devel] LCD text-centering patch for xojpanel

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

Allen Barnett wrote:
> I did run across an interesting thing. On my G85, when you enter Menu
> mode, after displaying the first choice (1: Copy Setup), the LCD display
> briefly flashes to the string: "Use -> and Press Enter." Where '->' is a
> single character which looks like a solid greater-than symbol (or a
> sideways teepee). I hadn't seen this before today; there is not such a
> character in the LCD font.
> 
> So, I was trying to figure out what character it was. It's returned from
> ptalPmlGetStringvalue as octal \201 (or 0x81). I was wondering if this
> is really what's returned from the machine or if ptalPmlGetStringvalue
> just called this the nonsense character? Even UNICODE doesn't supply a
> meaning for this character.
Yes, 0x81 is the right value for this character.  The character set goes
all the way up to 255.  Most of the extended set consists of foreign-
language characters, which you would see if your unit were configured
for languages that used them.  Most of these characters have the same
encoding you would see on Linux, but a few, like this right-arrow
character, do not.

> Further, when the buffer returned to ptalPmlGetStringValue is assigned
> to the QStrings Line1 and Line2, this character is treated as signed
> (and thus it is negative) and gets turned into the QChar -127. I'm
> wondering if buffer should be declared as 'unsigned char'. I guess it
> would depend on what ptalPmlGetStringValue was really returning.
Is QChar more than 8 bits (i.e. to support Unicode)?  If so, then it
might make sense to use an "unsigned char" buffer to prevent this
sign-extend.  I think the only reason I made it (signed) char for
ptalPmlGetStringValue is because that's what all the libc string functions
(strlen, etc.) want.

> I'm going to try an add the character 129 to my LCD font, but I'm not
> entirely sure how to do that. Maybe Adobe's got an encoding for it?
Joe, we could run into a problem with this character due to the algorithm
for stripping control and space characters from the end of the string
using either isgraph() or QChar::isSpace()/isPrint().  The problem is that
it would strip 129 if it happened to be at the end of the line, although
it isn't in this case.  One solution would be to do something like
what I did in ptal_hp.c:printOneLine(), which also changes control
characters in the middle of the line to spaces, or you could more simply
just narrow your criteria and only strip characters in the range of
{0<=x<=32}.  Either solution should allow non-standard extended characters
such as 129 to be displayed consistently.

David

Re: [hpoj-devel] hpoj / loading parallelport drivers / unresolved symbol

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

Anton Greil wrote:
> # insmod parport
> Using /lib/modules/2.2.16/misc/parport.o
> 
> # insmod parport_pc
> Using /lib/modules/2.2.16/misc/parport_pc.o
> 
> hpoj-0.7 # insmod parport_pc
> /usr/local/lib/ieee12844.o: unresolved symbol global_bh_lock
> /usr/local/lib/ieee12844.o: unresolved symbol synchronize_bh
> 
> hpoj-0.7 # insmod /usr/local/lib/ieee12844.o
> /usr/local/lib/ieee12844pp.o: unresolved symbol global_bh_lock
> /usr/local/lib/ieee12844pp.o: unresolved symbol tqueue_lock
> /usr/local/lib/ieee12844pp.o: unresolved symbol mlcp_unregister
> /usr/local/lib/ieee12844pp.o: unresolved symbol synchronize_bh
> /usr/local/lib/ieee12844pp.o: unresolved symbol mlcp_register
> 
> What could be the reason for "unsolved symbol" ?
> (SuSE Linux 7.0, kernel: 2.2.16)

Hi, Anton.  Offhand I'm not really sure what the problem is, but perhaps
Burkhard might know something.  Are you running an SMP (multi-processor)
kernel by any chance?  It might be helpful if I could see the output from
running the configure script, as well as from compiling the stuff in the
ieee12844 directory.

Alternatively, if you don't mind being a bit on the "bleeding edge", you
could try the development code in CVS, which no longer has this degree of
kernel dependence.  The code is fairly stable now, but I still need to
finish the documentation before I release it as version 0.8 (probably early
August).

David

Re: [hpoj-devel] ptal-init script

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

Allen Barnett wrote:
> > Would it help if it printed a message saying that it's stopping/starting the
> > daemons, the way it does with "ptal-init start" and "ptal-init stop"?
> 
> Wouldn't hurt :-)
OK, I checked in the change that makes "ptal-init setup" print these
messages, to reduce the surprise factor.  "ptal-init setup" certainly has
to stop the daemons before doing its thing, and I think it makes sense for
it to start them again afterwards, to eliminate an extra step in the setup
process.

> > > (Ever hopeful about hotplug:
> Just can't seem to get a break here :-) Well, your start up script works
> fine in /etc/rc.d. I guess I'll be happy with that.
I'm sorry it isn't feasible to dynamically load/unload the daemons, but I
have to work with the interfaces I'm given.  :-)  Of course, there's nothing
wrong with arranging to have kernel modules such as printer.o dynamically
loaded from a hotplug script, since that seems to be what hotplug scripts
were designed for.  In any case, I don't think there's all that much
overhead in having the daemons loaded for one peripheral even when not in
use, because each one appears to use less memory than /bin/bash.  I
typically have anywhere from 7 to 12 instances of each loaded for testing
purposes.

David

Re: [hpoj-devel] ptal-init script

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

David Paschal wrote:
> Allen Barnett wrote:
> > Tested your scripts some more. Works pretty well if you follow your
> > instructions (namely, you have to run 'ptal-init setup' once :-) I was a
> > little surprised that 'setup' actually started the daemons. I thought it
> > would just write the config files, but that's OK.
> Would it help if it printed a message saying that it's stopping/starting the
> daemons, the way it does with "ptal-init start" and "ptal-init stop"?

Wouldn't hurt :-)

> 
> > I'm wondering if it might be helpful to include the Serial Number of the
> > device in the MLC name. That would give any additional setup scripts
> > something more concrete to hang on to.
> And it would be especially annoying if the
> user always had to type in the serial number when specifying the PTAL device
> name to command-line utilities.

Indeed. I was mostly concerned with automated processes (such as
hotplugging).

> > (Ever hopeful about hotplug: can ptal-mlcd extract the device serial
> > number through the /dev/usb/lp* interface? This, along with examining
> > /proc/bus/usb/devices and /proc/bus/usb/[interface#]/[dev#] might be
> > enough to find the proper /dev/usb/lp* interface when a device is
> > plugged in. Or am I describing a chicken/egg situation :-)
> Some models supply it in the device ID string as a "SERN" or "SN" field,
> but others don't....

Just can't seem to get a break here :-) Well, your start up script works
fine in /etc/rc.d. I guess I'll be happy with that.

Thanks,
Allen

Re: [hpoj-devel] ptal-init script

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

I just checked in some build and ptal-init changes:

- Changed to not overwrite *.conf files if they exist and are different.
In this case, they are installed as *.conf.new (based on Joe's request).
Also added an information message if /etc/ptal-*.conf exists, because files
in /etc take precedence over files in $prefix/etc.

- Checks for and asks the user to delete outdated files, such as hpo,
bin/ptal-printd, ieee12844*.o, etc.  I did this mainly because ptal-printd
moved from bin to sbin and because ieee12844*.o could break ptal-mlcd if
they're still loaded.  I chose not to delete these files automatically, to
reduce the surprise factor.

- Checks ld.so.conf and adds line to $prefix/lib if necessary and runs
ldconfig, to eliminate a manual post-installation step.  The problem is
that if you install multiple times where the prefix (installation)
directory differs only in extra slashes, you end up with duplicate entries
in ld.so.conf (i.e. "/usr/local/lib" and "/usr/local//lib").

- Added /sbin and /usr/sbin to the make install PATH to fix problem
executing chkconfig that Allen reported (thanks for pointing that out!).
Also added this to ptal-init.

- Added some warnings about not finding the SysV init script directory and
problems running chkconfig.

- When running make install as non-root, added checks for things the
user needs to do by hand (creating the /dev/ptal-* directories, updating
ld.so.conf and running ldconfig).  However, I didn't add a check for
linking ptal-init into /etc/init.d.

- Updated some wording in *.conf and added a placeholder for "modprobe
printer" commands in case hotplugging isn't set up.

Of course, let me know if there are still any problems.  You'll also need
to re-run the configure script for most of these changes to take effect.

Allen Barnett wrote:
> Tested your scripts some more. Works pretty well if you follow your
> instructions (namely, you have to run 'ptal-init setup' once :-) I was a
> little surprised that 'setup' actually started the daemons. I thought it
> would just write the config files, but that's OK.
Would it help if it printed a message saying that it's stopping/starting the
daemons, the way it does with "ptal-init start" and "ptal-init stop"?

> I'm wondering if it might be helpful to include the Serial Number of the
> device in the MLC name. That would give any additional setup scripts
> something more concrete to hang on to.
It might be useful for differentiating two different instances of the same
model.  However, it would make things more difficult when replacing a
device with another one of the same model but different serial number (i.e.
after a warranty exchange).  And it would be especially annoying if the
user always had to type in the serial number when specifying the PTAL device
name to command-line utilities.

> (Ever hopeful about hotplug: can ptal-mlcd extract the device serial
> number through the /dev/usb/lp* interface? This, along with examining
> /proc/bus/usb/devices and /proc/bus/usb/[interface#]/[dev#] might be
> enough to find the proper /dev/usb/lp* interface when a device is
> plugged in. Or am I describing a chicken/egg situation :-)
Some models supply it in the device ID string as a "SERN" or "SN" field,
but others don't.  However, there are currently no printer.c ioctls to
retrieve this information from the standard USB serial number string
descriptor, which you would find under /proc.  Again, the problem here
is that there is no standard way to determine the linkage between a USB
device address and /dev/usb/lp* assignment (other than the hack you did
on your machine several months ago).

David

Re: FW: [hpoj-devel] Help, HP PSC-750 USB printer won't work afte r en abling hot-plug s cripts

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

Ben McCann=A0wrote:
> Thanks for the information. This PC is an old Pentium MMX 233
> on an ABIT PX5 motherboard. I think its using an Intel chip
> set and god knows what for USB. I was kind of surprised that
> USB worked at all given the PC is at least 3 years old.
Given the age of the PC, I would think that a defective USB chipset is th=
e
most likely culprit.  The two PCs I experienced problems with were a
Pentium-MMX 200 and a Pentium-II 266.  I'm sure they were at least 3 year=
s
old too, although I don't know for sure since I got them second-hand.

> Funny thing is once I get the PC and printer booted and
> talking (which takes several attempts) they run fine. This old
> PC is my home's file and print server and I leave it on all
> the time. So now I leave the printer on as well and then my
> wife and kids can print from the other PC's with no problem.
> =

> I'll look around for a USB PCI card. Do you have any recommendations?
I can't think of any brand names at the moment, but most of the cards I
have are based on an "OPTi" chipset, and I have no complaints about them.=


> P.S. I hate to decommission a PC when even a Pentium 233 runs so
> well with Linux. With a modern disk and a PCI ethernet card with
> DMA, I can get almost 8 Mbytes/second over NFS while running
> Seti@home in user space.
There's certainly no need to throw away the PC for this reason.  Hopefull=
y
the USB card will make these problems go away.  If it does, then you migh=
t
want to disable the integrated USB controller in the BIOS setup if it giv=
es
you such an option, to free up an IRQ for other things.

David

Re: [hpoj-devel] LCD text-centering patch for xojpanel

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

Joe Piolunek wrote:
> 
> David:
> 
> I've attached a patch for xojpanel that should allow text displayed with
> Allen Barnett's "LCD" font to be better centered in its space. It will also
> center other fonts including Courier, in a fairly wide range of sizes.
> 
> Allen:
> 
> It sounds like David will be too busy to look at the patch right away. Would
> you mind testing it?  Send any comments you have.
> 
> Patch from the top-level hpoj CVS directory.
> 
> This command should apply it :
> hpoj]$ patch -p0 < xojpanel_font_display.patch
> 

Hi Joe,

I applied this patch and it looks OK to me. I tried a few different
fonts and they all looked nice.

I did run across an interesting thing. On my G85, when you enter Menu
mode, after displaying the first choice (1: Copy Setup), the LCD display
briefly flashes to the string: "Use -> and Press Enter." Where '->' is a
single character which looks like a solid greater-than symbol (or a
sideways teepee). I hadn't seen this before today; there is not such a
character in the LCD font.

So, I was trying to figure out what character it was. It's returned from
ptalPmlGetStringvalue as octal \201 (or 0x81). I was wondering if this
is really what's returned from the machine or if ptalPmlGetStringvalue
just called this the nonsense character? Even UNICODE doesn't supply a
meaning for this character.

Further, when the buffer returned to ptalPmlGetStringValue is assigned
to the QStrings Line1 and Line2, this character is treated as signed
(and thus it is negative) and gets turned into the QChar -127. I'm
wondering if buffer should be declared as 'unsigned char'. I guess it
would depend on what ptalPmlGetStringValue was really returning.

I'm going to try an add the character 129 to my LCD font, but I'm not
entirely sure how to do that. Maybe Adobe's got an encoding for it?

Thanks,
Allen

Re: [hpoj-devel] ptal-init script

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

Allen Barnett wrote:
> 
> David Paschal wrote:
> >
> > Hi,
> >
> > At long last I have checked in an init script (ptal-init) and its related
> > configuration files (ptal-start.conf and ptal-stop.conf).  In addition to
> 
> Long description deleted...
> 
> >
> > Hopefully this feature will make setting up and starting the daemons much
> > easier in the long run once it has stabilized.
> >
> > David
> 

Tested your scripts some more. Works pretty well if you follow your
instructions (namely, you have to run 'ptal-init setup' once :-) I was a
little surprised that 'setup' actually started the daemons. I thought it
would just write the config files, but that's OK.

I'm wondering if it might be helpful to include the Serial Number of the
device in the MLC name. That would give any additional setup scripts
something more concrete to hang on to.

(Ever hopeful about hotplug: can ptal-mlcd extract the device serial
number through the /dev/usb/lp* interface? This, along with examining
/proc/bus/usb/devices and /proc/bus/usb/[interface#]/[dev#] might be
enough to find the proper /dev/usb/lp* interface when a device is
plugged in. Or am I describing a chicken/egg situation :-)


Thanks,
Allen

[hpoj-devel] hpoj / loading parallelport drivers / unresolved symbol

[Anton G. <gr...@mu...>]

problem: hpoj / loading parallel port drivers / "unresolved symbol" 

In the script sourceforge/download/hpoj-0.7/INSTALL
the followng sections appear:

Loading the parallel port drivers (quick version)
=================================================

Issue the following commands as root:
	insmod parport
	insmod parport_pc
	insmod parport_probe
	insmod /usr/local/lib/ieee12844.o
	insmod /usr/local/lib/ieee12844pp.o

Loading the parallel port drivers (notes and troubleshooting)
=============================================================

....

At the very least, the following kernel configuration options must be
enabled (preferably compiled as modules):
	CONFIG_PARPORT
	CONFIG_PARPORT_PC
	CONFIG_PNP_PARPORT (along with CONFIG_PNP)

If any of the first three insmod commands above fail due to not finding
the module, or either of the last two fail due to unresolved symbols,
then try reconfiguring and rebuilding your kernel with these options
enabled.

----------------------------------------------------------------------

Here comes my problem:
=====================

After "reconfiguring and rebuilding my kernel with these options
enabled", 
 (I did this job for the first time, but followed the SuSE
  "handbook" for making and installing a new kernel),
I got "unresolved symbols" again: 

# insmod parport
Using /lib/modules/2.2.16/misc/parport.o

# insmod parport_pc
Using /lib/modules/2.2.16/misc/parport_pc.o

hpoj-0.7 # insmod parport_pc
/usr/local/lib/ieee12844.o: unresolved symbol global_bh_lock
/usr/local/lib/ieee12844.o: unresolved symbol synchronize_bh

hpoj-0.7 # insmod /usr/local/lib/ieee12844.o
/usr/local/lib/ieee12844pp.o: unresolved symbol global_bh_lock
/usr/local/lib/ieee12844pp.o: unresolved symbol tqueue_lock
/usr/local/lib/ieee12844pp.o: unresolved symbol mlcp_unregister
/usr/local/lib/ieee12844pp.o: unresolved symbol synchronize_bh
/usr/local/lib/ieee12844pp.o: unresolved symbol mlcp_register

What could be the reason for "unsolved symbol" ?
(SuSE Linux 7.0, kernel: 2.2.16)

Many thanks & greetings,
Anton Greil

Re: [hpoj-devel] LCD text-centering patch for xojpanel

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

On Friday 13 July 2001 07:25 am, David Paschal wrote:
> > David:
> >
> > I've attached a patch for xojpanel that should allow text displayed with
> > Allen Barnett's "LCD" font to be better centered in its space. It will
> > also center other fonts including Courier, in a fairly wide range of
> > sizes.
> >
> > Allen:
> >
> > It sounds like David will be too busy to look at the patch right away.
> > Would you mind testing it?  Send any comments you have.
>
> Hi, Joe.  A quick test showed no adverse effects.  I ran it alongside the
> unpatched version and they looked the same to me.  I guess the intent is to
> make it look better if somebody hacks it for a non-fixed-space font?

It's mainly for a case when someone wants to build xojpanel using a big font 
that comes close to filling the entire space in the 'LCD'.  Being vertically 
off by one or more pixels becomes noticeable then.

It turns out that some fonts appear to display higher or lower than you might 
expect, depending on the relation between its baseline and the lowest part of 
the font (descent). 


> Let me know if/when you want it checked into CVS.  I'd prefer sooner than
> later (with sufficient testing, of course) if you want it to go in for 0.8,
> because I'm trying to wrap things up for that in the next 2-3 weeks.

If no problems are found with it in the next two or three days, It should be 
OK to commit the changes.

-- 
Joe

Re: [hpoj-devel] ptal-init script

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

David Paschal wrote:
> 
> Hi,
> 
> At long last I have checked in an init script (ptal-init) and its related
> configuration files (ptal-start.conf and ptal-stop.conf).  In addition to

Long description deleted...

> 
> Hopefully this feature will make setting up and starting the daemons much
> easier in the long run once it has stabilized.
> 
> David

I just started to look at this (and it looks pretty good!), but I ran
into a slight glitch. Normally, I build things as me (user 'allen') and
do an 'su' to do the installation. As you probably know, a plain su only
changes your user ID; all the rest of your environment is left intact
(compare to 'su -' which more or less performs a new login). So, as
'allen', the directory /sbin is not is in my PATH. When I execute 'su -c
'make install'', the current Makefile expects to find 'chkconfig' in the
PATH, which it isn't. So, maybe it would be better to put
'/sbin/chkconfig' explicitly in the Makefile (or maybe it's one of the
things ./configure should look for?).

Thanks,
Allen

Re: [hpoj-devel] LCD text-centering patch for xojpanel

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

> David:
> 
> I've attached a patch for xojpanel that should allow text displayed with 
> Allen Barnett's "LCD" font to be better centered in its space. It will also 
> center other fonts including Courier, in a fairly wide range of sizes.
> 
> Allen:
> 
> It sounds like David will be too busy to look at the patch right away. Would 
> you mind testing it?  Send any comments you have.

Hi, Joe.  A quick test showed no adverse effects.  I ran it alongside the
unpatched version and they looked the same to me.  I guess the intent is to
make it look better if somebody hacks it for a non-fixed-space font?

Let me know if/when you want it checked into CVS.  I'd prefer sooner than
later (with sufficient testing, of course) if you want it to go in for 0.8,
because I'm trying to wrap things up for that in the next 2-3 weeks.

David

Re: FW: [hpoj-devel] Help, HP PSC-750 USB printer won't work after en abling hot-plug s cripts

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

Hi, Ben.  After you power cycle the peripheral and get this timeout
message when trying to access the peripheral again (i.e. ptal-devid),
does this problem keep happening even if you try the re-access several
times?

It's possible (but not definite) that you have a defective USB chipset,
especially if it's integrated on the motherboard.  I've run into timeout
problems also, but generally during scanning and not of the nature that
you're seeing.  A USB analyzer showed numerous protocol errors on the wire,
and all of these problems went away when I installed a PCI USB add-in card.
This might be worth a try if you don't mind spending the extra money
(check the store's return policy first) or if you know somebody who already
has one that you can borrow for testing.

Do you have any other devices on the bus?  If you are connecting through
a USB hub, that could be suspect, especially if it's an unpowered one.

David

> -----Original Message-----
> From: Mccann, Benjamin E [mailto:bm...@en...] 
> Sent: Saturday, July 07, 2001 5:13 AM
> To: PASCHAL,DAVID (HP-Roseville,ex1)
> Subject: RE: [hpoj-devel] Help, HP PSC-750 USB printer won't work after en
> abling hot-plug s cripts
> 
> 
> Hi David, 
> Thanks for your help. I did have two copies of the ptal-printd 
> daemon because I had started with 0.7. That's fixed now, and I've 
> updated my snapshot to the latest CVS with your new ptal-init. 
> I also disabled CONFIG_HOTPLUG in my kernel and rebuilt/rebooted. 
> However, I've not started using your init script because I think 
> my problem is a more fundamental USB issue. I can sometimes get 
> my printer to work if I: 
> - Turn it on, then, 
> - Start ptal-mlcd, then, 
> - Run ptal-hp or ptal-printd 
> If I cycle power on the printer while ptal-mlcd is running and 
> then attempt to use ptal-hp or ptal-printd then I get errors 
> from ExMgr.cpp:llioGetDeviceID due to an ioctl failure and that 
> failure is always preceeded by a kernel printk of: 
> usb_control/bulk_msg: timeout 
> It appears my USB subsystem gets its shorts in a knot when I power 
> cycle my printer but I can still see the printer via 'lsusb' after 
> a power cycle. I can recover (sometimes) by killing ptal-mlcd and 
> restarting it. A kernel reboot has not been necessary nor have I 
> had to reload the usbcore or usb-uhci modules. I did reload 'printer' 
> once but it didn't help on one of the iterations when I could not 
> get the printer to answer without a timeout. 
> Note that sometimes when I run my process above I _also_ get the 
> bulk_msg timeout. Its seems like I have about a 25% chance of having 
> the startup sequence (turn on, ptal-mlcd, ptal-printd) work but 
> once I do, the printer is OK and I can print fine. 
> So, I think I have to resolve this problem before worrying about 
> the initialization scripts. Do you agree and if so, can you suggest 
> a plan of attack or a pointer to someone who can help me trouble 
> shoot this? 
> -Ben McCann 
> p.s. I have an HP USB cable that supposed to be certified for high 
> speed USB devices (12 mbit/sec).

Re: [hpoj-devel] cvs on SuSE Kernel 2.4.4 (7.2)

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

Hi, Charlie.

Charlie Reinl wrote:
> Jul  8 18:32:19 Charlie kernel: parport0: PC-style at 0x378
> [SPP,PS2,EPP,ECPEPP,ECPPS2]
> Jul  8 18:32:19 Charlie kernel: parport1: PC-style at 0x278 (0x678)
> [SPP,ECP,ECPEPP,ECPPS2]
> Jul  8 18:32:19 Charlie kernel: parport_probe: failed
> Jul  8 18:32:19 Charlie kernel: parport0: no IEEE-1284 device present.
> Jul  8 18:32:19 Charlie kernel: parport_probe: succeeded
> Jul  8 18:32:19 Charlie kernel: parport1: Printer, Hewlett-Packard
> OfficeJet Series 700

Based on this information, I would recommend the following:
    ptal-mlcd par:1 -base 0x278 -device /dev/lp1
The number after the "par:" is only for identification purposes, and can
be pretty much any string, as long as it doesn't contain spaces or other
characters that are "special" to the shell.  The "-device /dev/lp1" switch
tells ptal-mlcd to open that device node while it's using the port, to
lock out other programs that might try to access the port.

> Jul  8 18:32:19 Charlie kernel: IEEE1284.4 protocol layer for Linux
> installed
> Jul  8 18:32:19 Charlie kernel: ieee12844pp: IEEE1284.4 device found on
> parport1:
> Jul  8 18:32:19 Charlie kernel:    Hewlett-Packard OfficeJet Series 700;
> 
> Jul  8 18:32:19 Charlie kernel:    device registered to IEEE1284.4
> protocol layer as link mlcpp0
> 
> to konw I use vmware 2.0.3 (nexttime dateing up to  2.04)
ieee12844 and ieee12844pp are obsolete after version 0.7.  Run "lsmod" to
make sure they are no longer loaded, because if they're still loaded (even
if you deleted the files), then that could certainly cause problems for
ptal-mlcd.  It's also a good idea to "rmmod vmppuser", which you said you
did.

> tile now I only was printing (use scanning 4 times a year, do it in
> Windows)
Once you get ptal-mlcd working, you can scan under Linux using the
"ptal-hp scan" command-line utility (see SCAN-HOWTO).

> a ptal-hp mlc:par:1 brings also a list of errors
Make sure you give a command (device, display, clock, or scan) after the
device name (mlc:par:1).

If you are still having trouble with this, please try the following:

1. Run ptal-mlcd as above.
2. In another window, run something simple, like "ptal-devid mlc:par:1" or
"ptal-hp mlc:par:1 display".
3. If it doesn't work, please write back to the mailing list with any
error messages displayed in steps 1 and 2 above.  For your convenience,
ptal-mlcd also logs its messages to /var/log/messages.  Also, please
include the output from "lsmod", just to have an extra data point.

I hope this helps.

David

Re: [hpoj-devel] ptal-mlcd compiler-related changes

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

On 12 Jul, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> It compiles/runs fine for me (egcs-2.91.66), but I would
> appreciate any reports of problems with other compiler versions, especially
> gcc-3.0.

It also works fine with gcc-3.0, at least for me.

-- 
Ale...@fm... / The [Ford Foundation] is a
http://www.fmi.uni-passau.de/~zimmerma/ large body of money completely
for PGP public key finger            / surrounded by people who want
zim...@yo...     / some.   -- Dwight MacDonald 

[hpoj-devel] LCD text-centering patch for xojpanel

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

David:

I've attached a patch for xojpanel that should allow text displayed with 
Allen Barnett's "LCD" font to be better centered in its space. It will also 
center other fonts including Courier, in a fairly wide range of sizes.

Allen:

It sounds like David will be too busy to look at the patch right away. Would 
you mind testing it?  Send any comments you have.

Patch from the top-level hpoj CVS directory.

This command should apply it :
hpoj]$ patch -p0 < xojpanel_font_display.patch


-- 
Joe

[hpoj-devel] ptal-mlcd compiler-related changes

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

Hi,

I just checked in some changes to ptal-mlcd, mostly a result of changes made
to support a compiler upgrade for HP's non-GPL use of this code (JetDirect
firmware).  It compiles/runs fine for me (egcs-2.91.66), but I would
appreciate any reports of problems with other compiler versions, especially
gcc-3.0.

I also made a small syslog change to remove the redundant "ptal-mlcd:".

David

Re: [hpoj-devel] preliminary HTML documentation

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

On Wednesday 11 July 2001 07:28 am, David Paschal wrote:
> Hi,
>
> I just posted an early rough draft of a few pieces of the upcoming
> HTML-formatted documentation.  It's temporarily at
> "http://hpoj.sourceforge.net/hpoj-cvs/doc-temp/", and I haven't checked
> it into CVS yet.  So far only index.html, setup-scan.html, and
> ptal-hp-scan.html are there, with more to come over the next week or so.
> Any early feedback on what I have so far would be appreciated.  It's
> intentionally plain-looking, though.  :-)
>
> David

I looked at  doc-temp/index.html and setup-scan.html. They both look pretty 
good in netscape.

Thinking that the xhpcontrol app might be able to use a simple help browser, 
I viewed your HTML docs in one that I previously created with the qt designer.
The docs still looked reasonably good, but there are differences in how some 
elements are displayed. In the help browser, the <h4> tags caused the 
enclosed text to display at regular size. Apparently the only <hX> tags 
supported by the Qt classes are <h1>, <h2>, and <h3>.

Since the QSimpleRichText widget isn't a web browser, clicking on a www link 
in the text does not cause the page to change. Otherwise the www links look 
and act normally. Local ( file ) links do cause the page to change.

If you are interested in marking up any of the docs to be displayed in a 
(maybe) xhpcontrol help browser, a list of recognized tags can be found here.

http://doc.trolltech.com/qstylesheet.html

-- 
Joe

[hpoj-devel] preliminary HTML documentation

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

Hi,

I just posted an early rough draft of a few pieces of the upcoming
HTML-formatted documentation.  It's temporarily at
"http://hpoj.sourceforge.net/hpoj-cvs/doc-temp/", and I haven't checked
it into CVS yet.  So far only index.html, setup-scan.html, and
ptal-hp-scan.html are there, with more to come over the next week or so.
Any early feedback on what I have so far would be appreciated.  It's
intentionally plain-looking, though.  :-)

David

[hpoj-devel] libieee1284/ppdev needs for hpoj project

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

Tim Waugh wrote:
> Incidentally, if anyone on this list would like to help make sure that
> libieee1284 doesn't end up with a bad interface, please do.
> The mailing list is at libieee1284.sf.net.

Hi, Tim.  Sorry about not giving you input about libieee1284 until now.
Thanks for the gentle reminder.  :-)  BTW, there's nothing at
"http://libieee1284.sf.net".  I had to go to
"http://sourceforge.net/projects/libieee1284" to get to your mailing list.

As you know, I already did something like this for the HP OfficeJet Linux
driver project (http://hpoj.sourceforge.net), namely the ParPort C++ class,
which does strictly user-mode parallel port signalling, used by my user-mode
implementation of the HP MLC and IEEE 1284.4 transport protocols (ptal-mlcd).
At one point I got this class working under FreeBSD, but I haven't yet put
much effort into making the entire hpoj package work outside of Linux.

I'll list the basic requirements I had for this code, and sprinkle in some
comments about why I did some things the way I did:

- Negotiate into the following modes:
  - nibble (0x00)
  - nibble device ID (0x04)
  - ECP (0x10)
  - bounded ECP (0x18) (very important, see below)

- Terminate back to compatibility mode.

- Write single or multiple bytes in compatibility and [B]ECP forward modes.

- Write ECP commands (channel addresses).

- Read single or multiple bytes in nibble and [B]ECP reverse modes.

- Read the entire device ID string, removing the two length bytes and
appending a null byte, without rearranging or pruning it the way the
kernel does.

- ECP forward-to-reverse and reverse-to-forward.

- Checking the nPeriphRequest (nFault) signal, which IIRC ppdev reports
using select(), which I think is a good idea, but it needs to be
appropriately abstracted for when all of the signalling is done in user
mode, the way I do it.  I handled this because I use select for USB and
polling for parallel.

- A generic high-level write/read interface, with the following operations:
  - Set forward and reverse modes:
    - Forward: compatibility mode, ECP, BECP.
    - ECP channel, if applicable.
    - Reverse: nibble mode, ECP.
  - Write forward data.
  - Switch to reverse mode (as specified above).
  - Read reverse data.
  - Switch to forward mode (as specified above).

The direction switching can't be completely transparent, because I need to
return to forward after sending a reverse packet, which consists of a
header and data, even if I don't have forward data to send and possibly
have more reverse packets to receive.

  This allows the same code to use the following combinations of modes:
  - compatibility forward, nibble reverse
  - ECP forward, nibble reverse
  - BECP forward, nibble reverse (not actually necessary)
  - bidirectional ECP
  - bidirectional BECP

- Ideally, it should be possible to take advantage of hardware-assisted
and/or kernel-assisted transfers (i.e. ppdev), but it should be easy to
programatically disable this and fall back to user-mode signalling if
necessary, and possibly for one direction but not the other.

- Bounded ECP mode must take into account host-side rules specified in the
1284.3 (draft?) standard, mainly waiting for nFault to go high before
going back to forward.  This support is critical for me, because many of
the OfficeJets won't work correctly with regular (unbounded) ECP mode.

- When doing user-mode signalling, open the corresponding /dev/lpX to
prevent another process from opening it and conflicting with the library's
use of the port.

- Configurable timeouts for signalling, ECP host transfer recovery, etc.

- Information about whether the port has bidirectional capability.

- Hide the irritating inversion of certain signals by the PC parallel port,
compared to what I see on the wire with a logic analyzer and what the 1284
standard specifies.  Use standard names for the signals (NINIT, NSTROBE,
NAUTOFD, NSELECTIN, NACK, BUSY, PERROR, NFAULT, SELECT), with an appropriate
prefix, of course.

- I prefer a "set/clear" interface to control/status registers, where I use
separate parameters to specify the bits to set (or test as set) and the
bits to clear (or test as clear).  This makes the code much more readable.

- Since I expect I'm out-numbered on hiding the signal inversion and
preferring "set/clear" over "frob", due to the reasonable concern of even a
slight performance hit, I can always make my own wrapper interface that
takes care of these things if you don't want to incorporate them or at least
provide a "set/clear" alternative in addition to "frob".  Of course, if
the library has everything I need and works perfectly, then I shouldn't
need to worry about signal bits at all.

Since both libieee1284 and the hpoj software are GPL, feel free to look at
my code (mainly ParPort.{h,cpp} and the small ParMgr class defined in
ExMgr.cpp) and incorporate whatever you see fit.

Let me know if you have any questions.

David

Re: [hpoj-devel] original HP cable really 1284 compliant ?

[Tim W. <tw...@re...>]

On Mon, Jul 09, 2001 at 05:39:23PM -0700, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

> as FreeBSD.  The new 2.4 kernel has a generic "ppdev" interface, and Tim
> Waugh is working on a libieee1284 user-mode interface, both of which sound
> promising, but I haven't yet had a chance to sit down and take inventory of
> exactly what these facilities provide and what they lack that I need.

Incidentally, if anyone on this list would like to help make sure that
libieee1284 doesn't end up with a bad interface, please do.
The mailing list is at libieee1284.sf.net.

Tim.
*/

RE: [hpoj-devel] original HP cable really 1284 compliant ?

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

Karsten Hilbert wrote in response to me:
> > When you cat something to
> > /dev/lp0 does the command complete fairly quickly or does it hang
> > indefinitely?
> I hangs "indefinitely" (meaning that I gave up waiting ...).
> What does that tell me ?
It probably means that the kernel is stuck waiting for a handshake from the
peripheral acknowledging that it received a byte of data.  Probably one or
both of the handshaking lines (nAck and/or Busy) are bad, or maybe at least
of marginal quality, such that some devices work and others don't.

If you're not opposed to opening the laptop, perhaps you could at least
check the connector for signs of bent pins or other debris that could cause
lines to be shorted together.  This may not be practical if the connector is
completely enclosed in plastic, so be careful not to break anything.  Of
course, if it's still under warranty, consider having it serviced properly
instead of trying to do it yourself and voiding the warranty.

> OK, I will try that and report back. BTW, I assume that
> "bypassing the kernel for par port IO" was done because the
> kernel doesn't offer some parallel port functionality (yet) ?
> That being so are there any (however distant) plans to get in 
> touch with
> parport people to eventually get it into future kernels ?
The old kernel-mode drivers (ieee12844*.c) were very difficult to maintain,
and were extremely sensitive to changes in the kernel APIs.  For now I moved
to a completely user-mode parallel-port driver to achieve maximum
portability between Linux kernel versions and eventually to other OSes, such
as FreeBSD.  The new 2.4 kernel has a generic "ppdev" interface, and Tim
Waugh is working on a libieee1284 user-mode interface, both of which sound
promising, but I haven't yet had a chance to sit down and take inventory of
exactly what these facilities provide and what they lack that I need.

David

Re: [hpoj-devel] original HP cable really 1284 compliant ?

[Karsten H. <Kar...@gm...>]

Hi David,

> It's likely that there's something wrong
> with your parallel port (broken or shorted line) which the DeskJet and dot
> matrix printer can cope with but the G85 can't.
I was fearing something like that.

> When you cat something to
> /dev/lp0 does the command complete fairly quickly or does it hang
> indefinitely?
I hangs "indefinitely" (meaning that I gave up waiting ...).
What does that tell me ?

> It would be useful to try the latest CVS code, since it has a brand-new
> low-level driver (ptal-mlcd) that bypasses the kernel for parallel-port
> I/O.  Assuming a hardware problem, it probably won't work either, but at
> least maybe it will provide some useful diagnostic information.
OK, I will try that and report back. BTW, I assume that
"bypassing the kernel for par port IO" was done because the
kernel doesn't offer some parallel port functionality (yet) ?
That being so are there any (however distant) plans to get in touch with
parport people to eventually get it into future kernels ?

> If you don't mind experimenting with the production server, you could try
> connecting the G85 there.
Well, I still have a few other machines to test with so no
need yet to touch the server(s).

I'll test further and report.

Regards,
Karsten
-- 
GPG key ID E4071346 @ certserver.pgp.org
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

[hpoj-devel] cvs on SuSE Kernel 2.4.4 (7.2)

[dau <kar...@fe...>]

Hallo

trying to go on the cvs.
this is a protcoll to start the hpoj made from cvs (9/7/2001) on Kernel
2.4.x
may help me and you to understand problems on installing the
hpoj-drivers

I had
- read the  INSTALL
- cleaned up  (from hpoj-0.7 parts) /usr/loacl/bin   and /usr/loacl/lib
(they are listed in /etc/ld.so.conf)
- cleaned up also  /dev/ptal-parportd  (from hpoj-0.7 parts, at this
time I dit 'ptal-printing mlc:mlcpp0 -like /dev/lp1 &' )
- LD_LIBRARY_PATH is not in Set

./configure --without-ubs
make
make install (as root)  and  /dev/ptal-mlc and /dev/ptal-parportd  are
present

found in
    /usr/loacl/bin   6 files and copied ptal-printd en plus
    /usr/loacl/lib    1 file 2 links to the first

I have 2 // ports, the 1e ist empty (no more printer) on the 2d a HP
Officejet 710
I use SuSE Linux

here  parts of my /var/log /messages

on Kernel 2.4.4 (SuSE Linux 7.2)

Jul  9 07:27:40 Charlie kernel: parport0: PC-style at 0x378
[PCSPP,TRISTATE]
Jul  9 07:27:40 Charlie kernel: parport0: cpp_daisy: aa5500ff(38)
Jul  9 07:27:40 Charlie kernel: parport0: assign_addrs: aa5500ff(38)
Jul  9 07:27:40 Charlie kernel: parport0: cpp_daisy: aa5500ff(38)
Jul  9 07:27:40 Charlie kernel: parport0: assign_addrs: aa5500ff(38)
Jul  9 07:27:40 Charlie kernel: 0x278: FIFO is 16 bytes
Jul  9 07:27:40 Charlie kernel: 0x278: writeIntrThreshold is 9
Jul  9 07:27:40 Charlie kernel: 0x278: readIntrThreshold is 9
Jul  9 07:27:40 Charlie kernel: 0x278: PWord is 8 bits
Jul  9 07:27:40 Charlie kernel: 0x278: Interrupts are ISA-Pulses
Jul  9 07:27:40 Charlie kernel: 0x278: ECP port cfgA=0x10 cfgB=0x78
Jul  9 07:27:40 Charlie kernel: 0x278: ECP settings irq=5 dma=<none or
set by other means>
Jul  9 07:27:40 Charlie kernel: parport1: PC-style at 0x278 (0x678)
[PCSPP,TRISTATE,COMPAT,EPP,ECP]
Jul  9 07:27:40 Charlie kernel: parport1: cpp_daisy: aa5500ff(18)
Jul  9 07:27:40 Charlie kernel: parport1: assign_addrs: aa5500ff(18)
Jul  9 07:27:40 Charlie kernel: parport1: cpp_daisy: aa5500ff(18)
Jul  9 07:27:40 Charlie kernel: parport1: assign_addrs: aa5500ff(18)
Jul  9 07:27:40 Charlie kernel: ppdev: user-space parallel port driver

on Kernel 2.2.16 (SuSE Linux 7.0)

Sep  3 22:47:33 Charlie kernel: parport0: PC-style at 0x378
[SPP,PS2,EPP,ECPEPP,ECPPS2]
Sep  3 22:47:33 Charlie kernel: parport1: PC-style at 0x278 (0x678)
[SPP,ECP,ECPEPP,ECPPS2]
Sep  3 22:47:33 Charlie kernel: parport_probe: failed
Sep  3 22:47:33 Charlie kernel: parport0: no IEEE-1284 device present.
Sep  3 22:47:33 Charlie kernel: parport_probe: succeeded
Sep  3 22:47:33 Charlie kernel: parport1: Printer, Hewlett-Packard
OfficeJet Series 700
Sep  3 22:47:33 Charlie kernel: IEEE1284.4 protocol layer for Linux
installed
Sep  3 22:47:33 Charlie kernel: ieee12844pp: IEEE1284.4 device found on
parport1:
Sep  3 22:47:33 Charlie kernel:    Hewlett-Packard OfficeJet Series 700;

Sep  3 22:47:33 Charlie kernel:    device registered to IEEE1284.4
protocol layer as link mlcpp0

on Kernel 2.2.19 (SuSE Linux 7.2)

Jul  8 18:32:19 Charlie kernel: parport0: PC-style at 0x378
[SPP,PS2,EPP,ECPEPP,ECPPS2]
Jul  8 18:32:19 Charlie kernel: parport1: PC-style at 0x278 (0x678)
[SPP,ECP,ECPEPP,ECPPS2]
Jul  8 18:32:19 Charlie kernel: parport_probe: failed
Jul  8 18:32:19 Charlie kernel: parport0: no IEEE-1284 device present.
Jul  8 18:32:19 Charlie kernel: parport_probe: succeeded
Jul  8 18:32:19 Charlie kernel: parport1: Printer, Hewlett-Packard
OfficeJet Series 700
Jul  8 18:32:19 Charlie kernel: IEEE1284.4 protocol layer for Linux
installed
Jul  8 18:32:19 Charlie kernel: ieee12844pp: IEEE1284.4 device found on
parport1:
Jul  8 18:32:19 Charlie kernel:    Hewlett-Packard OfficeJet Series 700;

Jul  8 18:32:19 Charlie kernel:    device registered to IEEE1284.4
protocol layer as link mlcpp0

to konw I use vmware 2.0.3 (nexttime dateing up to  2.04)

tile now I started and stoped the ieee12844 and ieee12844pp in the SuSE
lpd script ( starting after parport-probe )

tile now I only was printing (use scanning 4 times a year, do it in
Windows)
It worked good, often from Netscape after the 3d page I hade problems
(i'm used from Windows, after a reboot, it worked)

now I dit
    rmmod  vmppuser
    rmmod  parport_pc
    rmmod  parport

after lsmod no more Printing-modules left. (see INSTALL)
try to connect the ptal-mlcd now:
    reading your installation instructions for the HP OfficeJet
    parameter 'par' = parport   means for me parport1
    so I do :
    ptal-mlc par:1 -alias mlcpp1 -base 0x278
a ptal-hp mlc:par:1 brings a list of errors

    ptal-mlc par:1 -alias mlcpp0 -base 0x278
a ptal-hp mlc:par:1 brings also a list of errors

You have an idea ?
Doesn't mean the number after par the parport?
see my //-ports
I have 2 // ports, the 1e ist empty (no more printer) on the 2d a HP
Officejet 710

if you need any more information please ask for.

Charlie