> if the device reported that it was a scanner type. > ... no IEEE1394 sbp2 or USB Mass-Storage device > will ever do, by definition.
Hi. May say I'm ignorant enough that I failed to follow this particular statement? I thought Usb bInterfaceClass ...SubClass ...Protocol = x 08 06 50 meant Scsi over Usb = as arbitrary as Scsi anywhere, no? > will also nicely cover the IEEE1394 people, > who have been facing the same problem. May I ask? Which problem are we meaning to solve here? I thought this problem had Microsoft market power as its root cause, broken into four key parts, namely: 1) Microsoft Windows commonly begins by issuing x 12 0 0 24 0 i.e. Inquiry for up to x24 (36) bytes. 2) Microsoft Windows commonly ignores the additional length field (the byte at offset 4). 3) For IEEE 1394 (aka FireWire, iLink, ...) connections, Microsoft Windows commonly doesn't issue op x12 Inquiry at all, choosing instead to emulate op x12 Inquiry from the 1394 plug 'n pray data. 4) People say if a device works with Windows what's wrong with Linux? I guess I can swallow that we can't fix (4), but then without data I'm left wondering how much of each of (1), (2), and (3) actually does account for the observable plug 'n pray troubles? Is there any point in fixing (1) without also fixing (2)? Is there any point in fixing (1) and (2) without also fixing (3)? Re (2), I know I've seen the emulated Scsi of the boot Ata drive in Windows leave the first 8 bytes of op x12 Inquiry data unchanged. Whatever the host had in the buffer beforehand remains there afterwards: thus the host, wittingly or unwittingly, decides the additional length, not the device. Given this works for the boot drive, I wonder how many other devices work the same way. > consider requesting 36 bytes only in the first place, > and then examine the "Additional Length" field > in the data returned to see if it is > 32. > If yes, the INQUIRY could be repeated with a larger transfer length. This proposal fixes (1) but not (2), not (3), and not (4). Hope this helps, thanks in advance, cluelessly yours ... Pat LaVarre P.S. Please reply to me person-to-person if reply-to-all was Not correct netiquette here. Me, I'm listening to email reflected after having been sent to <[EMAIL PROTECTED]>. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
