From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 125E1C43457 for ; Fri, 9 Oct 2020 13:10:38 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9913322248 for ; Fri, 9 Oct 2020 13:10:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9913322248 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B45666ECDB; Fri, 9 Oct 2020 13:10:36 +0000 (UTC) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id D44566ECDB for ; Fri, 9 Oct 2020 13:10:34 +0000 (UTC) IronPort-SDR: qMxWdeNScefpvTSJ7HuLfqmaPInxTd6XrJcAtCnvDgHgJsNN7rS/imtMn0N1IAuX13+2FcXYwX UCl+TvqECBZA== X-IronPort-AV: E=McAfee;i="6000,8403,9768"; a="165542663" X-IronPort-AV: E=Sophos;i="5.77,355,1596524400"; d="scan'208";a="165542663" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2020 06:10:29 -0700 IronPort-SDR: JfpZF4YWdVcfXgOtiP1oN7Lbbdp34dkUUtw1eQR45iGOM2V9FRFZxcMIeEyv6m5hT3PwIHJVI8 c+ZI7zA51t5w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,355,1596524400"; d="scan'208";a="317026229" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga006.jf.intel.com with SMTP; 09 Oct 2020 06:10:26 -0700 Received: by stinkbox (sSMTP sendmail emulation); Fri, 09 Oct 2020 16:10:25 +0300 Date: Fri, 9 Oct 2020 16:10:25 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Daniel Stone Subject: Re: [PATCH] drm: document that user-space should avoid parsing EDIDs Message-ID: <20201009131025.GS6112@intel.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pekka Paalanen , dri-devel , Daniel Vetter Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote: > Hi, > = > On Fri, 9 Oct 2020 at 10:24, Simon Ser 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 > = > Cheers, > Daniel > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- = Ville Syrj=E4l=E4 Intel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel