hpoj-devel — HPOJ development/support list

Re: [hpoj-devel] insmod fails

[Jarl F. <ja...@di...>]

On Sun, 7 Jan 2001, John Simpson wrote:

> Hi
> 
> I'm having trouble installing the ieee12844 modules from hpoj-0.7
> 
> My kernel seems to be configured correctly; the output from
> /proc/config.gz shows the following:
> 
> CONFIG_PARPORT=m
> CONFIG_PARPORT_PC=m
> CONFIG_PNP=y
> CONFIG_PNP_PARPORT=m

Mine shows:
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y                                                                      
CONFIG_PNP=y
CONFIG_PNP_PARPORT=m                                                                     

> Im using SuSe 7.0 kernel 2.2.16

I use the same system.

But it should work with your config too :-?

Jarl

[hpoj-devel] insmod fails

[John S. <xf...@di...>]

Hi

I'm having trouble installing the ieee12844 modules from hpoj-0.7

My kernel seems to be configured correctly; the output from
/proc/config.gz shows the following:

CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PNP=y
CONFIG_PNP_PARPORT=m

The parport modules all load ok, but the ieee12844 modules fail with
unresolved symbols as follows:

ieee12844.0 - global_bh_lock, synchonize_bh
ieee12844pp,o - same, plus tqueue_lock, mlcp_unregister, mlcp_register

Im using SuSe 7.0 kernel 2.2.16

Any help gratefully received

Thanks

John Simpson
http://dialspace.dial.pipex.com/john_simpson

[hpoj-devel] for the IEEE1284 developers

[Jarl F. <ja...@di...>]

Hi guys.

I just read a newsgroup and saw a release of a EPP utility, maybe it will
help you the ongoing development of the IEEE1284 driver, if not please
ignore this message.

The utility can be found at 
http://www.scn.org/~nedu/eppio.html

Jarl

Re: [hpoj-devel] About initscripts-printd.tgz

[Burkhard K. <bu...@bu...>]

Timothy Lee:
[Charset big5 unsupported, skipping...]

Hi Timothy,

as long as you are using big5 charset me (and probably others)
won't be able to read your messages. 

Regards, 

Burkhard
-- 
Burkhard Kohl		bu...@bu...

Re: [hpoj-devel] 2.4 kernel issues

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

On Thu, Jan 04, 2001 at 01:05:42AM +0100, Burkhard Kohl wrote:

> It seems the initial state of the parport DIRECTION registers depends
> on the hardware - that's why the other poster did not encounter
> these probs.

Odd.  parport_pc should set it to forward when it initialises.

Tim.
*/

Re: [hpoj-devel] 2.4 kernel issues

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

On Thu, Jan 04, 2001 at 01:40:29AM +0100, Burkhard Kohl wrote:

> What would be the proper replacement for a statement like
>       outb(PAR_ECP_CONTROL_BIDIRECTIONAL, ECONTROL(l->port));
> when switching from ecp forward to reverse? Or is that now obsolete
> because it could handled by the parport_pc module? Unfortunately
> we can't use the ieee1284 functions.

(If you're not using the in-kernel parport support, why do you need to
replace it?)  parport_pc doesn't even use the ECR for this (rightly or
wrongly), it just does it by hand.

As I understand it, the reason you need to avoid the IEEE 1284
functions is to do with blocking.  Is that right?  In 2.4 there was a
new function 'parport_set_timeout' which was for handling this
requirement.

> >From the parport driver sources I see that there is no BECP support=20
> for now - do you expect to have it in the near future? In ieee12844pp.c
> there is actually only one event (41) referring to becp when switching
> from ecp reverse to forward when the peripheral is idle.

It's not something that there's ever been demand for; in fact, you're
the first person who's even mentioned it. :-)

Tim.
*/

Re: [hpoj-devel] 2.4 kernel issues

[Burkhard K. <bu...@bu...>]

Tim Waugh
> On Sun, Dec 31, 2000 at 11:10:34AM -0800, David Paschal wrote:
> 
> > > It looks
> > > that access to some parport registers is now considered lowlevel 
> > > enough to justify hiding it from driver developers.
> > I can understand removing direct register access from individual drivers,
> > but I can't understand not providing an alternative interface.
> 
> It's because of other architectures that don't even have those
> registers.
> 

