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

[Nicolas Dufresne]

Le mardi 14 janvier 2025 à 14:37 +0300, Dmitry Osipenko a écrit :
> 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.

GStreamer uses G_PARM to get and report the frame interval (and flip the
fraction over to make it a frame rate). I've assumed these two should match and
it wasn't worth a special case of HDMI receivers.

Nicolas

> 
> 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.
>