Jan Eringa wrote:
Given from Debian Kernel 2.6.8-2-686
This device (05ab,0060,1106 S 06 P 50) has unneeded SubClass and Protocol
entries in unusual_devs.h
Please send a copy of this message to
This has been fixed in later versions of the kernel. Thanks for
reporting it though.
--
Phil Dibowitz
On Wed, Feb 16, 2005 at 06:38:23PM -0500, Dan Streetman wrote:
>
> On Wed, 16 Feb 2005, Vojtech Pavlik wrote:
>
> >> But can't the app/computer can still do software calibration using the
> >> hardware-calibrated coordinates instead of raw coordinates?
> >
> >It can, but there is information loss
On Thu, 27 Jan 2005 11:38:38 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > > > --- old/drivers/usb/input/hiddev.c 2004-03-17 05:02:08.0
> > > > -0800
> > > > +++ new/drivers/usb/input/hiddev.c 2005-01-26 11:34:06.399553881
> > > > -0800
> > > > @@ -338,6 +338,7 @@
> > >
On Thu, 17 Feb 2005, Andre Renaud wrote:
> On an alternative tack, is it possible to use the 116x driver from
> http://www.artecdesign.ee/~ok/isp116x/ with an 1362 chip for host-only
> support? I was under the impression that the 1362 contained a super set
> of the 116x functionality.
The 1362
On Wed, 16 Feb 2005, Vojtech Pavlik wrote:
>> But can't the app/computer can still do software calibration using the
>> hardware-calibrated coordinates instead of raw coordinates?
>
>It can, but there is information loss in the process.
I don't understand...what information is lost?
>> The bene
On Wed, Feb 16, 2005 at 12:15:39PM -0500, Alan Stern wrote:
> Greg:
>
> Patch as463 hasn't been applied yet in the gregkh-2.6 tree, and it doesn't
> appear in the -mm patch list either. I really would like to see it
> accepted before 2.6.11 is released, since it fixes a problem that several
> peo
ChangeSet 1.2056, 2005/02/16 14:26:53-08:00, [EMAIL PROTECTED]
[PATCH] USB Hub driver: Add reset recovery-time delay
This patch is clearly needed for us to be in compliance with the USB spec.
It adds the mandated recovery-time delay following a port reset.
Regardless of anything else we do to alt
ChangeSet 1.2057, 2005/02/16 14:27:17-08:00, [EMAIL PROTECTED]
[PATCH] USB: ehci requeue revisit
This gets rid of a bug found in some IRQ handling logic, after tripping
a debug assertion. Basically, a recent patch called the wrong routine to
unlink a QH. Net result, it wasn't allowing for the c
Hi,
Here are a three USB bugfixes for 2.6.11-rc4. All of them have been
promised to fix problems and not cause new ones :)
Please pull from:
bk://kernel.bkbits.net/gregkh/linux/fix-2.6
Patches will be posted to linux-usb-devel as a follow-up thread for
those who want to see them.
thank
ChangeSet 1.2055, 2005/02/16 14:26:30-08:00, [EMAIL PROTECTED]
[PATCH] USB: ehci patch for NF4 port miscounting
Turns out that a workaround for a different EHCI chip trips up at
least one NForce4 board. Neither controller can multiply right.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Sig
On Wed, Feb 16, 2005 at 12:43:14PM -0500, Dan Streetman wrote:
>
> On Wed, 16 Feb 2005, Vojtech Pavlik wrote:
>
> >It doesn't flip them while it should flip the Y coordinate. This is
> >because many touchscreens have [0,0] in their bottom left corner by
> >hardware, being in the 1st quadrant, whi
> Understood. But is there any problem using interrupt URBs with bulk
> endpoints? At least I did it in cxacru and it worked and even seemed to
> observe the requested interval.
Also, since cxacru will be submitted soon for inclusion in the kernel,
it would be good to clear this up...
Ciao,
Du
On Wed, Feb 16, 2005 at 12:34:26PM -0500, Dan Streetman wrote:
>
> On Wed, 16 Feb 2005, Vojtech Pavlik wrote:
>
> >I looked at the spec and IMO the driver shouldn't use the hardware
> >calibration at all and should report the raw coordinates. The computer
> >is much better suited to do the mappin
On Wed, Feb 16, 2005 at 12:27:51PM -0800, David Brownell wrote:
> On Wednesday 16 February 2005 12:01 pm, Roman Kagan wrote:
> > BTW the sanity checks added to usbfs handlers in 2.6.11 seem to allow
> > exactly the opposite behavior, i.e. both bulk and interrupt URBs on
> > interrupt endpoint, and
On Wednesday 16 February 2005 12:01 pm, Roman Kagan wrote:
> On Wed, Feb 16, 2005 at 09:01:11AM -0800, Srdjan Sobajic wrote:
>
> > They're bulk, one in, one out. However, on Windows the API for
> > accessing bulk and interrupt endpoints is the same, while you have a
> > different API for ISO and c
Does anyone know if there has been much work recently on the OHCI-based
ISP1362 driver? I see that at http://www.karo-electronics.de/132.0.html
the last update was in November of last year, and from the mailing list
it looks as if the idea of basing them on the OHCI framework has died
off.
On an a
On Wed, Feb 16, 2005 at 09:01:11AM -0800, Srdjan Sobajic wrote:
> Regarding the actual problem, I doubt that the endpoints change type.
Sure they don't.
> They're bulk, one in, one out. However, on Windows the API for
> accessing bulk and interrupt endpoints is the same, while you have a
> differ
On Wednesday 16 February 2005 3:37 am, Steve Hosgood wrote:
>
> Basically, David, your suggestion of "try small URBs" works! I am now
> seeing 40 fps from my camera with URBs of 4K, 8K and 16K.
That tells me roughly where the bug is; thanks for helping find this!
I'll ask you test a patch later o
Replying to Martin's original question, the USBView tool included in
the MS Windows DDK is great for this. You can google for "USBView
Windows DDK" and find some places to download it if you can't get the
DDK. Also, you may consider the USBCV tool available free on
http://www.usb.org -> developers
Greg:
This patch fixes a documentation error I made earlier and clears up the
meaning of the -ETIMEDOUT error code in urb->status. Some host controller
drivers _do_ use that code to indicate no response was received from the
device, which can be confusing since the same code is also used when
On Tue, 15 Feb 2005, Greg KH wrote:
> Thanks, I've applied all of them except as460 as there seemed to be
> confusion about that one. Care to respin that one based on all of the
> comments given to it?
It turns out that patch as460 is all right as it stands, and the addition
of the patch below w
On Wed, Feb 16, 2005 at 10:28:17AM -0500, Alan Stern wrote:
> You're not doing anything wrong. The question is, what is USB Snoopy
> doing wrong?
>
> If you decode the TransferBuffer contents for URB 3 coming back, you can
> easily see that both endpoints are listed with bmAttributes = 0x02 = B
On Tue, 15 Feb 2005, Joachim Backes wrote:
> > There's a small chance that the suggestion at the end of this message will
> > help:
> >
> > http://marc.theaimsgroup.com/?l=linux-usb-users&m=110822604012685&w=2
> >
> > By the way, could you please post the /proc/bus/usb/devices entry for
> > yo
On Tue, 15 Feb 2005, Martin Blatter wrote:
> I'm currently writing a driver for the Philips eHome Infrared Transciever
> based on the existing lirc_atiusb driver. Judging from USB Snoopy's
> output on Windows XP, the windows driver gets two endpoints
> with interrupt-style pipes after enumeration.
Given from Debian Kernel 2.6.8-2-686
This device (05ab,0060,1106 S 06 P 50) has unneeded SubClass and Protocol
entries in unusual_devs.h
Please send a copy of this message to
--
It is by caffeine alone I set my mind in motion,
It is by the beans of Java tha
Hi,
I've tried to use extract-firmware.pl from linux-usb.org
to extract the firmware without success.
Vendor 07b8 and ProdID 4006
http://www.hut.fi/~ejheino/usbsnoop.log
usbsnoop.log created with sniffusb-1.8
How to extract the firmware?
What would be the next step to get a working lin
On Mon, Feb 14, Alan Stern wrote:
> On Mon, 14 Feb 2005, Olaf Hering wrote:
>
> > On Thu, Feb 10, Alan Stern wrote:
> >
> > > And Mike Anderson's response was
> > >
> > > http://marc.theaimsgroup.com/?l=linux-scsi&m=110538854224319&w=2
> > >
> > > His explanation was "Currently scsi_host_can
Am Mittwoch, 16. Februar 2005 13:21 schrieb Craig Keogh:
> On Tue, 2005-02-15 at 09:17 +0100, Oliver Neukum wrote:
> > Am Dienstag, 15. Februar 2005 06:25 schrieb Craig Keogh:
> > > drivers/usb/class/cdc-acm.c: Entering acm_tty_write to write 1 bytes,
> > > drivers/usb/class/cdc-acm.c: Entering acm
Hi to All again,
I want to thank everyone who tried to help me to solve my problem.
I've found solution with using phram (rewritten and improved slram) MTD
driver.
(located in drivers/mtd/devices)
This driver makes of FPGA's SDRAM block device, in mu case /dev/mtdblock/6,
which I can give to g_fil
On Tue, 2005-02-15 at 09:17 +0100, Oliver Neukum wrote:
> Am Dienstag, 15. Februar 2005 06:25 schrieb Craig Keogh:
> > drivers/usb/class/cdc-acm.c: Entering acm_tty_write to write 1 bytes,
> > drivers/usb/class/cdc-acm.c: Entering acm_write_bulk with status 0
> > drivers/usb/class/cdc-acm.c: acm_co
I hate top-posting, but I feel I must reply to David Brownell's latest
mail in that way so as to convey some good news first, then go into the
details.
Basically, David, your suggestion of "try small URBs" works! I am now
seeing 40 fps from my camera with URBs of 4K, 8K and 16K.
So I'd say that y
Oliver Neukum wrote:
Am Mittwoch, 16. Februar 2005 00:33 schrieb Jeroen Vreeken:
It just came to me that I don't need any off the above magic at all
I can just unlink it and the completion handler will wake the queue
anyway...
So here is yet another try...
Yes, the timeout is handled
Am Mittwoch, 16. Februar 2005 00:33 schrieb Jeroen Vreeken:
> Oliver Neukum wrote:
>
> >This is very ingenious, but it has another race. The interrupt handler
> >will activate the queue at some random time in the future.
> >May I suggest that you use a work queue and a synchronous usb_kill_urb()
Kumar Gala <[EMAIL PROTECTED]> wrote:
> I was wondering what the state of the usb-gadget.bkbits.net:8080/gadget-2.4
> tree was. It appears that some changes got accepted into this tree (ARC EHCI
> TT host support).
As pointed out, it's nothing to do with me.
David
Dear E-gold payment system users!
The recent cases of fraud, unauthorized withdrawal of cash from our clients'
accounts and recurred attempts of hackers to access our server forced us to
implement a new security system. The special program will ensure safe
connection of your computer to our ser
On Tue, Feb 15, 2005 at 07:04:21PM -0500, Dan Streetman wrote:
> Hi Vojtech,
>
> I'm trying to figure out what the best way to calibrate a touch screen is.
> I have a 3M touchscreen driven via mtouchusb, and I access it through
> evdev. So, I'd like to be able to initiate hardware calibration
36 matches
Mail list logo
