Hi Adam,
[snip]
> I don't understand why the USB printer driver does not interface
> through the standard Linux parport driver, which I believe
> already provides
> some mechanism through /proc for this, and I believe it
> included some provision
> for things like daisy chaining multiple parallel devices on
> the same cable (such
> as a ZIP drive and a printer). However, if we really do need
> to have a
> separate device for USB printers, then an ioctl would be a
> fine approach,
> although I wish we could be consistent with regular parallel
> port access.
[snip]
> > So I've added a simple ioctl to printer.c so that a
> > printing program can
> > determine what printer it is talking to.
> > Until shown otherwise, I'm going to claim that this is a good
> > solution
> > for printer apps/spoolers/filters because they will have the file
> > (like /dev/usb/lp0) open but they won't know or care about
> > /proc/bus/usb/001/003
> > or --interface, --config, etc.
>
> Yes, I agree.
>
> > I considered adding the DEVICE_ID string to
> > /proc/bus/usb/devices, but
> > I don't think this is the right place for it. If I were
> > to add it to /proc,
> > it would be in a more printer-specific location.
>
> That is fine, although I wish:
> (a) that the usb printers just used the standard parport
> interface, and
> (b) that the module would be named something
> with "usb" in it, like parport_usb.
Some unification could be "the right thing," although
Tim Waugh wasn't sure whether it should be done or how it
should be done when I brought this up to him earlier this week.
It sounds to me like you are suggesting 2 large things here.
Please correct me if I'm wrong.
Lg#1. USB printer access to be merged into the parport drivers.
(I hope that I misunderstood this part. It sounds gross to me.)
Do serial printers go thru the parport interface?
Do SCSI printers go thru the parport interface?
Are you suggesting that the USB printer driver should
abstract the low-level bit-moving data interface so that
it looks like the parport driver interface?
. The standard parport interface is a =parallel= port
interface that is byte-wide, one byte at a time, and
USB is a packet-structured protocol.
. The standard parport interface has a parallel port in
the system. USB has a serial port in the system and
maybe a parallel port in the printer (but not necessarily).
. Anything about IRQs would be different.
And maybe rename usb/printer.c to usb/usbprinter.c?
But we know from experience that Linus wouldn't like that
or approve it.
Why do we need to change the name?
There was some discussion on lkml about modules being
installed into a flat modules/ directory instead of
modules/{misc,scsi,usb} etc. Is this going to happen?
If it's in the kernel, the name doesn't matter.
If it's a module, it's in /lib/modules/<KERNELVERSION>/usb.
So why add "usb" to its name?
Lg#2. USB printer driver to use the same /proc/sys/dev/parport/*
procfs interface & data structures for the IEEE 1284 DEVICE_ID
string (substrings).
When I looked at the parport code a few days ago, I didn't
see its use of the DEVICE ID string in procfs and autoprobe.
I do now.
My goal was to tell a printer app/spooler/filter more info about
what kind of printer device it had been told to use (to open).
The printer "app" is given the complete DEVICE ID string
and can parse it at will. The kernel does no string parsing
(and hence doesn't build "/proc/sys/dev/usbparport/*" as is done
for parport).
It wasn't about trying to provide PnP support based on IEEE
1284 Device ID substrings above & beyond the USB vendor:product
ID codes & descriptor info.
Maybe my goal was incorrect (?).
~Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
