Hi Adam,
I've finally found some time to reply to you about this.
(see below)
> >> = 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.
=====
parport_usb may be appropriate when it exposes that interface.
[snip]
> >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.
=====
I guess that makes sense (but I haven't looked at it very
closely). I wonder why it wasn't done like that very early.
> >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?
=====
Nope, I was extrapolating based on experience.
Granted maybe my extrapolation wasn't accurate.
He did strongly oppose renaming the usb/serial/ directory
to usb/usbserial/ (but I can't point you to that email
either; it was a private email and I don't keep all of the
email that I receive or send).
I don't agree with the phrase "the way most of of the usb drivers
are named". By my tally there are 22 drivers that don't
have the 3-letter sequence "usb" in their (file)names and 9 that do.
And for usb/printer.c, it registers itself as "usblp", so
'lsmod' and 'cat /proc/bus/usb/drivers' will be different
for it. Similar for scanner.c registered as "usbscanner".
Similar for usbkbd.c registered as "keyboard".
> >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.
=====
Whatever. It's not worthy of an argument and Linux drivers
aren't consistent about this.
[Meaning: I will accept a patch to change the name; this does
not guarantee that Linus will accept the patch.]
[snip]
> >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.
=====
That would be a good thing then.
> >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.
=====
I think that one reason for this discussion is that I don't
see parallel port dongles as that important, but I've been
known to be wrong before.
> 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."
My summary:
a. We should evolve usb/printer.c into using and exposing the
parport API.
b. We should rename usb/printer.c.
c. The ioctl() patch for IEEE 1284 Device ID strings that I
posted last week is OK and I will send it to Alan & Linus.
d. This is material for after 2.4. (I know Tim Waugh said this.
Did you say this also? I can't find it if you did, but I
thought you did.)
I have added this to my USB 2.5 jobs list.
Are you going to be contributing any patches for these?
~Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
