On Tue, Feb 14, 2023 at 10:26:24PM +0100, Martin Blumenstingl wrote: > On Mon, Feb 13, 2023 at 12:11 PM Ville Syrjälä > <ville.syrj...@linux.intel.com> wrote: > [...] > > > One could use HDMI_VENDOR_INFOFRAME_SIZE with this as well: > > > u8 buffer[HDMI_INFOFRAME_SIZE(VENDOR)]; > > > But it would only result in an 8 byte wide buffer. > > > Nobody uses it like this yet. > > > > Not sure that would make any sense since a vendor > > specific infoframe has no defined size until you > > figure out which vendor defined it (via the OUI). > My understanding is that all of the existing HDMI vendor infoframe > code is built for HDMI_IEEE_OUI.
Only because no one has bothered to implement any others. > > > I suppose the current value of 4 is also a bit nonsense > > as well then, becasue that is a legal value for the > > HDMI 1.4 vendor specific infoframe, but might not be > > valid for any other infoframe. > > > > 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. -- Ville Syrjälä Intel
