rreignier Posted March 2, 2020 Posted March 2, 2020 Hi! Now that the camera interface has been merged in mainline Kernel, I would like to try to use the OrangePi OV5640 camera module on my OrangePi One. So with the latest Armbian Bionic (20.02.1, kernel 5.4.20), I have been trying to get a device tree overlay. But for now, it fails to compile with: $ sudo armbian-add-overlay sun8i-h3-csi.dts Compiling the overlay Error: sun8i-h3-csi.dts:27.23-24 syntax error FATAL ERROR: Unable to parse input tree Error compiling the overlay My current overlay looks like this: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { csi_mclk_pin: csi-mclk-pin { pins = "PE1"; function = "csi"; }; }; }; fragment@1 { target = <&i2c2>; __overlay__ { status = "okay"; ov5640: camera@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&csi_mclk_pin>; clocks = <&ccu CLK_CSI_MCLK>; clock-names = "xclk"; AVDD-supply = <®_aldo1>; DOVDD-supply = <®_dldo3>; DVDD-supply = <®_eldo3>; reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */ powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */ port { ov5640_ep: endpoint { remote-endpoint = <&csi_ep>; bus-width = <8>; data-shift = <2>; /* lines 9:2 are used */ hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; }; fragment@2 { target = <&csi>; __overlay__ { status = "okay"; port { csi_ep: endpoint { remote-endpoint = <&ov5640_ep>; bus-width = <8>; hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; }; So the line 27, which seem to trigger the error is: `clocks = <&ccu CLK_CSI_MCLK>;` Also, according to the documentation, the regulator fields are required but this board does not have much regulators (like AXP209), so I have no idea what to write here. But this is my first time writing a device-tree overlay so I am not sure what is wrong with this line. Could someone guide me to get my overlay right? And, does anyone already got the CSI interface working with OV5460 sensor on a H3 based board? Thank you. 1 Quote
martinayotte Posted March 3, 2020 Posted March 3, 2020 14 hours ago, rreignier said: So the line 27, which seem to trigger the error is: `clocks = <&ccu CLK_CSI_MCLK>;` Right ! This is because CLK_CSI_MCLK is not define since it is not compiled from Main DT where there are kernel includes defining it. In overlays, you need to use strictly numeric values, no defines are allowed ... 0 Quote
rreignier Posted March 3, 2020 Author Posted March 3, 2020 5 minutes ago, martinayotte said: Right ! This is because CLK_CSI_MCLK is not define since it is not compiled from Main DT where there are kernel includes defining it. In overlays, you need to use strictly numeric values, no defines are allowed ... Ok, I see. Thank you @martinayotte From sun8i-h3-ccu.h I see: #define CLK_CSI_MCLK 107 So what syntax should I use to set it to 107? clocks = <&ccu 107>; or clocks = <107>; or clocks = "107"; Thank you 0 Quote
martinayotte Posted March 3, 2020 Posted March 3, 2020 10 minutes ago, rreignier said: So what syntax should I use to set it to 107? Yes, like that : clocks = <&ccu 107>; If it doesn't work, try to find the "phandle" of the "ccu" by decompiling the main DT, and write like (where N is the numeric value of the phandle found) : clocks = <N 107>; 0 Quote
rreignier Posted March 3, 2020 Author Posted March 3, 2020 2 minutes ago, martinayotte said: Yes, like that : clocks = <&ccu 107>; Ok, thanks a lot, I will try it tonight. 0 Quote
rreignier Posted March 3, 2020 Author Posted March 3, 2020 By replacing `CLK_CSI_MCLK`, `GPIO_ACTIVE_LOW` and `GPIO_ACTIVE_HIGH` constants by respectively `107`, `1` and `0` the device-tree overlay can be compiled. But during the boot, I got: [ 10.837084] i2c i2c-1: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 10.843681] ov5640 1-003c: ov5640_read_reg: error: reg=300a [ 10.849315] ov5640 1-003c: ov5640_check_chip_id: failed to read chip identifier So I have disabled my overlay and load the sun8i-h3-i2c2 overlay instead. With the command: i2cdetect -y 1 I got a lot of these errors in the serial console: [ 40.470126] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 42.518174] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 44.566261] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 [ 46.614294] i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0 From this post I assumed that I could have a pull-up issue so I have created this overlay to enable the internal pull-up on the i2c-2 pins: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { i2c2_pins: i2c2-pins { pins = "PE12", "PE13"; function = "i2c2"; bias-pull-up; }; }; }; fragment@1 { target = <&i2c2>; __overlay__ { pinctrl-0 = <&i2c2_pins>; status = "okay"; }; }; }; But now, I do not see the camera at the address 0x3c and if I let the i2cdetect continue, I get the "I2C bus locked" errors. With the GC235 camera module, I detect something at the address 0x4c. So, even if my OV5640 camera module is brand new, I am not sure if it is working. Does anyone have an idea on how to test if my module is still functional? 0 Quote
rreignier Posted March 3, 2020 Author Posted March 3, 2020 Actually, I have just discovered that the camera module I have received is a GC2035 and not a OV5640 as ordered. So I won't be able to continue my investigations. 0 Quote
olivluca Posted March 28, 2020 Posted March 28, 2020 Well, if you manage to get that (the gc2035) working it will make my day 0 Quote
rreignier Posted May 28, 2020 Author Posted May 28, 2020 @olivluca Sorry, but I don't feel like writing a full kernel driver After some discussions with the vendor and some delivery delays because of the COVID-19, I have now received the OV5640 camera sensor board! But with the overlay previously posted, there is not anything better I have then crafted this simple overlay to enable the `i2c2` with pull-up: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { i2c2_pins: i2c2-pins { pins = "PE12", "PE13"; function = "i2c2"; bias-pull-up; }; }; }; fragment@1 { target = <&i2c2>; __overlay__ { pinctrl-0 = <&i2c2_pins>; status = "okay"; }; }; }; I applied it with: $ sudo armbian-add-overlay i2c2-with-pullup.dts $ sudo reboot Once rebooted, I have checked the i2c device number. I am looking for address `1c2b400` according to the dtsi: $ ls -l /sys/class/i2c-adapter/ total 0 lrwxrwxrwx 1 root root 0 Jan 1 1970 i2c-0 -> ../../devices/platform/soc/1ee0000.hdmi/i2c-0 lrwxrwxrwx 1 root root 0 Jan 1 1970 i2c-1 -> ../../devices/platform/soc/1c2b400.i2c/i2c-1 So let's check the detected devices on bus `1`: $ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Nothing! While with the GC2035 connected, I have: $ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6f 70: -- -- -- -- -- -- -- -- Does someone who owns an H3 based Orange Pi and the OV5640 camera module could try the above commands to see if the module is detected? Thank you. 0 Quote
olivluca Posted May 29, 2020 Posted May 29, 2020 See: it's a sign you have to write a kernel driver for the gc2035 (just kidding). 0 Quote
mostly Posted June 2, 2020 Posted June 2, 2020 On 5/29/2020 at 12:50 AM, rreignier said: Does someone who owns an H3 based Orange Pi and the OV5640 camera module could try the above commands to see if the module is detected? Was playing with it last October, exactly the same result. OV5640 now works only on kernel 3.x Somebody has to fix mainline driver(s). 0 Quote
rreignier Posted June 3, 2020 Author Posted June 3, 2020 10 hours ago, mostly said: Somebody has to fix mainline driver(s). Actually. I cannot see the device on the i2c bus, so I don't think that the driver is to blame here. Or maybe i2c driver, but I don't think so. Which kernel are you using to make use of the OV5640 so I could check that my camera works? 0 Quote
Werner Posted June 3, 2020 Posted June 3, 2020 According to https://cateee.net/lkddb/web-lkddb/VIDEO_OV5640.html the OV5640 is in mainline since 4.13 so any earlier implementation must have been custom. 1 Quote
mostly Posted June 4, 2020 Posted June 4, 2020 On 6/3/2020 at 9:11 AM, rreignier said: Which kernel are you using to make use of the OV5640 so I could check that my camera works? 3.4.113 (Armbian_5.46) fex: [csi0] vip_dev0_mname = "ov5640" sunxi-pio -m "PG11<1><0><1><1>" modprobe ov5640 modprobe vfe_v4l2 On 6/3/2020 at 9:11 AM, rreignier said: I don't think that the driver is to blame here. Or maybe i2c driver, but I don't think so Yup maybe it's just needed to set somewhere a bit enabling that i2c lane, or something else H3/board-specific. I was thinking about connecting oscilloscope to csi to see if there is any activity at all. 0 Quote
jgauthier Posted June 13, 2020 Posted June 13, 2020 I have ov5640 I am trying to get to work on 5.4.43 and then found this thread. It seems like it doesn't work yet, but the reason is known? I have a CSI breakout board on my pi and I can test pins for communication if needed. But I can't even get a /dev/video device registered at this point. 0 Quote
rreignier Posted June 17, 2020 Author Posted June 17, 2020 On 6/13/2020 at 3:46 PM, jgauthier said: I have ov5640 I am trying to get to work on 5.4.43 and then found this thread. It seems like it doesn't work yet, but the reason is known? I have a CSI breakout board on my pi and I can test pins for communication if needed. But I can't even get a /dev/video device registered at this point. Before talking to /dev/video0, I would like to see some activity on the i2c side, so just with i2cdetect. But it did not work for me. If you have another camera module, maybe you could try. 0 Quote
jgauthier Posted June 18, 2020 Posted June 18, 2020 13 hours ago, rreignier said: Before talking to /dev/video0, I would like to see some activity on the i2c side, so just with i2cdetect. But it did not work for me. If you have another camera module, maybe you could try. Even with a working camera on 3.4.113 there's not any indication something is happening on i2c: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@drone:~# i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- 1 Quote
rreignier Posted June 18, 2020 Author Posted June 18, 2020 Thnak you @jgauthier very interesting report. I did not take the time yet to test a 3.4 kernel to make sure my module is actually working or not. 0 Quote
jgauthier Posted June 18, 2020 Posted June 18, 2020 Gotcha. The way I understand it, sun4i_csi should create /dev/video. It doesn't. Doing some kernel level debugging I discovered that the probe() function is never called when the module loads. I learned that probe() is only called if there is hardware to match the name of the device. https://stackoverflow.com/questions/16259580/probe-in-linux-devfreq-driver-not-being-called Quote In order for the probe function to be called, you must add a device from a machine file or via the device tree. This is typically done with platform_device_register() or platform_add_devices() in machine files. Alternatively, of_platform_populate() is used for the device tree model, but code does not use this directly. Furthermore, I found a thread from past January from the author of the OV5640 code that discusses it not working in 5. kernels yet. https://github.com/avafinger/bananapi-zero-ubuntu-base-minimal/issues/17 I have no idea what it takes, but if he says it's not ready for the mainline, I am taking that as the authoritative source. 0 Quote
@lex Posted June 18, 2020 Posted June 18, 2020 OV5640 is ready and works in mainline kernel. /dev/video0 will be created if the driver can find the sensor using the i2c line (generally speaking). You can check the schematic of your board if the sensor is attached to i2c. Compare it to NanoPi Neo Air schematic and you will see the nuances. 1 Quote
jgauthier Posted June 18, 2020 Posted June 18, 2020 1 minute ago, @lex said: OV5640 is ready and works in mainline kernel. /dev/video0 will be created if the driver can find the sensor using the i2c line (generally speaking). You can check the schematic of your board if the sensor is attached to i2c. Compare it to NanoPi Neo Air schematic and you will see the nuances. Okay, thanks. I'm using a banana Pi M2-Zero. the CSI port is actually inverted from normal. I don't know if there is any correlation there. So, are you saying that the NanoPi Neo Air works? If so, I will compare the schematics. 0 Quote
rreignier Posted June 18, 2020 Author Posted June 18, 2020 36 minutes ago, jgauthier said: Furthermore, I found a thread from past January from the author of the OV5640 code that discusses it not working in 5. kernels yet. https://github.com/avafinger/bananapi-zero-ubuntu-base-minimal/issues/17 I have no idea what it takes, but if he says it's not ready for the mainline, I am taking that as the authoritative source. Interesting, indeed. But avafinger does not appear to be a contributor of the mainline driver : here. I think he has worked the old one, for kernel 3.4. Interestingly, the PineTab device tree uses an ov5640 here. On a A64 that uses the same sun6i_csi driver that the H3. So I am sure there is still hope. Quote Doing some kernel level debugging I discovered that the probe() function is never called when the module loads. What device tree are you using? Are you using the device tree overlay I have posted above? 0 Quote
@lex Posted June 18, 2020 Posted June 18, 2020 Yes, it works on NanoPi Neo Air. Maybe someone can have a look at PineTab schematic and compare it to Pine64. It says /* Rear camera */. 0 Quote
jgauthier Posted June 18, 2020 Posted June 18, 2020 19 minutes ago, rreignier said: Interesting, indeed. But avafinger does not appear to be a contributor of the mainline driver : here. I think he has worked the old one, for kernel 3.4. Interestingly, the PineTab device tree uses an ov5640 here. On a A64 that uses the same sun6i_csi driver that the H3. So I am sure there is still hope. What device tree are you using? Are you using the device tree overlay I have posted above? Yes, i did try that. You're on an OrangePi? I'd have to compare that to the bove hardware and my banana as well. 0 Quote
rreignier Posted June 18, 2020 Author Posted June 18, 2020 3 minutes ago, jgauthier said: You're on an OrangePi? Yes, I have been trying on an Orange Pi One. I also have Orange Pi PC Plus and Orange Pi Lite2 (H6) on which I could also try. But since I have received the ov5640 board, I did not try the driver, only the i2cdetect. 0 Quote
jgauthier Posted June 18, 2020 Posted June 18, 2020 @lex Do you have access or knowledge of the device tree for how it works on the NanoPi? As I understand it the processor is basically the same as the BPi, so if the schematics are the same (haven't checked) then I should be able to get it working. 0 Quote
@lex Posted June 18, 2020 Posted June 18, 2020 NanoPi Neo Air https://github.com/avafinger/linux-5.6.y/blob/master/arch/arm/boot/dts/nanopi-neo-air.dts#L578 The NanoPi A64 also works, using the i2c bitbang as probably the same way for the PineTab rear camera, I posted it on the Armbian forum a long time ago. 0 Quote
jgauthier Posted June 20, 2020 Posted June 20, 2020 Well, I tried the i2c overlay, along with implementing the dts posted above. This is an H2+ but is pin-for-pin identical to the H3. I verified the schematics are the same between the two board. I still have nothing when i load the ov5640 driver. I'm not sure what else to try. 0 Quote
gsumner Posted June 21, 2020 Posted June 21, 2020 @rreignier, I've just gotten an ov5640 going with my Orange Pi Zero Plus2 at 640x480 on mainline, Buster 5.4.43 - maybe the following applies to you too. I had bus locked errors until I powered up the camera, on the Zero it was PA8 and PA7 for autofocus (which I turned on just in case). Looking at the One schematic (https://linux-sunxi.org/images/7/7e/ORANGE_PI-ONE-V1_1.pdf) it looks like it's PA17, PG11 and PG13 for autofocus. After that I still wasn't getting an answer on i2c2, the ov5640 datasheet (https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf) says XVCLK (CLK_CSI_MCLK in the device tree) needs to be running before accessing registers. I couldn't see an a/c voltage on the csi-mclk pin so figured that was the issue. The fix for me was connecting the clock parent in the device tree. I'll post my dtb changes. I'm not sure this is all correct, but it lets me open the camera without having to mess with any gpios etc after boot. Inside the "model = "OrangePi Zero Plus2";" braces: reg_vdd_1v5_csi: vdd-1v5-csi { compatible = "regulator-fixed"; regulator-name = "vdd1v5-csi"; regulator-min-microvolt = <1500000>; regulator-max-microvolt = <1500000>; gpio = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */ enable-active-high; regulator-boot-on; regulator-always-on; }; reg_vcc_csi: vcc-csi { compatible = "regulator-fixed"; regulator-name = "vcc-csi"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; gpio = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */ enable-active-high; regulator-boot-on; regulator-always-on; }; reg_vcc_af_csi: vcc-af-csi { compatible = "regulator-fixed"; regulator-name = "vcc-af-csi"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; gpio = <&pio 0 7 GPIO_ACTIVE_HIGH>; /* PA7 */ enable-active-high; regulator-boot-on; regulator-always-on; }; At top level: &ccu { /* Use a stable clock source with known fixed rate for MCLK */ assigned-clocks = <&ccu CLK_CSI_MCLK>; assigned-clock-parents = <&osc24M>; assigned-clock-rates = <24000000>; }; &csi { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; /* Parallel bus endpoint */ csi_ep: endpoint { remote-endpoint = <&ov5640_ep>; bus-width = <8>; hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; &i2c2_pins { bias-pull-up; }; &i2c2 { status = "okay"; ov5640: camera@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&csi_mclk_pin>; clocks = <&ccu CLK_CSI_MCLK>; clock-names = "xclk"; AVDD-supply = <®_vcc_af_csi>; DOVDD-supply = <®_vdd_1v5_csi>; DVDD-supply = <®_vcc_csi>; reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */ powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */ port { ov5640_ep: endpoint { remote-endpoint = <&csi_ep>; bus-width = <8>; data-shift = <2>; /* lines 9:2 are used */ hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; I also added csi_mclk_pin to sunxi-h3-h5.dtsi (after "csi_pins: csi-pins {") but I suspect you could reference the pin directly in the dtb and skip this: /omit-if-no-ref/ csi_mclk_pin: csi-mclk-pin { pins = "PE1"; function = "csi"; }; I'm currently having issues with only being able to use 640x480, vlc reporting incorrect frame size and crashes when streaming from motion, but I don't want to derail your thread unless you have the same issues. Hope that helps, Greg 2 Quote
@lex Posted June 22, 2020 Posted June 22, 2020 Ahh, Good catch. DOVDD first, then AVDD, followed by DVDD. In the case of M2Z: gpio = <&pio 3 14 GPIO_ACTIVE_HIGH>; /* PD14 */ sensor is at least recognized with i2c bit bang. ls /dev/video video0 video1 v4l2-ctl --list-devices sun6i-csi (platform:camera): /dev/video1 cedrus (platform:cedrus): /dev/video0 v4l2-ctl -d 1 --list-formats --list-ctrls User Controls contrast 0x00980901 (int) : min=0 max=255 step=1 default=0 value=0 flags=slider saturation 0x00980902 (int) : min=0 max=255 step=1 default=64 value=64 flags=slider hue 0x00980903 (int) : min=0 max=359 step=1 default=0 value=0 flags=slider white_balance_automatic 0x0098090c (bool) : default=1 value=1 flags=update red_balance 0x0098090e (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider blue_balance 0x0098090f (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider exposure 0x00980911 (int) : min=0 max=65535 step=1 default=0 value=885 flags=inactive, volatile gain_automatic 0x00980912 (bool) : default=1 value=1 flags=update gain 0x00980913 (int) : min=0 max=1023 step=1 default=0 value=176 flags=inactive, volatile horizontal_flip 0x00980914 (bool) : default=0 value=0 vertical_flip 0x00980915 (bool) : default=0 value=0 power_line_frequency 0x00980918 (menu) : min=0 max=3 default=1 value=1 Camera Controls auto_exposure 0x009a0901 (menu) : min=0 max=1 default=0 value=0 flags=update Image Processing Controls pixel_rate 0x009f0902 (int64) : min=0 max=2147483647 step=1 default=61430400 value=61430400 flags=read-only test_pattern 0x009f0903 (menu) : min=0 max=4 default=0 value=0 ioctl: VIDIOC_ENUM_FMT Type: Video Capture [0]: 'BA81' (8-bit Bayer BGBG/GRGR) [1]: 'GBRG' (8-bit Bayer GBGB/RGRG) [2]: 'GRBG' (8-bit Bayer GRGR/BGBG) [3]: 'RGGB' (8-bit Bayer RGRG/GBGB) [4]: 'BG10' (10-bit Bayer BGBG/GRGR) [5]: 'GB10' (10-bit Bayer GBGB/RGRG) [6]: 'BA10' (10-bit Bayer GRGR/BGBG) [7]: 'RG10' (10-bit Bayer RGRG/GBGB) [8]: 'BG12' (12-bit Bayer BGBG/GRGR) [9]: 'GB12' (12-bit Bayer GBGB/RGRG) [10]: 'BA12' (12-bit Bayer GRGR/BGBG) [11]: 'RG12' (12-bit Bayer RGRG/GBGB) [12]: 'YUYV' (YUYV 4:2:2) [13]: 'YVYU' (YVYU 4:2:2) [14]: 'UYVY' (UYVY 4:2:2) [15]: 'VYUY' (VYUY 4:2:2) [16]: 'HM12' (YUV 4:2:0 (16x16 Macroblocks)) [17]: 'NV12' (Y/CbCr 4:2:0) [18]: 'NV21' (Y/CrCb 4:2:0) [19]: 'YU12' (Planar YUV 4:2:0) [20]: 'YV12' (Planar YVU 4:2:0) [21]: 'NV16' (Y/CbCr 4:2:2) [22]: 'NV61' (Y/CrCb 4:2:2) [23]: '422P' (Planar YUV 4:2:2) [24]: 'RGBP' (16-bit RGB 5-6-5) [25]: 'RGBR' (16-bit RGB 5-6-5 BE) [26]: 'JPEG' (JFIF JPEG, compressed) 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.