Hi,
as far as I know, the usbvision driver did not support the Logitech
Camera.
To confirm this, please, can you send me the output of "cat
/proc/bus/usb/devices"
when the camera is plugged in.
Bye,
Joerg.
Namachivayam C schrieb:
>
> Dear Sir,
>
> Could U please send the details of a
Dear Sir,
Could U please send the details of adding a device
driver to my Linux PC. I have tried installed many
drivers for Logitech Camera in my PC. But none of the
driver is working. I have tried installed my kernel
also for camera driver support. But there is no use...
The device file
This resends the "usb_make_path()" update (my net-0408 patch)
to pegasus, so it reports the same bus info the other usb network
drivers now return, and fixes a couple other bugs in ethtool support I
happened to notice:
- driver info wasn't providing the "driver short name".
- settings wer
[EMAIL PROTECTED] writes:
> A moment ago I have made available on ftp.XX.kernel.org
> under linux/kernel/people/aeb/sddr09.c a new SDDR-09 driver,
> namely one that not only reads but also writes.
>
> It works for me.
>
> Will submit some version for inclusion in 2.5 next week
> or so. Feedback
> > Devfs goes the whole way.
> > Let's look at the basic function of major:minor combinations.
> > You use them to assign names and permissions to a device.
> > If minors become dynamic minors no longer have any function,
> > you are better of eliminating them.
>
> I would love to eliminate minor
On Thu, 25 Apr 2002, David Brownell wrote:
> > > cvs -d cvs.linux-usb.sf.net:/cvsroot/linux-usb -z3 co hcd
>
> Don't use that, it's not as current as what's in the 2.5.latest kernel.
>
>
> > Thanks, reading README was quite enlightening. I now feel much better
> > about 16mb/sec transfer rate t
> Is it possible to use Simple A-to-A cable for this purpose ?
>if not why not
No, and the guts of "why" was in the note Steve sent you
(which you quoted). "Simple A-to-A cable" was not on the
list of products I mentioned, either. (Return it to whoever
you bought it from and insist on your
On Fri, 26 Apr 2002 13:29, Rakesh A. Ughreja wrote:
> Is it possible to use Simple A-to-A cable for this purpose ? if not why not
> ? if yes then in what sense it is different from USB network cables ?
Definitely not possible, and making such cables is not compliant with the USB
specs. [If you h
Is it possible to use Simple A-to-A cable for this purpose ? if not why not
? if yes then in what sense it is different from USB network cables ?
Thanks
- Original Message -
From: "Steve Calfee" <[EMAIL PROTECTED]>
To: "Rakesh A. Ughreja" <[EMAIL PROTECTED]>; "Brad Hards"
<[EMAIL PROTEC
On Fri, Apr 26, 2002 at 01:49:33AM +0200, Oliver Neukum wrote:
> Am Donnerstag, 25. April 2002 17:11 schrieb Greg KH:
> > On Thu, Apr 25, 2002 at 10:14:59AM +0200, Oliver Neukum wrote:
> > > > Right now there isn't a "simple" way for userspace to realize what
> > > > minor is assigned to each devi
Am Donnerstag, 25. April 2002 17:11 schrieb Greg KH:
> On Thu, Apr 25, 2002 at 10:14:59AM +0200, Oliver Neukum wrote:
> > > Right now there isn't a "simple" way for userspace to realize what
> > > minor is assigned to each device, but I will work on that tomorrow,
> > > as it's late (hint, /sbin/h
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.563 -> 1.564
# drivers/usb/serial/
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.562 -> 1.563
# drivers/usb/image/m
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.561 -> 1.562
# drivers/usb/core/Co
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.560 -> 1.561
# drivers/usb/Config.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.544.3.4 -> 1.544.3.5
# drivers/usb/mis
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.544.3.3 -> 1.544.3.4
#include/linux/
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.544.3.2 -> 1.544.3.3
# drivers/usb/hos
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.544.3.1 -> 1.544.3.2
# drivers/usb/net
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.544 -> 1.544.3.1
# include/linux/brl
Pull from: bk://linuxusb.bkbits.net/linus-2.5
drivers/usb/Config.help |8
drivers/usb/class/printer.c | 21 +
drivers/usb/core/Config.in | 11 -
drivers/usb/core/usb.c | 170 ++--
drivers/usb/host/ehci-hub.c | 36 +--
drivers/usb/host/ohci-hub.c |5
> > p.p.s. Driver-visible API change in 2.5.10: if you use
> > fops, you MUST set num_minors ... listing in the
> > /proc/bus/usb/drivers file happens even if there's
> > no way the driver will be accessible. I think it'd be
> > better to fail the registration if num_minors is zer
On Thu, Apr 25, 2002 at 12:57:03PM -0500, Curran, Dominic wrote:
>
> But perhaps it sounds like user mode is a better place for a firmware loaded
> anyway ?
Yes it is. Even the drivers currently in the kernel today that
implement firmware download will be eventually moved to userspace.
> I'm a
Hi
Firstly, I don't have a device that currently implements the Firmware
Upgrade spec.
I was discussing yesterday with a colleague how to solve a firmware upgrade
on a mass storage part and we got to talking about what OS's supported the
spec (we were mainly talking about Windows I'm afraid).
On Thu, Apr 25, 2002 at 07:39:03AM -0700, David Brownell wrote:
> This patch is the result of that discussion a short while back
> to fix the "hub driver polls too quickly at high speed" bug.
>
> - redefines "interval" of usb_fill_int_urb() to be what
> the endpoint descriptor returns,
On Thu, Apr 25, 2002 at 06:02:24AM -0700, David Brownell wrote:
> > I didn't see an easy fix for these warnings, so patches from the authors
> > are greatly appreciated :)
>
> Here's one from me. The fix is to stop using set_bit()
> and friends -- which aren't as portable as we need.
>
> Agains
On Thu, Apr 25, 2002 at 05:29:59PM +1000, Brad Hards wrote:
> On Thu, 25 Apr 2002 12:04, Greg KH wrote:
> > I would gladly accept one if someone has one around.
> Greg: Isn't the move to keep this sort of stuff out of the kernel? Or would
> you expect the driver to have a simple "write" char inte
On Thu, Apr 25, 2002 at 10:14:59AM +0200, Oliver Neukum wrote:
>
> > Right now there isn't a "simple" way for userspace to realize what minor
> > is assigned to each device, but I will work on that tomorrow, as it's
> > late (hint, /sbin/hotplug will be involved :)
>
> This is no good. You come
Am Donnerstag, 25. April 2002 08:00 schrieb Greg KH:
> Hi all,
>
> Here's a patch that finishes off my previous patch that enabled us to
> use less than 16 minor numbers per USB device that uses the USB major
> number. This patch allows all such devices to share all 256 minor
> numbers at once, m
> > cvs -d cvs.linux-usb.sf.net:/cvsroot/linux-usb -z3 co hcd
Don't use that, it's not as current as what's in the 2.5.latest kernel.
> Thanks, reading README was quite enlightening. I now feel much better
> about 16mb/sec transfer rate that I was seeing. Does anyone know of a host
> controller
Use the 2.5.10 code. And just use explicit queuing of ISO urbs,
not the urb->next stuff ... which I suspect will vanish before long,
thereby simplifying a number of things! (Your driver can resubmit
when it's needed, and won't risk missing an error case.)
Minor disclaimer, that iso code is real
This patch is the result of that discussion a short while back
to fix the "hub driver polls too quickly at high speed" bug.
- redefines "interval" of usb_fill_int_urb() to be what
the endpoint descriptor returns, and transparently
does the log-to-linear conversion if it's high spe
I'll punt on the linear-to-log conversion for now.
If it turns out to be needed, someone (you? :)
can submit a patch.
Actually it'll be easier for drivers overriding the
endpoint descriptors to overwrite urb->interval
and not bother with the linear-to-log-to-linear.
- Dave
- Original Messag
> I didn't see an easy fix for these warnings, so patches from the authors
> are greatly appreciated :)
Here's one from me. The fix is to stop using set_bit()
and friends -- which aren't as portable as we need.
Against 2.5.10, please integrate to Linus' tree.
- Dave
setbit-0424.patch
Desc
On Thu, 25 Apr 2002 19:46, Rakesh A. Ughreja wrote:
> Once again I am posting this question. Sorry for that.
>
> I am running Kernel 2.4.18 on Intel 810E with 2 USB ports. Both the ports
> are connected BACK TO BACK by a USB cable. I have compiled everything as a
> part of bzImage (I mean not as
Once again I am posting this question. Sorry for that.
I am running Kernel 2.4.18 on Intel 810E with 2 USB ports. Both the ports
are connected BACK TO BACK by a USB cable. I have compiled everything as a
part of bzImage (I mean not as a module ) including usbnet.c. But still I am
not able to see
As the subject says...
datafab.c: In function `datafab_read_data':
datafab.c:260: structure has no member named `address'
datafab.c:261: structure has no member named `address'
datafab.c:269: structure has no member named `address'
datafab.c:270: structure has no member named `address'
datafab.c:
On Thu, 25 Apr 2002 12:04, Greg KH wrote:
> On Wed, Apr 24, 2002 at 09:51:31PM -0500, Curran, Dominic wrote:
> > Hi
> >
> > Simple question.
> >
> > Does a driver that conforms to the 'Device Firmware Upgrade 1.0' class
> > spec exist ?
>
> There isn't one currently in the kernel tree, no. I've h
38 matches
Mail list logo
