OK, I recompiled the kernel. When I compiled ndiswrapper, I obtained a
warning :
this kernel seems to use 4K stack size option (CONFIG_4KSTACKS); many
Windows drivers will not work with this option enabled. Disable
CONFIG_4KSTACKS option, recompile and install kernel.
So, I dit a "cat .config |
Am Dienstag, 13. Februar 2007 18:51 schrieb Antoine Jacquet:
> Hello,
>
> >> + /* swap to good indian if camera needs it */
> >> + if (cam->method == 0)
> >> + for (i = 0; i < BUFFER_SIZE; i += 2) {
> >> + swap = cam->buffer[i];
> >> +
> > My comment is not very good, in fact on some cameras I need to swap the
> > bytes
> > to have correct JPEG data (so this is not an endianness issue I think).
> > Maybe there is a macro to swap bytes in a buffer? I cannot find it.
>
> Sorry, there's a swab32, but no swab16. I misremembered.
I
On 14 Feb 2007 07:16:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> wrote:
> Hi Jon,
>
> on 13 Feb 07 at 23:46, you wrote:
> [...]
> > evdev doesn't just handle keyboards.
>
> Yes, sorry for simplifying it too much. I just opt for using uinput from
> user-space so that configuration is consisten
On Tue, 13 Feb 2007, Guilherme Salgado wrote:
> Hi Alan,
> > Below is a revised version of the diagnostic patch. Try using it instead
> > of the earlier one and let's see what happens.
> >
>
> This revised version didn't apply cleanly into my tree,
Maybe because you didn't remove the original
On Wed, 14 Feb 2007, Thibaud Hulin wrote:
> Thanks for your advices.
> I check the options with a "cat .config | grep CONFIG_USB_SUSPEND" ; I get :
> # CONFIG_USB_SUSPEND is not set
Okay, good.
> But, with the option USB_AUTOSUSPEND_DELAY, I obtain nothing.
Because it doesn't do anything when C
On Wed, 14 Feb 2007, Thibaud Hulin wrote:
> OK, I recompiled the kernel. When I compiled ndiswrapper, I obtained a
> warning :
> this kernel seems to use 4K stack size option (CONFIG_4KSTACKS); many
> Windows drivers will not work with this option enabled. Disable
> CONFIG_4KSTACKS option, reco
On Wed, 14 Feb 2007, Sven Anders wrote:
> Hello!
>
> I want to change the actual "appletouch.c" USB driver and run into a problem.
>
>
> After I called
>
> usb_fill_int_urb(dev->urb, udev,
> usb_rcvintpipe(udev, int_in_endpointAddr),
>
On Tue, 13 Feb 2007, Edwin Olson wrote:
> Hello folks,
>
> I've incorporated the suggestions mentioned before, and a few other
> cleanups. Anecdotally, the module seems to be performing very well on my
> system (x86-64). Not withstanding recent development work to
> usbfs/libusb, I think that
On Wed, Feb 14, 2007 at 09:44:46AM -0500, Jon Smirl wrote:
> >Sending an IR signal involves things like setting the carrier frequency,
> >duty cycle, and then writing a stream of timing values.
> >I think that evdev in general is not the right interface for this.
>
> This could be worked into the
On 2/14/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 14, 2007 at 09:44:46AM -0500, Jon Smirl wrote:
> > >Sending an IR signal involves things like setting the carrier frequency,
> > >duty cycle, and then writing a stream of timing values.
> > >I think that evdev in general is not the
On Wed, Feb 14, 2007 at 10:50:27AM -0500, Jon Smirl wrote:
> On 2/14/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> >On Wed, Feb 14, 2007 at 09:44:46AM -0500, Jon Smirl wrote:
> >> >Sending an IR signal involves things like setting the carrier frequency,
> >> >duty cycle, and then writing a stream
On 2/14/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 14, 2007 at 10:50:27AM -0500, Jon Smirl wrote:
> > On 2/14/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > >On Wed, Feb 14, 2007 at 09:44:46AM -0500, Jon Smirl wrote:
> > >> >Sending an IR signal involves things like setting the
On Tue, 13 Feb 2007, Raphael Assenat wrote:
> Hello,
> I have some pxa270 based single board computers which have an
> IT8152G companion chip. This chip has a built-in USB Host controller
> which is (according to the datasheet) register compatible with OHCI
> specification version 1.0.
>
> Dur
This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 24 hours on the queue on
externalmx-1.sourceforge.net.
The message identifier is: 1HGzJm-00049Y-AN
The subject of the message i
On Tue, 13 Feb 2007, Jon Smirl wrote:
> On 2/13/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > It's possible that after resuming, the device is still functional but in
> > some weird state. Perhaps sending it the right sort of HID messages would
> > get it fully working again. But I don't want to
On 2/14/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 13 Feb 2007, Jon Smirl wrote:
>
> > On 2/13/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > > It's possible that after resuming, the device is still functional but in
> > > some weird state. Perhaps sending it the right sort of HID messages
On Wed, 14 Feb 2007, Jon Smirl wrote:
> > I did run another test. Before suspending, the device responds to the
> > dial and the mute button by sending messages to the computer. After
> > resuming, it does not send any messages when I twist the dial or press the
> > button. I think we should as
On Wed, Feb 14, 2007 at 11:27:44AM -0500, Jon Smirl wrote:
> You need something like this:
>
> lircd opens /dev/uinput once for each remote control. This creates the
> corresponding /dev/input/event* nodes.
>
> Remote gets clicked, lircd catches event and passes it to uinput. User
> app can read
Ishizaki Kou wrote:
> ps3_system_bus_driver_register is PS3 platform specific function.
> On other platforms, it triggers WARN_ON in kref_get.
> +++ linux-powerpc-git/drivers/usb/host/ehci-hcd.c
> +++ linux-powerpc-git/drivers/usb/host/ohci-hcd.c
I would think we only need to modify ps3_system_bu
Alan Stern wrote:
> On Tue, 13 Feb 2007, Raphael Assenat wrote:
>>I have some pxa270 based single board computers which have an
>>IT8152G companion chip. This chip has a built-in USB Host controller
>>which is (according to the datasheet) register compatible with OHCI
>>specification version 1.0
On Wed, 14 Feb 2007, Raphael Assenat wrote:
> > Is that true even if there was also a device attached at boot time, or
> > does it happen only when you connect a new device and all the ports are
> > unoccupied?
> I had not thought of trying that... I did some tests and found that
> if a device
On Wed, 2007-02-14 at 16:04 +0900, Ishizaki Kou wrote:
> ps3_system_bus_driver_register is PS3 platform specific function.
> On other platforms, it triggers WARN_ON in kref_get.
>
> Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
A bit nasty but that's the price of wanting to have all the bus glu
With the help of Dmitry, I solved the exclusive access issue that
required blacklisting our IPanel so, I'm going to need to submit another
patch to remove our IPanel from the blacklist. The HID driver
recognizes and parses our IPanels properly.
Sorry.
On Fri, 2007-02-09 at 08:46 -0800, Greg KH
Hello... While running minor stress on a system, I'm seeing messages
like this quite frequently:
usb 3-1.1: reset full speed USB device using ehci_hcd and address 5
These messages are occurring for all 4 of my low/full speed HID devices
that are connected to a USB2.0 hub (so all are using split
On 2/14/07, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 14, 2007 at 11:27:44AM -0500, Jon Smirl wrote:
>
> > You need something like this:
> >
> > lircd opens /dev/uinput once for each remote control. This creates the
> > corresponding /dev/input/event* nodes.
> >
> > Remote gets clicke
On Wed, 14 Feb 2007, Alan wrote:
> > > My comment is not very good, in fact on some cameras I need to swap the
> > > bytes
> > > to have correct JPEG data (so this is not an endianness issue I think).
> > > Maybe there is a macro to swap bytes in a buffer? I cannot find it.
> >
> > Sorry, there's
On Wed, 14 Feb 2007 15:47:16 -0700, Jeremy Roberson <[EMAIL PROTECTED]> wrote:
> With the help of Dmitry, I solved the exclusive access issue that
> required blacklisting our IPanel so, I'm going to need to submit another
> patch to remove our IPanel from the blacklist. The HID driver
> recognize
From: Jeremy Roberson <[EMAIL PROTECTED]>
Removes our GTCO CalComp Interwrite IPanels from the hid-core.c blacklist
because the HID Driver properly handles them.
Signed-off-by: Jeremy A. Roberson <[EMAIL PROTECTED]>
---
--- a/drivers/usb/input/hid-core.c 2007-02-04 11:44:54.0 -0700
I have a USB drawing tablet made by a Taiwanese company called UGEE
(using UC-Logic's technology). As of now, there are no Linux drivers
for it, although it has basic functionality as a mouse.
I want to be able to use its pressure sensitivity feature in Linux, and
I need somebody to write the d
This is a note to let you know that I've just added the patch titled
Subject: USB: add driver for iowarrior devices.
to my gregkh-2.6 tree. Its filename is
usb-iowarrior.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>
On Wed, Feb 14, 2007 at 04:49:11PM -0600, [EMAIL PROTECTED] wrote:
>
> Hello... While running minor stress on a system, I'm seeing messages
> like this quite frequently:
What kernel version are you using?
> usb 3-1.1: reset full speed USB device using ehci_hcd and address 5
>
> These messages a
On Wed, Feb 14, 2007 at 03:47:16PM -0700, Jeremy Roberson wrote:
> With the help of Dmitry, I solved the exclusive access issue that
> required blacklisting our IPanel so, I'm going to need to submit another
> patch to remove our IPanel from the blacklist. The HID driver
> recognizes and parses ou
This is a note to let you know that I've just added the patch titled
Subject: EHCI: turn off remote wakeup during shutdown
to my gregkh-2.6 tree. Its filename is
ehci-turn-off-remote-wakeup-during-shutdown.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/p
Em Ter, 2007-02-13 às 22:27 +0100, Antoine Jacquet escreveu:
> Hi,
>
> > Instead of those, you should call v4l1_compat to allow your driver to
> > work with older apps.
>
> As far as I know, the zr364xx cameras only handle JPEG data.
> So is it usefull to have V4L1 compatibility since I think old
On 2/15/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
> On Wed, 14 Feb 2007, Alan wrote:
> > > > My comment is not very good, in fact on some cameras I need to swap the
> > > > bytes
> > > > to have correct JPEG data (so this is not an endianness issue I think).
> > > > Maybe there is a macro to swa
Hi Jon,
on 14 Feb 07 at 09:44, you wrote:
[...]
> Adding uinput support would also let you get rid of all the X specific
> code since X knows how to read evdev.You just need to do is add a
> small section to your xorg.conf.
>
> Are your interested in adding this support?
Yes, I like the concept y
On 15 Feb 2007 05:40:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> wrote:
> Hi Jon,
>
> on 14 Feb 07 at 09:44, you wrote:
> [...]
> > Adding uinput support would also let you get rid of all the X specific
> > code since X knows how to read evdev.You just need to do is add a
> > small section to
Thomas Bächler wrote:
> Add Teac HD-35PU devices to unusual_devs.h to fix I/O
> errors resulting from wrong residue values returned
> by the device.
Sorry for the delay in getting back to you. I help run SCALE (Southern
California Linux Expo), and that always kills a good week or so for me.
Anway
[EMAIL PROTECTED] wrote:
> This is a note to let you know that I've just added the patch titled
>
> Subject: USB: Teac HD-35PU patch to unusual_devs.h
>
> to my gregkh-2.6 tree. Its filename is
Greg,
Check you're tree, I believe you've now added a duplicate entry. I already
had a 0x1652/0
Begin forwarded message:
Date: Wed, 14 Feb 2007 20:01:32 -0500
From: George Nychis <[EMAIL PROTECTED]>
To: Linux Kernel Mailing List
Cc: discuss-gnuradio@gnu.org
Subject: USB ehci problems with USRP, -71 EPROTO
Hey all,
I am having troubles connecting and interfacing to a device called a
US
41 matches
Mail list logo
