On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote: > Hi, > > On Fri, 9 Oct 2020 at 10:24, Simon Ser <contact@xxxxxxxxxxx> wrote: > > User-space should avoid parsing EDIDs for metadata already exposed via > > other KMS interfaces and properties. For instance, user-space should not > > try to extract a list of modes from the EDID: the kernel might mutate > > the mode list (because of link capabilities or quirks for instance). > > > > Other metadata not exposed by KMS can be parsed by user-space. This > > includes for instance monitor identification (make/model/serial) and > > supported color-spaces. > > So I take it the only way to get modes is through the connector's list > of modes. That sounds reasonable enough to me, but I think to properly > handle colour (e.g. CEA modes have different behaviour for > limited/full range depending on which VIC they correspond to IIRC) If the mode has a VIC and that VIC is not 1, then it's limited range, otherwise full range. There are fortunately no cases where you would have the same exact timings corresponding to different quantization range depending on the VIC. And the only reason the same timings could correspond to multiple VICs is aspect ratio. Which is already exposed via the mode flags, assuming the appropriate client cap is enabled. So I think the only reason to expose the VIC would be if userspace is non-lazy and wants to manage its colors presicely, but is otherwise lazy and doesn't want to figure out what the VIC of the mode is on its own. I guess one related thing we might want to expose is the "is quantization range selectable?" bits from the EDID (assuming we really want the "don't parse the EDID in userspace" policy [1]). That would be needed for userspace to be able to figure out if it can override the VIC based quantization range in the display. Although with a bunch of crappy displays you will want to override it anyway because they just didn't bother with implementing the spec correctly and instead always expect full range data. [1] which probably would mean a huge boatload if properties or some structure inside a blob (which is pretty much just the EDID with a different layout then). > we'd need to take more bits out of drm_mode_modeinfo::flags, which is > unfortunate since there aren't that many of them left and it's not an > extensible structure. Maybe proper mode handling is going to require > an expanded mode structure, but today is not that day, so: > Acked-by: Daniel Stone <daniels@xxxxxxxxxxxxx> > > Cheers, > Daniel > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