Thanks Tim for commenting on this. I certainly see your argument.

I hope you don't mind if I ask you some questions, maybe you 
can help:

What would be the proper replacement for a statement like
      outb(PAR_ECP_CONTROL_BIDIRECTIONAL, ECONTROL(l->port));
when switching from ecp forward to reverse? Or is that now obsolete
because it could handled by the parport_pc module? Unfortunately
we can't use the ieee1284 functions.

From the parport driver sources I see that there is no BECP support 
for now - do you expect to have it in the near future? In ieee12844pp.c
there is actually only one event (41) referring to becp when switching
from ecp reverse to forward when the peripheral is idle.

Regards,

Burkhard
-- 
Burkhard Kohl			bu...@bu...

Re: [hpoj-devel] 2.4 kernel issues

[Burkhard K. <bu...@bu...>]

David Paschal
> It looks like it failed during the termination phase (event 23) of getting
> the device ID string (do_neg(mode=0x04)), which is before it even attempts
> to change the ECR.  The problem might have to do with the polling-timer
> changes, because when it's waiting for a signal response from the
> peripheral, it spins in a poll loop for a bit, then reschedules itself
> in the task queue, which as you discovered has been changed.

I think the debug messages were a bit misleading. I resolved this
to be a failure during the transmit mode negotiation phase due 
to the parport being set to reverse mode. This can be cured by
inserting a 
	parport_data_forward(l->port);
statement just before the 
	parDataWrite(l, ...);
statement of event 0. (or inside the parDataWrite() function call).

It seems the initial state of the parport DIRECTION registers depends
on the hardware - that's why the other poster did not encounter
these probs.

Besides that I have learned a lot about parport transmit mode 
negotiation ;-) 

But now the driver runs into another problem - the peripheral answers
the hosts MLCConfigSocket command for socket 1 with MLCError 7 after
a succesful MLCInit/InitReply pair:

	mlcpp0: Got device ID string: <MFG:HEWLETT-PACKARD;MDL:OFFICEJET R40;CMD:MLC,PCL,PML,SCL;CLS:PRINTER;DES:Hewlett-Packard OfficeJet R40;CMT:OFFICEJET PRO;SERN:SGD98AH3MWWZ;VSTATUS:$HB0$FC0,ff,DN,IDLE,CUT;LSS:01;LDF:1;LDE:1;>
	mlcpp0: usebecp=0.
	do_neg(c9068320,mode=0x10): in_1284=1, neg_mode=0x04.
	put_ecp_byte(c9068320): byte=0xCE, cmd=1.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0xCD, cmd=1.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x08, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x03, cmd=0.
	s_idle(c9068320): Reverse data available.
	parport0 (mlcpp): use data_reverse for this!
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x09.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x80.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x03.
	mlc: configuring socket
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x0D, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	put_ecp_byte(c9068320): byte=0x07, cmd=0.
	put_ecp_byte(c9068320): byte=0x01, cmd=0.
	put_ecp_byte(c9068320): byte=0x08, cmd=0.
	put_ecp_byte(c9068320): byte=0x06, cmd=0.
	put_ecp_byte(c9068320): byte=0x08, cmd=0.
	put_ecp_byte(c9068320): byte=0x06, cmd=0.
	put_ecp_byte(c9068320): byte=0x00, cmd=0.
	s_idle(c9068320): Reverse data available.
	parport0 (mlcpp): use data_reverse for this!
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x08.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x00.
	ecp_read_byte(c9068320): byte=0x7F.
	ecp_read_byte(c9068320): byte=0x07.
	mlc: mlcpp0: Got MLCError 07
	mlc_getsockopt: c411e134
	mlc_sendmsg: c411e134 credit=0, flags=0
	mlc_release: c411e134
	do_neg(c9068320,mode=0x00): in_1284=1, neg_mode=0x10.
	ieee12844pp: unregistering device at parport0 (link mlcpp0)

