Hi Marco,
On Saturday 12 July 2008, Marco Argiolas wrote:
> Hi all,
> just few weeks ago I made a patch for the uvcvideo driver in order to flip
> webcam images.
> I thought it wasn't possible to ask the webcam to flip the image by
> itself!!
>
> But now, surfing on internet I found this:
> http://serialize.blogspot.com/2008/02/asus-g1s-a1-13m-pixel-webcam-adventur
>e.html
>
> I have the same webcam described in that post:
> 174f:5a35 , Sonix Technology Co., Ltd. , USB 2.0 Camera
>
> So now I know my webcam can flip the image just changing one bit in a
> register:
> 1E MVFP 00 RW Mirror / Vertical Flip Enable
> Bit[7:6] Reserved
> Bit[5] Mirror
> 0: Normal Image
> 1: Mirror Image
> Bit[4] Vertical Flip
> 0: Vertical Flip Disable
> 1: Vertical Flip Enable
> Bit[3:0] Reserved
>
> You can download
> here<http://rapidshare.com/files/94672360/OV9655-datasheet.pdf.html>the
> datasheet of my webcam chip:
> http://rapidshare.com/files/94672360/OV9655-datasheet.pdf.html
>
> Do someone have any ideas on how to change the 4th bit of the register at
> the address 1E?
> In the datasheet there is also written that: "The device slave addresses
> are 60 for write and 61 for read."
Your webcam module is made of two chipsets, a CMOS sensor and a USB bridge.
The sensor, an OV9655, is controlled by the USB bridge firmware through its
I2C interface.
With pre-UVC bridges, I2C registers were configured by the driver on the host.
Flipping the image, if supported by the sensor, was quite easy provided you
have the bridge and sensor documentation.
UVC brought a new standardised interface on the USB side, and the sensor is
now configured by the firmware running on the bridge. There is no standard
way to access the I2C bus from the host. To make specific sensor features
configurable by the driver, the firmware has to implement an extension unit
with proprietary controls and map those controls to I2C register operations.
For instance, a firmware could implement a vertical flip and an horizontal
flip control, and write the appropriate values to the sensor's I2C registers.
Even though this model seems more complex, it makes sense to abstracts the
sensor behind an extension unit so that only the firmware has to care about
sensor-specific information. The host driver sees functions, the firmware
translate between those functions and the low-level, vendor-specific
commands.
Sonix predefined two extension units in their firmware SDK called XU1 and XU2.
Their GUID are
{0x28f03370, 0x6311, 0x4a2e, {0xba, 0x2c, 0x68, 0x90, 0xeb, 0x33, 0x40, 0x16}}
{0x2812ae3f, 0xbcd7, 0x4e11, {0xa3, 0x57, 0x6f, 0x1e, 0xde, 0xf7, 0xd6, 0x1d}}
XU1 implements 5 controls to read and write from ASIC registers, I2C
registers, serial flash and runtime variables, and to read from the internal
ROM.
XU2 implements up to 8 controls that can be used by module vendors through
custom firmware modifications.
Sonix ships a default firmware that doesn't support XU2. Many webcam modules
vendors don't bother adding extra functions and ship their device with that
default firmware. If you look at the lsusb -v output for your camera you will
notice that only XU1 is implemented, so the vendor didn't explicitly provide
a way to access the vertical and horizontal flip functions.
Even though XU1 can be used to read and write I2C registers, that control is
often not implemented, or at least not exposed, by the firmware. The
bmControls field in the extension unit is a bitmask that list the supported
controls. The individual bits, from left to right, are
7-5 Reserved
4 Runtime variables read/write
3 Internal ROM read
2 Serial flash read/write
1 I2C read/write
0 ASIC registers read/write
Your camera has bmControls set to 0x01, which means the I2C read/write control
is marked as supported. However, it might still be supported in the firmware
but marked as unsupported so that applications will not try to access it.
Even if the I2C read/write control is not available, it might still be
possible to access the I2C bus through the ASIC registers. Unfortunately, the
I2C-related ASIC registers are not documented, but it might be possible to
reverse-engineer the binary-only firmware to gather information about those
registers. Another option, of course, would be to ask Sonix for more
information.
I would personally try the I2C read/write control first, even if the camera
claims not to implement it.
To read an I2C register, you will first have to issue a SET_CUR query followed
by a GET_CUR query.
The I2C read/write control is 8 bytes long. Here is how Sonix documents it.
SET_CUR
Index Field Name Description
0x00 SlaveID I2C slave ID
0x01 Length Number of bytes to read/write to the I2C slave
0x02 Data0 I2C data field 0 (I2C slave sub-address)
0x03 Data1 I2C data field 1
0x04 Data2 I2C data field 2
0x05 Data3 I2C data field 3
0x06 Data4 I2C data field 4
0x07 Dummy 0x00: write
0xff: read
GET_CUR
Index Field Name Description
0x00 SlaveID I2C slave ID
0x01 Length Number of bytes issued by SET_CUR
0x02 Data0 Data 0 issued by SET_CUR
0x03 Data1 Retrieved I2C data field 0
0x04 Data2 Retrieved I2C data field 1
0x05 Data3 Retrieved I2C data field 2
0x06 Data4 Retrieved I2C data field 3
0x07 Fixed 0x00
I have no other information so you will probably have to experiment a bit. For
instance I don't know if the I2C slave ID is the 8-bit device address (60 for
write, 61 for read - or is it 0x60 and 0x61 ?) or the 7-bit device address
(30 or 0x30). I'm also not sure what the length field should be set to in the
SET_CUR command. For a 8-bit register read I would guess it should be set to
1.
Could you try to tweak the driver to read the PID and VER OV9655 registers and
see how the camera behaves ?
Best regards,
Laurent Pinchart
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
