Hi,
On 06/21/2009 02:10 PM, Mauro Carvalho Chehab wrote:
Em Sun, 21 Jun 2009 08:45:03 +0200
Hans de Goede<hdegoede@xxxxxxxxxx> escreveu:
On 06/21/2009 02:39 AM, Mauro Carvalho Chehab wrote:
Em Sat, 20 Jun 2009 15:26:25 +0200
Hans de Goede<hdegoede@xxxxxxxxxx> escreveu:
On 06/20/2009 12:51 PM, Mauro Carvalho Chehab wrote:
Em Wed, 17 Jun 2009 23:54:40 +0200
Hans de Goede<hdegoede@xxxxxxxxxx> escreveu:
Support for the st6422 bridge + sensor !
Give it a try, I know now you have a cam which uses this bridge :)
When you try it be sure to use the latest (just updated my
libv4l tree) libv4l, this enables (software) automatic control of
the gain and exposure, for a decent image in most lighting
conditions.
Didn't work :( See the logs bellow.
<snip>
$ dmesg
STV06xx: Probing for a stv06xx device
gspca: probing 046d:08f6
usbcore: registered new interface driver STV06xx
STV06xx: registered
gspca: usb_submit_urb [0] err -28
gspca: no transfer endpoint found
err -28 is ENOSPC which is given by usb_submit_urb, when the
required bandwidth for the isoc transfer is not available.
With most cams we then automatically fall back to an altsetting
which requires less bandwidth, but the st6422 has only one
hence the: "gspca: no transfer endpoint found" error.
There are 3 possible causes for this:
1) You are using the device through an usb 2.0 hub, this should work
but does not work due to a bug in the usb subsystem of the kernel,
which I have reported but most likely won't be fixed
OK. On a direct port:
OK, better :)
mplayer does not recognize /dev/video0 as a "v4l" url, so it will just
try to use plain open and then read, which is causing the errors, as
read() on a v4l device wants a buffer large enough to hold 1 frame in one
read.
Yes, I know, but the v4l1 and v4l2 calls also fails:
$ export LD_PRELOAD=/usr/local/lib/libv4l/v4l1compat.so
$ mplayer -tv driver=v4l2 tv://
...
Cannot find codec matching selected -vo and video format 0x32315659.
Read DOCS/HTML/en/codecs.html!
$ mplayer -tv driver=v4l tv://
The 'outfmt' of 'Planar YV12' is likely not supported by your card
Hmm,
This works fine for me, perhaps you are using an older libv4l, mplayer did
not work with some libv4l versions back as it wants YV12 and some versions
back libv4l only did YU12.
When trying a new libv4l, make sure you don't have an older version elsewhere,
I notice that your LD_PRELOAD points to /usr/local, notice that that will only
specify where the compat wrapper gets loaded from (which hasn't changed in ages)
the compat_wrapper itself is dynamically linked, so if you have an older libv4l
in /usr/lib, chances are that one actually gets used.
I tested also luvcview 0.2.5 without success:
ERROR: Requested frame format MJPG is not available and no fallback format was found.
luvcview is a somewhat limited app, which only works with uvc cams, even libv4l cannot
help it, as it requests uvc specific formats to which libv4l cannot convert.
Hmm... on a moment of inspiration, I tested it with ekiga, and it properly worked!
Great, that supports my using older libv4l theory :)
Now, I just want to find a way for it to work with the applications I use ;)
See above.
I'll try to test later the patches you've sent me for the hub
Thanks.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