To me this seems to be a gross misunderstanding between host and
peripheral. From the specs I can't see no reason why this should
happen. 

For now I am rather clueless.

Burkhard
-- 
Burkhard Kohl			bu...@bu...

Re: [hpoj-devel] Problems wih hpoj 635c sourcecode

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

On Sunday 31 December 2000 15:10, David Paschal wrote:
> Johan Laagland wrote:
> > After answering your reply I remembered another bug in the
> > hpoj-0.6 source in xojpanel. The exact location of the
> > bitmapfile was not given. The program made errors when the
> > bitmap was not in the working directory. Therefore I give
> > the bitmap a location in a directory under /usr/local/share
> > and changed the sourcecode with this location. Now it is
> > working fine from any location in the directory tree.
>
> Hi, Johan.  Please try version 0.7, which was released a few weeks ago.
> It has a much nicer version of xojpanel (thanks to Joe Piolunek) which
> fixes the problem you described.
>
> David
>

David:
..
I've started working again on an 'xojpanel replacement' that should be much 
more functional. 

An earlier version that I had put together just got too big and complicated, 
so I started over from scratch. The newer version looks a lot better, I think.
It may still be too early to decide exactly how the application should look 
or what it should contain, but the more thought put into it in the beginning, 
the better, IMHO.

I have the application building into a new directory under hpoj-0.7/apps/. 
It's a little too early to make the code available. There isn't much of it 
yet.

On my site are screenshots of the two windows created so far. These are 
'previews' created by the Qt designer.

The web server has been a little messed up, so if you don't see a page with 
OfficeJet GUI screenshots, try again later.

http://pages.cthome.net/jsp/hpoj-linux-gui/index.html

Is it worth continuing in this direction? Let me know what you think.


Johan:

If you keep looking, you may still find things in the project you can fix.

-- 
Joe

Re: [hpoj-devel] Re: ptal-printd init script for RedHat

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

Daniel Gun wrote:
> It may not detect hot-plugging, but my PSC500 is almost never turned on when
> I start the computer.  I turn it on just before I am about to scan or print.
> So, either Windows polls it at print and/or scan time, or else it has some
> other way to know that the device was turned on.
> 
> In the former case, the answer would be to have hpoj poll the device each
> time it is about to print or scan.
Oh, sorry, I thought you were talking about the "plug-and-play" detection
where it discovers a new peripheral connected and starts installing the
drivers.  Once the drivers are installed, I think they try to initialize
the peripheral the first time you try to use it.  Actually, the hpoj
drivers also reinitialize the printer every time a new connection to the
peripheral is made (when there wasn't already one).  The problem is that
when an attempt is made to load ieee12844pp.o, it queries parport_probe to
find out what peripheral was connected at the time parport_probe was loaded,
and refuses to load in the first place no suitable peripheral was detected.
I think this behavior could be fixed by hacking the init_module function
(which has two different versions depending on the kernel version).  However,
if init_module were made more promiscuous like this then one could run into
problems if there were non-OfficeJet peripherals on other parallel ports.

If all goes well, then I will be able to release a new user-mode I/O driver
soon, which will make this whole issue a moot point anyway.  :-)

David

[hpoj-devel] Re: ptal-printd init script for RedHat

[DG <dg...@um...>]

> From: pa...@rc... (David Paschal)
> Hi, Daniel.
>
> Daniel Gun wrote:
> > Does the device try to communicate with the computer when it is turned
on?
> > If so, the module could look for this signal and add the device when
turned
> > on.
> IEEE1284-compliant peripherals power up in compatibility mode with no such
> peripheral-initiated communication that you suggested.  In some cases you
> might notice a change in the status (peripheral-to-host) lines, but it's
> not guaranteed since different host and peripheral parallel ports have
> different pull-up or pull-down resistors.
>
> > Windows can handle having the device turned on or off arbitrarily.  How
is
> > it done?
> Windows tries to read the device ID string from the peripheral when it
> boots and when you invoke the "Add New Hardware" wizard, just as
> parport_probe does when it is insmoded.  I don't think Windows
automatically
> detects hot-plugging of devices on the parallel port the way it does with
> USB devices.

It may not detect hot-plugging, but my PSC500 is almost never turned on when
I start the computer.  I turn it on just before I am about to scan or print.
So, either Windows polls it at print and/or scan time, or else it has some
other way to know that the device was turned on.

In the former case, the answer would be to have hpoj poll the device each
time it is about to print or scan.

--
Daniel
ZZZ-dgun-ZZZ-@-ZZZ-umpire.com-ZZZ
(Remove the Z-'s to reply)
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

[hpoj-devel] init script

[Maurizio S. <sch...@li...>]

Where could I find the RedHat init script for hpoj-0.7?

Re: [hpoj-devel] OID lists

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

Jarl Friis wrote:
> I can imagine the usage of one OID is the same among different devices,
> but what I ment was: the *set* of OIDs is not the same among different
> devices, right? hence the OID-table is device dependent. So it would
> probably be in order to make a global table of all known OIDs, and then
> for each device make a table (representing a subset of the global
> list) that tells which OIDs the device can use. the device-specific subset
> could eventually just be a list of indexes to the global table.
Yes, strictly speaking, the *set* of OIDs may vary between devices, depending
on which devices you're talking about.  One could certainly expect devices
in the same series to support the same set of OIDs, for example, G55/G85/G95.
There is also a fair amount of overlap between groups of series.  For example,
on http://hpoj.sourceforge.net/suplist.shtml, the devices which say "not yet"
under "Scan" all use PML to set scan parameters and start scanning.  The
core set of scan OIDs is pretty consistent across this class of devices,
but there are also a few device-dependent scan OIDs which may not be very
important for our purposes.  The same is true for devices which support
PC-assisted fax-send, fax-receive, and copy.

Actually, I'm not planning on having a master OID table compiled into the
code the way it is with ojlib.  Instead, applications will pass
#defines for the OIDs they need to PTAL, which will dynamically build a
list of OIDs that the application is actually using.  That way, only the
OIDs that are actually used are compiled into the application, and they
should be compiled in only once as long as they are "created" in only one
place.  (I think this will make more sense once I have some working code
to show you.:-)

David

[hpoj-devel] OID lists

[Jarl F. <ja...@di...>]

On Sun, 31 Dec 2000, David Paschal wrote:

> Jarl Friis wrote:
> > Good idea, the OID tables are device dependent, different devices
> > recongnise different OIDs, correct?, so there should probably be one
> > OID-table for each device or devicegroup, it would be smart if one could
> > autodetect what kind of device, and then use the related table for that,
> > the one on the web/in the pmloidentries.c is for OfficeJets I guess.
> There actually is a fair amount of consistency in the most important OIDs,
> but there are also some device-specific OIDs which may not be worth worrying
> about for our purposes.

I can imagine the usage of one OID is the same among different devices,
but what I ment was: the *set* of OIDs is not the same among different
devices, right? hence the OID-table is device dependent. So it would
probably be in order to make a global table of all known OIDs, and then
for each device make a table (representing a subset of the global
list) that tells which OIDs the device can use. the device-specific subset
could eventually just be a list of indexes to the global table.

Jarl

Re: [hpoj-devel] 2.4 kernel issues

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

On Sun, Dec 31, 2000 at 11:10:34AM -0800, David Paschal wrote:

> > It looks
> > that access to some parport registers is now considered lowlevel=20
> > enough to justify hiding it from driver developers.
> I can understand removing direct register access from individual drivers,
> but I can't understand not providing an alternative interface.

It's because of other architectures that don't even have those
registers.

Tim.
*/

Re: [hpoj-devel] Problems wih hpoj 635c sourcecode

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

Johan Laagland wrote:
> After answering your reply I remembered another bug in the 
> hpoj-0.6 source in xojpanel. The exact location of the 
> bitmapfile was not given. The program made errors when the 
> bitmap was not in the working directory. Therefore I give 
> the bitmap a location in a directory under /usr/local/share 
> and changed the sourcecode with this location. Now it is 
> working fine from any location in the directory tree.
Hi, Johan.  Please try version 0.7, which was released a few weeks ago.
It has a much nicer version of xojpanel (thanks to Joe Piolunek) which
fixes the problem you described.

David

Re: [hpoj-devel] some port of PML to ptal

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

Jarl Friis wrote:
> I thought when there is no sign of this in the cvs, it was a
> job to be done, anyway I got a deep knowledge of MLC, PML, so I will
> eventually be able contribute on something else.
Sorry about that.  I will make it clearer on the web what the status is
of in-progress items, but actually I had already said "in progress" for
the item "Add PML support to PTAL" on the TODO page.

> But I still wonder why the CVS is on the release-0.7 stage... is it only
> used for realeases? not development?
I prefer not to commit new developments to CVS until they are fairly
functional.  That makes it easier to make interim releases (as was the case
with 0.7) without having to "back out" file revisions or set up branches.

> Are you working full-time on hpoj?
No, but I'd like to.  :-)  For now I'm mostly working on it in my spare time
since I have other responsibilities at work, but out of necessity some of it
does end up spilling into company time.

> Good idea, the OID tables are device dependent, different devices
> recongnise different OIDs, correct?, so there should probably be one
> OID-table for each device or devicegroup, it would be smart if one could
> autodetect what kind of device, and then use the related table for that,
> the one on the web/in the pmloidentries.c is for OfficeJets I guess.
There actually is a fair amount of consistency in the most important OIDs,
but there are also some device-specific OIDs which may not be worth worrying
about for our purposes.

David

Re: [hpoj-devel] 2.4 kernel issues

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

Burkhard Kohl wrote:
> Somewhere between test8 and test12 the parport interface has changed
> substantially enough to break the ieee12844 modules.
> 
> I have tried to take care of this changes by adapting ieee12844pp.c
> and managed to compile with the patch appended. 
Hi, Burkhard.  Thanks for looking into this problem.  (I'm actually replying
to your earlier version of this message that didn't make it to the mailing
list.)

> But my compilate does not work properly:
> When I try ./hpo list_pml I get:
> 	IEEE1284.4 protocol layer for Linux installed
> 	ieee12844pp: init_module.
> 	mlcpp_attach: New device found on parport0
> 	ieee12844pp: IEEE1284.4 device found on parport0:
> 	HEWLETT-PACKARD OFFICEJET R40;
> 	device registered to IEEE1284.4 protocol layer as link mlcpp0
> 	mlcpp_attach: links: 1.
> 	parport0 (mlcpp): use data_reverse for this!
> 	do_neg(c9067d1c,mode=0x04): in_1284=1, neg_mode=0x04.
> 	c9067d1c: event=23.
> 	PAR_WAIT_SET_CLEAR(l=c9067d1c,set=0x0088,clear=0x0050):
> 	timed out waiting for event=23!
> 	mlcpp0: mlcpp_intr ERROR -110
> 	state=2 event=23 reset=1 recv=0 rcv=0 send=0
> 	do_neg(c9067d1c,mode=0x00): in_1284=1, neg_mode=0x04.
> 	c9067d1c: event=23.
> 	PAR_WAIT_SET_CLEAR(l=c9067d1c,set=0x0088,clear=0x0050):
> 	timed out waiting for event=23!
> 
> David, can you make sense out of these messages? Does it mean that
> I did not successfully set the ECR to bidirectional? 
It looks like it failed during the termination phase (event 23) of getting
the device ID string (do_neg(mode=0x04)), which is before it even attempts
to change the ECR.  The problem might have to do with the polling-timer
changes, because when it's waiting for a signal response from the
peripheral, it spins in a poll loop for a bit, then reschedules itself
in the task queue, which as you discovered has been changed.

> The message "use data_reverse for this!" stems from 
> parport_pc_write_control in the parport_pc module which means, that
> now an inline parport_pc_data_reverse() is calling parport_pc_frob_control()
> with the value of 0x20. This is just a cosmetical change but it 
> looks that the parport interface in future 2.4 kernels will change
> further and more breakage has to be expected. I have the feeling
> that ieee12844pp.c will need some redesign to work with 2.4.
All this madness of a constantly changing/breaking kernel interface is one
of many reasons why I'm trying to move towards a user-level driver approach.
I'm actively pursuing a solution to that problem at work, and if all goes
well (keep your fingers crossed!) I may be able to provide a solution in the
near future.  Of course, for now we should do what we can to fix the current
code just in case things don't work out in our favor.

> It looks
> that access to some parport registers is now considered lowlevel 
> enough to justify hiding it from driver developers.
I can understand removing direct register access from individual drivers,
but I can't understand not providing an alternative interface.

> A further note on compiling the kernel modules: egcs 1.1.2
> is now the recommended compiler. But on the other hand many 
> distributions supply users with gcc 2.95.2. Linux/Documentation/Changes 
> strongly recommends to use 2.95.x with the -fno-strict_aliasing option.
> I thus added EXTRA_CFLAGS to ieee12844/Makefile which has to be 
> activated by gcc 2.95.x users. Is there a way to handle this via 
> configure?
That shouldn't be a problem.

David

[hpoj-devel] 2.4 kernel issues

[Burkhard K. <bu...@bu...>]

Hi everyone,

I tried to get hpoj-0.7 running with kernel 2.4.0-test12. I encountered
the same compiler errors someone else reported earlier to this list.
But after changing the ieee12844pp.c module accordingly (define 
PARPORT_CONTROL_DIRECTION, substitue parport_write_econtrol, and 
substitute queue_task(tq_scheduler) with schedule_task) I was not
able to run anything but ./hpo devid. ./hpo listpml would yield 
error -100 in mlcpp_intr and scanimage MLCError 7.

I thus tried to replace parport_write_econtrol with the original
code (outb(PAR_ECP_CONTROL_BIDIRECTIONAL 0x34, ECONTROL(l->port))
since using parport_write_control (as recommended by the original
poster) was not very sensible. This did not change the outcome.

With debugging turned on in ieee12844pp.o I see the following
log for ./hpo listpml:
	do_neg(c5067d9c,mode=0x04): in_1284=0, neg_mode=0x10.
	c5067d9c: event=2.
	c5067d9c: event=6.
	negotiate(c5067d9c,mode=0x04): rejected!
	mlcpp0: mlcpp_intr ERROR -100
	state=2 event=6 reset=1 recv=4 rcv=0 send=2
	do_neg(c5067d9c,mode=0x00): in_1284=1, neg_mode=0x04.
	c5067d9c: event=23.
	PAR_WAIT_SET_CLEAR(l=c5067d9c,set=0x0088,clear=0x0050):
		timed out waiting for event=23!

One further note on compiling the modules. The recommended compiler
for 2.4.0 kernels is now egcs 1.1.2. But with many distributions 
comes gcc 2.95.x. linux/Documentation/Changes strongly recommends
to use 2.95 with the -fno_strict_aliasing flag. I therefore suggest
to add an EXTRA_CFLAGS=-fno_strict_aliasing field to the makefile, 
which might be uncommented by gcc 2.95.x users.

Burkhard
-- 
Burkhard Kohl			bu...@bu...

Re: [hpoj-devel] Problems wih hpoj 635c sourcecode

[Johan L. <j.l...@ch...>]

David Paschal wrote:
> 
> Johan Laagland wrote:
> > Recently I downloaded the sourcecode hpoj-0.6 for my
> > HP OfficeJet for working with it under RH Linux 6.2.
> Hi, Johan.  0.7 was released recently, but I don't think it will fix any of
> the problems you raised:
> 
> > Problem 1.
> >
> > Printqueue stops and LC panel is frozen dead when printing
> > more than one job. When killing the xojpanel process
> > printing resumes normal operation.
> This is a known problem with the low-level drivers (ieee12844.o).
> For now the workaround is to kill xojpanel before printing.
> 
> > Problem 2.
> >
> > I'd like to scan with the OfficeJet so I downloaded the
> > sane sourcecode and applied your patch.
> Scanning is not yet supported with the model you have, but it's on my
> to-do list.

Hello David,

After answering your reply I remembered another bug in the 
hpoj-0.6 source in xojpanel. The exact location of the 
bitmapfile was not given. The program made errors when the 
bitmap was not in the working directory. Therefore I give 
the bitmap a location in a directory under /usr/local/share 
and changed the sourcecode with this location. Now it is 
working fine from any location in the directory tree.

Kind regards,

Johan Laagland,

The Netherlands.

Re: [hpoj-devel] Problems wih hpoj 635c sourcecode

[Johan L. <j.l...@ch...>]

David Paschal wrote:
> 
> Johan Laagland wrote:
> > Recently I downloaded the sourcecode hpoj-0.6 for my
> > HP OfficeJet for working with it under RH Linux 6.2.
> Hi, Johan.  0.7 was released recently, but I don't think it will fix any of
> the problems you raised:
> 
> > Problem 1.
> >
> > Printqueue stops and LC panel is frozen dead when printing
> > more than one job. When killing the xojpanel process
> > printing resumes normal operation.
> This is a known problem with the low-level drivers (ieee12844.o).
> For now the workaround is to kill xojpanel before printing.
> 
> > Problem 2.
> >
> > I'd like to scan with the OfficeJet so I downloaded the
> > sane sourcecode and applied your patch.
> Scanning is not yet supported with the model you have, but it's on my
> to-do list.

Hello David,

Thank you for answering my questions. I'll wait for the supporting
release.

Johan Laagland,
The Netherlands.

Re: [hpoj-devel] some port of PML to ptal

[Jarl F. <ja...@di...>]

On Sun, 31 Dec 2000, David Paschal wrote:

> Jarl Friis wrote:
> > I have ported some of the PML stuff to the ptal API.
> > 
> > until now I have ported getValue and setvalue, they are not thoroughly
> > tested, but I can get the LCD lines at least :-) porting xojpanel..???
> Hi, Jarl.  I've actually done a lot of this work already (adding PML
> support to PTAL).  I'm using a different design from ojlib, so I started
> from scratch rather than porting ojlib code, just as I did with PTAL itself.

I thought when there is no sign of this in the cvs, it was a
job to be done, anyway I got a deep knowledge of MLC, PML, so I will
eventually be able contribute on something else.

But I still wonder why the CVS is on the release-0.7 stage... is it only
used for realeases? not development?

> > I do not have the time to continue the development in January, but I might
> > do something in February, hope the code is good for soemthing, at least
> > inspiration :-)
> I got distracted from this lately dealing with I/O and printing issues in
> preparation for releasing 0.7, and I'll try to get back to it within the
> next couple of weeks.

Are you working full-time on hpoj?

> 
> > 2)How are the THREE bytes of errorcode (after the exec_code byte) supposed
> > to be interpreted when such are sent as a reply?
> According to the PML spec (which you can get by registering for a free
> membership at http://www.hp-developer-solutions.com), these three bytes are:

Thanks, that helped a lot.

> > I am currently working on adding the PML to the ptal, and I discovered
> > that the PML oids on the web are not the same as in the
> > ojlib/pmloidentries.c the difference are (at least) the two folloing
> > objects:
> I plan to significantly rewrite the web-based documentation once I finish
> obsoleting ojlib and (if everything goes well) ieee12844*.c.  In addition,
> I want to avoid coding knowledge of specific OIDs at the PTAL level, so
> the centralized OID table will either go away or move somewhere else in
> the codebase.

Good idea, the OID tables are device dependent, different devices
recongnise different OIDs, correct?, so there should probably be one
OID-table for each device or devicegroup, it would be smart if one could
autodetect what kind of device, and then use the related table for that,
the one on the web/in the pmloidentries.c is for OfficeJets I guess.

Jarl

Re: [hpoj-devel] Forking of ptal-printd

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

Timothy Lee wrote:
> Yes, I think you can exit upon failing to create the pipe.  As for the
> other run-time conditions you mentioned, here are my suggestions:
> 
>    * Failure to open the pipe / failure on select () ---- Just discard
>      the data
>    * Failure to open peripheral ---- can ieee12844pp.o force ieee12844.o
>      to re-scan for new peripherals???  If not, I'd say discard the data
Once ieee12844pp is successfully loaded, a rescan actually happens each time
an application tries to open a service on the peripheral if no other
application currently has any open channels, which is usually the case
since currently there are reliability problems otherwise.  :-)

