Mailinglist Archive: opensuse (4054 mails)
| < Previous | Next > |
Re: [SLE] epson rx620
- From: Dave Howorth <dhoworth@xxxxxxxxxxxxxxxxx>
- Date: Tue, 03 Jan 2006 14:55:19 +0000
- Message-id: <1136300119.1989.40.camel@xxxxxxxxxxxxxxxxxxxxxxx>
On Tue, 2006-01-03 at 10:18 +0100, Johannes Meixner wrote:
> Hello,
>
> On Jan 3 00:01 Dave Howorth wrote (shortened):
> > > > > I've bought an RX620
> ...
> > > The basic situation is that both Yast and CUPS claim the printer is
> > > configured and I can print raw text to it (cat some-file > /dev/usb/lp0)
> > > but when I try to print from an application or use Yast or CUPS test
> > > print they all think the print has finished but the printer does
> > > nothing.
>
> When you do
> cat some-file > /dev/usb/lp0
> you don't use the printing system at all.
> If the printer prints this way, it shows that the basic
> low-level data transfer via USB works.
> I.e. you know then that your USB system can send data to
> your printer (for example this would fail if wrong USB kernel
> modules are loaded or if USB kernel modules are missing).
OK
> When you print from an application or do the YaST or CUPS test print,
> you use the full printing system. See
> http://portal.suse.com/sdb/en/2004/05/jsmeix_print-cups-in-a-nutshell.html
> how the CUPS printing system works.
This looks useful - an expanded version of what's in the manual.
> > CUPS error log
> ...
> > I [02/Jan/2006:16:31:51 +0000] Started
> > filter /usr/lib64/cups/filter/rastertopips (PID 20234) for job 17.
> ...
> > E [02/Jan/2006:16:31:51 +0000] PID 20234 stopped with status 22!
>
> I.e. the filter /usr/lib64/cups/filter/rastertopips
> stopped with an error.
>
> This filter is not included in any of the Suse Linux packages.
OK, that's useful information.
> As fas as I know this filter is part of the Epson Avasys driver.
>
> Because of "lib64" you have a 64-bit architecture.
> Does the Epson Avasys driver really work on 64-bit architectures?
> What does the Epson Avasys documentation say about non-i386
> architectures?
I'll check tonight (I'm at work now).
> See for example
> http://portal.suse.com/sdb/en/2005/03/jsmeix_scanner-setup-93.html
> for an example about problems with a not-100%-free driver (iscan)
> on non-i386 architectures.
>
> I tested one Epson Avasys printer driver once on a i386 system
> and it shows that this software is somewhat broken-by-design:
> I set up a CUPS queue to print into a file but this nice
> proprietary driver didn't care how I had set up the queue.
> It simply spits out its printer specific binary stuff directly
> on my first USB printer (a real good PostScript printer)
> which printed tons of sheets with nonsense characters.
> On the other hand this indicates that their driver may work
> if the first USB printer is the right printer for their driver
> (e.g. when only one printer is connected to the system).
This would drive me mad if I was using it at work (I always go for
netwok printers there), but you're right it's the only printer on my
home PC.
> Since a long time I had desribed in detail in
> http://portal.suse.com/sdb/en/2003/11/jsmeix_print-info-for-manufacturers.html
> which conditions a driver software must meet so that we can
> integrate it into our products and the HP drivers show
> how successful such drivers can be.
> But we can neither itegrate the Epson Avasys printer driver
> into our products nor do we support broken-by-design software.
>
> Therefore you can only ask those who made this software
> how to use it on your (non-i386) system.
OK, I'll do that. And I'll ask the place where I bought it since they're
the ones that will have to refund the money if it doesn't work!
It sounds like a made a poor decision again. I'm throwing out an old HP
Laserjet 3100 because it's a Linux paperweight. Epson appeared to be the
optimal choice (http://www.linuxprinting.org/suggested.html). It sounds
like you're not fond of them; would you recommend anything else?
Or is it worth trying Gutenprint?
> > (1) /usr/lib64 everywhere but isn't some of the driver software 32-bit?
>
> Right!
> As far as I know their proprietary library (which includes all
> what is really interesting of this driver) is only 32-bit
> and therefore it may not work in a 64-bit environment.
>
> Some details (assuming you have an AMD 64-bit (x86_64) system):
Yes, I mentioned previously that I have an Athlon64, but I should have
restated it so the message is freestanding.
> On the one hand on x86_64 hardware 32-bit i386 software can work.
> But on the other hand 32-bit software requires 32-bit libraries.
> Only the kernel on x86_64 has a special interface to accept both
> 64-bit and 32-bit system calls.
> On x86_64 from user application down to the kernel interface
> (but excluding the actual kernel which is of course the same)
> 64-bit software and 32-bit software are totally seperated:
> 64-bit application -> 64-bit library -> 64-bit kernel interface
> 32-bit application -> 32-bit library -> 32-bit kernel interface
I understand this.
> Therefore you must either ask Epson Avasys for a 64-bit version
> of their driver or you must try to compile and link their driver
> only with 32-bit libraries.
> I don't know how their driver is linked with other libraries.
> If their 32-bit driver runs as a stand-alone 32-bit application
> it should work even on a 64-bit system.
I guess I'm going to have to get to understand yet more infrastructure
that I'll really like to be able to treat as a black box.
It seems obvious that with the current mix of 32-bit and 64-bit systems,
it makes sense to design a process boundary in between components with
different origins. Isn't CUPS designed that way? Running multiple
incompatible versions of libraries on systems is by no means a new
problem.
And I thought the whole point of having /usr/lib and /usr/lib64 was that
dumb 32-bit software would automatically link to the right libraries.
Now I guess I need to understand the build system.
> You can get rid of all 32-bit/64-bit problems when you simply
> install the 32-bit version of Suse Linux on your 64-bit system.
> This would be the same as if you install 32-bit Windows on your
> 64-bit system.
That's a depressing thought. I'd like a box where my printer just works
and my videos just play :)
Thanks again,
Dave
> Hello,
>
> On Jan 3 00:01 Dave Howorth wrote (shortened):
> > > > > I've bought an RX620
> ...
> > > The basic situation is that both Yast and CUPS claim the printer is
> > > configured and I can print raw text to it (cat some-file > /dev/usb/lp0)
> > > but when I try to print from an application or use Yast or CUPS test
> > > print they all think the print has finished but the printer does
> > > nothing.
>
> When you do
> cat some-file > /dev/usb/lp0
> you don't use the printing system at all.
> If the printer prints this way, it shows that the basic
> low-level data transfer via USB works.
> I.e. you know then that your USB system can send data to
> your printer (for example this would fail if wrong USB kernel
> modules are loaded or if USB kernel modules are missing).
OK
> When you print from an application or do the YaST or CUPS test print,
> you use the full printing system. See
> http://portal.suse.com/sdb/en/2004/05/jsmeix_print-cups-in-a-nutshell.html
> how the CUPS printing system works.
This looks useful - an expanded version of what's in the manual.
> > CUPS error log
> ...
> > I [02/Jan/2006:16:31:51 +0000] Started
> > filter /usr/lib64/cups/filter/rastertopips (PID 20234) for job 17.
> ...
> > E [02/Jan/2006:16:31:51 +0000] PID 20234 stopped with status 22!
>
> I.e. the filter /usr/lib64/cups/filter/rastertopips
> stopped with an error.
>
> This filter is not included in any of the Suse Linux packages.
OK, that's useful information.
> As fas as I know this filter is part of the Epson Avasys driver.
>
> Because of "lib64" you have a 64-bit architecture.
> Does the Epson Avasys driver really work on 64-bit architectures?
> What does the Epson Avasys documentation say about non-i386
> architectures?
I'll check tonight (I'm at work now).
> See for example
> http://portal.suse.com/sdb/en/2005/03/jsmeix_scanner-setup-93.html
> for an example about problems with a not-100%-free driver (iscan)
> on non-i386 architectures.
>
> I tested one Epson Avasys printer driver once on a i386 system
> and it shows that this software is somewhat broken-by-design:
> I set up a CUPS queue to print into a file but this nice
> proprietary driver didn't care how I had set up the queue.
> It simply spits out its printer specific binary stuff directly
> on my first USB printer (a real good PostScript printer)
> which printed tons of sheets with nonsense characters.
> On the other hand this indicates that their driver may work
> if the first USB printer is the right printer for their driver
> (e.g. when only one printer is connected to the system).
This would drive me mad if I was using it at work (I always go for
netwok printers there), but you're right it's the only printer on my
home PC.
> Since a long time I had desribed in detail in
> http://portal.suse.com/sdb/en/2003/11/jsmeix_print-info-for-manufacturers.html
> which conditions a driver software must meet so that we can
> integrate it into our products and the HP drivers show
> how successful such drivers can be.
> But we can neither itegrate the Epson Avasys printer driver
> into our products nor do we support broken-by-design software.
>
> Therefore you can only ask those who made this software
> how to use it on your (non-i386) system.
OK, I'll do that. And I'll ask the place where I bought it since they're
the ones that will have to refund the money if it doesn't work!
It sounds like a made a poor decision again. I'm throwing out an old HP
Laserjet 3100 because it's a Linux paperweight. Epson appeared to be the
optimal choice (http://www.linuxprinting.org/suggested.html). It sounds
like you're not fond of them; would you recommend anything else?
Or is it worth trying Gutenprint?
> > (1) /usr/lib64 everywhere but isn't some of the driver software 32-bit?
>
> Right!
> As far as I know their proprietary library (which includes all
> what is really interesting of this driver) is only 32-bit
> and therefore it may not work in a 64-bit environment.
>
> Some details (assuming you have an AMD 64-bit (x86_64) system):
Yes, I mentioned previously that I have an Athlon64, but I should have
restated it so the message is freestanding.
> On the one hand on x86_64 hardware 32-bit i386 software can work.
> But on the other hand 32-bit software requires 32-bit libraries.
> Only the kernel on x86_64 has a special interface to accept both
> 64-bit and 32-bit system calls.
> On x86_64 from user application down to the kernel interface
> (but excluding the actual kernel which is of course the same)
> 64-bit software and 32-bit software are totally seperated:
> 64-bit application -> 64-bit library -> 64-bit kernel interface
> 32-bit application -> 32-bit library -> 32-bit kernel interface
I understand this.
> Therefore you must either ask Epson Avasys for a 64-bit version
> of their driver or you must try to compile and link their driver
> only with 32-bit libraries.
> I don't know how their driver is linked with other libraries.
> If their 32-bit driver runs as a stand-alone 32-bit application
> it should work even on a 64-bit system.
I guess I'm going to have to get to understand yet more infrastructure
that I'll really like to be able to treat as a black box.
It seems obvious that with the current mix of 32-bit and 64-bit systems,
it makes sense to design a process boundary in between components with
different origins. Isn't CUPS designed that way? Running multiple
incompatible versions of libraries on systems is by no means a new
problem.
And I thought the whole point of having /usr/lib and /usr/lib64 was that
dumb 32-bit software would automatically link to the right libraries.
Now I guess I need to understand the build system.
> You can get rid of all 32-bit/64-bit problems when you simply
> install the 32-bit version of Suse Linux on your 64-bit system.
> This would be the same as if you install 32-bit Windows on your
> 64-bit system.
That's a depressing thought. I'd like a box where my printer just works
and my videos just play :)
Thanks again,
Dave
| < Previous | Next > |