[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFBinCARqY5K6r_9WcKvBnVfUJuFv78ZYk6D0UiA7FYaA4Kkog@mail.gmail.com>
Date: Sat, 18 Feb 2023 16:33:56 +0100
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc: dri-devel@...ts.freedesktop.org, Helge Deller <deller@....de>,
linux-fbdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Hans Verkuil <hans.verkuil@...co.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Bernard Zhao <bernard@...o.com>
Subject: Re: [PATCH v1 RFC] video/hdmi: Fix HDMI_VENDOR_INFOFRAME_SIZE
On Tue, Feb 14, 2023 at 10:35 PM Ville Syrjälä
<ville.syrjala@...ux.intel.com> wrote:
[...]
> > > We should perhaps just get rid of HDMI_VENDOR_INFOFRAME_SIZE
> > > entirely.
> > My thought was to make it the correct size for
> > drm_hdmi_vendor_infoframe_from_display_mode(). Then developers using
> > this "common" vendor infoframe don't have to worry much.
> > If there's another vendor infoframe implementation (which I'm not
> > aware of, but it may exist - since as you point out: it's vendor
> > specific) then the driver code shouldn't use
> > drm_hdmi_vendor_infoframe_from_display_mode() but rather implement
> > something custom. At that point the person implementing that will also
> > need to know their specific infoframe maximum size.
>
> Yes but that other infoframe will still have
> type==HDMI_INFOFRAME_TYPE_VENDOR, and
> HDMI_INFOFRAME_SIZE(VENDOR) would again
> give the wrong answer.
So this means the way forward is to remove HDMI_VENDOR_INFOFRAME_SIZE?
That means it's up to the (HDMI) driver developers to use a big enough
buffer (by hard-coding the size). Last time I checked all drivers did.
Best regards,
Martin
Powered by blists - more mailing lists