ao2 wrote:Mplayer works fine because it can handle YUYV with no problems, other programs have to rely on
libv4l (libv4lconvert) for format conversion, using the LD_PRELOAD mechanism.
My version of skype seems to be fine with YUYV (it doesn't complain), it just shows a green screen. libv4lconvert didn't help, although I only played with it a tiny bit. Not a big concern at this point.
Anyway, here's some random comments while I'm thinking about them:
First, it seems strange to call the driver "ov534" when it's really a driver for "ov534/538 + ov7720". And it's a shame there's so much repetition in v4l2 in general. For example, there's definitely some shared code between ov519 vs ov534. And there's a driver for "ov772x" and another driver for "ov7x20" -- seems we should be able to use at least one of those for the sensor part in the PS Eye.
On the other hand, they don't necessarily expose everything we'd want (like clock control), and I'd be hesitant to go modifying the common code because of other devices we'd break. Maybe it's better to just keep the pseye driver standalone.
Code: Select all
ov534_reg_write(udev, 0x1c, 0x00);
ov534_reg_write(udev, 0x1d, 0x40);
ov534_reg_write(udev, 0x1d, 0x02);
ov534_reg_write(udev, 0x1d, 0x00);
ov534_reg_write(udev, 0x1d, 0x02); // frame_h
ov534_reg_write(udev, 0x1d, 0x57); // frame_m
ov534_reg_write(udev, 0x1d, 0xff); // frame_l
These are indirect writes that set the ov534 frame size.
frame_size = ((frame_h << 16) + (frame_m << 8) + (frame_l)) * 4 = 0x0257ff * 4 = 614396
That's .sizeimage-4. I think setting this to 0x025800 would stop dropping the last 2 pixels, and you'd need to change it for 320x240.
Code: Select all
switch (sd->frame_rate) {
case 50:
sccb_reg_write(gspca_dev->dev, 0x11, 0x01);
sccb_check_status(gspca_dev->dev);
sccb_reg_write(gspca_dev->dev, 0x0d, 0x41);
sccb_check_status(gspca_dev->dev);
ov534_reg_verify_write(gspca_dev->dev, 0xe5, 0x02);
break;
The sccb_check_status should be unnecessary, sccb_reg_write does it already.
We could be smarter with the clock rates here. I've almost figured them out, and we can support more flexible framerates if we do. We'll need different numbers here based on the capture resolution. I'm not sure how to best work that into v4l2 though. The module option is easy, but it seems v4l2 has some frame rate enumeration stuff that could be used (v4l2_frmivalenum).
Same with resolution and pixel formats. We should be able to support a lot more than just YUYV and 640x480 and 320x240, and I think I can figure out some of that at the hardware level, I just don't know how to fit it into v4l2/gspca.