Re: ulpt problem (USB_ERR_IOERROR)

On Saturday 04 July 2009 16:43:41 Patrick Lamaiziere wrote:
> Le Sat, 4 Jul 2009 09:45:40 +0200,
>
> Hans Petter Selasky <hselasky_at_c2i.net> a écrit :
> > > ulpt_write_callback:220: state=0x1 actlen=2889
> > > ulpt_write_callback:220: state=0x1 actlen=3023
> >
> > These two lines are interesting. Are these printed when doing the
> > same job?
>
> Yes.
>
> > If the actlen is not a factor of 64 in your case, the printer will
> > think that the document has ended. Could you verify that, that cups
> > is feeding too little data into the ULPT port?
>
> Sometime cups writes only a litle amount of datas:
>
> [Job 40] Read 161 bytes of print data...
> [Job 40] Wrote 161 bytes of print data...
> [Job 40] Read 251 bytes of print data...
> [Job 40] Wrote 251 bytes of print data...
> [Job 40] Read 162 bytes of print data...
> [Job 40] Wrote 162 bytes of print data...
> [Job 40] Read 86 bytes of print data...
> [Job 40] Wrote 86 bytes of print data...
> [Job 40] Read 3292 bytes of print data...
> [Job 40] Wrote 3292 bytes of print data...
> [Job 40] Read 43 bytes of print data...
> [Job 40] Wrote 43 bytes of print data...
> [Job 40] Read 4096 bytes of print data...
> [Job 40] Wrote 4096 bytes of print data...
>
> Cups uses a select() on the input file to print, reads the datas and
> writes them to the usb port until the input file is empty.
>
> There is no warranty that the amount of datas will be a factor of 64
> bytes.

It is not right to defragment the data in /dev/ulpt either. Maybe I can make a 
variant device, /dev/udlpt, that will automatically defrag the data.

What happens if you dd if=myjob.pcl.or.ps of=/dev/ulpt bs=1024

--HPS