Re: PATCH[linux-usb-devel] Firmware Frustration

Ken, I was able to blank and then burn a CD using my Backpack CD ReWriter and the bpckusb driver/patch. Worked great with only one minor problem. I was only able to get 2x speed. This is a newer drive and I am able to get up to 8x on Win2K or the parallel port under Linux (I have a laptop tha

[linux-usb-devel] Re: Scsi op x12 definitions

> 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

[linux-usb-devel] Re: Hack to make Datafab KECF-USB work

> Umm.. I'm talking about the SCSI probing function... it requests 255 bytes > of then throws it away after processing the first 36. The remainder never > gets sent to anywhere (if I'm reading the code right). It would be up to > the scanner driver to request an INQUIRY data again... Which it w

[linux-usb-devel] Scsi op x23 definitions

> SCSI command 0x23 to the device ... > What command is that? In short: 1) I've heard Microsoft Windows thinks the vendor-unique op x23 of Scsi Dasd should mean "Read Format Capacities", which in turn should behave something like as described in copies of

[linux-usb-devel] Re: Hack to make Datafab KECF-USB work

Umm.. I'm talking about the SCSI probing function... it requests 255 bytes of then throws it away after processing the first 36. The remainder never gets sent to anywhere (if I'm reading the code right). It would be up to the scanner driver to request an INQUIRY data again... Which it would do

[linux-usb-devel] Re: Hack to make Datafab KECF-USB work

> The Linux-SCSI people (now on the CC:) have rejected the idea of making all > INQUIRYs 36-bytes. Apparently, there are some HBA drivers which want to > snoop the INQUIRY data in the vendor-specific area for some reason. For one the full INQ data is needed by some scanner drivers > I'm thinkin

Re: [linux-usb-devel] iso automatically resubmitted?

> > > Ok, it *can* be automatically resubmitted, but how? > > > > Usually through linking urb->next fields in a ring. > > Ah. So I submit a ring, using the ASAP flag for all of them. Their > frames point into, say, a ring buffer kept by the driver. Hm... and then > the user process which read

[linux-usb-devel] Re: Hack to make Datafab KECF-USB work

Martin -- What you've found is an issue I'm still trying to find the best solution to. The Linux-SCSI people (now on the CC:) have rejected the idea of making all INQUIRYs 36-bytes. Apparently, there are some HBA drivers which want to snoop the INQUIRY data in the vendor-specific area for some

[linux-usb-devel] Hack to make Datafab KECF-USB work

Hi, I recently bought the above device (07c4/a400/113). It is a CompactFlash + Microdrive Reader. Seems to be so new that it is in no hardware darta base yet. Couldn't get it to work on Linux first (nor with bulk transport nor with datafab transport). After some playing with usb-robot and usb-

Re: [linux-usb-devel] iso automatically resubmitted?

On Wed, 2002-02-06 at 12:04, David Brownell wrote: > > Ok, it *can* be automatically resubmitted, but how? > > Usually through linking urb->next fields in a ring. > Ah. So I submit a ring, using the ASAP flag for all of them. Their frames point into, say, a ring buffer kept by the driver. Hm.

Re: [linux-usb-devel] iso automatically resubmitted?

> "After completing one URB, the next one can be > automatically submitted. This is especially useful for ISO transfers: > You only have read/write the data from/to the buffers in the completion > handler, the continuous streaming itself is transparently done by the > URB-machinery." > > Ok, it

Re: PATCH[linux-usb-devel] Firmware Frustration

Thanks Ken, That patch worked. I was even able to see the Backpack drive with cdrecord -scanbus. I'll burn a CD later and let you know how that works. Thanks again, Rick Knight ([EMAIL PROTECTED]) Ken Hahn wrote: >How embarassing. > >It will work with all of the firmwares being built. > >I sc

Re: [linux-usb-devel] driver module loading

On Wed, Feb 06, 2002 at 03:01:25PM +0530, Ravi Kumar B S wrote: > hi i found why the driver is not listed as being used. when i connect > the device. the probe function is getting called. in that first it makes > check on the device class signature. there it is immediately returning > as i am g

Re: [linux-usb-devel] driver module loading

Dmitri wrote: >Quoting Ravi Kumar B S <[EMAIL PROTECTED]>: > >>Dmitri wrote: >> > >>>In worst case, presence of printk's moves the memory around, and you have >>>a stray pointer somewhere that reads or writes past the allocated >>>memory. With printks in place, this pointer happens to point to a

Re: [linux-usb-devel] driver module loading

Quoting Ravi Kumar B S <[EMAIL PROTECTED]>: > Dmitri wrote: > >In worst case, presence of printk's moves the memory around, and you have > >a stray pointer somewhere that reads or writes past the allocated > >memory. With printks in place, this pointer happens to point to a safe > >place; withou

Re: [linux-usb-devel] driver module loading

Dmitri wrote: >Quoting Ravi Kumar B S <[EMAIL PROTECTED]>: > >>i am using the usb bluetooth driver. i have configured the usb bluetooth >>driver as a module. i have two versions of the driver. one with the >>comments, extensive debug statements(printks) etc. the other one is the >>one which is