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 85179C6FA82 for ; Tue, 13 Sep 2022 12:16:43 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6918210E6D2; Tue, 13 Sep 2022 12:16:42 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 32B5D10E6D1; Tue, 13 Sep 2022 12:16:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663071399; x=1694607399; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=02GdAJcmnqd4e4fwZKv4VilRiYCld4fS/ddF/auc/w0=; b=gnOJHO/HEpg4jLu5qn1D/qQE7IAzVPoQBUHwcXNuMw9MWnXd/jnBJKZR zbut+BfDshAr2XzzzElFRhLFARfZbFFErntyHkrL7oWxLUjBSdiJt3H85 AF8d/CvyJMiheqB1bBqpzQbPPGaMc6J1t/mE/TGuaBvxIfiewVlOZusTW Ip4n6hVGyvTHrbcEWkvvHzdgMpi+HaEffgdqAtzI1dEPYLjwEeliu5/YE f+pa+SHNkj5fJ/jK0oN1DP7s1EtHkGwLlNliapnXbs+R3p9KjIftAStXt OZFPwo+X0+UVYsZMV4O1vL08PL4KAdi+YP0f0f5SHIiHX4C8M+d039Tcy g==; X-IronPort-AV: E=McAfee;i="6500,9779,10468"; a="324365577" X-IronPort-AV: E=Sophos;i="5.93,312,1654585200"; d="scan'208";a="324365577" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2022 05:16:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,312,1654585200"; d="scan'208";a="720145315" Received: from stinkpipe.fi.intel.com (HELO stinkbox) ([10.237.72.191]) by fmsmga002.fm.intel.com with SMTP; 13 Sep 2022 05:16:34 -0700 Received: by stinkbox (sSMTP sendmail emulation); Tue, 13 Sep 2022 15:16:34 +0300 Date: Tue, 13 Sep 2022 15:16:34 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Thomas Zimmermann Message-ID: References: <20220823112920.352563-1-jouni.hogander@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment Subject: Re: [Intel-gfx] [PATCH v2 0/4] Fixes for damage clips handling 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: "Nikula, Jani" , "daniel.vetter@ffwll.ch" , "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , "mairacanal@riseup.net" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, Sep 13, 2022 at 12:56:49PM +0200, Thomas Zimmermann wrote: > > > Am 13.09.22 um 12:54 schrieb Thomas Zimmermann: > > Hi > > > > Am 13.09.22 um 12:47 schrieb Hogander, Jouni: > >> On Tue, 2022-09-13 at 12:04 +0300, Ville Syrjälä wrote: > >>> On Tue, Aug 23, 2022 at 02:29:16PM +0300, Jouni Högander wrote: > >>>> Currently damage clips handling is broken for planes when using big > >>>> framebuffer + offset in case kms driver adjusts drm_plane_state.src > >>>> coords. This is because damage clips are using coords relative to > >>>> original coords from user-space. > >>>> > >>>> This patchset is fixing this by using original > >>>> coords from user-space instead of drm_plane_state.src when > >>>> iterating > >>>> damage_clips. > >>>> > >>>> v2: Modify drm unit tests accordingly > >>>> > >>>> Cc: Daniel Vetter > >>>> Cc: Maarten Lankhorst > >>>> Cc: Jani Nikula > >>>> Cc: Ville Syrjälä > >>>> Cc: José Roberto de Souza > >>>> Cc: Mika Kahola > >>>> Cc: Maíra Canal > >>>> > >>>> Jouni Högander (4): > >>>>    drm: Use original src rect while initializing damage iterator > >>>>    drm/i915/display: Use original src in psr2 sel fetch area > >>>> calculation > >>>>    drm/i915/display: Use drm helper instead of own loop for damage > >>>> clips > >>>>    drm/tests: Set also mock plane src_x, src_y, src_w and src_h > >>> > >>> Do these need to be applied into the same tree, or can > >>> the drm vs. i915 stuff go in separately? > >> > >> Patch 1 and 2 are needed to fix that bigfb handling for i915. Patch 4 > >> is also needed to prevent breaking tests. Patch 3 is more like cleanup. > >> > >> I think i915 patches could go via i915 tree. This just means that i915 > >> bigfb handling isn't fixed by either of the sets alone. > > > > I have a number of updates for damage handling that I want to get > > reviewed soon. Could you please merge your patchset via drm-misc-next? > > Or at least patches 1 and 4. Went with the 50/50 split. Everything pushed now. Thanks. -- Ville Syrjälä Intel