Hi,
I have written a driver for the Konica webcam chip found in the
Intel YC76 webcam. It uses the usbvideo, so it just acts as a
miniport driver.
The patch is against 2.5.4-pre2 and can be found @
http://www.renegade.org.uk/konica/patch-2.5.4-pre2-konicawc.diff
I had to make a small change to
[[[Replied-by-CC-to-all with seemingly individual addresses demoted from CC to BC.]]]
Hi. May I ask? How wrong are these conjectures:
> [EMAIL PROTECTED] 02/07/02 11:12AM
> the SG driver, the mid-level
> and the low level drivers should avoid messing
> with the details of a SCSI command
Agr
I'm still working on this ethernet driver for a USB ADSL modem. Its
going pretty good, it works for the most part. I followed the model used
by most other drivers, with one read URB for incoming data. I set the
size of this urb's transfer_buffer to 3392, which is 64*53 - the least
common multiple
On Thu, 7 Feb 2002, Matthew Dharm wrote:
> On Wed, Feb 06, 2002 at 11:39:00PM +0100, Gérard Roudier wrote:
> > On Thu, 7 Feb 2002, Martin Wilck wrote:
> > > Just for curiosity about SCSI-4: If a SCSI-4 device answers an INQUIRY
> > > (even with only 36 bytes), won't it identify itself as a SCSI
Ah, finally got something to work properly...
Here's a patch against 2.5.4-pre2 that adds driverfs support to the USB
subsystem. It differs from my previous patches, in that this one works
well :)
First off, here's what a USB tree on my machine looks like right now:
| |-- 00:1f.2
|
Is the sym driver the only problematic one?
Matt
On Thu, Feb 07, 2002 at 12:29:04AM +0100, Gérard Roudier wrote:
>
>
> On Thu, 7 Feb 2002, Matthew Dharm wrote:
>
> > If you need 56 bytes for SCSI-4, then why not get 36 bytes, see if the
> > device is SCSI 4, then ask for the 56 bytes if it is
On Thu, 7 Feb 2002, Matthew Dharm wrote:
> If you need 56 bytes for SCSI-4, then why not get 36 bytes, see if the
> device is SCSI 4, then ask for the 56 bytes if it is.
Nobody disagreed with this proposal.
> Look, this issue is going to continue to haunt us as more and more
> "emulated SCSI"
On Thu, 7 Feb 2002, Alan Cox wrote:
> > > Possible, but not required for the initial INQUIRY
> >
> > The Linux SCSI layer performs a single INQUIRY for the device discovery
> > process. It was proposed to shorten this INQUIRY to 36 bytes.
>
> Which is fine. We do a 36 byte inquiry just like win
On Wed, 6 Feb 2002, Gérard Roudier wrote:
g >For my part, if I had a device that fails INQUIRY I would try to get
g >reimbursed and if not possible I would break it into pieces and throw it
g >far away. Software is hard to maintain. Any additional code or complexity
g >adds possible bugs for a lo
On Wed, Feb 06, 2002 at 11:39:00PM +0100, Gérard Roudier wrote:
> On Thu, 7 Feb 2002, Martin Wilck wrote:
> > Just for curiosity about SCSI-4: If a SCSI-4 device answers an INQUIRY
> > (even with only 36 bytes), won't it identify itself as a SCSI-4 device,
> > thereby showing the driver that it sh
On Wed, Feb 06, 2002 at 10:26:29PM +0100, Gérard Roudier wrote:
> On paper, performing some short INQUIRY prior to a normal INQUIRY should
> not harm. Just it will change behaviour and may confuse drivers that snoop
> the INQUIRY data. Please do it first in development kernel so that this
> will a
If you need 56 bytes for SCSI-4, then why not get 36 bytes, see if the
device is SCSI 4, then ask for the 56 bytes if it is.
Look, this issue is going to continue to haunt us as more and more
"emulated SCSI" devices and busses appear. And, no version of windows will
make an initial INQUIRY reque
Ken, I did use speed=4, but I had an old CD-RW disk and I think that was
the problem. I tried a couple of newer CD-R and CD-RW disks and got 4x
every time.
Thanks again,
Rick Knight
([EMAIL PROTECTED])
Ken Hahn wrote:
>Did you try higher speeds and have it fail?
>Or did you forget to do speed
> > Possible, but not required for the initial INQUIRY
>
> The Linux SCSI layer performs a single INQUIRY for the device discovery
> process. It was proposed to shorten this INQUIRY to 36 bytes.
Which is fine. We do a 36 byte inquiry just like windows. If the device
turns out to be scsi-4 we can
On Thu, 7 Feb 2002, Alan Cox wrote:
> > A SCSI device that is broken for INQUIRY is definitely broken for SCSI.
> > FYI, we need at least 56 bytes of INQUIRY data to be possible for SPC2
> > (SCSI 4).
>
> Possible, but not required for the initial INQUIRY
The Linux SCSI layer performs a single
On Thu, 7 Feb 2002, Martin Wilck wrote:
> On Wed, 6 Feb 2002, Gérard Roudier wrote:
>
> g >For my part, if I had a device that fails INQUIRY I would try to get
> g >reimbursed and if not possible I would break it into pieces and throw it
> g >far away. Software is hard to maintain. Any addition
Here is a small patch...
--- linux-2.4.17.orig/drivers/usb/storage/transport.c Thu Feb 7 17:58:04 2002
+++ linux/drivers/usb/storage/transport.c Thu Feb 7 18:11:09 2002
@@ -1124,6 +1130,9 @@
if (result == -ENOENT)
return USB_STOR_TRANSPORT_ABORTED;
+ if (
On Wed, 6 Feb 2002, Matthew Dharm wrote:
> 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
> sn
> A SCSI device that is broken for INQUIRY is definitely broken for SCSI.
> FYI, we need at least 56 bytes of INQUIRY data to be possible for SPC2
> (SCSI 4).
Possible, but not required for the initial INQUIRY
___
[EMAIL PROTECTED]
To unsubscribe, use
Alan Cox wrote:
>
> > If understand Martin's proposal right, the SCSI layer should first issue
> > a standard 36 byte INQUIRY, even if an application or high level SCSI
> > driver wants to get more data; and if byte 4 of the returned data
> > indicates that the device can provide more data, a sec
Quoting Greg K-H <[EMAIL PROTECTED]>:
> With Linus starting to use BitKeeper to do kernel development, I've
> changed the way I submit patches to him. Because of this, I didn't send
> out copies of the patches to the mailing list.
It is actually quite convenient, I was able to track my latest p
On Thu, 7 Feb 2002, Martin Wilck wrote:
>
>
> > Generally, I think that the SG driver, the mid-level and the low level
> > drivers should avoid messing with the details of a SCSI command -- they
> > should simply pass a command to the device and return the result; any
> > implicit assumptions a
On Thu, 7 Feb 2002, Alan Cox wrote:
> > > SCSI layer proper. The only problem I can see is a broken device
> > > that violates the specs by truncating the additonal length
> > > parameter to the buffer length provided. Other than that,
> >
> > I have the documentation from a scanner vendor whic
> If understand Martin's proposal right, the SCSI layer should first issue
> a standard 36 byte INQUIRY, even if an application or high level SCSI
> driver wants to get more data; and if byte 4 of the returned data
> indicates that the device can provide more data, a second INQUIRY is
> issued.
P
[message to DataFab support forwarded to linux-usb-devel and linux-scsi]
Dear Spencer,
You may be pleased to learn that your KECF-USB reader works nicely
with Linux, too. To get it working, I "just" had to make a small
workaround that overrides the standard Linux behaviour to request
255 bytes
> Generally, I think that the SG driver, the mid-level and the low level
> drivers should avoid messing with the details of a SCSI command -- they
> should simply pass a command to the device and return the result; any
> implicit assumptions about a SCSI command may lead to unneccasry
> hassles.
Alan Cox wrote:
>
> > > SCSI layer proper. The only problem I can see is a broken device
> > > that violates the specs by truncating the additonal length
> > > parameter to the buffer length provided. Other than that,
> >
> > I have the documentation from a scanner vendor which indicates exactly
On Thu, 7 Feb 2002, abel deuring wrote:
adeuri >I have the documentation from a scanner vendor which indicates exactly
adeuri >this broken behaviour.
Your device doesn't handle small requests, mine large. That's brilliance!
However, as a workaround in usb-storage my patch _should_ do no harm.
C
Hi all,
With Linus starting to use BitKeeper to do kernel development, I've
changed the way I submit patches to him. Because of this, I didn't send
out copies of the patches to the mailing list.
So here's the list of changes that I sent off, and links to the patches
themselves if anyone is inte
> I think that if someone were to take a careful look at how ISO
> is done, and compare that to how it's supposed to be done
> (per the USB spec), some issues would turn up. And that's
> beyond the "Linux isn't real-time" class of issues that can
> prevent Linux from consuming (or producing) ISO
Did you try higher speeds and have it fail?
Or did you forget to do speed=4?
In addition.. the USB interface generally gets 4x (6x if the conditions are
right)
the PCMCIA interface gets the 8x and USB2 will get much higher speeds.
If you're getting 8x on the parallel port, that's exceedingly coo
Did you try higher speeds and have it fail?
Or did you forget to do speed=4?
In addition.. the USB interface generally gets 4x (6x if the conditions are
right)
the PCMCIA interface gets the 8x and USB2 will get much higher speeds.
If you're getting 8x on the parallel port, that's exceedingly coo
> > SCSI layer proper. The only problem I can see is a broken device
> > that violates the specs by truncating the additonal length
> > parameter to the buffer length provided. Other than that,
>
> I have the documentation from a scanner vendor which indicates exactly
> this broken behaviour.
So
On Thu, Feb 07, 2002 at 09:15:18AM -0600, Benjamin Pharr wrote:
> I got the following error when trying to compile 2.5.4-pre2:
This patch fixes this. I'll send it upstream later today.
thanks,
greg k-h
diff -Nru a/drivers/usb/inode.c b/drivers/usb/inode.c
--- a/drivers/usb/inode.c Thu
[EMAIL PROTECTED] wrote:
>
> Here is a patch for usb-storage that approaches the problem
> like this:
>
> - Submit a 36-byte INQUIRY.
> - Check additional length in response.
> - If the device tells us it provides more than 36 bytes,
> INQUIRY again, setting the length to the number of bytes
>
Here is a patch for usb-storage that approaches the problem
like this:
- Submit a 36-byte INQUIRY.
- Check additional length in response.
- If the device tells us it provides more than 36 bytes,
INQUIRY again, setting the length to the number of bytes
the device promises to deliver.
36 matches
Mail list logo
