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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 CE4A7C433E6 for ; Mon, 8 Mar 2021 16:51:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 95F7E6522B for ; Mon, 8 Mar 2021 16:51:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230078AbhCHQvA (ORCPT ); Mon, 8 Mar 2021 11:51:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59480 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229757AbhCHQuy (ORCPT ); Mon, 8 Mar 2021 11:50:54 -0500 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1151CC06174A for ; Mon, 8 Mar 2021 08:50:54 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id r15-20020a05600c35cfb029010e639ca09eso4217522wmq.1 for ; Mon, 08 Mar 2021 08:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=csdGRTC/fqgxsx3MqD2CY30jxKKY88IrwPuEZV8x6Ik=; b=DX98jyr5QLOmJ8E7yGn6bjv/PpieA9Cosj5ziznlKkeYgIlkJgCfrI0YrEgh0j8I6/ twMC2UTSK3Z1ow3Kg345iexCRbOdFO2B/f8UzcxqaaKGs4kLepGlpue2mnXWMo5u89GI PKatd4km02S4zeQap6wAKbamucP7/ijFuuZGdlCDH4hzu8xcLT6nXY0yGS06xYW9QUOq 7YRR+PERcI7f3pfmIEdEvU9zTB9TdYviHHQFYUId/RdzTCs0T5t29AdLqQWFQ1TyqbwT zJ43clxhaQ9Od+geafT84c4b1f+5fT395Ovnee2HEqyyO2cHO6waLoXu1/b/NjhC1NwJ iGow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=csdGRTC/fqgxsx3MqD2CY30jxKKY88IrwPuEZV8x6Ik=; b=L+n9qCsXRbZri7SN38AZrGfbcnRH/8me0wT/I1hQqQlDX7uya2V0Cu+FfEltfmX5ZD U72nkWUuGJqoWeifc/tRdQsqBjIe9nHX1Q50nM9bPg7nLhmQxKY6PsIi9jSitbFLq+Ak LDnCkxNzX+UPTZeuWGmv+axN7U0wjAoFFxhnTUoKDhiWu9/BUwKuCLNRhpZWig/K9RfM gqlILSoG+SzqEL6Uxwp74t/fD4sttBjLpViSlZVTyykUCkAxJd37s8oHCYJHMv1uzwC5 gErm/j4wkSjeaIgimttrDw1b/iXtiaE0x6MF/zDSJ85l4mdQNPlUxq2Mc70ifTuGXrtb iQXQ== X-Gm-Message-State: AOAM530Avx4xN4j3emAIyburCx+Xu2n5V35y+/DTmKlDur9Hmg0WFeJC 4QXBe9W2OIaZb+NtNFwP1ENXuA== X-Google-Smtp-Source: ABdhPJwiGAFh2Sq055ZPR+B0t2Vb4lvtPttu/FfPEwa5HdoRsCuHmy/uMDSJ943qk0DgZb+bSLnPhg== X-Received: by 2002:a7b:c2aa:: with SMTP id c10mr22868798wmk.101.1615222252666; Mon, 08 Mar 2021 08:50:52 -0800 (PST) Received: from maple.lan (cpc141216-aztw34-2-0-cust174.18-1.cable.virginm.net. [80.7.220.175]) by smtp.gmail.com with ESMTPSA id b15sm20536789wmd.41.2021.03.08.08.50.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Mar 2021 08:50:52 -0800 (PST) Date: Mon, 8 Mar 2021 16:50:50 +0000 From: Daniel Thompson To: Lyude Paul Cc: nouveau@lists.freedesktop.org, "open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS" , David Airlie , Pankaj Bharadiya , James Jones , open list , stable@vger.kernel.org, Ben Skeggs , Dave Airlie Subject: Re: [PATCH] drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128 Message-ID: <20210308165050.qhhf5aqdcldet5p6@maple.lan> References: <20210305015242.740590-1-lyude@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210305015242.740590-1-lyude@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 04, 2021 at 08:52:41PM -0500, Lyude Paul wrote: > While Kepler does technically support 256x256 cursors, it turns out that > Kepler actually has some additional requirements for scanout surfaces that > we're not enforcing correctly, which aren't present on Maxwell and later. > Cursor surfaces must always use small pages (4K), and overlay surfaces must > always use large pages (128K). > > Fixing this correctly though will take a bit more work: as we'll need to > add some code in prepare_fb() to move cursor FBs in large pages to small > pages, and vice-versa for overlay FBs. So until we have the time to do > that, just limit cursor surfaces to 128x128 - a size small enough to always > default to small pages. > > This means small ovlys are still broken on Kepler, but it is extremely > unlikely anyone cares about those anyway :). > > Signed-off-by: Lyude Paul > Fixes: d3b2f0f7921c ("drm/nouveau/kms/nv50-: Report max cursor size to userspace") > Cc: # v5.11+ I was experiencing problems with the mouse cursor on my system in v5.11 and after a bisect to help me search the web I found my way to this patch, which fixed the problem for me. Mine is an Armv8 system but there is nothing particularly exotic from a graphics card or software point of view: Debian bullseye/wayland (gnome-shell 3.38.3, mesa-20.3.4) running on a GT-710. However FWIW: Tested-by: Daniel Thompson Daniel. > --- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c > index 196612addfd6..1c9c0cdf85db 100644 > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c > @@ -2693,9 +2693,20 @@ nv50_display_create(struct drm_device *dev) > else > nouveau_display(dev)->format_modifiers = disp50xx_modifiers; > > - if (disp->disp->object.oclass >= GK104_DISP) { > + /* FIXME: 256x256 cursors are supported on Kepler, however unlike Maxwell and later > + * generations Kepler requires that we use small pages (4K) for cursor scanout surfaces. The > + * proper fix for this is to teach nouveau to migrate fbs being used for the cursor plane to > + * small page allocations in prepare_fb(). When this is implemented, we should also force > + * large pages (128K) for ovly fbs in order to fix Kepler ovlys. > + * But until then, just limit cursors to 128x128 - which is small enough to avoid ever using > + * large pages. > + */ > + if (disp->disp->object.oclass >= GM107_DISP) { > dev->mode_config.cursor_width = 256; > dev->mode_config.cursor_height = 256; > + } else if (disp->disp->object.oclass >= GK104_DISP) { > + dev->mode_config.cursor_width = 128; > + dev->mode_config.cursor_height = 128; > } else { > dev->mode_config.cursor_width = 64; > dev->mode_config.cursor_height = 64; > -- > 2.29.2 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel