Yes, oops, my mistake!
It is probably Lexar's fault and this is probably a hideous workaround,
but appending these to unusual_devs.h seems to do the "trick":
UNUSUAL_DEV( 0x05dc, 0xb013, 0x0000, 0x9999,
"Lexar Media",
"JumpDrive Trio",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_INQUIRY),
UNUSUAL_DEV( 0x05dc, 0xa300, 0x0000, 0x9999,
"LEXAR MEDIA",
"JUMPDRIVE2",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_FIX_INQUIRY),
I'm not sure if there are many devices with "broken" (meaning: not
matching the usb vendor and product strings) INQUIRY responses? Getting
them to work and automatically appear on the desktop with updfstab would
be nice.
The problem is that, rom a short discussion on kudzu bugzilla, updfstab
*has* to use the info in /proc/scsi/scsi, since the info in
/proc/bus/usb/devices has no information about the block device that the
USB storage unit is "mapped" to.
Adding UNUSUAL_DEV entries for every such device seems stupid (I'm
guessing that Windows does not use SCSI INQUIRIES, so vendors do not care
about that?) and, of course, a pain in the behind.
Would it make sense at all to str(n)cmp the USB vendor and product strings
with the appropriate parts of the device's own INQUIRY response and
"patch" the inquiry response if they do not match? This should
"automatically" take care of situations like this, but I have absolutely
no idea if it breaks other things...
Cheers!
Spiros
On Mon, 2004-08-02 at 20:17, Matthew Dharm wrote:
On Mon, Aug 02, 2004 at 07:58:35PM -0400, Spiros Papadimitriou wrote:
> > If I understand correctly, the INQUIRY response is filled in from the
> > strings which, in lsusb, correspond to the iManufacturer and iProduct
> > fields? These are set fine for all three devices.
>
> That is not correct. The INQUIRY response is only filled in like that for
> devices which do not support INQUIRY directly directly (i.e. sddr09, etc.).
>
> Your devices do not fall into that category.
>
> If they did fall into that category, they would get their strings from the
> unusual device list entry for that device. None of the entries in that
> table use the word 'generic'.
>
> > Also, if I am guessing correctly, the sg_inq output (see followup email)
> > indicates that it is the "if(data[0]&0x20)" in fill_inquiry_response()
> > that is "responsible" for this.
> >
> > Any idea why this is happening for two out of three jumpdrives? All
> > three jumpdrives light up fine and mount fine (if that means anything).
> > What does "not connected" (comment in fill_inquiry_response()) mean in
> > this context?
>
> That's dead code which should be removed. It's a code path which is
> impossible to hit.
>
> Matt
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
