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 F28EBECAAD5 for ; Mon, 12 Sep 2022 13:38:45 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 943AD10E4D5; Mon, 12 Sep 2022 13:38:15 +0000 (UTC) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by gabe.freedesktop.org (Postfix) with ESMTPS id A509410E270; Sun, 11 Sep 2022 04:48:55 +0000 (UTC) Received: by mail-lj1-x231.google.com with SMTP id bn9so6858287ljb.6; Sat, 10 Sep 2022 21:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date; bh=Dzsg7L5ZergN95ne20wSAndouco2GHRCcAKDGT5ut8M=; b=lnJSJ1rpPquPPQQ7+qwNxZU0KY4cxdt9cZsUfORqiByh5zBeV7T/f2AeD4CHLeQWsL pn/QAS+EYTqsiG33r4KCLVivr4UVR2fkrWlUbBFPEs2NN8DOnjcYFzDbEeCxW6j/eSrk UpfjmHvlyE5mteYOdPzKQlvIJjr45s4gE4qzJ9Aguut4RLgTyipHyMQAZLcC1fwFHgoL sO1OkWvcsJfljWKfyz3usM58D7bW30DTD4Lk2j6CKNy4eRRSn6HoiBzaIuU5kxmYdb3A DWw8dBUSROSbZrw422MwwHDwQfmjPxfumFzmZsU7nuvtjQWZB2IHbIG3YAHF+KSJ/l0q Grmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=Dzsg7L5ZergN95ne20wSAndouco2GHRCcAKDGT5ut8M=; b=EGLux+m1EqorDNUPXm5YBz9sSAkStxMOt7ltrZiIycKSWXCLwA0gpNLsJTZr90Q4Nc DXZQa0FIbHTyIoL5U8S1LXjnF2FZUwFMuroSs0IWRQ3qprG+k5psnTQEQezgPyUp6eex +DJ3oNAMqAJxakBsP2fP0yL9luwlkiv4ZvtuEmk5cLwoJoaHiVgXoGKdPEirqXecsPCM P73uSYCY44Qg9wAiO7wCbETZh7r36zNEk44m9qvpFOYLlMVgdw9Q1zRB7IbrghqhNFnX S7Pq9s2n3/c8zToZvIlut0vibO4qIiEhsdPeYM394uaTGdluh1N8yjmzM+CeZGUjU1ob HMnw== X-Gm-Message-State: ACgBeo1e6fjItJzXGOF3GRQ84e4OPxf2B7Y9JWaPMJP3/p1TSk4cbEIU zK39PgcVzfGTgA7+gWH/LUM= X-Google-Smtp-Source: AA6agR4/MY0JB6ClAyvCNHYM+nBqc9ZHtZAEN3tIKgEe93m/3PECgyhOeLoav75g49sW8ehsPZL7+w== X-Received: by 2002:a2e:a7c6:0:b0:26b:e7b4:5136 with SMTP id x6-20020a2ea7c6000000b0026be7b45136mr2628014ljp.425.1662871733790; Sat, 10 Sep 2022 21:48:53 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:e929:c054:a46d:3844? ([2a02:a31a:a240:1700:e929:c054:a46d:3844]) by smtp.googlemail.com with ESMTPSA id m9-20020a056512358900b00497a7dfe6a9sm482145lfr.64.2022.09.10.21.48.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Sep 2022 21:48:53 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <79ab3fef-fdaa-e191-d839-4af88191e672@gmail.com> Date: Sun, 11 Sep 2022 06:48:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Content-Language: pl To: Maxime Ripard References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-10-459522d653a7@cerno.tech> <242d272b-5b79-986c-9aaf-64e62f6b37ff@gmail.com> <20220905133755.gcmmntg3wnecyqjq@houat> <10ce686a-d7c8-9ce4-3979-735ad8eab3b5@gmail.com> <20220907143421.4iopqwhp3yfircsh@houat> <20220909135444.5oi6oh6nqwuke3jl@houat> In-Reply-To: <20220909135444.5oi6oh6nqwuke3jl@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 12 Sep 2022 13:38:08 +0000 Subject: Re: [Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Karol Herbst , David Airlie , nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Phil Elwell , Emma Anholt , Samuel Holland , Jernej Skrabec , Chen-Yu Tsai , Geert Uytterhoeven , Ben Skeggs , linux-sunxi@lists.linux.dev, Thomas Zimmermann , intel-gfx@lists.freedesktop.org, Rodrigo Vivi , Daniel Vetter , linux-arm-kernel@lists.infradead.org, Dom Cobley , Dave Stevenson , linux-kernel@vger.kernel.org, =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , Philipp Zabel Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Hi Maxime, W dniu 9.09.2022 o 15:54, Maxime Ripard pisze: > Hi, > > On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote: > [...] >> I think you're confusing the "post-equalizing pulses" with the "vertical back >> porch" a little bit. The "vertical back porch" includes both the post-equalizing >> pulses and the entire rest of the VBI period, for the standard resolutions at >> least. >> >> The "canonical" modelines (at least for vc4's VEC, see the notes below): >> >> - (vfp==4, vsync==6, vbp==39) for 576i >> - (vfp==7, vsync==6, vbp==32) for 480i >> - (vfp==5, vsync==6, vbp==28) for 486i (full frame NTSC as originally specified) >> >> The numbers for vfp don't exactly match the theoretical values, because: >> >> - VEC actually adds a half-line pulse on top of VFP_ODD, and in the 625-line >>   mode also on top of VFP_EVEN (not always, but let's not dwell too much) >> - Conversely, VEC subtracts the half-line pulse from VSYNC_ODD and VSYNC_EVEN >>   in the 625-line mode >> - SMPTE S170M (see https://www.itu.int/rec/R-REC-BT.1700-0-200502-I/en) defines >>   that active picture for NTSC is on lines 21-263 and 283-525; 263 and 283 are >>   half-lines that are represented as full lines in the "486i" spec > > It's going to be a bit difficult to match that into a drm_display_mode, > since as far I understand it, all the timings are the sum of the timings > of both fields in interlaced. I guess we'll have to be close enough. Well, it's probably the job of the CRTC driver to split the values from drm_display_mode back into separate values for odd and even fields. That's how it's done in the vc4 driver, anyway. > >> - SMPTE 314M, which is the spec for DV, defines the 480 active lines as lines >>   23-262 and 285-524; see Table 20 on page 26 in >>   https://last.hit.bme.hu/download/firtha/video/SMPTE/SMPTE-314M%20DV25-50.pdf; >>   this means that the standard 480i frame shaves off four topmost and two >>   bottommost lines (2 and 1 per field) of the 486i full frame > > I'm still struggling a bit to match that into front porch, sync period > and back porch. I guess the sync period is easy since it's pretty much > fixed. That line 0-23 is the entire blanking area though, right? Yes, lines 0-23 is the entire blanking area. And the "back porch" in this context is everything from the start of the sync pulse to the start of active video. It's not just the equalizing pulses. The equalizing pulses have no equivalent in DRM terms. VC4/VEC inserts those automatically and there's no direct control over them, I'm not sure about other encoders. The equalizing pulses are also not essential for the composite video to work. The spec requires them, but most TVs will tolerate them not being there (and early systems like the British 405-line system didn't have any). >> Note that the half-line pulses in vfp/vsync may be generated in a different way >> on encoders other than vc4's VEC. Maybe we should define some concrete >> semantics for vfp/vsync in analog TV modes, and compensate for that in the >> drivers. But anyway, that's a separate issue. >> >> My point is that, to get a centered image, you can then proportionately add >> values to those "canonical" vfp/vbp values. For example if someone specifies >> 720x480 frame, but 50 Hz PAL, you should set (vfp==52, vsync==6, vbp==87). > > In this case, you add 48 both front porches, right? How is that > proportionate? Yes, I meant adding 48 lines to both porches, and I meant "proportionately" as "split equally". Maybe that was an unfortunate choice of words. >> Those extra vbp lines will be treated as a black bar at the top of the frame, >> and extra vfp lines will be at the bottom of the frame. >> >> However if someone specifies e.g. 720x604, there's nothing more you could >> remove from vfp, so your only option is to reduce vbp compared to the standard >> mode, so you'll end up with (vfp==4, vsync==6, vbp==11). The image will not be >> centered, the topmost lines will get cropped out, but that's the best we can do >> and if someone is requesting such resolution, they most likely want to actually >> access the VBI to e.g. emit teletext. >> >> Your current code always starts at (vfp==5 or 6, vsync=6, vbp==6) and then >> increases both vfp and vbp proportionately. This puts vsync dead center in the >> VBI, which is not how it's supposed to be - and that in turn causes the image >> to be significantly shifted upwards. >> >> I hope this makes more sense to you now. > > I'm really struggling with this, so thanks for explaining this further > (and patiently ;)) > > If I get this right, what you'd like to change is this part of the > calculus (simplified a bit, and using PAL, 576i): > >   vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 >   vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 6 >   vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > >   porches = params->num_lines - vactive - vslen; // 43 >   porches_rem = porches - vfp_min - vbp_min; // 32 > >   vfp = vfp_min + (porches_rem / 2); // 21 >   vbp = porches - vfp; // 22 > > Which is indeed having sync centered. > > I initially changed it to: > >   vfp = vfp_min; // 6 >   vbp = num_lines - vactive - vslen - vfp; // 38 > > Which is close enough for 576i, but at 480i/50Hz would end up with 134, > so still fairly far off. > > I guess your suggestion would be along the line of: > >   vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 >   vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 38 >   vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > >   porches = params->num_lines - vactive - vslen; // 0 >   porches_rem = porches - vfp_min - vbp_min; // 0 > >   vfp = vfp_min + (porches_rem / 2); // 5 >   vbp = porches - vfp; // 38 > > Which is still close enough for 576i, but for 480i would end up with: > >   porches = params->num_lines - vactive - vslen; // 139 >   porches_rem = porches - vfp_min - vbp_min; // 96 > >   vfp = vfp_min + (porches_rem / 2); // 53 >   vbp = porches - vfp; // 86 > > Right? Yes. And if that's supposed to mean 480i in 50 Hz "PAL" mode, that's also "close enough" to the values I suggested above. If you substitute values for true 60 Hz "NTSC" 480i, you should also get values that are "close enough" to the official spec. The only thing I'd conceptually change is that the 38 lines is not really "vbp_min". It's more like "vbp_typ". As I mentioned above, we may want to lower this value if someone wants more active lines than the official 486/576. If they're doing that, they probably want to have vbp in the framebuffer, like VBIT2. Best regards, Mateusz Kwiatkowski From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D1C837F for ; Sun, 11 Sep 2022 04:48:55 +0000 (UTC) Received: by mail-lj1-f176.google.com with SMTP id p5so6827974ljc.13 for ; Sat, 10 Sep 2022 21:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date; bh=Dzsg7L5ZergN95ne20wSAndouco2GHRCcAKDGT5ut8M=; b=lnJSJ1rpPquPPQQ7+qwNxZU0KY4cxdt9cZsUfORqiByh5zBeV7T/f2AeD4CHLeQWsL pn/QAS+EYTqsiG33r4KCLVivr4UVR2fkrWlUbBFPEs2NN8DOnjcYFzDbEeCxW6j/eSrk UpfjmHvlyE5mteYOdPzKQlvIJjr45s4gE4qzJ9Aguut4RLgTyipHyMQAZLcC1fwFHgoL sO1OkWvcsJfljWKfyz3usM58D7bW30DTD4Lk2j6CKNy4eRRSn6HoiBzaIuU5kxmYdb3A DWw8dBUSROSbZrw422MwwHDwQfmjPxfumFzmZsU7nuvtjQWZB2IHbIG3YAHF+KSJ/l0q Grmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=Dzsg7L5ZergN95ne20wSAndouco2GHRCcAKDGT5ut8M=; b=MXfOMr0/d9rqwdBqms3yxhfUtXixNb65qRFtJfl1I89EV88/d90xfsP30WZTpWroqE tKLTUmWD+Wopfy5qrQrbsGSZRTDu0Cql4uBf6B3LLsDNs4wby+F4BEW5K8qKB7kPfPGb 24Y5SqCNbPIlWhsBslDjMArxcRD11gdTpZlBm+8zYnHaQqHzmUFQ8elOpZqX780nrJlf xP0sdS3Kp5WkMPsvQa4lcBlPKwEH0UOodfMjPQYCQMkZvXAETpMsRZYIoYznZFKiY9kN mCh3GKza7ZMU/bTUKmCK8d7H4HVFWVSH5Cngw7GBKd7YO3YR5wVyvQ9UwihojdVKXim1 4OoQ== X-Gm-Message-State: ACgBeo0gaKOZNbDL8ThrJTESW+m/bK2Zg0Xx6cJcsPm4VBGFS410oaxi stvrNY72wwOfDKjSH0DIHiA= X-Google-Smtp-Source: AA6agR4/MY0JB6ClAyvCNHYM+nBqc9ZHtZAEN3tIKgEe93m/3PECgyhOeLoav75g49sW8ehsPZL7+w== X-Received: by 2002:a2e:a7c6:0:b0:26b:e7b4:5136 with SMTP id x6-20020a2ea7c6000000b0026be7b45136mr2628014ljp.425.1662871733790; Sat, 10 Sep 2022 21:48:53 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:e929:c054:a46d:3844? ([2a02:a31a:a240:1700:e929:c054:a46d:3844]) by smtp.googlemail.com with ESMTPSA id m9-20020a056512358900b00497a7dfe6a9sm482145lfr.64.2022.09.10.21.48.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Sep 2022 21:48:53 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <79ab3fef-fdaa-e191-d839-4af88191e672@gmail.com> Date: Sun, 11 Sep 2022 06:48:50 +0200 Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes Content-Language: pl To: Maxime Ripard Cc: Ben Skeggs , David Airlie , Chen-Yu Tsai , Thomas Zimmermann , Jani Nikula , Lyude Paul , Philipp Zabel , Maarten Lankhorst , Rodrigo Vivi , Tvrtko Ursulin , Jernej Skrabec , Samuel Holland , Karol Herbst , =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , Emma Anholt , Daniel Vetter , Joonas Lahtinen , Hans de Goede , linux-arm-kernel@lists.infradead.org, Phil Elwell , intel-gfx@lists.freedesktop.org, Dave Stevenson , dri-devel@lists.freedesktop.org, Dom Cobley , linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org, linux-sunxi@lists.linux.dev, Geert Uytterhoeven References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-10-459522d653a7@cerno.tech> <242d272b-5b79-986c-9aaf-64e62f6b37ff@gmail.com> <20220905133755.gcmmntg3wnecyqjq@houat> <10ce686a-d7c8-9ce4-3979-735ad8eab3b5@gmail.com> <20220907143421.4iopqwhp3yfircsh@houat> <20220909135444.5oi6oh6nqwuke3jl@houat> In-Reply-To: <20220909135444.5oi6oh6nqwuke3jl@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Maxime, W dniu 9.09.2022 o 15:54, Maxime Ripard pisze: > Hi, > > On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote: > [...] >> I think you're confusing the "post-equalizing pulses" with the "vertical back >> porch" a little bit. The "vertical back porch" includes both the post-equalizing >> pulses and the entire rest of the VBI period, for the standard resolutions at >> least. >> >> The "canonical" modelines (at least for vc4's VEC, see the notes below): >> >> - (vfp==4, vsync==6, vbp==39) for 576i >> - (vfp==7, vsync==6, vbp==32) for 480i >> - (vfp==5, vsync==6, vbp==28) for 486i (full frame NTSC as originally specified) >> >> The numbers for vfp don't exactly match the theoretical values, because: >> >> - VEC actually adds a half-line pulse on top of VFP_ODD, and in the 625-line >>   mode also on top of VFP_EVEN (not always, but let's not dwell too much) >> - Conversely, VEC subtracts the half-line pulse from VSYNC_ODD and VSYNC_EVEN >>   in the 625-line mode >> - SMPTE S170M (see https://www.itu.int/rec/R-REC-BT.1700-0-200502-I/en) defines >>   that active picture for NTSC is on lines 21-263 and 283-525; 263 and 283 are >>   half-lines that are represented as full lines in the "486i" spec > > It's going to be a bit difficult to match that into a drm_display_mode, > since as far I understand it, all the timings are the sum of the timings > of both fields in interlaced. I guess we'll have to be close enough. Well, it's probably the job of the CRTC driver to split the values from drm_display_mode back into separate values for odd and even fields. That's how it's done in the vc4 driver, anyway. > >> - SMPTE 314M, which is the spec for DV, defines the 480 active lines as lines >>   23-262 and 285-524; see Table 20 on page 26 in >>   https://last.hit.bme.hu/download/firtha/video/SMPTE/SMPTE-314M%20DV25-50.pdf; >>   this means that the standard 480i frame shaves off four topmost and two >>   bottommost lines (2 and 1 per field) of the 486i full frame > > I'm still struggling a bit to match that into front porch, sync period > and back porch. I guess the sync period is easy since it's pretty much > fixed. That line 0-23 is the entire blanking area though, right? Yes, lines 0-23 is the entire blanking area. And the "back porch" in this context is everything from the start of the sync pulse to the start of active video. It's not just the equalizing pulses. The equalizing pulses have no equivalent in DRM terms. VC4/VEC inserts those automatically and there's no direct control over them, I'm not sure about other encoders. The equalizing pulses are also not essential for the composite video to work. The spec requires them, but most TVs will tolerate them not being there (and early systems like the British 405-line system didn't have any). >> Note that the half-line pulses in vfp/vsync may be generated in a different way >> on encoders other than vc4's VEC. Maybe we should define some concrete >> semantics for vfp/vsync in analog TV modes, and compensate for that in the >> drivers. But anyway, that's a separate issue. >> >> My point is that, to get a centered image, you can then proportionately add >> values to those "canonical" vfp/vbp values. For example if someone specifies >> 720x480 frame, but 50 Hz PAL, you should set (vfp==52, vsync==6, vbp==87). > > In this case, you add 48 both front porches, right? How is that > proportionate? Yes, I meant adding 48 lines to both porches, and I meant "proportionately" as "split equally". Maybe that was an unfortunate choice of words. >> Those extra vbp lines will be treated as a black bar at the top of the frame, >> and extra vfp lines will be at the bottom of the frame. >> >> However if someone specifies e.g. 720x604, there's nothing more you could >> remove from vfp, so your only option is to reduce vbp compared to the standard >> mode, so you'll end up with (vfp==4, vsync==6, vbp==11). The image will not be >> centered, the topmost lines will get cropped out, but that's the best we can do >> and if someone is requesting such resolution, they most likely want to actually >> access the VBI to e.g. emit teletext. >> >> Your current code always starts at (vfp==5 or 6, vsync=6, vbp==6) and then >> increases both vfp and vbp proportionately. This puts vsync dead center in the >> VBI, which is not how it's supposed to be - and that in turn causes the image >> to be significantly shifted upwards. >> >> I hope this makes more sense to you now. > > I'm really struggling with this, so thanks for explaining this further > (and patiently ;)) > > If I get this right, what you'd like to change is this part of the > calculus (simplified a bit, and using PAL, 576i): > >   vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 >   vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 6 >   vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > >   porches = params->num_lines - vactive - vslen; // 43 >   porches_rem = porches - vfp_min - vbp_min; // 32 > >   vfp = vfp_min + (porches_rem / 2); // 21 >   vbp = porches - vfp; // 22 > > Which is indeed having sync centered. > > I initially changed it to: > >   vfp = vfp_min; // 6 >   vbp = num_lines - vactive - vslen - vfp; // 38 > > Which is close enough for 576i, but at 480i/50Hz would end up with 134, > so still fairly far off. > > I guess your suggestion would be along the line of: > >   vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 >   vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 38 >   vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > >   porches = params->num_lines - vactive - vslen; // 0 >   porches_rem = porches - vfp_min - vbp_min; // 0 > >   vfp = vfp_min + (porches_rem / 2); // 5 >   vbp = porches - vfp; // 38 > > Which is still close enough for 576i, but for 480i would end up with: > >   porches = params->num_lines - vactive - vslen; // 139 >   porches_rem = porches - vfp_min - vbp_min; // 96 > >   vfp = vfp_min + (porches_rem / 2); // 53 >   vbp = porches - vfp; // 86 > > Right? Yes. And if that's supposed to mean 480i in 50 Hz "PAL" mode, that's also "close enough" to the values I suggested above. If you substitute values for true 60 Hz "NTSC" 480i, you should also get values that are "close enough" to the official spec. The only thing I'd conceptually change is that the 38 lines is not really "vbp_min". It's more like "vbp_typ". As I mentioned above, we may want to lower this value if someone wants more active lines than the official 486/576. If they're doing that, they probably want to have vbp in the framebuffer, like VBIT2. Best regards, Mateusz Kwiatkowski 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 6354BECAAA1 for ; Sun, 11 Sep 2022 04:48:59 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2BA0C10E270; Sun, 11 Sep 2022 04:48:57 +0000 (UTC) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by gabe.freedesktop.org (Postfix) with ESMTPS id A509410E270; Sun, 11 Sep 2022 04:48:55 +0000 (UTC) Received: by mail-lj1-x231.google.com with SMTP id bn9so6858287ljb.6; Sat, 10 Sep 2022 21:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date; bh=Dzsg7L5ZergN95ne20wSAndouco2GHRCcAKDGT5ut8M=; b=lnJSJ1rpPquPPQQ7+qwNxZU0KY4cxdt9cZsUfORqiByh5zBeV7T/f2AeD4CHLeQWsL pn/QAS+EYTqsiG33r4KCLVivr4UVR2fkrWlUbBFPEs2NN8DOnjcYFzDbEeCxW6j/eSrk UpfjmHvlyE5mteYOdPzKQlvIJjr45s4gE4qzJ9Aguut4RLgTyipHyMQAZLcC1fwFHgoL sO1OkWvcsJfljWKfyz3usM58D7bW30DTD4Lk2j6CKNy4eRRSn6HoiBzaIuU5kxmYdb3A DWw8dBUSROSbZrw422MwwHDwQfmjPxfumFzmZsU7nuvtjQWZB2IHbIG3YAHF+KSJ/l0q Grmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=Dzsg7L5ZergN95ne20wSAndouco2GHRCcAKDGT5ut8M=; b=EGLux+m1EqorDNUPXm5YBz9sSAkStxMOt7ltrZiIycKSWXCLwA0gpNLsJTZr90Q4Nc DXZQa0FIbHTyIoL5U8S1LXjnF2FZUwFMuroSs0IWRQ3qprG+k5psnTQEQezgPyUp6eex +DJ3oNAMqAJxakBsP2fP0yL9luwlkiv4ZvtuEmk5cLwoJoaHiVgXoGKdPEirqXecsPCM P73uSYCY44Qg9wAiO7wCbETZh7r36zNEk44m9qvpFOYLlMVgdw9Q1zRB7IbrghqhNFnX S7Pq9s2n3/c8zToZvIlut0vibO4qIiEhsdPeYM394uaTGdluh1N8yjmzM+CeZGUjU1ob HMnw== X-Gm-Message-State: ACgBeo1e6fjItJzXGOF3GRQ84e4OPxf2B7Y9JWaPMJP3/p1TSk4cbEIU zK39PgcVzfGTgA7+gWH/LUM= X-Google-Smtp-Source: AA6agR4/MY0JB6ClAyvCNHYM+nBqc9ZHtZAEN3tIKgEe93m/3PECgyhOeLoav75g49sW8ehsPZL7+w== X-Received: by 2002:a2e:a7c6:0:b0:26b:e7b4:5136 with SMTP id x6-20020a2ea7c6000000b0026be7b45136mr2628014ljp.425.1662871733790; Sat, 10 Sep 2022 21:48:53 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:e929:c054:a46d:3844? ([2a02:a31a:a240:1700:e929:c054:a46d:3844]) by smtp.googlemail.com with ESMTPSA id m9-20020a056512358900b00497a7dfe6a9sm482145lfr.64.2022.09.10.21.48.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Sep 2022 21:48:53 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <79ab3fef-fdaa-e191-d839-4af88191e672@gmail.com> Date: Sun, 11 Sep 2022 06:48:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Content-Language: pl To: Maxime Ripard References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-10-459522d653a7@cerno.tech> <242d272b-5b79-986c-9aaf-64e62f6b37ff@gmail.com> <20220905133755.gcmmntg3wnecyqjq@houat> <10ce686a-d7c8-9ce4-3979-735ad8eab3b5@gmail.com> <20220907143421.4iopqwhp3yfircsh@houat> <20220909135444.5oi6oh6nqwuke3jl@houat> In-Reply-To: <20220909135444.5oi6oh6nqwuke3jl@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Nouveau] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Airlie , nouveau@lists.freedesktop.org, Joonas Lahtinen , dri-devel@lists.freedesktop.org, Phil Elwell , Emma Anholt , Samuel Holland , Jernej Skrabec , Chen-Yu Tsai , Geert Uytterhoeven , Ben Skeggs , linux-sunxi@lists.linux.dev, intel-gfx@lists.freedesktop.org, Maarten Lankhorst , Jani Nikula , Hans de Goede , Rodrigo Vivi , Daniel Vetter , linux-arm-kernel@lists.infradead.org, Tvrtko Ursulin , Dom Cobley , linux-kernel@vger.kernel.org, =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , Philipp Zabel Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" Hi Maxime, W dniu 9.09.2022 o 15:54, Maxime Ripard pisze: > Hi, > > On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote: > [...] >> I think you're confusing the "post-equalizing pulses" with the "vertical back >> porch" a little bit. The "vertical back porch" includes both the post-equalizing >> pulses and the entire rest of the VBI period, for the standard resolutions at >> least. >> >> The "canonical" modelines (at least for vc4's VEC, see the notes below): >> >> - (vfp==4, vsync==6, vbp==39) for 576i >> - (vfp==7, vsync==6, vbp==32) for 480i >> - (vfp==5, vsync==6, vbp==28) for 486i (full frame NTSC as originally specified) >> >> The numbers for vfp don't exactly match the theoretical values, because: >> >> - VEC actually adds a half-line pulse on top of VFP_ODD, and in the 625-line >>   mode also on top of VFP_EVEN (not always, but let's not dwell too much) >> - Conversely, VEC subtracts the half-line pulse from VSYNC_ODD and VSYNC_EVEN >>   in the 625-line mode >> - SMPTE S170M (see https://www.itu.int/rec/R-REC-BT.1700-0-200502-I/en) defines >>   that active picture for NTSC is on lines 21-263 and 283-525; 263 and 283 are >>   half-lines that are represented as full lines in the "486i" spec > > It's going to be a bit difficult to match that into a drm_display_mode, > since as far I understand it, all the timings are the sum of the timings > of both fields in interlaced. I guess we'll have to be close enough. Well, it's probably the job of the CRTC driver to split the values from drm_display_mode back into separate values for odd and even fields. That's how it's done in the vc4 driver, anyway. > >> - SMPTE 314M, which is the spec for DV, defines the 480 active lines as lines >>   23-262 and 285-524; see Table 20 on page 26 in >>   https://last.hit.bme.hu/download/firtha/video/SMPTE/SMPTE-314M%20DV25-50.pdf; >>   this means that the standard 480i frame shaves off four topmost and two >>   bottommost lines (2 and 1 per field) of the 486i full frame > > I'm still struggling a bit to match that into front porch, sync period > and back porch. I guess the sync period is easy since it's pretty much > fixed. That line 0-23 is the entire blanking area though, right? Yes, lines 0-23 is the entire blanking area. And the "back porch" in this context is everything from the start of the sync pulse to the start of active video. It's not just the equalizing pulses. The equalizing pulses have no equivalent in DRM terms. VC4/VEC inserts those automatically and there's no direct control over them, I'm not sure about other encoders. The equalizing pulses are also not essential for the composite video to work. The spec requires them, but most TVs will tolerate them not being there (and early systems like the British 405-line system didn't have any). >> Note that the half-line pulses in vfp/vsync may be generated in a different way >> on encoders other than vc4's VEC. Maybe we should define some concrete >> semantics for vfp/vsync in analog TV modes, and compensate for that in the >> drivers. But anyway, that's a separate issue. >> >> My point is that, to get a centered image, you can then proportionately add >> values to those "canonical" vfp/vbp values. For example if someone specifies >> 720x480 frame, but 50 Hz PAL, you should set (vfp==52, vsync==6, vbp==87). > > In this case, you add 48 both front porches, right? How is that > proportionate? Yes, I meant adding 48 lines to both porches, and I meant "proportionately" as "split equally". Maybe that was an unfortunate choice of words. >> Those extra vbp lines will be treated as a black bar at the top of the frame, >> and extra vfp lines will be at the bottom of the frame. >> >> However if someone specifies e.g. 720x604, there's nothing more you could >> remove from vfp, so your only option is to reduce vbp compared to the standard >> mode, so you'll end up with (vfp==4, vsync==6, vbp==11). The image will not be >> centered, the topmost lines will get cropped out, but that's the best we can do >> and if someone is requesting such resolution, they most likely want to actually >> access the VBI to e.g. emit teletext. >> >> Your current code always starts at (vfp==5 or 6, vsync=6, vbp==6) and then >> increases both vfp and vbp proportionately. This puts vsync dead center in the >> VBI, which is not how it's supposed to be - and that in turn causes the image >> to be significantly shifted upwards. >> >> I hope this makes more sense to you now. > > I'm really struggling with this, so thanks for explaining this further > (and patiently ;)) > > If I get this right, what you'd like to change is this part of the > calculus (simplified a bit, and using PAL, 576i): > >   vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 >   vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 6 >   vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > >   porches = params->num_lines - vactive - vslen; // 43 >   porches_rem = porches - vfp_min - vbp_min; // 32 > >   vfp = vfp_min + (porches_rem / 2); // 21 >   vbp = porches - vfp; // 22 > > Which is indeed having sync centered. > > I initially changed it to: > >   vfp = vfp_min; // 6 >   vbp = num_lines - vactive - vslen - vfp; // 38 > > Which is close enough for 576i, but at 480i/50Hz would end up with 134, > so still fairly far off. > > I guess your suggestion would be along the line of: > >   vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 >   vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 38 >   vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > >   porches = params->num_lines - vactive - vslen; // 0 >   porches_rem = porches - vfp_min - vbp_min; // 0 > >   vfp = vfp_min + (porches_rem / 2); // 5 >   vbp = porches - vfp; // 38 > > Which is still close enough for 576i, but for 480i would end up with: > >   porches = params->num_lines - vactive - vslen; // 139 >   porches_rem = porches - vfp_min - vbp_min; // 96 > >   vfp = vfp_min + (porches_rem / 2); // 53 >   vbp = porches - vfp; // 86 > > Right? Yes. And if that's supposed to mean 480i in 50 Hz "PAL" mode, that's also "close enough" to the values I suggested above. If you substitute values for true 60 Hz "NTSC" 480i, you should also get values that are "close enough" to the official spec. The only thing I'd conceptually change is that the 38 lines is not really "vbp_min". It's more like "vbp_typ". As I mentioned above, we may want to lower this value if someone wants more active lines than the official 486/576. If they're doing that, they probably want to have vbp in the framebuffer, like VBIT2. Best regards, Mateusz Kwiatkowski 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 C7D11ECAAA1 for ; Sun, 11 Sep 2022 04:50:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:Cc:To:Subject: MIME-Version:Date:Message-ID:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bJMblNmL2cobp9BIS4IUBvEehzYDe7l8NY7fW7y02Aw=; b=vTqY2OfP8sTjeh bmy33DuK0gObhsiaECkGnzeuWdMb50S66gv5csWUaJobAQUaccUA9R2avIq5g+0xGRMwoYQk5QwjY tF3EZcvRUS8h4VRYZn3LDUQSW35X2Hsk2khfAYI3L7pSqvUl9RjDnycp4OWQ3CpfTQq8O6XYrwc9T YPguQHLimgxY5HGWZ6VC+aNHzrc5Kth2ZdrOWykODRV8VKW04p2iSPe3zt1YzYFXNHiuKF8wnw1Pk 8yQi1cpO0pxe9aHLkqH07gdghTybHwcJ0DS4y+cN81IZEsGsKgF7RZbHPDzD/pPLmpeapvClv55r2 fParD1QavnyGz0aHE2sw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oXEtw-00FyFO-BL; Sun, 11 Sep 2022 04:49:00 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oXEtr-00FyEA-RN for linux-arm-kernel@lists.infradead.org; Sun, 11 Sep 2022 04:48:57 +0000 Received: by mail-lj1-x230.google.com with SMTP id l12so6854863ljg.9 for ; Sat, 10 Sep 2022 21:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date; bh=Dzsg7L5ZergN95ne20wSAndouco2GHRCcAKDGT5ut8M=; b=lnJSJ1rpPquPPQQ7+qwNxZU0KY4cxdt9cZsUfORqiByh5zBeV7T/f2AeD4CHLeQWsL pn/QAS+EYTqsiG33r4KCLVivr4UVR2fkrWlUbBFPEs2NN8DOnjcYFzDbEeCxW6j/eSrk UpfjmHvlyE5mteYOdPzKQlvIJjr45s4gE4qzJ9Aguut4RLgTyipHyMQAZLcC1fwFHgoL sO1OkWvcsJfljWKfyz3usM58D7bW30DTD4Lk2j6CKNy4eRRSn6HoiBzaIuU5kxmYdb3A DWw8dBUSROSbZrw422MwwHDwQfmjPxfumFzmZsU7nuvtjQWZB2IHbIG3YAHF+KSJ/l0q Grmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=Dzsg7L5ZergN95ne20wSAndouco2GHRCcAKDGT5ut8M=; b=S4AQ/U4yYIyeTRwMHiWUIfhDjLdATSsK2yET1cXUOBZBd1iZxGPneppi7zOoqF8+62 1pbXvsWaDbxugXKT3IHjdZTufVI1B9ffMyAKbXxf8SXwBp696J4OAg4FrubYd6IEPAHV BRl4H9SuOXI2/bDxI4akkbpOoNvINdbHDI5KQHyIolmiTQskdxAOxMXM6wCCrf56ALob b79aRyWk41CV9rCqjhRffute4FtyRsGCL7FJZvK9EQiNQFA4pbCrb/RnCjfGJK1HNt8/ qk8PmWPEAhO2iKG/tSeqKO5j1u5rCoOZM3/nLmu11Y7AW/Q0zxDPzccaYLpM3OBN6nMY XGng== X-Gm-Message-State: ACgBeo1LhKNhXFei/Dsq57XkQ2262RzlSRWLnfqYRxzwN5/db8LUkLXB IZ5bi90+c3LQFYiuJFbgSgg= X-Google-Smtp-Source: AA6agR4/MY0JB6ClAyvCNHYM+nBqc9ZHtZAEN3tIKgEe93m/3PECgyhOeLoav75g49sW8ehsPZL7+w== X-Received: by 2002:a2e:a7c6:0:b0:26b:e7b4:5136 with SMTP id x6-20020a2ea7c6000000b0026be7b45136mr2628014ljp.425.1662871733790; Sat, 10 Sep 2022 21:48:53 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:e929:c054:a46d:3844? ([2a02:a31a:a240:1700:e929:c054:a46d:3844]) by smtp.googlemail.com with ESMTPSA id m9-20020a056512358900b00497a7dfe6a9sm482145lfr.64.2022.09.10.21.48.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Sep 2022 21:48:53 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <79ab3fef-fdaa-e191-d839-4af88191e672@gmail.com> Date: Sun, 11 Sep 2022 06:48:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes Content-Language: pl To: Maxime Ripard Cc: Ben Skeggs , David Airlie , Chen-Yu Tsai , Thomas Zimmermann , Jani Nikula , Lyude Paul , Philipp Zabel , Maarten Lankhorst , Rodrigo Vivi , Tvrtko Ursulin , Jernej Skrabec , Samuel Holland , Karol Herbst , =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= , Emma Anholt , Daniel Vetter , Joonas Lahtinen , Hans de Goede , linux-arm-kernel@lists.infradead.org, Phil Elwell , intel-gfx@lists.freedesktop.org, Dave Stevenson , dri-devel@lists.freedesktop.org, Dom Cobley , linux-kernel@vger.kernel.org, nouveau@lists.freedesktop.org, linux-sunxi@lists.linux.dev, Geert Uytterhoeven References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-10-459522d653a7@cerno.tech> <242d272b-5b79-986c-9aaf-64e62f6b37ff@gmail.com> <20220905133755.gcmmntg3wnecyqjq@houat> <10ce686a-d7c8-9ce4-3979-735ad8eab3b5@gmail.com> <20220907143421.4iopqwhp3yfircsh@houat> <20220909135444.5oi6oh6nqwuke3jl@houat> In-Reply-To: <20220909135444.5oi6oh6nqwuke3jl@houat> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220910_214855_935294_A176A684 X-CRM114-Status: GOOD ( 42.39 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org SGkgTWF4aW1lLAoKVyBkbml1IDkuMDkuMjAyMiBvIDE1OjU0LCBNYXhpbWUgUmlwYXJkIHBpc3pl Ogo+IEhpLAo+Cj4gT24gV2VkLCBTZXAgMDcsIDIwMjIgYXQgMTE6MzE6MjFQTSArMDIwMCwgTWF0 ZXVzeiBLd2lhdGtvd3NraSB3cm90ZToKPiBbLi4uXQo+PiBJIHRoaW5rIHlvdSdyZSBjb25mdXNp bmcgdGhlICJwb3N0LWVxdWFsaXppbmcgcHVsc2VzIiB3aXRoIHRoZSAidmVydGljYWwgYmFjawo+ PiBwb3JjaCIgYSBsaXR0bGUgYml0LiBUaGUgInZlcnRpY2FsIGJhY2sgcG9yY2giIGluY2x1ZGVz IGJvdGggdGhlIHBvc3QtZXF1YWxpemluZwo+PiBwdWxzZXMgYW5kIHRoZSBlbnRpcmUgcmVzdCBv ZiB0aGUgVkJJIHBlcmlvZCwgZm9yIHRoZSBzdGFuZGFyZCByZXNvbHV0aW9ucyBhdAo+PiBsZWFz dC4KPj4KPj4gVGhlICJjYW5vbmljYWwiIG1vZGVsaW5lcyAoYXQgbGVhc3QgZm9yIHZjNCdzIFZF Qywgc2VlIHRoZSBub3RlcyBiZWxvdyk6Cj4+Cj4+IC0gKHZmcD09NCwgdnN5bmM9PTYsIHZicD09 MzkpIGZvciA1NzZpCj4+IC0gKHZmcD09NywgdnN5bmM9PTYsIHZicD09MzIpIGZvciA0ODBpCj4+ IC0gKHZmcD09NSwgdnN5bmM9PTYsIHZicD09MjgpIGZvciA0ODZpIChmdWxsIGZyYW1lIE5UU0Mg YXMgb3JpZ2luYWxseSBzcGVjaWZpZWQpCj4+Cj4+IFRoZSBudW1iZXJzIGZvciB2ZnAgZG9uJ3Qg ZXhhY3RseSBtYXRjaCB0aGUgdGhlb3JldGljYWwgdmFsdWVzLCBiZWNhdXNlOgo+Pgo+PiAtIFZF QyBhY3R1YWxseSBhZGRzIGEgaGFsZi1saW5lIHB1bHNlIG9uIHRvcCBvZiBWRlBfT0RELCBhbmQg aW4gdGhlIDYyNS1saW5lCj4+wqDCoCBtb2RlIGFsc28gb24gdG9wIG9mIFZGUF9FVkVOIChub3Qg YWx3YXlzLCBidXQgbGV0J3Mgbm90IGR3ZWxsIHRvbyBtdWNoKQo+PiAtIENvbnZlcnNlbHksIFZF QyBzdWJ0cmFjdHMgdGhlIGhhbGYtbGluZSBwdWxzZSBmcm9tIFZTWU5DX09ERCBhbmQgVlNZTkNf RVZFTgo+PsKgwqAgaW4gdGhlIDYyNS1saW5lIG1vZGUKPj4gLSBTTVBURSBTMTcwTSAoc2VlIGh0 dHBzOi8vd3d3Lml0dS5pbnQvcmVjL1ItUkVDLUJULjE3MDAtMC0yMDA1MDItSS9lbikgZGVmaW5l cwo+PsKgwqAgdGhhdCBhY3RpdmUgcGljdHVyZSBmb3IgTlRTQyBpcyBvbiBsaW5lcyAyMS0yNjMg YW5kIDI4My01MjU7IDI2MyBhbmQgMjgzIGFyZQo+PsKgwqAgaGFsZi1saW5lcyB0aGF0IGFyZSBy ZXByZXNlbnRlZCBhcyBmdWxsIGxpbmVzIGluIHRoZSAiNDg2aSIgc3BlYwo+Cj4gSXQncyBnb2lu ZyB0byBiZSBhIGJpdCBkaWZmaWN1bHQgdG8gbWF0Y2ggdGhhdCBpbnRvIGEgZHJtX2Rpc3BsYXlf bW9kZSwKPiBzaW5jZSBhcyBmYXIgSSB1bmRlcnN0YW5kIGl0LCBhbGwgdGhlIHRpbWluZ3MgYXJl IHRoZSBzdW0gb2YgdGhlIHRpbWluZ3MKPiBvZiBib3RoIGZpZWxkcyBpbiBpbnRlcmxhY2VkLiBJ IGd1ZXNzIHdlJ2xsIGhhdmUgdG8gYmUgY2xvc2UgZW5vdWdoLgoKV2VsbCwgaXQncyBwcm9iYWJs eSB0aGUgam9iIG9mIHRoZSBDUlRDIGRyaXZlciB0byBzcGxpdCB0aGUgdmFsdWVzIGZyb20KZHJt X2Rpc3BsYXlfbW9kZSBiYWNrIGludG8gc2VwYXJhdGUgdmFsdWVzIGZvciBvZGQgYW5kIGV2ZW4g ZmllbGRzLiBUaGF0J3MgaG93Cml0J3MgZG9uZSBpbiB0aGUgdmM0IGRyaXZlciwgYW55d2F5LgoK Pgo+PiAtIFNNUFRFIDMxNE0sIHdoaWNoIGlzIHRoZSBzcGVjIGZvciBEViwgZGVmaW5lcyB0aGUg NDgwIGFjdGl2ZSBsaW5lcyBhcyBsaW5lcwo+PsKgwqAgMjMtMjYyIGFuZCAyODUtNTI0OyBzZWUg VGFibGUgMjAgb24gcGFnZSAyNiBpbgo+PsKgwqAgaHR0cHM6Ly9sYXN0LmhpdC5ibWUuaHUvZG93 bmxvYWQvZmlydGhhL3ZpZGVvL1NNUFRFL1NNUFRFLTMxNE0lMjBEVjI1LTUwLnBkZjsKPj7CoMKg IHRoaXMgbWVhbnMgdGhhdCB0aGUgc3RhbmRhcmQgNDgwaSBmcmFtZSBzaGF2ZXMgb2ZmIGZvdXIg dG9wbW9zdCBhbmQgdHdvCj4+wqDCoCBib3R0b21tb3N0IGxpbmVzICgyIGFuZCAxIHBlciBmaWVs ZCkgb2YgdGhlIDQ4NmkgZnVsbCBmcmFtZQo+Cj4gSSdtIHN0aWxsIHN0cnVnZ2xpbmcgYSBiaXQg dG8gbWF0Y2ggdGhhdCBpbnRvIGZyb250IHBvcmNoLCBzeW5jIHBlcmlvZAo+IGFuZCBiYWNrIHBv cmNoLiBJIGd1ZXNzIHRoZSBzeW5jIHBlcmlvZCBpcyBlYXN5IHNpbmNlIGl0J3MgcHJldHR5IG11 Y2gKPiBmaXhlZC4gVGhhdCBsaW5lIDAtMjMgaXMgdGhlIGVudGlyZSBibGFua2luZyBhcmVhIHRo b3VnaCwgcmlnaHQ/CgpZZXMsIGxpbmVzIDAtMjMgaXMgdGhlIGVudGlyZSBibGFua2luZyBhcmVh LiBBbmQgdGhlICJiYWNrIHBvcmNoIiBpbiB0aGlzCmNvbnRleHQgaXMgZXZlcnl0aGluZyBmcm9t IHRoZSBzdGFydCBvZiB0aGUgc3luYyBwdWxzZSB0byB0aGUgc3RhcnQgb2YgYWN0aXZlCnZpZGVv LiBJdCdzIG5vdCBqdXN0IHRoZSBlcXVhbGl6aW5nIHB1bHNlcy4KClRoZSBlcXVhbGl6aW5nIHB1 bHNlcyBoYXZlIG5vIGVxdWl2YWxlbnQgaW4gRFJNIHRlcm1zLiBWQzQvVkVDIGluc2VydHMgdGhv c2UKYXV0b21hdGljYWxseSBhbmQgdGhlcmUncyBubyBkaXJlY3QgY29udHJvbCBvdmVyIHRoZW0s IEknbSBub3Qgc3VyZSBhYm91dCBvdGhlcgplbmNvZGVycy4KClRoZSBlcXVhbGl6aW5nIHB1bHNl cyBhcmUgYWxzbyBub3QgZXNzZW50aWFsIGZvciB0aGUgY29tcG9zaXRlIHZpZGVvIHRvIHdvcmsu ClRoZSBzcGVjIHJlcXVpcmVzIHRoZW0sIGJ1dCBtb3N0IFRWcyB3aWxsIHRvbGVyYXRlIHRoZW0g bm90IGJlaW5nIHRoZXJlIChhbmQKZWFybHkgc3lzdGVtcyBsaWtlIHRoZSBCcml0aXNoIDQwNS1s aW5lIHN5c3RlbSBkaWRuJ3QgaGF2ZSBhbnkpLgoKPj4gTm90ZSB0aGF0IHRoZSBoYWxmLWxpbmUg cHVsc2VzIGluIHZmcC92c3luYyBtYXkgYmUgZ2VuZXJhdGVkIGluIGEgZGlmZmVyZW50IHdheQo+ PiBvbiBlbmNvZGVycyBvdGhlciB0aGFuIHZjNCdzIFZFQy4gTWF5YmUgd2Ugc2hvdWxkIGRlZmlu ZSBzb21lIGNvbmNyZXRlCj4+IHNlbWFudGljcyBmb3IgdmZwL3ZzeW5jIGluIGFuYWxvZyBUViBt b2RlcywgYW5kIGNvbXBlbnNhdGUgZm9yIHRoYXQgaW4gdGhlCj4+IGRyaXZlcnMuIEJ1dCBhbnl3 YXksIHRoYXQncyBhIHNlcGFyYXRlIGlzc3VlLgo+Pgo+PiBNeSBwb2ludCBpcyB0aGF0LCB0byBn ZXQgYSBjZW50ZXJlZCBpbWFnZSwgeW91IGNhbiB0aGVuIHByb3BvcnRpb25hdGVseSBhZGQKPj4g dmFsdWVzIHRvIHRob3NlICJjYW5vbmljYWwiIHZmcC92YnAgdmFsdWVzLiBGb3IgZXhhbXBsZSBp ZiBzb21lb25lIHNwZWNpZmllcwo+PiA3MjB4NDgwIGZyYW1lLCBidXQgNTAgSHogUEFMLCB5b3Ug c2hvdWxkIHNldCAodmZwPT01MiwgdnN5bmM9PTYsIHZicD09ODcpLgo+Cj4gSW4gdGhpcyBjYXNl LCB5b3UgYWRkIDQ4IGJvdGggZnJvbnQgcG9yY2hlcywgcmlnaHQ/IEhvdyBpcyB0aGF0Cj4gcHJv cG9ydGlvbmF0ZT8KClllcywgSSBtZWFudCBhZGRpbmcgNDggbGluZXMgdG8gYm90aCBwb3JjaGVz LCBhbmQgSSBtZWFudCAicHJvcG9ydGlvbmF0ZWx5IiBhcwoic3BsaXQgZXF1YWxseSIuIE1heWJl IHRoYXQgd2FzIGFuIHVuZm9ydHVuYXRlIGNob2ljZSBvZiB3b3Jkcy4KCj4+IFRob3NlIGV4dHJh IHZicCBsaW5lcyB3aWxsIGJlIHRyZWF0ZWQgYXMgYSBibGFjayBiYXIgYXQgdGhlIHRvcCBvZiB0 aGUgZnJhbWUsCj4+IGFuZCBleHRyYSB2ZnAgbGluZXMgd2lsbCBiZSBhdCB0aGUgYm90dG9tIG9m IHRoZSBmcmFtZS4KPj4KPj4gSG93ZXZlciBpZiBzb21lb25lIHNwZWNpZmllcyBlLmcuIDcyMHg2 MDQsIHRoZXJlJ3Mgbm90aGluZyBtb3JlIHlvdSBjb3VsZAo+PiByZW1vdmUgZnJvbSB2ZnAsIHNv IHlvdXIgb25seSBvcHRpb24gaXMgdG8gcmVkdWNlIHZicCBjb21wYXJlZCB0byB0aGUgc3RhbmRh cmQKPj4gbW9kZSwgc28geW91J2xsIGVuZCB1cCB3aXRoICh2ZnA9PTQsIHZzeW5jPT02LCB2YnA9 PTExKS4gVGhlIGltYWdlIHdpbGwgbm90IGJlCj4+IGNlbnRlcmVkLCB0aGUgdG9wbW9zdCBsaW5l cyB3aWxsIGdldCBjcm9wcGVkIG91dCwgYnV0IHRoYXQncyB0aGUgYmVzdCB3ZSBjYW4gZG8KPj4g YW5kIGlmIHNvbWVvbmUgaXMgcmVxdWVzdGluZyBzdWNoIHJlc29sdXRpb24sIHRoZXkgbW9zdCBs aWtlbHkgd2FudCB0byBhY3R1YWxseQo+PiBhY2Nlc3MgdGhlIFZCSSB0byBlLmcuIGVtaXQgdGVs ZXRleHQuCj4+Cj4+IFlvdXIgY3VycmVudCBjb2RlIGFsd2F5cyBzdGFydHMgYXQgKHZmcD09NSBv ciA2LCB2c3luYz02LCB2YnA9PTYpIGFuZCB0aGVuCj4+IGluY3JlYXNlcyBib3RoIHZmcCBhbmQg dmJwIHByb3BvcnRpb25hdGVseS4gVGhpcyBwdXRzIHZzeW5jIGRlYWQgY2VudGVyIGluIHRoZQo+ PiBWQkksIHdoaWNoIGlzIG5vdCBob3cgaXQncyBzdXBwb3NlZCB0byBiZSAtIGFuZCB0aGF0IGlu IHR1cm4gY2F1c2VzIHRoZSBpbWFnZQo+PiB0byBiZSBzaWduaWZpY2FudGx5IHNoaWZ0ZWQgdXB3 YXJkcy4KPj4KPj4gSSBob3BlIHRoaXMgbWFrZXMgbW9yZSBzZW5zZSB0byB5b3Ugbm93Lgo+Cj4g SSdtIHJlYWxseSBzdHJ1Z2dsaW5nIHdpdGggdGhpcywgc28gdGhhbmtzIGZvciBleHBsYWluaW5n IHRoaXMgZnVydGhlcgo+IChhbmQgcGF0aWVudGx5IDspKQo+Cj4gSWYgSSBnZXQgdGhpcyByaWdo dCwgd2hhdCB5b3UnZCBsaWtlIHRvIGNoYW5nZSBpcyB0aGlzIHBhcnQgb2YgdGhlCj4gY2FsY3Vs dXMgKHNpbXBsaWZpZWQgYSBiaXQsIGFuZCB1c2luZyBQQUwsIDU3NmkpOgo+Cj7CoMKgIHZmcF9t aW4gPSBwYXJhbXMtPnZmcF9saW5lcy5ldmVuICsgcGFyYW1zLT52ZnBfbGluZXMub2RkOyAvLyA1 Cj7CoMKgIHZicF9taW4gPSBwYXJhbXMtPnZicF9saW5lcy5ldmVuICsgcGFyYW1zLT52YnBfbGlu ZXMub2RkOyAvLyA2Cj7CoMKgIHZzbGVuID0gcGFyYW1zLT52c2xlbl9saW5lcy5ldmVuICsgcGFy YW1zLT52c2xlbl9saW5lcy5vZGQ7IC8vIDYKPgo+wqDCoCBwb3JjaGVzID0gcGFyYW1zLT5udW1f bGluZXMgLSB2YWN0aXZlIC0gdnNsZW47IC8vIDQzCj7CoMKgIHBvcmNoZXNfcmVtID0gcG9yY2hl cyAtIHZmcF9taW4gLSB2YnBfbWluOyAvLyAzMgo+Cj7CoMKgIHZmcCA9IHZmcF9taW4gKyAocG9y Y2hlc19yZW0gLyAyKTsgLy8gMjEKPsKgwqAgdmJwID0gcG9yY2hlcyAtIHZmcDsgLy8gMjIKPgo+ IFdoaWNoIGlzIGluZGVlZCBoYXZpbmcgc3luYyBjZW50ZXJlZC4KPgo+IEkgaW5pdGlhbGx5IGNo YW5nZWQgaXQgdG86Cj4KPsKgwqAgdmZwID0gdmZwX21pbjsgLy8gNgo+wqDCoCB2YnAgPSBudW1f bGluZXMgLSB2YWN0aXZlIC0gdnNsZW4gLSB2ZnA7IC8vIDM4Cj4KPiBXaGljaCBpcyBjbG9zZSBl bm91Z2ggZm9yIDU3NmksIGJ1dCBhdCA0ODBpLzUwSHogd291bGQgZW5kIHVwIHdpdGggMTM0LAo+ IHNvIHN0aWxsIGZhaXJseSBmYXIgb2ZmLgo+Cj4gSSBndWVzcyB5b3VyIHN1Z2dlc3Rpb24gd291 bGQgYmUgYWxvbmcgdGhlIGxpbmUgb2Y6Cj4KPsKgwqAgdmZwX21pbiA9IHBhcmFtcy0+dmZwX2xp bmVzLmV2ZW4gKyBwYXJhbXMtPnZmcF9saW5lcy5vZGQ7IC8vIDUKPsKgwqAgdmJwX21pbiA9IHBh cmFtcy0+dmJwX2xpbmVzLmV2ZW4gKyBwYXJhbXMtPnZicF9saW5lcy5vZGQ7IC8vIDM4Cj7CoMKg IHZzbGVuID0gcGFyYW1zLT52c2xlbl9saW5lcy5ldmVuICsgcGFyYW1zLT52c2xlbl9saW5lcy5v ZGQ7IC8vIDYKPgo+wqDCoCBwb3JjaGVzID0gcGFyYW1zLT5udW1fbGluZXMgLSB2YWN0aXZlIC0g dnNsZW47IC8vIDAKPsKgwqAgcG9yY2hlc19yZW0gPSBwb3JjaGVzIC0gdmZwX21pbiAtIHZicF9t aW47IC8vIDAKPgo+wqDCoCB2ZnAgPSB2ZnBfbWluICsgKHBvcmNoZXNfcmVtIC8gMik7IC8vIDUK PsKgwqAgdmJwID0gcG9yY2hlcyAtIHZmcDsgLy8gMzgKPgo+IFdoaWNoIGlzIHN0aWxsIGNsb3Nl IGVub3VnaCBmb3IgNTc2aSwgYnV0IGZvciA0ODBpIHdvdWxkIGVuZCB1cCB3aXRoOgo+Cj7CoMKg IHBvcmNoZXMgPSBwYXJhbXMtPm51bV9saW5lcyAtIHZhY3RpdmUgLSB2c2xlbjsgLy8gMTM5Cj7C oMKgIHBvcmNoZXNfcmVtID0gcG9yY2hlcyAtIHZmcF9taW4gLSB2YnBfbWluOyAvLyA5Ngo+Cj7C oMKgIHZmcCA9IHZmcF9taW4gKyAocG9yY2hlc19yZW0gLyAyKTsgLy8gNTMKPsKgwqAgdmJwID0g cG9yY2hlcyAtIHZmcDsgLy8gODYKPgo+IFJpZ2h0PwoKWWVzLiBBbmQgaWYgdGhhdCdzIHN1cHBv c2VkIHRvIG1lYW4gNDgwaSBpbiA1MCBIeiAiUEFMIiBtb2RlLCB0aGF0J3MgYWxzbwoiY2xvc2Ug ZW5vdWdoIiB0byB0aGUgdmFsdWVzIEkgc3VnZ2VzdGVkIGFib3ZlLgoKSWYgeW91IHN1YnN0aXR1 dGUgdmFsdWVzIGZvciB0cnVlIDYwIEh6ICJOVFNDIiA0ODBpLCB5b3Ugc2hvdWxkIGFsc28gZ2V0 IHZhbHVlcwp0aGF0IGFyZSAiY2xvc2UgZW5vdWdoIiB0byB0aGUgb2ZmaWNpYWwgc3BlYy4KClRo ZSBvbmx5IHRoaW5nIEknZCBjb25jZXB0dWFsbHkgY2hhbmdlIGlzIHRoYXQgdGhlIDM4IGxpbmVz IGlzIG5vdCByZWFsbHkKInZicF9taW4iLiBJdCdzIG1vcmUgbGlrZSAidmJwX3R5cCIuIEFzIEkg bWVudGlvbmVkIGFib3ZlLCB3ZSBtYXkgd2FudCB0byBsb3dlcgp0aGlzIHZhbHVlIGlmIHNvbWVv bmUgd2FudHMgbW9yZSBhY3RpdmUgbGluZXMgdGhhbiB0aGUgb2ZmaWNpYWwgNDg2LzU3Ni4KSWYg dGhleSdyZSBkb2luZyB0aGF0LCB0aGV5IHByb2JhYmx5IHdhbnQgdG8gaGF2ZSB2YnAgaW4gdGhl IGZyYW1lYnVmZmVyLApsaWtlIFZCSVQyLgoKQmVzdCByZWdhcmRzLApNYXRldXN6IEt3aWF0a293 c2tpCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51 eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVh ZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1h cm0ta2VybmVsCg== 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 66724ECAAA1 for ; Sun, 11 Sep 2022 04:49:08 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 42A2B10E3B3; Sun, 11 Sep 2022 04:48:59 +0000 (UTC) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by gabe.freedesktop.org (Postfix) with ESMTPS id A509410E270; Sun, 11 Sep 2022 04:48:55 +0000 (UTC) Received: by mail-lj1-x231.google.com with SMTP id bn9so6858287ljb.6; Sat, 10 Sep 2022 21:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date; bh=Dzsg7L5ZergN95ne20wSAndouco2GHRCcAKDGT5ut8M=; b=lnJSJ1rpPquPPQQ7+qwNxZU0KY4cxdt9cZsUfORqiByh5zBeV7T/f2AeD4CHLeQWsL pn/QAS+EYTqsiG33r4KCLVivr4UVR2fkrWlUbBFPEs2NN8DOnjcYFzDbEeCxW6j/eSrk UpfjmHvlyE5mteYOdPzKQlvIJjr45s4gE4qzJ9Aguut4RLgTyipHyMQAZLcC1fwFHgoL sO1OkWvcsJfljWKfyz3usM58D7bW30DTD4Lk2j6CKNy4eRRSn6HoiBzaIuU5kxmYdb3A DWw8dBUSROSbZrw422MwwHDwQfmjPxfumFzmZsU7nuvtjQWZB2IHbIG3YAHF+KSJ/l0q Grmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=Dzsg7L5ZergN95ne20wSAndouco2GHRCcAKDGT5ut8M=; b=EGLux+m1EqorDNUPXm5YBz9sSAkStxMOt7ltrZiIycKSWXCLwA0gpNLsJTZr90Q4Nc DXZQa0FIbHTyIoL5U8S1LXjnF2FZUwFMuroSs0IWRQ3qprG+k5psnTQEQezgPyUp6eex +DJ3oNAMqAJxakBsP2fP0yL9luwlkiv4ZvtuEmk5cLwoJoaHiVgXoGKdPEirqXecsPCM P73uSYCY44Qg9wAiO7wCbETZh7r36zNEk44m9qvpFOYLlMVgdw9Q1zRB7IbrghqhNFnX S7Pq9s2n3/c8zToZvIlut0vibO4qIiEhsdPeYM394uaTGdluh1N8yjmzM+CeZGUjU1ob HMnw== X-Gm-Message-State: ACgBeo1e6fjItJzXGOF3GRQ84e4OPxf2B7Y9JWaPMJP3/p1TSk4cbEIU zK39PgcVzfGTgA7+gWH/LUM= X-Google-Smtp-Source: AA6agR4/MY0JB6ClAyvCNHYM+nBqc9ZHtZAEN3tIKgEe93m/3PECgyhOeLoav75g49sW8ehsPZL7+w== X-Received: by 2002:a2e:a7c6:0:b0:26b:e7b4:5136 with SMTP id x6-20020a2ea7c6000000b0026be7b45136mr2628014ljp.425.1662871733790; Sat, 10 Sep 2022 21:48:53 -0700 (PDT) Received: from ?IPV6:2a02:a31a:a240:1700:e929:c054:a46d:3844? ([2a02:a31a:a240:1700:e929:c054:a46d:3844]) by smtp.googlemail.com with ESMTPSA id m9-20020a056512358900b00497a7dfe6a9sm482145lfr.64.2022.09.10.21.48.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Sep 2022 21:48:53 -0700 (PDT) From: Mateusz Kwiatkowski X-Google-Original-From: Mateusz Kwiatkowski Message-ID: <79ab3fef-fdaa-e191-d839-4af88191e672@gmail.com> Date: Sun, 11 Sep 2022 06:48:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes Content-Language: pl To: Maxime Ripard References: <20220728-rpi-analog-tv-properties-v2-0-459522d653a7@cerno.tech> <20220728-rpi-analog-tv-properties-v2-10-459522d653a7@cerno.tech> <242d272b-5b79-986c-9aaf-64e62f6b37ff@gmail.com> <20220905133755.gcmmntg3wnecyqjq@houat> <10ce686a-d7c8-9ce4-3979-735ad8eab3b5@gmail.com> <20220907143421.4iopqwhp3yfircsh@houat> <20220909135444.5oi6oh6nqwuke3jl@houat> In-Reply-To: <20220909135444.5oi6oh6nqwuke3jl@houat> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Karol Herbst , David Airlie , nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Phil Elwell , Emma Anholt , Samuel Holland , Jernej Skrabec , Chen-Yu Tsai , Geert Uytterhoeven , Ben Skeggs , linux-sunxi@lists.linux.dev, Thomas Zimmermann , intel-gfx@lists.freedesktop.org, Hans de Goede , Rodrigo Vivi , linux-arm-kernel@lists.infradead.org, Tvrtko Ursulin , Dom Cobley , Dave Stevenson , linux-kernel@vger.kernel.org, =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Maxime, W dniu 9.09.2022 o 15:54, Maxime Ripard pisze: > Hi, > > On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote: > [...] >> I think you're confusing the "post-equalizing pulses" with the "vertical back >> porch" a little bit. The "vertical back porch" includes both the post-equalizing >> pulses and the entire rest of the VBI period, for the standard resolutions at >> least. >> >> The "canonical" modelines (at least for vc4's VEC, see the notes below): >> >> - (vfp==4, vsync==6, vbp==39) for 576i >> - (vfp==7, vsync==6, vbp==32) for 480i >> - (vfp==5, vsync==6, vbp==28) for 486i (full frame NTSC as originally specified) >> >> The numbers for vfp don't exactly match the theoretical values, because: >> >> - VEC actually adds a half-line pulse on top of VFP_ODD, and in the 625-line >>   mode also on top of VFP_EVEN (not always, but let's not dwell too much) >> - Conversely, VEC subtracts the half-line pulse from VSYNC_ODD and VSYNC_EVEN >>   in the 625-line mode >> - SMPTE S170M (see https://www.itu.int/rec/R-REC-BT.1700-0-200502-I/en) defines >>   that active picture for NTSC is on lines 21-263 and 283-525; 263 and 283 are >>   half-lines that are represented as full lines in the "486i" spec > > It's going to be a bit difficult to match that into a drm_display_mode, > since as far I understand it, all the timings are the sum of the timings > of both fields in interlaced. I guess we'll have to be close enough. Well, it's probably the job of the CRTC driver to split the values from drm_display_mode back into separate values for odd and even fields. That's how it's done in the vc4 driver, anyway. > >> - SMPTE 314M, which is the spec for DV, defines the 480 active lines as lines >>   23-262 and 285-524; see Table 20 on page 26 in >>   https://last.hit.bme.hu/download/firtha/video/SMPTE/SMPTE-314M%20DV25-50.pdf; >>   this means that the standard 480i frame shaves off four topmost and two >>   bottommost lines (2 and 1 per field) of the 486i full frame > > I'm still struggling a bit to match that into front porch, sync period > and back porch. I guess the sync period is easy since it's pretty much > fixed. That line 0-23 is the entire blanking area though, right? Yes, lines 0-23 is the entire blanking area. And the "back porch" in this context is everything from the start of the sync pulse to the start of active video. It's not just the equalizing pulses. The equalizing pulses have no equivalent in DRM terms. VC4/VEC inserts those automatically and there's no direct control over them, I'm not sure about other encoders. The equalizing pulses are also not essential for the composite video to work. The spec requires them, but most TVs will tolerate them not being there (and early systems like the British 405-line system didn't have any). >> Note that the half-line pulses in vfp/vsync may be generated in a different way >> on encoders other than vc4's VEC. Maybe we should define some concrete >> semantics for vfp/vsync in analog TV modes, and compensate for that in the >> drivers. But anyway, that's a separate issue. >> >> My point is that, to get a centered image, you can then proportionately add >> values to those "canonical" vfp/vbp values. For example if someone specifies >> 720x480 frame, but 50 Hz PAL, you should set (vfp==52, vsync==6, vbp==87). > > In this case, you add 48 both front porches, right? How is that > proportionate? Yes, I meant adding 48 lines to both porches, and I meant "proportionately" as "split equally". Maybe that was an unfortunate choice of words. >> Those extra vbp lines will be treated as a black bar at the top of the frame, >> and extra vfp lines will be at the bottom of the frame. >> >> However if someone specifies e.g. 720x604, there's nothing more you could >> remove from vfp, so your only option is to reduce vbp compared to the standard >> mode, so you'll end up with (vfp==4, vsync==6, vbp==11). The image will not be >> centered, the topmost lines will get cropped out, but that's the best we can do >> and if someone is requesting such resolution, they most likely want to actually >> access the VBI to e.g. emit teletext. >> >> Your current code always starts at (vfp==5 or 6, vsync=6, vbp==6) and then >> increases both vfp and vbp proportionately. This puts vsync dead center in the >> VBI, which is not how it's supposed to be - and that in turn causes the image >> to be significantly shifted upwards. >> >> I hope this makes more sense to you now. > > I'm really struggling with this, so thanks for explaining this further > (and patiently ;)) > > If I get this right, what you'd like to change is this part of the > calculus (simplified a bit, and using PAL, 576i): > >   vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 >   vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 6 >   vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > >   porches = params->num_lines - vactive - vslen; // 43 >   porches_rem = porches - vfp_min - vbp_min; // 32 > >   vfp = vfp_min + (porches_rem / 2); // 21 >   vbp = porches - vfp; // 22 > > Which is indeed having sync centered. > > I initially changed it to: > >   vfp = vfp_min; // 6 >   vbp = num_lines - vactive - vslen - vfp; // 38 > > Which is close enough for 576i, but at 480i/50Hz would end up with 134, > so still fairly far off. > > I guess your suggestion would be along the line of: > >   vfp_min = params->vfp_lines.even + params->vfp_lines.odd; // 5 >   vbp_min = params->vbp_lines.even + params->vbp_lines.odd; // 38 >   vslen = params->vslen_lines.even + params->vslen_lines.odd; // 6 > >   porches = params->num_lines - vactive - vslen; // 0 >   porches_rem = porches - vfp_min - vbp_min; // 0 > >   vfp = vfp_min + (porches_rem / 2); // 5 >   vbp = porches - vfp; // 38 > > Which is still close enough for 576i, but for 480i would end up with: > >   porches = params->num_lines - vactive - vslen; // 139 >   porches_rem = porches - vfp_min - vbp_min; // 96 > >   vfp = vfp_min + (porches_rem / 2); // 53 >   vbp = porches - vfp; // 86 > > Right? Yes. And if that's supposed to mean 480i in 50 Hz "PAL" mode, that's also "close enough" to the values I suggested above. If you substitute values for true 60 Hz "NTSC" 480i, you should also get values that are "close enough" to the official spec. The only thing I'd conceptually change is that the 38 lines is not really "vbp_min". It's more like "vbp_typ". As I mentioned above, we may want to lower this value if someone wants more active lines than the official 486/576. If they're doing that, they probably want to have vbp in the framebuffer, like VBIT2. Best regards, Mateusz Kwiatkowski