-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Camera with libcamera #55
Comments
Some logs (and documenting debug tools):
another suggestion was |
This is often a permissions thing. Make sure the user is in the 'video' group.
This is curios. Can you post a report of this to the libcamera mailing list? |
I forgot to link to the patches for libcamera added due to the gnutls version on SailfishOS being old (?) https://git.sailfishos.org/mal/libcamera |
Ok, if that's all that is required to support the older gnutls, we can prepare a patch for that to be integrated in libcamera. |
The gnutls patch to libcamera is not tested and we had some issues during testing. It might be that something else could be needed also. |
If I'm not mistaken, the latest gnutls 2.x version was released 4 years ago. Isn't this a pretty big security concern ? |
Ok, it looks like we wouldn't really want to support an older version of GnuTLS anyway. It might be better to investigate upgrading the packages in your distribution. |
gnutls is not really used any more in Sailfish OS, after next release it is not needed at all by default. |
I'm fine with having this as a downstream patch ... but if it's not needed otherwise, it should be safe to upgrade to gnutls 3? |
The AF firmware currently does not get started correctly after uploading ... under investigation. This aborted the driver startup and might have been the reason for not being able to open I also added This fixes (?) the error about
|
I'm afraid you need a bit more than that. The flag itself reports that the driver conforms with the related API requirements. From a libcamera point of view, this means that the driver should implement support for filtering formats during format enumeration through the mbus_code argument (see https://linuxtv.org/downloads/v4l-dvb-apis/userspace-api/v4l/vidioc-enum-fmt.html). Without that, the simple pipeline handler won't work properly. |
Thanks for the pointers! If I understand correctly I basically need to replicate/implement this https://github.com/sailfish-on-dontbeevil/kernel-megi/blob/9429f77dc7e252a99f11cd0613913e5634a2e981/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c#L50 What I don't understand yet is why libcamera wouldn't work with a unfiltered list as well? Or does it give up after a certain number of tries? |
Hmm, I'm confused ... I tried implementing (a rough version of what I wrote above) but it does not seem to get called ever:
The text message never gets printed to dmesg. I also tried
|
libcamera needs to know what V4L2 pixel formats a video node supports for a given media bus code. The V4L2 API used to only support enumerating all supported pixel formats, until the recent addition of format enumeration filtering. |
This doesn't seem right. As you're using a non-mainline kernel I can't really help much to diagnose the issue, but it shouldn't be too difficult to trace the code paths to figure out why an error is returned. |
Some progress:
There is a bug in ov6540 where it uses the current frame rate to check if a certain format is possible but some (all?) formats are actually only available at a lower FPS. I changed that to 2FPS (0). Now I get a bit further. For the first half of the output I implemented the format filtering already, so it gets one step further. It then complained about the resolution (VIDIOC_ENUM_FRAMESIZES) https://www.kernel.org/doc/html/v4.13/media/uapi/v4l/vidioc-enum-framesizes.html not being available for sun6i-csi so I implemented that (returning 4800x4800 as written in the header). ov5640 also seems to return the max resolution only ... future todo ... Running libcamerasrc unfortunately crashes:
with dmesg:
I'll clean up my changes and upload it somewhere for review/discussion next. Any ideas why the malloc fails? |
Can you use gstreamer like this? doesn't it need to connect to something? Does qcam work?
do the CMA reserved allocations need increasing somewhere? |
I think so, but just to be save I also now tested
Qt5 on SailfishOS is ancient (5.6) so we deactivated that. Will try if it actually compiles.
Will try to google how to do that and what it means :-D |
Adding
|
Before you try gstreamer, I really, really advice using either the qcam or cam tools (cam would be best, it's simpler and lower-level). Otherwise you'll end up debugging kernel issues, libcamera issues and gstreamer issues all together, it will be messy. Once you can successfully capture images with the cam tool, you can move to testing with gstreamer. |
I had a look at the line Debugging a bit further, I got to understand that linking the main camera (ov5640) succeeds and actually only the front camera fails to link
Three questions:
in mc-entity.c in
|
I cleaned up my patches so far and uploaded them here on a fork of the megi kernel (based on 5.10rc2): Otherwise I'm unfortunately no further than in the comment above, ie. it tries to capture but nothing actually happens |
Possibly not, but given that there's an issue here, and that you can't capture images from the other sensor, investigating this may unveil a hidden problem.
No, this is fine. If a driver doesn't care about links it doesn't have to implement the .link_setup() operation, in which case media_entity_call() returns -ENOIOCTLCMD. That's expected behaviour.
I'd recommend configuring the MC pipeline manually (with media-ctl), and capturing with a V4L2 test application (yavta or v4l2-ctl) in order to ensure that the kernel drivers are operational. I suspect a misconfiguration that prevents the CSI-2 receiver from correctly receiving images. There may be debug information that the hardware can provide, but I don't have any experience with sun6i so I can't really help you there. |
After dropping some WIP changes to ov5640 I can now get it to manually capture frames using
(already done via systemd)
without the second command it will complain about unsupported pixelformat and/or resolution mismatch capturing with
after capturing with
Thinks I need to look at:
|
I limited the max resolution/frame size returned by ov5640 to 1280x720 and can now receive "data" with
I used imagemagick to convert: |
The big picture is that libcamera talks to the sun6i_csi and the camera drivers. It also provides a gstreamer source. This source can then be used by the normal sfos camera app.
Issues:
flash driver is broken, needs to be disabled in dts: sailfish-on-dontbeevil/kernel-megi@9429f77 thanks @piggz
libcamera as packaged by mal crashes due to (?) gnutls patch (workaround: set HAVE_GNUTLS to 0 in libcamera/meson.build)
missing firmware files: dmesg:
and
Update: gc2145-init.bin is not needed (thanks MartijnBraam)
for more see https://paste.ubuntu.com/p/hw5ZVpB2cr/
will need to be added here: https://github.com/sailfish-on-dontbeevil/kernel-megi/blob/9429f77dc7e252a99f11cd0613913e5634a2e981/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c#L708
thanks to @pinchartl and @MartijnBraam for infos
The text was updated successfully, but these errors were encountered: