On Tue, 3 Aug 2004, Spiros Papadimitriou wrote: > 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),
These entries shouldn't be added. The US_FL_FIX_INQUIRY flag is really intended for devices that don't support INQUIRY at all. > 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. There are some; I've seen logs sent in by other users where the INQUIRY strings don't match the USB strings. It's not clear why you think that makes the devices "broken" in any way. It's quite possible, for example, that the USB interface and the drive hardware were made by two different manufacturers and then assembled and sold as a single unit by an OEM. In cases like that it makes sense for the two sets of strings to be different. > 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. That's not true. For an example of how to perform the mapping using only the information in /proc/bus/usb/devices plus sysfs, see this thread: http://marc.theaimsgroup.com/?l=linux-usb-devel&m=109147449719112&w=2 Furthermore, all this information is available in hotplug events. The fstab file could be updated by a hotplug script. > 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. Not to mention that it completely prevents programs from retrieving the actual INQUIRY data from the device. Some programs might be interested in other parts of the data besides the strings, but they wouldn't be able to get at it. > 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... No, it doesn't make sense. A driver is supposed to do its best to ferry data back and forth between programs and devices. It's not supposed to change the data just because some programs don't like what they get. Also, the INQUIRY string fields are generally shorter than the USB strings. So the strings would have to be truncated and still wouldn't match the way you want. Alan Stern ------------------------------------------------------- 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
