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

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