Joel Becker wrote:
> Pete Zaitcev poked me with your URL because I have played with
> the USB device ID issues in the past
...
> I ran into this problem for a simple printing frontend for the New
> Internet Computer. My solution was an ioctl like LPIOC_GET_BUS_ADDRESS,
> but only for the device ID, as our appliance has but one USB bus. The
> patch is attached, and surely can be extended to respond with the bus id
> as well.
Hi, Joel. Thanks for the heads-up, although you neglected to attach the
patch. :-)
> I am sure (because I do it already) that you can already manage
> your high/medium _GET_ queries via /proc/bus/usb/devices. I do not know
> if the corresponding _SET_ items are available via usbdevfs. I think
> the solution here really depends on your taste in the "ioctls are ugly"
> vs "/proc is ugly" war.
I'll look into the usbdevfs option, although I wanted to avoid the
complexity of juggling multiple device FDs. My other concern is that
I've noticed that usbdevfs doesn't seem to be allow me to get to the
device after printer.c has bound to the device. Or at least that appears
to be the case when using Adam Richter's usb-printer-id utility, which
does usbdevfs requests.
In any case, I really only "need" the high-priority items, so I'll start
with those. I'll also look into how libusb can help out, but at a minimum
I'll need to put in the LPIOC_GET_BUS_ADDRESS for that or the underlying
usbdevfs option to work.
> Doing the converse of LPIOC_GET_BUS_ADDRESS (retriving the lpX
> by an ioctl on the /proc/bus/usb/<busid>/<deviceid> file) would require
> a code restructure, as the current driver only holds the minor number as
> an index into an array. I didn't feel like going that far, when only a
> small number of minors were available for printing.
I'll let the "experts" handle that in 2.5. :-)
> I merely run
> through all /dev/usb/lpX entries until I find the one matching my
> requested device ID. Not the most efficient, but completes quickly
> until someone makes this better.
I do something very similar, except that I match the model field in the
device ID string, in contrast to the bus:device address that you referred
to as the "device ID".
> I haven't seen GET_DEVICE_ID caching the value, but I might have
> missed that in the code.
Evidently it has changed. In the 2.2.18 backport the device ID string is
read once during usblp_probe() and copied into user space in response to the
ioctl. However, in 2.4.7 at least, it's read both in usblp_probe() and
usblp_ioctl(). Sneaky. :-)
> I don't rely on the HP status values therein
> myself, so I don't worry about it. I don't know that caching gains all
> that much, as someone asking likely wants to know.
The problem is that some HP DeskJet 8xx models have bugs where they may
die if you request the device ID string from them after enumeration time.
This is related to the "quirk" bit for those models, which causes printer.c
to bind to 7/1/2 but not post any bulk-IN requests.
David
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
