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
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?
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
-----END PGP SIGNATURE-----
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/