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 34F17CCA47B for ; Mon, 11 Jul 2022 10:19:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229917AbiGKKTv (ORCPT ); Mon, 11 Jul 2022 06:19:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232934AbiGKKTX (ORCPT ); Mon, 11 Jul 2022 06:19:23 -0400 Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DFB4DC5944; Mon, 11 Jul 2022 02:36:05 -0700 (PDT) Received: by mail-qk1-f174.google.com with SMTP id l26so3392499qkl.10; Mon, 11 Jul 2022 02:36:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DVJUGFx3bR67+/E6+DBeYAU8MgftXdOcu6+8ewnr6LE=; b=Grb1mICe/KhbwLOEfAkKDySeSxSgknGkd+imBlMn5B3iGw309ODADz+Eg//P2ZT7iV 3utw/l1fNrnbwYfqGyFeNqmIVrb1YW4A0RehUd3Jk0GqWEl9vMEUrXuDiDgLjJ8WqQN4 tl7nl721wzrX/YV0tmyyfnAlXAYyhsfSYUxkW/F6nSEyBDTIN1bES3pdoEG5X8McxXhl KVLqcUNLmxjPu7OUOtYFaf0gqJmlWuFXBE4Na+rBei5sFi+jgNZPTmTsd1HCpwnocEC0 IXa8hOazblbkU/dL7jQDX8OcxGEadX1bYWuiWe12nS9l9/etlohe7+q2VT+vj0kpay5u njJQ== X-Gm-Message-State: AJIora/MaWNWJeoWUexTtHx7MFiJuFrAK06DWdFRBoe5IiGQHUGr4Dhd LP7hPE4xQQy1AO1kHtb5xGt391qORApzmA== X-Google-Smtp-Source: AGRyM1vZzBucHiqPQeSQ/wXnca/TSwvQ/zQg9JGqNdFX+0Q2mLUM/6ehODCCxvHYTFcAisSYYK4hAw== X-Received: by 2002:a05:620a:254f:b0:6a6:313:3ccc with SMTP id s15-20020a05620a254f00b006a603133cccmr10787076qko.716.1657532164248; Mon, 11 Jul 2022 02:36:04 -0700 (PDT) Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com. [209.85.128.181]) by smtp.gmail.com with ESMTPSA id v15-20020a05620a0f0f00b006a785ba0c25sm5993061qkl.77.2022.07.11.02.36.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jul 2022 02:36:03 -0700 (PDT) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-31d85f82f0bso7031027b3.7; Mon, 11 Jul 2022 02:36:03 -0700 (PDT) X-Received: by 2002:a81:9209:0:b0:31c:b1b7:b063 with SMTP id j9-20020a819209000000b0031cb1b7b063mr18545635ywg.383.1657532162961; Mon, 11 Jul 2022 02:36:02 -0700 (PDT) MIME-Version: 1.0 References: <68923c8a129b6c2a70b570103679a1cf7876bbc2.1657301107.git.geert@linux-m68k.org> In-Reply-To: From: Geert Uytterhoeven Date: Mon, 11 Jul 2022 11:35:51 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/5] drm/modes: Add support for driver-specific named modes To: Thomas Zimmermann Cc: Maarten Lankhorst , Maxime Ripard , David Airlie , Daniel Vetter , Hans de Goede , DRI Development , Linux Fbdev development list , "Linux/m68k" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org Hi Thomas, On Mon, Jul 11, 2022 at 11:03 AM Thomas Zimmermann wrote: > Am 08.07.22 um 20:21 schrieb Geert Uytterhoeven: > > The mode parsing code recognizes named modes only if they are explicitly > > listed in the internal whitelist, which is currently limited to "NTSC" > > and "PAL". > > > > Provide a mechanism for drivers to override this list to support custom > > mode names. > > > > Ideally, this list should just come from the driver's actual list of > > modes, but connector->probed_modes is not yet populated at the time of > > parsing. > > I've looked for code that uses these names, couldn't find any. How is > this being used in practice? For example, if I say "PAL" on the command > line, is there DRM code that fills in the PAL mode parameters? I guess Maxime knows, as he added the whitelist? Reading the description of commit 3764137906a5acec ("drm/modes: Introduce a whitelist for the named modes"), it looks like this is more about preventing the parser from taking any string as a random mode, than about adding support for "PAL" or "NTSC"? Note that drivers/gpu/drm/i915/display/intel_tv.c defines an array of tv_modes[], including "PAL", so perhaps these end up as named modes? > And another question I have is whether this whitelist belongs into the > driver at all. Standard modes exist independent from drivers or > hardware. Shouldn't there simply be a global list of all possible mode > names? Drivers would filter out the unsupported modes anyway. For standard modes, I agree. And these are usually specified by resolution and refresh rate (e.g. "640x480@60", instead of "480p"). But legacy hardware may have very limited support for programmable pixel clocks (e.g. Amiga is limited to pixel clocks of 7, 14, or 28 MHz), so the standard modes are a bad match, or may not work at all. Hence drivers may need to provide their own modes, but it seems wrong to me to make these non-standard modes global, and possibly pollute the experience for everyone. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds