mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Brad Hards <bhards@bigpond.net.au>
To: Pete de Zwart <dezwart@froob.net>,
	Linux Kernel Mailing List <Linux-Kernel@vger.kernel.org>
Subject: Re: 2.4.19: drivers/usb/printer.c usblpX on fire
Date: Sun, 11 Aug 2002 10:52:25 +1000	[thread overview]
Message-ID: <200208111052.25488.bhards@bigpond.net.au> (raw)
In-Reply-To: <20020811000340.GF27819@niflheim>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 11 Aug 2002 10:03, Pete de Zwart wrote:
> Cool, thanx Jesse, I always wondered what the history was behind it and
> how to achieve it.
>
> Here is another query:
>
> If each printer had their own set of error codes, what would be the way to
> implement their display from the kernel?
>
> Would each printer have to have their own module if they had a non-standard
> list of error codes or would we simply ignore them and state that the
> ill conforming printer is on fire?
There is more than one way of getting information over the printer connection.

If you think about old-style centronics type parallel connections, there are 
data pins that can provide 8-bit parallel transfers. There are also some 
status pins (no paper, busy, on-fire, whatever). Clearly there will never be 
enough pins on a real system to indicate every combination that might be 
possible ("cyan toner nearly empty", "jam in duplexer unit", "C5 envelope 
tray at 42%"). So you need another way. One option is to make the parallel 
transfer mechanism bi-directional, and do both data and status transfers over 
the same 8-bit parallel pins. Then you can establish a protocol for this (eg 
IEEE-1284 variants).

When you want to map this type of usage to USB, you can indicate some things 
over a "get_status" query at the USB level (which is basically mapping the 
old status pins), and you can just pass the data up to a normal printer 
system (which doesn't care whether it is talking to the printer over the 
traditional /dev/lpX device or a USB emulation.

So the kernel doesn't care about most of the error codes (since it isn't 
interpreting the data stream), but there are some things that are noted for 
historical reasons. Those things (like "out of paper" turn out to be widely 
supported (or if not, are at least set to benign values). All the "unique" 
error codes are a problem for userspace.

Does this make sense?

Brad
- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9VbVJW6pHgIdAuOMRAmvXAJ9lWcnGN24F6tyJEOUoID/1fl4oUQCgovse
oPsfs1E7GHh1jbUjCYUiiTg=
=qENi
-----END PGP SIGNATURE-----


  reply	other threads:[~2002-08-11  0:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-09 22:00 Jesse Pollard
2002-08-11  0:03 ` Pete de Zwart
2002-08-11  0:52   ` Brad Hards [this message]
2002-08-11  1:36     ` Pete de Zwart
2002-08-11  3:30       ` Brad Hards
  -- strict thread matches above, loose matches on Subject: below --
2002-08-09  6:03 Pete de Zwart
2002-08-09  8:20 ` Mikael Pettersson
2002-08-09 17:10   ` Samuel Flory
2002-08-09 20:44     ` Pete de Zwart
2002-08-13  2:53       ` Bill Davidsen
2002-08-11 20:18     ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200208111052.25488.bhards@bigpond.net.au \
    --to=bhards@bigpond.net.au \
    --cc=Linux-Kernel@vger.kernel.org \
    --cc=dezwart@froob.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®