>> = Adam Richter
> = Randy Dunlap
>> [...] 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.
[...]
>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 am suggesting that usb/printer.c use the parport
application programming interface, like usb/uss720.c does.
I don't want to touch the high level parport code.
>Do serial printers go thru the parport interface?
>Do SCSI printers go thru the parport interface?
serial and scsi printers are not use a parallel interface.
In contrast, the USB printer standard is really just a USB parallel
port standard (although it does not allow you to do everything
that a parallel port can), so all USB printers essentially look like
parallel port printers.
>. 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).
I don't know what you mean by "USB has a serial port in
the system." If you mean that USB electrically transmitted as
a serial protocol across four conductors, I don't see the relevance
of your point. Even at the level of the OHCI or UHCI registers,
the quantum of transfers is at least in bytes.
struct parport_operations provides for block transfers,
so I do not think that using the parport interface would cause
data to be copied more slowly.
>. Anything about IRQs would be different.
usb/uss720.c seems to pass 0 as the IRQ number to the
relevant parport routines, and, presumably, that works (although
I do not have a uss720 device handy).
>And maybe rename usb/printer.c to usb/usbprinter.c?
>But we know from experience that Linus wouldn't like that
>or approve it.
Can you please point me to a statement by Linus where he
says he opposes naming the usb printer driver consistently with
the way most of of the usb drivers are named?
>Why do we need to change the name?
Currently, a user looking at the list of loaded modules does
not see any indication that this is a usb driver. It looks misleading
like it is a generic high level printer driver. As a general
rule of thumb for any software, anything that is likely to decrease
the amount of technical support calls that a product using the software
would generate and has no other drawbacks will makes the software
easier to use.
>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?
I hope not. That is not what I was suggesting or why.
(By the way, it really simplifies things like the automated generation
of initial ramdisks that need to have all of the ethernet
driver modules, but not all of the arcnet and fddi modules if there
is a naming scheme and directory hierarchy that categorizes the
different types of modules in a way that the correct categories can
be identified even as new drivers are added in subsequent kernel
releases.)
>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).
I believe you would get this in the process of using the
parport interface.
>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).
Yes, that is really by far the most useful thing.
I just thought that using the parport interface might make
it easier to use a parallel port dongle for other parallel port
uses, such as, say, talking to old parallel port zip drives,
running plip, talking to parallel port scanners, etc.
Because the USB "printer" standard only provides for
some of the functionality of a modern PC parallel port, some
functionality, such as speaking laplink by manipulating various
parport control lines is not possible with a dongle that only
implements the standard functionality. However, things that
just require a bidirectional parallel port should be supportable.
Also, at least one dongle that I have looked at exports a
vendor specific (0xFF class) interface, which I suspect probably
implements the other parallel port control features. I think it
would be possible to recognize these dongles by their vendor and
product ID's, and add code to fill in the matching parport_operations
fields when these dongles are detected.
>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 (?).
I agree that parsing the strings does not have to be in the
kernel. I would prefer that the generic parport interface adopted your
approach.
Also, I let me be clear that I think that about 95% of the
benefit to users is already achieved by your patch for simply reading
the IEEE-1284 device info (of the current interface, configuration and
alternate setting), since most users will use their USB parallel dongles
only to connect directly to one printer. I just think that we could
get a more functionality and maintainability by letting some of
the existing high level parallel port code drive this. For example,
we would not have to contend with behavioral differences like the
weird -ENOSPC errors that USB printer driver returns, but that are
not generated if the parallel port is built into the computer. So,
please just take this is a suggestion for the future. It is not
urgent. It is just something that might be useful that somebody might
want to take a whack at implementing.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
