[libcamera-devel] Failed to commit atomic request: Invalid argument

Fri Oct 29 18:15:57 CEST 2021

Quoting Eric Curtin (2021-10-29 15:54:25)
> On Fri, 29 Oct 2021 at 15:02, Kieran Bingham
> <kieran.bingham at ideasonboard.com> wrote:
> >
> > Quoting Eric Curtin (2021-10-29 14:36:08)
> > > On Fri, 29 Oct 2021 at 13:21, Kieran Bingham
> > > <kieran.bingham at ideasonboard.com> wrote:
> > > >
> > > > Quoting Eric Curtin (2021-10-29 12:38:46)
> > > > > Hi Guys,
> > > > >
> > > > > Still struggling to get the display working on 2 different fedora 34 laptops.
> > > > > The first problem I run into is:
> > > >
> > > > Just ... checking... By on 'laptops' you mean - without running a
> > > > GUI/Wayland/X ?
> > >
> > > I have GUI/Wayland/X installed but not started. One machine started in
> > > multi-user.target node with text-console:
> > >
> > > sudo systemctl set-default multi-user.target
> > >
> > > And the other machine I just switch out of X server via Ctrl-Alt-F4.
> >
> > I assumed so - but I had to check ;-)
> >
> > > > This cam drm support is for direct render when a GUI isn't available.
> > > > If a graphical environment is running, it will have ownership of the
> > > > screen.
> > >
> > > The screen does go blank, the console disappears but it's completely black, no
> > > camera output.
> > >
> > > >
> > > > > "Failed to commit atomic request: Invalid argument"
> > > > >
> > > > > This occurs when drmModeAtomicCommit is called with  these flags set:
> > > > >
> > > > > DRM_MODE_ATOMIC_ALLOW_MODESET | DRM_MODE_PAGE_FLIP_EVENT |
> > > > > DRM_MODE_ATOMIC_NONBLOCK
> > > > >
> > > > > in the drmFlags.
> > > > >
> > > > > Then we go from:
> > > > >
> > > > > drmModeAtomicCommit -> DRM_IOCTL -> drmIoctl -> ioctl
> > > > >
> > > > > and return EINVAL. Anybody have an idea what could be going wrong here?
> > > > > Are the flags ok in this case etc.?
> > > > >
> > > > > Some version info and other info on how I am running this:
> > > > >
> > > > > $ rpm -qa | grep libdrm
> > > > > libdrm-2.4.107-1.fc34.x86_64
> > > > > libdrm-devel-2.4.107-1.fc34.x86_64
> > > > > libdrm-debugsource-2.4.107-1.fc34.x86_64
> > > > > libdrm-debuginfo-2.4.107-1.fc34.x86_64
> > > > >
> > > > > $ uname -a
> > > > > Linux fedora 5.14.13-200.fc34.x86_64 #1 SMP Mon Oct 18 12:39:31 UTC
> > > > > 2021 x86_64 x86_64 x86_64 GNU/Linux
> > > > >
> > > > > sudo LD_LIBRARY_PATH=./build/src/ipa/ipu3:./build/src/ipa/raspberrypi:./build/src/ipa/rkisp1:./build/src/ipa/vimc:./build/src/libcamera:./build/src/libcamera/base:./build/src/libcamera/base/libcamera-base.so.0.0.0.p:./build/src/libcamera/libcamera.so.0.0.0.p
> > > > > ./build/src/cam/cam -c 1 -C16 -DeDP-1 -s
> > > >
> > > > You shouldn't need to set LD_LIBRARY_PATH for this. Meson links the
> > > > binaries to the built location, and updates them when installing.
> > > >
> > > > Have you set LD_LIBRARY_PATH due to an issue you faced?
> > >
> > > I tend to do this to make builds quicker, skip the install step and
> > > just run. And to avoid
> > > potentially overwriting stuff in /usr (and to not cause any issues
> > > with the wrong library being
> > > loaded system vs built one) the case where I want. I can just install
> > > and see what happens.
> >
> > That's what I meant, you can run directly from the build directory
> > without installing.
> >
> > You should be able to run
> >   ./build/src/cam/cam -c 1 -C16 -DeDP-1 -s  ...
> >
> > without exporting / setting LD_LIBRARY_PATH.
> 
> Good to know thanks for your help, in general.
> 
> >
> > >
> > > >
> > > >
> > > > > pixelformat=YUYV,height=1080,width=1920
> >
> > Do you know if your DRM connector target capable of displaying
> > YUYV,height=1080,width=1920 ? Or is it limited to RGB formats?
> 
> I think so, it I'm reading this output correctly, thanks for telling me about
> modetest:
> 
> trying to open device 'i915'...done

<big snip>

> Planes:
> id crtc fb CRTC x,y x,y gamma size possible crtcs
> 31 98 256 0,0 0,0 0        0x00000001
>   formats: C8   RG16 XR24 XB24 AR24 AB24 XR30 XB30 AR30 AB30 XR4H XB4H
> AR4H AB4H YUYV YVYU UYVY VYUY NV12 P010 P012 P016 Y210 Y212 Y216 XYUV
> XV30 XV36 XV48

Ok, so the dispaly knows about YUYV formats, and we're just on a
standard i915 driver I think, so I expect it to be possible.

I've just been able to (I think) replicate this on a Surface Go2:

./build/gcc/src/cam/cam -c2 -C16 -s width=1920,height=1280,pixelformat=YUYV -D

[0:35:12.842448030] [7402]  INFO IPAManager ipa_manager.cpp:138 libcamera is not installed. Adding '/home/kbingham/libcamera/build/gcc/src/ipa' to the IPA search path
[0:35:12.843900299] [7402]  INFO Camera camera_manager.cpp:293 libcamera v0.0.11+2283-c40e84d4
[0:35:13.009721157] [7405]  INFO IPU3 ipu3.cpp:1194 Registered Camera[0] "\_SB_.PCI0.LNK0" connected to CSI-2 receiver 0
[0:35:13.026343684] [7405]  INFO IPU3 ipu3.cpp:1194 Registered Camera[1] "\_SB_.PCI0.LNK1" connected to CSI-2 receiver 1
Camera configuration adjusted
Using camera \_SB_.PCI0.LNK0 as cam0
[0:35:13.029442089] [7402]  INFO Camera camera.cpp:937 configuring streams: (0) 1920x1280-NV12
Using KMS plane 52, CRTC 72, connector eDP-1 (95)
cam0: Capture 16 frames
Failed to commit atomic request: Invalid argument
2113.550267 (0.00 fps) cam0-stream0 seq: 000017 bytesused: 2457600/1228800
2113.616847 (15.02 fps) cam0-stream0 seq: 000018 bytesused: 2457600/1228800
2113.683606 (14.98 fps) cam0-stream0 seq: 000019 bytesused: 2457600/1228800
2113.750291 (15.00 fps) cam0-stream0 seq: 000020 bytesused: 2457600/1228800
2113.881542 (7.62 fps) cam0-stream0 seq: 000021 bytesused: 2457600/1228800
2113.948161 (15.01 fps) cam0-stream0 seq: 000022 bytesused: 2457600/1228800
2114.081625 (7.49 fps) cam0-stream0 seq: 000023 bytesused: 2457600/1228800
2114.148303 (15.00 fps) cam0-stream0 seq: 000024 bytesused: 2457600/1228800
2114.281707 (7.50 fps) cam0-stream0 seq: 000025 bytesused: 2457600/1228800
2114.348555 (14.96 fps) cam0-stream0 seq: 000026 bytesused: 2457600/1228800
2114.481826 (7.50 fps) cam0-stream0 seq: 000027 bytesused: 2457600/1228800
2114.548481 (15.00 fps) cam0-stream0 seq: 000028 bytesused: 2457600/1228800
2114.681834 (7.50 fps) cam0-stream0 seq: 000029 bytesused: 2457600/1228800
2114.749734 (14.73 fps) cam0-stream0 seq: 000030 bytesused: 2457600/1228800
2114.882433 (7.54 fps) cam0-stream0 seq: 000031 bytesused: 2457600/1228800
2114.948995 (15.02 fps) cam0-stream0 seq: 000032 bytesused: 2457600/1228800
Failed to stop display pipeline: Invalid argument
Failed to stop frame sink

So, not a solution, but at least I think I can see the same thing as you
now.

> > There is no scaling/format conversion available in this DRM display
> > currently.
> >
> > 'modetest' should report the capabilities to check.
> >
> >
> > > > > [24:13:06.877580453] [12783]  INFO IPAManager ipa_manager.cpp:138
> > > > > libcamera is not installed. Adding
> > > > > '/home/ecurtin/git/libcamera/build/src/ipa' to the IPA search path
> > > > > [24:13:06.878456861] [12783]  INFO Camera camera_manager.cpp:293
> > > > > libcamera v0.0.0+3205-8bba804b
> > > > > Using camera \_SB_.PCI0.XHC_.RHUB.HS01-1:1.0-046d:0843 as cam0
> > > > > [24:13:07.080928044] [12783]  INFO Camera camera.cpp:945 configuring
> > > > > streams: (0) 1920x1080-YUYV
> > > > > Using KMS plane 169, CRTC 236, connector eDP-1 (239)
> > > >
> > > > Seeing this though makes me think it probably got far enough so it must
> > > > be expected to work.
> > >
> > > The screen does go black on both laptops but that's it, I can only see
> > > this output if
> > > I'm connected via ssh or redirect the output to file, but the tty does
> > > get replaced if that
> > > makes sense.
> > >
> > > >
> > > > > cam0: Capture 16 frames
> > > > > Failed to commit atomic request: Invalid argument
> > > >
> > > > But without further debug, I'm not sure I can help on this one yet I'm
> > > > afraid.
> >
> > Can you run:
> >
> > echo 0x1ff | sudo tee /sys/module/drm/parameters/debug
> >
> > then re-run the cam and save the kernel logs to inspect for any hints?
> >
> 
> Thanks for the tip, this looks like it may be highlighting where the problem is:
> 
> [98847.430957] i915 0000:00:02.0:
> [drm:drm_atomic_set_mode_prop_for_crtc [drm]] [CRTC:236:pipe C] bad
> mode blob length: 104

This looks like a clue to follow yes...

--
Kieran