On Sat, Feb 02, 2008 at 10:30:51PM -0500, Alan Stern wrote:
> On Sat, 2 Feb 2008, Matthew Dharm wrote:
>
> > On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote:
> > > IMO this indicates we shouldn't issue any clear-halts at all unless the
> > > device actually needs it. In general it's n
On Sat, 2 Feb 2008, Matthew Dharm wrote:
> On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote:
> > IMO this indicates we shouldn't issue any clear-halts at all unless the
> > device actually needs it. In general it's not a good idea to do a
> > clear-halt for an endpoint that isn't actu
On Sunday 03 February 2008 00:39:26 Jiri Kosina wrote:
> On Sun, 3 Feb 2008, Michael Buesch wrote:
>
> > Here's the current userspace implementation of the HAL:
> > http://bu3sch.de/gitweb?p=razer.git;a=blob;f=librazer/hw_deathadder.c;h=e76d9347552eb5ea33b524a82e33ba869f3e0b3f;hb=HEAD
> > The comm
Thanks for catching that :^)
Craig Nadler
Adrian Bunk wrote:
A bug every C programmer makes at some point in time...
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/gadget/printer.c b/drivers/usb/gadget/printer.c
index 9fdabc8..4f6bfa1 100644
--- a/drivers/usb/gadg
On Sun, 3 Feb 2008, Michael Buesch wrote:
> Here's the current userspace implementation of the HAL:
> http://bu3sch.de/gitweb?p=razer.git;a=blob;f=librazer/hw_deathadder.c;h=e76d9347552eb5ea33b524a82e33ba869f3e0b3f;hb=HEAD
> The commands changed slightly in latest firmware version and there's
> a
On Saturday 02 February 2008 23:46:29 Greg KH wrote:
> On Sat, Feb 02, 2008 at 11:31:02PM +0100, Michael Buesch wrote:
> > Hi,
> >
> > I am implementing a driver for Razer USB mice. These
> > mice are standard HID input devices with additional features
> > accessible through USB control commands.
On Sunday 03 February 2008 00:05:21 Jiri Kosina wrote:
> On Sat, 2 Feb 2008, Michael Buesch wrote:
>
> > I am implementing a driver for Razer USB mice. These mice are standard
> > HID input devices with additional features accessible through USB
> > control commands.
>
> Hi Michael,
>
> what d
On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote:
> IMO this indicates we shouldn't issue any clear-halts at all unless the
> device actually needs it. In general it's not a good idea to do a
> clear-halt for an endpoint that isn't actually halted; devices are
> prone to misinterpret
On Sat, 2 Feb 2008, Michael Buesch wrote:
> I am implementing a driver for Razer USB mice. These mice are standard
> HID input devices with additional features accessible through USB
> control commands.
Hi Michael,
what do the control commands look like? (or is there the source code of
your d
On Sat, Feb 02, 2008 at 11:31:02PM +0100, Michael Buesch wrote:
> Hi,
>
> I am implementing a driver for Razer USB mice. These
> mice are standard HID input devices with additional features
> accessible through USB control commands.
>
> My current prototype driver does this access in userspace
>
Hi,
I am implementing a driver for Razer USB mice. These
mice are standard HID input devices with additional features
accessible through USB control commands.
My current prototype driver does this access in userspace
via libusb, but this brings all kinds of issues while the
kernel driver and othe
On Sat, 2 Feb 2008, Robert Spitzenpfeil wrote:
> if I understand right you wanted me to make my system mimic this:
>
> Loop 3 times {
> Get-Max-LUN => STALL
> clear-halt(ep0)
> }
>
> I don't know how to hack usb-storage to run this very l
On Fri, 2008-02-01 at 15:17 -0800, Greg Kroah-Hartman wrote:
> Note, the module-init-tools package also needs to be changed to properly
> generate the depmod tables.
Noted.
Jon.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
A bug every C programmer makes at some point in time...
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/gadget/printer.c b/drivers/usb/gadget/printer.c
index 9fdabc8..4f6bfa1 100644
--- a/drivers/usb/gadget/printer.c
+++ b/drivers/usb/gadget/printer.c
@@ -1299,7 +1299,
On Sat, Feb 02, 2008 at 12:37:10PM +0100, Christer Weinigel wrote:
> On Fri, 25 Jan 2008 10:02:32 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > FYI, this is a patch that will be sent out in the next round to Linus
> > for inclusion in 2.6.25.
> >
> > If anyone has any objections about it, plea
On Sat, Feb 02, 2008 at 02:36:53AM -0800, David Brownell wrote:
> On Friday 01 February 2008, Greg Kroah-Hartman wrote:
> > From: Marcin Slusarz <[EMAIL PROTECTED]>
> >
> > fix warning:
> > drivers/usb/host/ehci-hcd.c:832:8: warning: symbol 'status' shadows an
> > earlier one
> > drivers/usb/host
Hi Oliver,
Am Freitag, 1. Februar 2008 15:52:37 schrieben Sie:
> this should implement autosuspend. Could you please test it?
> It's against 1.0.6.
I still don't know yet, what usb autosuspend really does and how I have to
control /sys/bus/usb/devices/*/power/autosuspend.
But anyway... the new f
On Fri, 25 Jan 2008 10:02:32 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> FYI, this is a patch that will be sent out in the next round to Linus
> for inclusion in 2.6.25.
>
> If anyone has any objections about it, please let me know.
Yes, I have objections and I've told you before.
> Over two y
This limits how long the OHCI port reset loop waits for the hardware
to do its job, if the controller either (a) dies, or (b) can't finish
the reset. Such limits are always a good idea.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
This patch from November seems to have gotten misplaced.
On Friday 01 February 2008, Greg Kroah-Hartman wrote:
> From: Marcin Slusarz <[EMAIL PROTECTED]>
>
> fix warning:
> drivers/usb/host/ehci-hcd.c:832:8: warning: symbol 'status' shadows an
> earlier one
> drivers/usb/host/ehci-hcd.c:790:71: originally declared here
>
> Signed-off-by: Marcin Slusar
20 matches
Mail list logo
