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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 61653C00144 for ; Fri, 29 Jul 2022 19:58:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239019AbiG2T6K (ORCPT ); Fri, 29 Jul 2022 15:58:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238704AbiG2T55 (ORCPT ); Fri, 29 Jul 2022 15:57:57 -0400 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33D7B87C20 for ; Fri, 29 Jul 2022 12:57:56 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id m20so384908ejx.1 for ; Fri, 29 Jul 2022 12:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=W+QN4O2BhXHS+vUE27PDdCSUcq9hnSAP99uK5Xn1FCM=; b=Zj2jLtqa9dUSEbGnR+hTFlVho37WJlcebbvW7QtxZQ0BO9XFH3vP2obk6NtwMZBu9R lvbWvFWpxmZeSay2R3uGC3Gv6F/586vBXsKjvhZu7UkEmvbwxhHNC+8Oiy55snkgH5t7 txYnsgBEpnqU+xpfPzP7gA3W/jmyDWqpjGygI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=W+QN4O2BhXHS+vUE27PDdCSUcq9hnSAP99uK5Xn1FCM=; b=fDF/N7cDjTG3zKlDNVuaiMPlQfF5Uy3XsYDK4WOwWyYatLwrp3kybkFaA9KsUcJxrl /zJzSMjux+jWdDgvTHBzzL5sJioVqyITovpgNb/c+HvG5CLsl1L9UPy3flsuXjU972t8 lIK2bzGzXZWI7wElM/n5C4yMMGGPl8fKcm+o9yCwpjuTfXrGsZ9ElkTSLWOnvI53wz6X M29rvr+fVQvK6s+SOXHLQcocviSLSjeyY/VO1geGyBodL2J0NBQUBvJwBuxjHK7gs3lF wR0oEQx1NDtRdCvsJLXnjRT664azp/SpG/siLxDkBi2Kd3WEoSro1Te5GfGtRMqqd14h t9uA== X-Gm-Message-State: AJIora8aGQzFZ6jIlfrDdKFMYHaMoW3Q+5JRbu8Rwl8tftBdzaVLNJGj sYQ2nlrL0pRU4NTphdTTHw43Jw7f6neo1oz8LmE= X-Google-Smtp-Source: AGRyM1sQ95HrjlgqqFsLlxrWLJYE0tJ1VdqmG9X17tMlVzP/Q9ZZfDYn6xXGNH+2sVDJNUBRG3XkcA== X-Received: by 2002:a17:906:7e43:b0:72b:52de:b039 with SMTP id z3-20020a1709067e4300b0072b52deb039mr4154117ejr.198.1659124674230; Fri, 29 Jul 2022 12:57:54 -0700 (PDT) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com. [209.85.128.52]) by smtp.gmail.com with ESMTPSA id dk15-20020a0564021d8f00b0043cedad30a5sm2887914edb.21.2022.07.29.12.57.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Jul 2022 12:57:53 -0700 (PDT) Received: by mail-wm1-f52.google.com with SMTP id 8-20020a05600c024800b003a2fe343db1so2943111wmj.1 for ; Fri, 29 Jul 2022 12:57:53 -0700 (PDT) X-Received: by 2002:a05:600c:1e0f:b0:3a3:191c:a3c8 with SMTP id ay15-20020a05600c1e0f00b003a3191ca3c8mr3637779wmb.151.1659124672731; Fri, 29 Jul 2022 12:57:52 -0700 (PDT) MIME-Version: 1.0 References: <20220721152314.RFC.1.Ie333b3e4aff6e4a5b58c4aa805e030e561be8773@changeid> <269f2610-425b-f296-dcfc-89bdc2e1d587@quicinc.com> <5c8ca71c-5f0b-d5f5-9f16-e312dec0d01b@quicinc.com> <20220729075118.ofnpk52tk4usm3n3@penduick> <20220729164136.opucqg64qz4ypmvo@penduick> In-Reply-To: <20220729164136.opucqg64qz4ypmvo@penduick> From: Doug Anderson Date: Fri, 29 Jul 2022 12:57:40 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] drm/edid: Make 144 Hz not preferred on Sharp LQ140M1JW46 To: Maxime Ripard Cc: Abhinav Kumar , Rob Clark , dri-devel , freedreno , Daniel Vetter , David Airlie , Maarten Lankhorst , Thomas Zimmermann , LKML , Sankeerth Billakanti Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Fri, Jul 29, 2022 at 9:41 AM Maxime Ripard wrote: > > On Fri, Jul 29, 2022 at 07:50:20AM -0700, Doug Anderson wrote: > > On Fri, Jul 29, 2022 at 12:51 AM Maxime Ripard wrote: > > > > > > On Thu, Jul 28, 2022 at 02:18:38PM -0700, Doug Anderson wrote: > > > > Hi, > > > > > > > > On Thu, Jul 28, 2022 at 10:34 AM Abhinav Kumar > > > > wrote: > > > > > > > > > > Hi Rob and Doug > > > > > > > > > > On 7/22/2022 10:36 AM, Rob Clark wrote: > > > > > > On Fri, Jul 22, 2022 at 9:48 AM Doug Anderson wrote: > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> On Fri, Jul 22, 2022 at 9:37 AM Abhinav Kumar wrote: > > > > > >>> > > > > > >>> + sankeerth > > > > > >>> > > > > > >>> Hi Doug > > > > > >>> > > > > > >>> On 7/21/2022 3:23 PM, Douglas Anderson wrote: > > > > > >>>> The Sharp LQ140M1JW46 panel is on the Qualcomm sc7280 CRD reference > > > > > >>>> board. This panel supports 144 Hz and 60 Hz. In the EDID, the 144 Hz > > > > > >>>> mode is listed first and thus is marked preferred. The EDID decode I > > > > > >>>> ran says: > > > > > >>>> > > > > > >>>> First detailed timing includes the native pixel format and preferred > > > > > >>>> refresh rate. > > > > > >>>> > > > > > >>>> ... > > > > > >>>> > > > > > >>>> Detailed Timing Descriptors: > > > > > >>>> DTD 1: 1920x1080 143.981 Hz 16:9 166.587 kHz 346.500 MHz > > > > > >>>> Hfront 48 Hsync 32 Hback 80 Hpol N > > > > > >>>> Vfront 3 Vsync 5 Vback 69 Vpol N > > > > > >>>> DTD 2: 1920x1080 59.990 Hz 16:9 69.409 kHz 144.370 MHz > > > > > >>>> Hfront 48 Hsync 32 Hback 80 Hpol N > > > > > >>>> Vfront 3 Vsync 5 Vback 69 Vpol N > > > > > >>>> > > > > > >>>> I'm proposing here that the above is actually a bug and that the 60 Hz > > > > > >>>> mode really should be considered preferred by Linux. > > > > > > > > > > Its a bit tricky to say that this is a bug but I think we can certainly > > > > > add here that for an internal display we would have ideally had the > > > > > lower resolution first to indicate it as default. > > > > > > > > Yeah, it gets into the vagueness of the EDID spec in general. As far > > > > as I can find it's really up to the monitor to decide by what means it > > > > chooses the "preferred" refresh rate if the monitor can support many. > > > > Some displays may decide that the normal rate is "preferred" and some > > > > may decide that the high refresh rate is "preferred". Neither display > > > > is "wrong" per say, but it's nice to have some consistency here and to > > > > make it so that otherwise "dumb" userspace will get something > > > > reasonable by default. I'll change it to say: > > > > > > > > While the EDID spec appears to allow a display to use any criteria for > > > > picking which refresh mode is "preferred" or "optimal", that vagueness > > > > is a bit annoying. From Linux's point of view let's choose the 60 Hz > > > > one as the default. > > > > > > And if we start making that decision, it should be for all panels with a > > > similar constraint, so most likely handled by the core, and the new > > > policy properly documented. > > > > > > Doing that just for a single panel is weird. > > > > Yeah, though having a "general policy" in the core can be problematic. > > > > In general I think panel EDIDs are only trustworthy as far as you can > > throw them. They are notorious for having wrong and incorrect > > information, which is why the EDID quirk list exists to begin with. > > Trying to change how we're going to interpret all EDIDs, even all > > EDIDs for eDP panels, seems like it will break someone somewhere. > > Maybe there are EDIDs out there that were only ever validated at the > > higher refresh rate and they don't work / flicker / cause digitizer > > noise at the lower refresh rate. Heck, we've seen eDP panel vendors > > that can't even get their checksum correct, so I'm not sure I want to > > make a global assertion that all panels validated their "secondary" > > display mode. > > > > In this particular case, we have validated that this particular Sharp > > panel works fine at the lower refresh rate. > > > > I would also note that, as far as I understand it, ODMs actually can > > request different EDIDs from the panel vendors. In the past we have > > been able to get panel vendors to change EDIDs. Thus for most panels > > I'd expect that we would discover this early, change the EDID default, > > and be done with it. The case here is a little unusual in that by the > > time we got involved and started digging into this panel too many were > > created and nobody wants to throw away those old panels. This is why > > I'm treating it as a quirk/bug. Really: we should have updated the > > EDID of the panel but we're unable to in this case. > > You raise some good points, but most of the discussion around that patch > were mostly around performances, power consumption and so on. > > This is very much a policy decision, and if there is some panel where > the EDID reports 60Hz but is broken, then that panel should be the > exception to the policy > > But doing it for a single panel is just odd OK, fair enough. I'll abandon this patch at least as far as mainline is concerned, then. -Doug 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 7390DC00144 for ; Fri, 29 Jul 2022 19:57:59 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8228C10E077; Fri, 29 Jul 2022 19:57:58 +0000 (UTC) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by gabe.freedesktop.org (Postfix) with ESMTPS id A3CAB10E077 for ; Fri, 29 Jul 2022 19:57:57 +0000 (UTC) Received: by mail-ed1-x52c.google.com with SMTP id c12so7054222ede.3 for ; Fri, 29 Jul 2022 12:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=W+QN4O2BhXHS+vUE27PDdCSUcq9hnSAP99uK5Xn1FCM=; b=Zj2jLtqa9dUSEbGnR+hTFlVho37WJlcebbvW7QtxZQ0BO9XFH3vP2obk6NtwMZBu9R lvbWvFWpxmZeSay2R3uGC3Gv6F/586vBXsKjvhZu7UkEmvbwxhHNC+8Oiy55snkgH5t7 txYnsgBEpnqU+xpfPzP7gA3W/jmyDWqpjGygI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=W+QN4O2BhXHS+vUE27PDdCSUcq9hnSAP99uK5Xn1FCM=; b=RbxdMMo8dCx4nzJ9OMyIpswu0gvD0dNygMKGjovgkdeQq1qmA4gmEredHuzFxTfteA zVRg0IeNunVt12fwuG0awZMD3eVW9z9XB+OJWvdNGPCVkH+aldNoE//+qDoNtHzwpf2z wRFSCj/C8d58v1bc8qYqNwAlDghqgrb4YXN/ZzGQq5qL1oWlPbnK2+GMH28E990fcvBG emgucjHF6CqXjlA8+s7uGAXxN+bBZe6L+lZvBaKatz0INzx9CsmV7lQaHHGFVReI7kNJ lL+YItLD3Lk11ZogElXRg3DQmqA0LXszsbR176sa1cGyi0/eEYizPax0v1GDsZ+f1sZT 60FA== X-Gm-Message-State: AJIora/unDLJqg0NbyFHcJciqrk7Z3hzltGfQsNJ0U18ySRC0fgI879c oiVi0gpd4RILkUmHqWorIXMmrIb/lyIwHEId91A= X-Google-Smtp-Source: AGRyM1sI8DvFNWf18bYDe8TXxh78+C3v1hkUfm86ENi2sHru6dIiY19/LYM2Fj2KTT+Z3Z0hQG0Eiw== X-Received: by 2002:a05:6402:5415:b0:43b:a888:fefe with SMTP id ev21-20020a056402541500b0043ba888fefemr4987789edb.302.1659124675867; Fri, 29 Jul 2022 12:57:55 -0700 (PDT) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com. [209.85.128.46]) by smtp.gmail.com with ESMTPSA id c17-20020a170906d19100b0072ffbbc3341sm2029787ejz.204.2022.07.29.12.57.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Jul 2022 12:57:53 -0700 (PDT) Received: by mail-wm1-f46.google.com with SMTP id i10-20020a1c3b0a000000b003a2fa488efdso2390648wma.4 for ; Fri, 29 Jul 2022 12:57:53 -0700 (PDT) X-Received: by 2002:a05:600c:1e0f:b0:3a3:191c:a3c8 with SMTP id ay15-20020a05600c1e0f00b003a3191ca3c8mr3637779wmb.151.1659124672731; Fri, 29 Jul 2022 12:57:52 -0700 (PDT) MIME-Version: 1.0 References: <20220721152314.RFC.1.Ie333b3e4aff6e4a5b58c4aa805e030e561be8773@changeid> <269f2610-425b-f296-dcfc-89bdc2e1d587@quicinc.com> <5c8ca71c-5f0b-d5f5-9f16-e312dec0d01b@quicinc.com> <20220729075118.ofnpk52tk4usm3n3@penduick> <20220729164136.opucqg64qz4ypmvo@penduick> In-Reply-To: <20220729164136.opucqg64qz4ypmvo@penduick> From: Doug Anderson Date: Fri, 29 Jul 2022 12:57:40 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] drm/edid: Make 144 Hz not preferred on Sharp LQ140M1JW46 To: Maxime Ripard Content-Type: text/plain; charset="UTF-8" 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: Sankeerth Billakanti , Thomas Zimmermann , David Airlie , Abhinav Kumar , dri-devel , LKML , freedreno Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On Fri, Jul 29, 2022 at 9:41 AM Maxime Ripard wrote: > > On Fri, Jul 29, 2022 at 07:50:20AM -0700, Doug Anderson wrote: > > On Fri, Jul 29, 2022 at 12:51 AM Maxime Ripard wrote: > > > > > > On Thu, Jul 28, 2022 at 02:18:38PM -0700, Doug Anderson wrote: > > > > Hi, > > > > > > > > On Thu, Jul 28, 2022 at 10:34 AM Abhinav Kumar > > > > wrote: > > > > > > > > > > Hi Rob and Doug > > > > > > > > > > On 7/22/2022 10:36 AM, Rob Clark wrote: > > > > > > On Fri, Jul 22, 2022 at 9:48 AM Doug Anderson wrote: > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> On Fri, Jul 22, 2022 at 9:37 AM Abhinav Kumar wrote: > > > > > >>> > > > > > >>> + sankeerth > > > > > >>> > > > > > >>> Hi Doug > > > > > >>> > > > > > >>> On 7/21/2022 3:23 PM, Douglas Anderson wrote: > > > > > >>>> The Sharp LQ140M1JW46 panel is on the Qualcomm sc7280 CRD reference > > > > > >>>> board. This panel supports 144 Hz and 60 Hz. In the EDID, the 144 Hz > > > > > >>>> mode is listed first and thus is marked preferred. The EDID decode I > > > > > >>>> ran says: > > > > > >>>> > > > > > >>>> First detailed timing includes the native pixel format and preferred > > > > > >>>> refresh rate. > > > > > >>>> > > > > > >>>> ... > > > > > >>>> > > > > > >>>> Detailed Timing Descriptors: > > > > > >>>> DTD 1: 1920x1080 143.981 Hz 16:9 166.587 kHz 346.500 MHz > > > > > >>>> Hfront 48 Hsync 32 Hback 80 Hpol N > > > > > >>>> Vfront 3 Vsync 5 Vback 69 Vpol N > > > > > >>>> DTD 2: 1920x1080 59.990 Hz 16:9 69.409 kHz 144.370 MHz > > > > > >>>> Hfront 48 Hsync 32 Hback 80 Hpol N > > > > > >>>> Vfront 3 Vsync 5 Vback 69 Vpol N > > > > > >>>> > > > > > >>>> I'm proposing here that the above is actually a bug and that the 60 Hz > > > > > >>>> mode really should be considered preferred by Linux. > > > > > > > > > > Its a bit tricky to say that this is a bug but I think we can certainly > > > > > add here that for an internal display we would have ideally had the > > > > > lower resolution first to indicate it as default. > > > > > > > > Yeah, it gets into the vagueness of the EDID spec in general. As far > > > > as I can find it's really up to the monitor to decide by what means it > > > > chooses the "preferred" refresh rate if the monitor can support many. > > > > Some displays may decide that the normal rate is "preferred" and some > > > > may decide that the high refresh rate is "preferred". Neither display > > > > is "wrong" per say, but it's nice to have some consistency here and to > > > > make it so that otherwise "dumb" userspace will get something > > > > reasonable by default. I'll change it to say: > > > > > > > > While the EDID spec appears to allow a display to use any criteria for > > > > picking which refresh mode is "preferred" or "optimal", that vagueness > > > > is a bit annoying. From Linux's point of view let's choose the 60 Hz > > > > one as the default. > > > > > > And if we start making that decision, it should be for all panels with a > > > similar constraint, so most likely handled by the core, and the new > > > policy properly documented. > > > > > > Doing that just for a single panel is weird. > > > > Yeah, though having a "general policy" in the core can be problematic. > > > > In general I think panel EDIDs are only trustworthy as far as you can > > throw them. They are notorious for having wrong and incorrect > > information, which is why the EDID quirk list exists to begin with. > > Trying to change how we're going to interpret all EDIDs, even all > > EDIDs for eDP panels, seems like it will break someone somewhere. > > Maybe there are EDIDs out there that were only ever validated at the > > higher refresh rate and they don't work / flicker / cause digitizer > > noise at the lower refresh rate. Heck, we've seen eDP panel vendors > > that can't even get their checksum correct, so I'm not sure I want to > > make a global assertion that all panels validated their "secondary" > > display mode. > > > > In this particular case, we have validated that this particular Sharp > > panel works fine at the lower refresh rate. > > > > I would also note that, as far as I understand it, ODMs actually can > > request different EDIDs from the panel vendors. In the past we have > > been able to get panel vendors to change EDIDs. Thus for most panels > > I'd expect that we would discover this early, change the EDID default, > > and be done with it. The case here is a little unusual in that by the > > time we got involved and started digging into this panel too many were > > created and nobody wants to throw away those old panels. This is why > > I'm treating it as a quirk/bug. Really: we should have updated the > > EDID of the panel but we're unable to in this case. > > You raise some good points, but most of the discussion around that patch > were mostly around performances, power consumption and so on. > > This is very much a policy decision, and if there is some panel where > the EDID reports 60Hz but is broken, then that panel should be the > exception to the policy > > But doing it for a single panel is just odd OK, fair enough. I'll abandon this patch at least as far as mainline is concerned, then. -Doug