Re: [RESEND PATCH v5 0/4] Add Synopsys DesignWare HDMI RX Controller

[Dmitry Osipenko <dmitry.osipenko@collabora.com>]

On 1/9/25 02:17, Tim Surber wrote:
> Hi,
> 
> I tested your patch with the command
> 
> # gst-launch-1.0 -v v4l2src device=/dev/video1 ! fakesink
> 
> If this worked I moved on to a visual test using
> 
> # gst-launch-1.0 -v v4l2src device=/dev/video1 ! queue ! v4l2convert !
> waylandsink
> 
> I used a Windows PC  with a Nvidia GTX 4060 as my source for the
> following tests.
> 
> | Format       | Result                                      |
> | ------------ | ------------------------------------------- |
> | 4k60p RGB    | Recognized as 1080p / 120 fps - no output   |
> | 4k60p 4:2:2  | Recognized as 1080p / 120 fps - no output   |
> | 4k60p 4:4:4  | Error: Device wants 1 planes                |
> | 4k30p RGB    | ok                                          |
> | 4k30p 4:2:2  | ok                                          |
> | 4k30p 4:4:4  | Error: Device wants 1 planes                |
> | FHD60p RGB   | ok                                          |
> | FHD60p 4:2:2 | ok                                          |
> | FHD60p 4:4:4 | Error: Device wants 1 planes                |
> 
> 
> When testing 4:4:4 chroma I got the following error:
> 
> # gst-launch-1.0 -v v4l2src device=/dev/video1 ! fakesink
> /sys/v4l2/gstv4l2object.c(4344): gst_v4l2_object_set_format_full (): /
> GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> Device wants 1 planes
> 
> I could record and convert (with errors) the files with 4:4:4 chroma
> using the command Shreeya posted, but the resulting video had wrong
> colors and was flashing.
> 
> I was not able to test 4:2:0 chroma. I tried to generate an custom EDID
> with support for it but I could not select it in the graphics driver in
> the source, maybe this is just an issue with my setup.

Thanks a lot for the testing, very appreciate it! Good that RGB works
for you with no problems.

Testing YUV formats isn't trivial. Personally I've a custom setup with a
modified display driver of RPi to test them. See more below.

> I also observed that the the framerate is reported wrong, for example
> setting the source to FHD60p RGB resulted in the following:
> 
> # v4l2-ctl --all -L --list-formats-ext -d /dev/video0
> Active width: 1920
>     Active height: 1080
>     Total width: 2200
>     Total height: 1125
>     Frame format: progressive
>     Polarities: -vsync -hsync
>     Pixelclock: 214076000 Hz (86.50 frames per second)
> 
> This wrong framerate reporting seemed to happen across all framerates
> and resolutions. Gstreamer Pipeline negotation showed the same results.

I've re-tested YUV444 4k capture using RPi4, works flawlessly. Note for
gst-launch-1.0 you used video1 and video0 device is used by v4l2-ctl
command above, maybe you're using wrong device. Please post a complete
output of the v4l2-ctl command.

The command I used to test YUV444 capture:

# v4l2-ctl --verbose -d /dev/video1
--set-fmt-video=width=3840,height=2160,pixelformat=NV24 --stream-mmap=4
--stream-skip=3 --stream-count=3300 --stream-to=hdmi.raw --stream-poll

The I converted captured data to a video file and played it:

# ffmpeg -f rawvideo -vcodec rawvideo -s 3840x2160 -r 30 -pix_fmt nv24
-y -i hdmi.raw output.mkv && mpv output.mkv -loop 0

Don't see any problems with a reported framerate:

DV timings:
        Active width: 3840
        Active height: 2160
        Total width: 4400
        Total height: 2250
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 296992000 Hz (30.00 frames per second)

Note the timing data reported by v4l2-ctl updates after launching the
capture. It's not updated dynamically when you changing mode on the source.

Lastly, please run `echo 3 >
/sys/module/synopsys_hdmirx/parameters/debug`.  Watch the kmsg log.
Check that it says "hdmirx_get_pix_fmt: pix_fmt: YUV444" when you
connecting HDMI cable to a YUV444 source and see other related messages.
If it says RGB, then your source is transmitting RGB.

> During my testing I got sometimes an error
> 
> 
> # dmesg
> dma alloc of size 24883200 failed
> 
> 
> I'm not sure when this happened and how to reproduce it.

This comes from v4l core, should be harmless as long as capture works.
It's a known noisy msg, you may ignore it for today.

> Then I tried to use an AppleTV 4k as source. I don't know what
> resolution it tried to negotiate but I got this error in addition to the
> previous "Device wants 1 planes" and no connection:
> 
> # dmesg
> fdee0000.hdmi_receiver: hdmirx_query_dv_timings: signal is not locked
> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: signal not lock,
> tmds_clk_ratio:0
> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: mu_st:0x0, scdc_st:0x0,
> dma_st10:0x10
> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: signal not lock,
> tmds_clk_ratio:0
> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: mu_st:0x0, scdc_st:0x0,
> dma_st10:0x14

"Device wants 1 planes" sounds like you're using a wrong v4l video
device. Please double check. Though, the "signal not lock" means it
doesn't work anyways, please make sure you're using the default driver
EDID and not a custom one.

-- 
Best regards,
Dmitry