Re: [hpoj-devel] xojpanel

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

On Tuesday 05 December 2000 19:06, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> Hi, Joe.
>
> Joe Piolunek wrote:
> > There wasn't any real improvement after changing the port
> > type. Without the
> > usenibble=1 option, xojpanel still fails to start 1/25 times
> > averaged over
> > 500 attempts to execute.
>
> That's strange.  So are there any error messages in syslog related to this?
> If I know where it fails, then I might know what needs to be fixed.  You
> could also try adding the "debug=1" parameter when loading ieee12844pp.o.
>

You asked earlier about the circumstances when this happens, but I didn't 
send it. Sorry about that. The no-starts occur seemingly at random without 
any special situation that I can identify.

There don't seem to be any related error messages unless I use debug=1, which 
produces a very large number of them. /var/log/messages receives about 185 
lines every second that xojpanel is running.

Here are a few lines from /var/log/messages that may be helpful. The presence 
of the printer's ID string seems to be related to the number of xojpanel 
no-starts.  It also seems related to the time the no-starts occur, but that's 
hard to be sure of. The device ID is the message that most stands out, but 
there are a lot of messages to look at, and I could have missed something 
more important.

Dec  6 10:39:04 tumbleweed kernel: c4842368: event=9. 
Dec  6 10:39:04 tumbleweed kernel: get_nibble(c4842368): nibble=0x6. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=11. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=6. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=9. 
Dec  6 10:39:04 tumbleweed kernel: get_nibble(c4842368): nibble=0xB. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=11. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=6. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=9. 
Dec  6 10:39:04 tumbleweed kernel: get_nibble(c4842368): nibble=0x3. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=11. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=6. 
Dec  6 10:39:04 tumbleweed kernel: mlcpp0: Got device ID string: 
<MFG:Hewlett-Packard;MDL:OfficeJet Series 
600;CMD:MLC,PCL,PML;CLASS:PRINTER;REV:4.03b;> 
Dec  6 10:39:04 tumbleweed kernel: mlcpp0: usebecp=0. 
Dec  6 10:39:04 tumbleweed kernel: do_neg(c4842368,mode=0x10): in_1284=1, 
neg_mode=0x04. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=23. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=27. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=0. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=2. 


> > cat /proc/parports/0/devices showed this:
> > IEEE1284.4 device
> > lp
>
> I noticed that situation too when playing around with printing the other
> day.  It seems dangerous to me, even though I could still print, so that's
> why I added a note in color_printing.txt recommending to change the port
> from /dev/lpX to /dev/null.
>.

I was able to print before with the two devices on the same port, though it 
seemed like only one device at a time could use the port. The file 
parport.txt in the 2.2.16 kernel documentation seems to say that multiple 
device drivers can co-exist at the same parallel port. They don't seem to be 
able to use the port simultaneously, though.


> (regarding patch's error messages)

> I just looked at a hex dump of the message I got back from the mailing
> list, and I didn't see any null bytes in the message.  Perhaps your mail
> client is adding them when you save attachments?  You could always remove
> the offending character before patching.
>
> Has anybody else seen this problem, where patch complains that "patch
> unexpectedly ends in middle of line"?

Looking at the files with kedit, there was a single space on the last line. 
Removing the space allowed the patches to be applied without errors. I don't 
know how the space got there, but It  may very well be the mailer I use. It's 
the new kmail that's part of kde2. Nearly everything in kde 2.0 is buggy.
>
> I'm not sure why you couldn't add a delay between lines 1 and 2.  Did you
> try calling sleep(5 seconds or whatever) in between the two line requests
> in getPrinterLCDMessages?
>

We might have been having a misunderstanding. Maybe it was only me. 

The sleep() call did cause a delay when I finally tried to introduce one. It 
didn't prevent the no-start problem though.


-- 
Joe