| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| javier__ | sailus: hi, I got access to a Skylake SoC (Core i7-7500U) based laptop that has two MIPI cameras
by looking at the dissasemble ACPI DSDT table, it seems the Camera sensors are ov2680 and ov5648 Device (CAM0) Name (_HID, "OVTI5648") // _HID: Hardware ID Name (_CID, "OVTI5648") // _CID: Compatible ID Name (_DDN, "OV5648-CRDD") // _DDN: DOS Device Name Device (CAM1) Name (_HID, "OVTI2680") // _HID: Hardware ID Name (_CID, "OVTI2680") // _CID: Compatible ID Name (_DDN, "OV2680-CRDD") // _DDN: DOS Device Name for ov2680 there was a driver for ATOMISP drivers/staging/media/atomisp/i2c/atomisp-ov2680.c, but that got removed with the rest of the bridge driver and there is now a new drivers/media/i2c/ov2680.c that's DT-only for ov5648 there was an attempt to land a ATOMISP driver but was found to be pointless IIUC due the state of the bridge driver https://patchwork.kernel.org/patch/9983663/ sailus: I'm not familiar with neither IPU3 CIO2 nor ISP2 (ATOMISP), so I was wondering if these drivers were a good starting point to look at what will take to support these cameras and also wondered what was the plan w.r.t the ipu3 driver, are there camera sensors drivers for it in mainline already or we only have the ISP driver right now? | [09:57] |
| ...... (idle for 27mn) | ||
| cristian_c | I own ov2680 sensor
(that is not supported by windows 10 anymore) I mean, isp is not aupported anymore in windows 10 isp 2401 | [10:31] |
| ................ (idle for 1h19mn) | ||
| ezequielg | mripard: ping | [11:51] |
| mort | Is there a way to find what stride an output device expects?
ah, v4l2_plane_pix_format has bytesperline | [11:56] |
| ......... (idle for 41mn) | ||
| mripard | ezequielg: pong | [12:38] |
| ezequielg | mripard: o/
so, I understand you guys based the decoder work on previous patches from ST, but still I can't find exactly the reason why we need to have a protocol specific struct in the v4l2_ctrl_ptr union, as oposed to just use a void* I am guessing it is to standarize the controls. | [12:50] |
| .... (idle for 19mn) | ||
| *** | ezequielg has quit IRC (Quit: leaving) | [13:12] |
| ........... (idle for 50mn) | ||
| mripard | ezequielg: I'm not sure what you refer to | [14:02] |
| .............. (idle for 1h9mn) | ||
| *** | benjiG has left | [15:11] |
| ....................... (idle for 1h54mn) | ||
| andrey_utkin | Hi, i'm gentoo developer and am considering whether to preserve v4l2loopback package (https://github.com/umlaeute/v4l2loopback) in the distro by stepping up as maintainer of it. Is this software still useful for something which is not available from mainline kernel? Thanks for any clue. | [17:05] |
| .......... (idle for 46mn) | ||
| *** | pmmd has quit IRC (Ping timeout: 248 seconds) | [17:51] |
| ................................ (idle for 2h39mn) | ||
| ndufresne | andrey_utkin, well, this feature is only indirectly available through vivid driver own loopback. But it's not a complete replacement
and don't read me wrong, v4l2loopback is crap and works terribly badly, is not well maintained but being able to create virtual camera is still a feature not covered by the linux kernel (and might never be ;-P) | [20:30] |
| ..... (idle for 24mn) | ||
| cristian_c | ndufresne: I've done a couple of tests | [20:55] |
| ndufresne | cristian_c, sorry, of v4l2loopback ? or some of the subject we discussed yesterday ? | [20:56] |
| cristian_c | ndufresne: default pixel format is UYVY (UYVY 4:2:2) | [20:57] |
| ndufresne | which is quite common | [20:58] |
| cristian_c | I've tried also otger pixel formats from the list: RGB3 (Emulated), BGR3 (Emulated), YU12 (Emulated) and YV12 (Emulated) | [20:59] |
| ndufresne | well, these are (Emulated) which means it's libv4l2 converting from, probably YUY2 | [20:59] |
| cristian_c | all them (except UYVY) don't produce nothing | [20:59] |
| ndufresne | sorry, YUYV, YUY2 is the name in Gst and in MS stuf | [21:00] |
| cristian_c | UYVY makes 'error' line printed continuosly on the terminal
ah, ok | [21:00] |
| ndufresne | UYVY is a variant, little endian ;-P | [21:00] |
| cristian_c | I've tried also v4l2-ctl --list-formats-ext
anyway, what did you mean by 'buffer layout calculation'? I mean what did you mean, exactly, by 'buffer layout calculation'? if I look at qv4l2, I don't know what to look at, about this ndufresne: then, qv4l2 returns info about height and width but I don't see info about bytes per line and image size ndufresne: and about trace, do you mean vlc or qv4l2? | [21:01] |
| ndufresne | best would be to grab a frame using v4l2-ctl, forgot the details, read the man page
then, you can try and calculate the expected size of the buffer with the buffer you captured for YUYV, you have 2bytes per pixels have to leave | [21:08] |
| cristian_c | ok
I tried v4l2-ctl some dwys ago, I'll read the manual | [21:12] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |