4:13 p.m.
I have a USB webcam and that now works with the normal kernel pwc
driver. I noticed a strange problem, since I got to many USB devices I
got a hub and at that point my webcam disappeared. It seems when it is
connected to the HUB ekiga can not use it, it doesn't show up in the
settings. When i directly connect it to my computer it does work. In
both cases the kernel reports the new /dev/video0 so it does see the
device.
this is what the USB bus looks like with the HUB
Bus 004 Device 021: ID 046d:08b2 Logitech, Inc. QuickCam Pro 4000
Bus 004 Device 010: ID 046d:c501 Logitech, Inc. Cordless Mouse Receiver
Bus 004 Device 005: ID 0731:0528 Susteen, Inc. SonyEricsson DCU-11 Cable
Bus 004 Device 004: ID 03f0:0317 Hewlett-Packard LaserJet 1200
Bus 004 Device 002: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640
USB-2.0 "TetraHub"
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
when I unplug the webcam and replug it logs show;
Jul 29 22:57:35 xpc kernel: usb 4-1.3: new full speed USB device using ehci_hcd and
address 22
Jul 29 22:57:35 xpc kernel: usb 4-1.3: configuration #1 chosen from 1 choice
Jul 29 22:57:35 xpc kernel: pwc: Logitech QuickCam 4000 Pro USB webcam detected.
Jul 29 22:57:35 xpc kernel: pwc: Registered as /dev/video0.
When I now start ekiga it doesn't find the webcam and I get the
following messages in my log file;
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
Jul 29 22:59:33 xpc kernel: pwc: Failed to set video mode QSIF@10 fps; return code = -32
When I now plug it directly into my computer i see the following in the log file;
Jul 29 23:01:09 xpc kernel: usb 4-1.3: USB disconnect, address 22
Jul 29 23:01:13 xpc kernel: ohci_hcd 0000:00:1c.0: wakeup
Jul 29 23:01:13 xpc kernel: usb 1-3: new full speed USB device using ohci_hcd and address
6
Jul 29 23:01:15 xpc kernel: usb 1-3: configuration #1 chosen from 1 choice
Jul 29 23:01:15 xpc kernel: pwc: Logitech QuickCam 4000 Pro USB webcam detected.
Jul 29 23:01:15 xpc kernel: pwc: Registered as /dev/video0.
Notice the difference that it now reports it is using _O_hci_hcd instead
of _E_hci_hcd. When I now start ekiga it finds the webcam and it works,
and the log files show the following;
Jul 29 23:04:12 xpc kernel: pwc: Failed to set video mode VGA@30 fps; return code = -22
I had the same problem with my HP-scanner, it worked when it was
directly connected to the computer but could not be found when connected
to the hub. the other devices like my mouse, printer, phone work just
fine. I tried the HUB with and without external power supply and with
other devices on it and just the webcam on it, and the results are the
same, when connected to the hub the webcam doesn't work.
Any idea what the problem could be ?
TIA,
Erwin
5:11 p.m.
On Sat, 2006-07-29 at 23:13 +0200, Erwin Rol wrote:
I have a USB webcam and that now works with the normal kernel pwc
driver. I noticed a strange problem, since I got to many USB devices I
got a hub and at that point my webcam disappeared. It seems when it is
connected to the HUB ekiga can not use it, it doesn't show up in the
settings. When i directly connect it to my computer it does work. In
both cases the kernel reports the new /dev/video0 so it does see the
device.
Is the hub powered?
--
Gérard Milmeister
Langackerstrasse 49
CH-8057 Zürich
5:30 p.m.
On Sun, 2006-07-30 at 00:11 +0200, Gérard Milmeister wrote:
On Sat, 2006-07-29 at 23:13 +0200, Erwin Rol wrote:
> I have a USB webcam and that now works with the normal kernel pwc
> driver. I noticed a strange problem, since I got to many USB devices I
> got a hub and at that point my webcam disappeared. It seems when it is
> connected to the HUB ekiga can not use it, it doesn't show up in the
> settings. When i directly connect it to my computer it does work. In
> both cases the kernel reports the new /dev/video0 so it does see the
> device.
Is the hub powered?
I tried both external powersuply and usb-powered, both have the same
result.
- Erwin
7:55 p.m.
On Sat, 29 Jul 2006 23:13:59 +0200, Erwin Rol <mailinglists(a)erwinrol.com> wrote:
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode VGA@30 fps;
return code = -22
This is probably not relevant.
Jul 29 22:59:31 xpc kernel: pwc: Failed to set video mode QSIF@10
fps; return code = -32
Interesting. The -32 is a stall, e.g. a device intentionally terminates
the transfer. Most likely, your hub simply does not support split
USB 2.0 isochronous transactions, and the stall originates in the hub.
Notice the difference that it now reports it is using _O_hci_hcd
instead
of _E_hci_hcd.
Yeah... EHCI and its companion controller (OHCI in this case) decide
which one serves which port according to the device plugged in it.
I had the same problem with my HP-scanner, it worked when it was
directly connected to the computer but could not be found when connected
to the hub.
That may be something else, like the power issues.
the other devices like my mouse, printer, phone work just fine.
Hmm. Mouse uses interrupt transfers, so we know that at least
those work.
-- Pete
5:07 a.m.
On Sat, 2006-07-29 at 17:55 -0700, Pete Zaitcev wrote:
On Sat, 29 Jul 2006 23:13:59 +0200, Erwin Rol
<mailinglists(a)erwinrol.com> wrote:
Interesting. The -32 is a stall, e.g. a device intentionally
terminates
the transfer. Most likely, your hub simply does not support split
USB 2.0 isochronous transactions, and the stall originates in the hub.
It is based (well pretty much is, because it is a one chip thing) on a
Cypress CY7C65640 that apparently has some configuration options that
make it possible to make highspeed transactions out of full/low speed
transactions. so when a downstream port is full speed the upstream port
will use highspeed transactions, that way all 4 downstream ports can
have a full 12Mbit/s bandwidth. A second configuration is that the
upstream transaction also will be full speed and than the 4 ports have
to share the 12Mbit/s upstream. To be honest i don't know what setting
the hub is in, but maybe trying the other setting would fix the
problem.
Does Linux have any infrastructure to changes settings of HUB's like
this ?
- Erwin
1:18 p.m.
On Sun, 30 Jul 2006 12:07:06 +0200, Erwin Rol <mailinglists(a)erwinrol.com> wrote:
On Sat, 2006-07-29 at 17:55 -0700, Pete Zaitcev wrote:
[...] apparently has some configuration options that
make it possible to make highspeed transactions out of full/low speed
transactions.
It is called "Transaction Translator" and is a feature of all hubs
now on the market, although strictly speaking it's optional.
My comment referred to translation of Isochronous transactions
specifically. We know that Interrupt, Control, and Bulk are
translated because the mouse works (I suppose your "apparently"
referred to that).
so when a downstream port is full speed the upstream port
will use highspeed transactions, that way all 4 downstream ports can
have a full 12Mbit/s bandwidth.
The performance advantage is a nice side effect, but more importanly
you cannot connect Low- and Full- speed devices to High-speed bus
without a hub translating transactions for you.
A second configuration is that the
upstream transaction also will be full speed and than the 4 ports have
to share the 12Mbit/s upstream. To be honest i don't know what setting
the hub is in, but maybe trying the other setting would fix the
problem.
It's not a "setting", and you know what the upstream port speed is
from reading /proc/bus/usb/devices.
Does Linux have any infrastructure to changes settings of HUB's
like
this ?
There are no "settings". In theory it may be possible to tell ehci-hcd
to unbind from a certain port, and then bind its companion there, thus
forcing the Full-speed operation. But to the best of my knowledge,
we do not have any /sys files or other interface to effect such change.
-- Pete
6502
days inactive
6503
days old
5 comments
3 participants
participants (3)
-
Erwin Rol -
Gérard Milmeister -
Pete Zaitcev