[libcamera-devel] presentation

[Enrique Artal]

Hi Laurent,

Thanks for the answer. If at some point, I can provide information, 
please let me know. Amitiés, Enrique.

El 29/4/20 a las 16:07, Laurent Pinchart escribió:
> Hi Enrique,
>
> On Wed, Apr 29, 2020 at 03:08:44PM +0200, Enrique Artal wrote:
>> In the previous reply I forgot to send the output to the list:
>>
>> Media controller API version 5.6.7
>>
>> Media device information
>> ------------------------
>> driver          ipu3-cio2
>> model           Intel IPU3 CIO2
>> serial
>> bus info        PCI:0000:00:14.3
>> hw revision     0x0
>> driver version  5.6.7
>>
>> Device topology
>> - entity 1: ipu3-csi2 0 (2 pads, 1 link)
>>               type V4L2 subdev subtype Unknown flags 0
>>               device node name /dev/v4l-subdev0
>>       pad0: Sink
>>       pad1: Source
>>           [fmt:SGRBG10_1X10/1936x1096 field:none]
>>           -> "ipu3-cio2 0":0 [ENABLED,IMMUTABLE]
>>
>> - entity 4: ipu3-cio2 0 (1 pad, 1 link)
>>               type Node subtype V4L flags 0
>>               device node name /dev/video0
>>       pad0: Sink
>>           <- "ipu3-csi2 0":1 [ENABLED,IMMUTABLE]
>>
>> - entity 10: ipu3-csi2 1 (2 pads, 1 link)
>>                type V4L2 subdev subtype Unknown flags 0
>>                device node name /dev/v4l-subdev1
>>       pad0: Sink
>>       pad1: Source
>>           [fmt:SGRBG10_1X10/1936x1096 field:none]
>>           -> "ipu3-cio2 1":0 [ENABLED,IMMUTABLE]
>>
>> - entity 13: ipu3-cio2 1 (1 pad, 1 link)
>>                type Node subtype V4L flags 0
>>                device node name /dev/video1
>>       pad0: Sink
>>           <- "ipu3-csi2 1":1 [ENABLED,IMMUTABLE]
>>
>> - entity 19: ipu3-csi2 2 (2 pads, 1 link)
>>                type V4L2 subdev subtype Unknown flags 0
>>                device node name /dev/v4l-subdev2
>>       pad0: Sink
>>       pad1: Source
>>           [fmt:SGRBG10_1X10/1936x1096 field:none]
>>           -> "ipu3-cio2 2":0 [ENABLED,IMMUTABLE]
>>
>> - entity 22: ipu3-cio2 2 (1 pad, 1 link)
>>                type Node subtype V4L flags 0
>>                device node name /dev/video2
>>       pad0: Sink
>>           <- "ipu3-csi2 2":1 [ENABLED,IMMUTABLE]
>>
>> - entity 28: ipu3-csi2 3 (2 pads, 1 link)
>>                type V4L2 subdev subtype Unknown flags 0
>>                device node name /dev/v4l-subdev3
>>       pad0: Sink
>>       pad1: Source
>>           [fmt:SGRBG10_1X10/1936x1096 field:none]
>>           -> "ipu3-cio2 3":0 [ENABLED,IMMUTABLE]
>>
>> - entity 31: ipu3-cio2 3 (1 pad, 1 link)
>>                type Node subtype V4L flags 0
>>                device node name /dev/video3
>>       pad0: Sink
>>           <- "ipu3-csi2 3":1 [ENABLED,IMMUTABLE]
> OK, this is where things get a bit messy I'm afraid. The CIO2 driver
> didn't detect the camera sensor. In a nutshell, the driver gets
> information about the hardware topology (which sensor is used and how
> it's connected) from the platform firmware. On x86, this means ACPI (in
> the DSDT table to be exact), on arm it means device tree.
>
> There's no standard to express that information ACPI, and all device
> vendors came up with their own solution (there has been some effort to
> standardize this though, but no complete formal solution in the ACPI
> spec itself). Intel has, for reasons that are out of scope, developed
> two different ways to represent that information in the DSDT. One has
> been designed for devices manufactured for the Windows market, and
> another one for devices manufactured for the Linux market (mostly
> Chromebooks). The CIO2 driver only supports the latter, and your device
> probably implements the former.
>
> We need to teach the CIO2 driver about the Windows-specific data
> representation. The challenge is that, on Windows, vendors usually
> hardcode some information in drivers, so not all the information we need
> may be available in the DSDT. The information that is available also
> makes it difficult to find the sensor from the CIO2, as far as I know
> there's no "link" between the two. Finally, the format of the data isn't
> documented. Different solutions can be considered, but it will take
> someone to do the work. Once that is done, libcamera should be able to
> support your device.
>
> All we need is a volunteer :-)
>
>> El 29/4/20 a las 14:22, Laurent Pinchart escribió:
>>> On Wed, Apr 29, 2020 at 09:04:57AM +0200, Enrique Artal wrote:
>>>> Dear members of the lists,
>>>>
>>>> I am not a developer, so my contribution to this list may be only for
>>>> testing. I use an hp pro x2 612 g2, with Fedora 31 at this time, which
>>>> has (I think!) an ipu3 device. I have compiled libcamera and the device
>>>> is recognized somehow (four /dev/video*) are created but none of them
>>>> are listed with "sudo cam -l"; neither cheese nor webcamoid recognize
>>>> them, only ucview seems to detect something with no image. Last git
>>>> version is installed. If there is some test that should run for this
>>>> device, you can use my assistance. Thanks for you work, Enrique.
>>>>
>>>> PS. If more data is needed, feel free to ask for it.
>>> Could you please send the output of
>>>
>>> media-ctl -p -d /dev/mediaX
>>>
>>> for each of the /dev/media* devices present in your system ? media-ctl
>>> is part of v4l-utils.