>    * Failure to write data to the peripheral ---- maybe a retry
>      threshold, after which data are discarded?
It might make sense to retry the remainder of a partial write (which would
probably be best located in PTAL itself rather than in each application).
I don't think there's any point in retrying a completely failed write.

> One more thing, about the ieee12844.c and ieee12844pp.c:  the static
> variable *debug* should be initialized to 0.  Most end-users probably
> don't want to see messages popping up on their consoles.....  <grin>
I did make sure to initialize it to 0 when I added it to ieee12844pp.c.
Now that you mentioned it, I noticed that the one in ieee12844.c (in which I
haven't made any code changes of my own anyway) doesn't have an initializer.
I suppose it's a bad assumption that it gets initialized to 0 by default,
but that may be the case anyway since I haven't had any trouble with it.
Have you seen any situations where debugging was turned on by default due to
its being "initialized" to a garbage nonzero value?

David

Re: [hpoj-devel] some port of PML to ptal

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

Jarl Friis wrote:
> I have ported some of the PML stuff to the ptal API.
> 
> until now I have ported getValue and setvalue, they are not thoroughly
> tested, but I can get the LCD lines at least :-) porting xojpanel..???
Hi, Jarl.  I've actually done a lot of this work already (adding PML
support to PTAL).  I'm using a different design from ojlib, so I started
from scratch rather than porting ojlib code, just as I did with PTAL itself.

