On Sat, 2007-03-10 at 15:39 -0800, Phil Dibowitz wrote:
> while (bytes = read((int)fh, buf, SIZE)) {
> printf("writing %d bytes (%d)\n",SIZE,++i);
> if (usb_interrupt_write(udev, OUT_EP, buf, bytes, 2) < 0) {
read can return -1, at which point you stuff -1 i
On Sat, 2007-03-03 at 11:44 +0100, Laurent Pinchart wrote:
> I'm trying to find a way to synchronise the Linux system clock with a device
> clock using the USB frame counter as a shared clock.
In a related scenario I have an USB device that periodically sends its
device clock over USB and I want
On Wed, 2006-12-20 at 10:55 +1100, Aras Vaichas wrote:
> I'm at a loss to understand the status code. Can someone point me to where I
> can decode this?
With the help of /usr/include/asm/errno.h, you can translate the error
numbers to error names.
Documentation/usb/error-codes.txt then documents
On Sun, 2006-08-06 at 14:10 -0700, Randy.Dunlap wrote:
> It was just posted to the linux-pci m-l on Aug-04 and has not
> been acted on.
I'm a bit worried that just storing a gzipped file as usb.ids will
confuse users. Storing it as usb.ids.gz would make it more clear that it
is a compressed file,
On Wed, 2005-09-21 at 15:35 +0800, Yu Zhenshen wrote:
> I have tried all host controller interfaces: ohci, ehci and uhci, all of
> them works the same, except the output messages differ:
> For EHCI, the dmesg output is:
This is obviously not ehci, as the P18F2455 only supports low and full
sp
control transaction requests required by save
and restore asynchronously.
Signed-off-by: Thomas Sailer, <[EMAIL PROTECTED]>
diff --git a/drivers/usb/misc/uss720.c b/drivers/usb/misc/uss720.c
--- a/drivers/usb/misc/uss720.c
+++ b/drivers/usb/misc/uss720.c
@@ -3,8 +3,8 @@
/*
* us
/*
* uss720.c -- USS720 USB Parport Cable.
*
- * Copyright (C) 1999
- * Thomas Sailer ([EMAIL PROTECTED])
+ * Copyright (C) 1999, 2005
+ * Thomas Sailer ([EMAIL PROTECTED])
*
* This program is free software; you can redistribute it and/or modify
* it
On Mon, 2005-02-21 at 12:36 -0500, John Leimgruber wrote:
> It does say that only 2 channel playback works in on Mac systems...
The OSS API usb audio driver also only supports two channels, if you
want 5.1, use the ALSA usb audio driver
> I attached some info below that might help if anyone is
On Thu, 2004-11-11 at 13:03 +0100, Christian Iversen wrote:
> Signed-off-by: Christian Iversen <[EMAIL PROTECTED]>
All 3 applied to sf cvs
---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorl
On Fri, 2004-03-19 at 17:38, David Brownell wrote:
> "usbbmodules" is part of "usbutils" though. I sent out a patch to
> usbutils 0.11 a while ago that fixed the ridiculous timeouts for
> the "lsusb" program, but it didn't touch "usbmodules" (which I've
> just disabled on all my systems, since la
All,
the attached patch for the USB OSS audio driver works around an
apparently common (because windows apparently works around it too) USB
audio descriptor bug.
I've tested it with a micronas UAC3556B eval board that features such
buggy descriptors.
Thanks,
Tom
--- drivers/usb/audio.c.orig 200
On Tue, 2004-02-24 at 15:05, Clemens Ladisch wrote:
> BTW: A Plantronics headset (0x047f/0x0ca1) and the Griffin iMic
> (0x077d/0x07af) have a similar bug.
Hm, haven't found this in alsa in the linux kernel 2.6.3.
Also, I do have a Griffin iMic and it works for me without kludge...
strange...
T
All,
the Mirconas UAC355x audio chips don't currently work with my driver
(haven't tried alsa), because it announces both playback and capture
being adaptive, while only playback is really adaptive, capture is
asynchronous. So we need a quirk to handle this.
How do we handle this best? In the dri
Thanks.
> bNrChannels 6
Hm, the OSS driver doesn't really support more than 2 channels, as the
OSS API is more or less stereo only.
ALSA should be better suited for this, but I don't know too much about
their USB driver...
Tom
-
please also post the decoded USB audio descriptor, using lsusb
Tom
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything fro
On Mon, 2003-09-15 at 05:25, David Brownell wrote:
> Thomas, this goes on top of the other patch. It fixes several
> other lint warnings/bugs in lsusb; it was the only file with
> those problems. How correct is that HID parsing? :)
I don't know :)
I've applied most of your patch, thanks.
Tom
2003-06-30 17:08:26.0 +0200
@@ -105,6 +105,8 @@
* functionality. Tested and used in production with the emagic emi 2|6
* on PPC and Intel. Also fixed a few logic 'crash and burn' corner
* cases.
+ * 2003-06-30: Thomas Sailer
On Wed, 2002-07-10 at 16:29, Oliver Neukum wrote:
> Here:
> spin_lock_init(&ps->lock);
> INIT_LIST_HEAD(&ps->async_pending);
> INIT_LIST_HEAD(&ps->async_completed);
> init_waitqueue_head(&ps->wait);
> init_rwsem(&ps->devsem);
>
> you unconditionally reinit locks
..
On Tue, 2002-07-09 at 23:48, Oliver Neukum wrote:
> Here we have an open with no protection at all against reentrancy.
> The comment is absolutely bogus as open can sleep. Very bad.
What problem is there if usbdev_open is reentered? You failed to explain
this. I agree that the GFP_KERNEL is a po
Johannes Erdfelt wrote:
> usb_control_msg() is probably what he wants. It waits.
Yes. But still we should probably have control queueing for
the uhci's (possibly at the HCD level?)
Think about multi-interface devices, where all interfaces have
different drivers that do not know about each other
Brad Hards wrote:
> The problem appears to be broken descriptors. You need a real developers to
> help you with this:
> usbaudio: warning: found 2 of 1 logical channels.
> usbaudio: no idea what's going on..., contact
> [EMAIL PROTECTED]
doesn't look like a message I coded 8-)
Anyway, if you su
Even though I originally implemented it, the sanity check removed
by the patch below seems wrong to me...
Tom
--- audio.c.origTue Apr 9 20:49:44 2002
+++ audio.c Tue Apr 9 20:50:14 2002
@@ -3524,7 +3524,7 @@
return;
case PROCESSING_UNIT:
- if
Greg KH wrote:
> Oh, didn't realize that, sorry. Does anyone use it today?
Yes, extensively.
eg. usbstress on usb.in.tum.de,
baycomusb (www.baycom.org)
Tom
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.n
Duncan Sands wrote:
> races with disconnect. In usb.c there is the usb_disconnect
> function which first calls driver->disconnect, then only later
Ah ok, you're concerned about the driver ioctl getting called
via usbdevfs. The proc_ioctl interface wasn't added by me,
so I don't know the origina
Oliver Neukum wrote:
> A look through usbdevfs shows that there's no locking.
???
usbdevfs has devsem to prevent these races (it's a rwsem,
reading used to access the device, disconnect requires taking
the semaphore for writing, thus locking out readers).
That's the way USB locking works. The
[EMAIL PROTECTED] schrieb:
> Another problem with usbdevfs is that it really is an aggregate of three
> seperable functions.
> - The drivers and devices files, which should IMHO be in proc on their own
> - Informing on connected drivers
> - Access as generic devices
I do not believe that separat
Oliver Neukum schrieb:
> The only problem you have then is that a generic driver would need to give up
> its devices whenever a new driver is probed. But that problem is not harder
> than dealing with disconnect.
A generic driver also prohibits things like lsusb. lsusb IMO has been
useful
so far
Bryce Nesbitt found a case where audio handled the
OSS API wrongly. This is basically his patch fixing
it.
Please apply.
Tom
--- audio.c.origMon Jun 18 15:05:56 2001
+++ audio.c Tue Jun 19 10:47:49 2001
@@ -12,6 +12,8 @@
* the Free Software Foundation; either version 2 of the
JE, please apply
oops, forgot to attach the patchfile
On Thu, 7 Jun 2001, Steve Tell wrote:
>
> Greetings from Chapel Hill, North Carolina, USA...
>
> I recently bought a USB parallel-port adaptor cable and discovered that is
> used a Lucent uss720 chip. Naturaly I had to get it working wi
Dan Streetman schrieb:
> Here is a patch which makes usbdevfs use the mount options.
Thanks
Tom
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Matt Eccleston schrieb:
>
> The particular problem I have is that the uhci driver refuses low speed bulk
> transfers, thus you can't always submit interrupt packets as bulk packets.
>
> This check could of course be removed, but I don't think its prudent to have HCDs
> worry that their BULK tran
Roman Weissgaerber schrieb:
> Also if a HCD would use static, typed Endpoint-Descriptors there
> would be a type mismatch.
> (OHCI uses different HW-queues for int
> and bulk transfers so if you mix them there could be some quirks).
Do you know how the WDM OHCI driver works? Because there the AP
Dan Streetman schrieb:
> 2.Polling interval
> The polling interval for bulk URBs is as-fast-as-possible. The device must
I thought in case of a NAK the HC should wait for the next frame to try again,
but maybe I'm wrong
> 3.Guaranteed polling
> Interrupt URBs are (supposed to be) guarantee
Dan Streetman schrieb:
> The URB is not automatically resubmitted by the HCD.
BTW, what is the difference between such a nonresubmitted
interrupt and a bulk transfer? Unless I'm missing something
they look exactly the same on the wire, so why add another
redundant interface?
Tom
__
Dan Streetman schrieb:
> Ok, here is a patch that adds interrupts (via interrupt URBs, instead of bulk
> URBs) to usbdevfs. This takes a different approach than the last
> (usbdevfs-interrupt) patch. It allows using interrupt-type URBs via usbdevfs,
> and maintains the correct polling interval
"Adam J. Richter" wrote:
> I noticed this as I was writing a patch to implement a
> USBDEVFS_INTERRUPT ioctl for doing transfers from interrupt pipes
> (like USBDEVFS_BULK). I have attached the patch, in case anybody is
Why do you need this? You can already poll interrupt endpoints by
u
matthew denner wrote:
> i guess what this comes down to is: is this a problem within the USB support
> under Linux or is it something incorrect in the quickcam driver in how it's
> using the USB stuff?
I don't think this is a general Linux USB problem, I can use two mice
without problem.
Tom
37 matches
Mail list logo