> I was considering if it were best placed in ptal-mlc.c or maybe even
> a new ptal-mlc-pml.c, currenctly its a mix of pml.c and ptal.c
My overall philosophy for PTAL, which I continued when adding PML support,
is to have the generic interface and common implementation in ptal.c,
MLC-specific implementation in ptal-mlc.c, and JetDirect-specific
implementation in ptal-hpjd.c.  That way, the differences in accessing
PC- and JetDirect-connected peripherals are hidden from applications which
use PTAL.

> I do not have the time to continue the development in January, but I might
> do something in February, hope the code is good for soemthing, at least
> inspiration :-)
I got distracted from this lately dealing with I/O and printing issues in
preparation for releasing 0.7, and I'll try to get back to it within the
next couple of weeks.

> There are some open question:
> 1)What are the TWO bytes in the begining of PML values of type String?
The symbol set (character set) identifier.

> 2)How are the THREE bytes of errorcode (after the exec_code byte) supposed
> to be interpreted when such are sent as a reply?
According to the PML spec (which you can get by registering for a free
membership at http://www.hp-developer-solutions.com), these three bytes are:
0x18 (ErrorCodeDataType)
0x01 (constant)
0x?? (ErrorValue, for example 0x83=ErrorUnknownObjectIdentifier)

> Does anyone know anything about the PML error codes that can turnup in
> request responses?
> Has it anything to do with the ones found on HP help page:
> http://www.hp.com/cposupport/multifunction/support_doc/bpu50364.html
Those are firmware assert (panic) codes which indicate serious hardware
failures or firmware bugs and are completely unrelated to the error codes
defined by the PML protocol.

> I am currently working on adding the PML to the ptal, and I discovered
> that the PML oids on the web are not the same as in the
> ojlib/pmloidentries.c the difference are (at least) the two folloing
> objects:
I plan to significantly rewrite the web-based documentation once I finish
obsoleting ojlib and (if everything goes well) ieee12844*.c.  In addition,
I want to avoid coding knowledge of specific OIDs at the PTAL level, so
the centralized OID table will either go away or move somewhere else in
the codebase.

(BTW, it's not necessary for people to CC me on messages they send to the
mailing list.  I CC myself when sending messages just to make sure I have
a copy of it in case it gets lost or delayed.)

David

Re: [hpoj-devel] SuSE RPMs (for HP OffJet) & sugg: rename ptal -> POrTAL

[Robert G. B. <rg...@ph...>]

Oops, helps if I actually attach the tarball...;-)

   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...