[PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes

[PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes

[Lyude Paul]

Nvidia hardware doesn't actually support using tiling formats with the
cursor plane, only linear is allowed. In the future, we should write a
testcase for this.

Fixes: c586f30bf74c ("drm/nouveau/kms: Add format mod prop to base/ovly/nvdisp")
Cc: James Jones <jajones-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Martin Peres <martin.peres-GANU6spQydw@public.gmane.org>
Cc: Jeremy Cline <jcline-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Simon Ser <contact-sV0wSBM+kKVWj0EZb7rXcA@public.gmane.org>
Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v5.8+
Signed-off-by: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 drivers/gpu/drm/nouveau/dispnv50/wndw.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index ce451242f79e..271de3a63f21 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -702,6 +702,11 @@ nv50_wndw_init(struct nv50_wndw *wndw)
 	nvif_notify_get(&wndw->notify);
 }
 
+static const u64 nv50_cursor_format_modifiers[] = {
+	DRM_FORMAT_MOD_LINEAR,
+	DRM_FORMAT_MOD_INVALID,
+};
+
 int
 nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
 	       enum drm_plane_type type, const char *name, int index,
@@ -713,6 +718,7 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
 	struct nvif_mmu *mmu = &drm->client.mmu;
 	struct nv50_disp *disp = nv50_disp(dev);
 	struct nv50_wndw *wndw;
+	const u64 *format_modifiers;
 	int nformat;
 	int ret;
 
@@ -728,10 +734,13 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
 
 	for (nformat = 0; format[nformat]; nformat++);
 
-	ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw,
-				       format, nformat,
-				       nouveau_display(dev)->format_modifiers,
-				       type, "%s-%d", name, index);
+	if (type == DRM_PLANE_TYPE_CURSOR)
+		format_modifiers = nv50_cursor_format_modifiers;
+	else
+		format_modifiers = nouveau_display(dev)->format_modifiers;
+
+	ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw, format, nformat,
+				       format_modifiers, type, "%s-%d", name, index);
 	if (ret) {
 		kfree(*pwndw);
 		*pwndw = NULL;
-- 
2.29.2

[PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Lyude Paul]

Cc: Martin Peres <martin.peres-GANU6spQydw@public.gmane.org>
Cc: Jeremy Cline <jcline-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Simon Ser <contact-sV0wSBM+kKVWj0EZb7rXcA@public.gmane.org>
Signed-off-by: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c6367035970e..5f4f09a601d4 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2663,6 +2663,14 @@ nv50_display_create(struct drm_device *dev)
 	else
 		nouveau_display(dev)->format_modifiers = disp50xx_modifiers;
 
+	if (disp->disp->object.oclass >= GK104_DISP) {
+		dev->mode_config.cursor_width = 256;
+		dev->mode_config.cursor_height = 256;
+	} else {
+		dev->mode_config.cursor_width = 64;
+		dev->mode_config.cursor_height = 64;
+	}
+
 	/* create crtc objects to represent the hw heads */
 	if (disp->disp->object.oclass >= GV100_DISP)
 		crtcs = nvif_rd32(&device->object, 0x610060) & 0xff;
-- 
2.29.2

[PATCH 3/3] drm/nouveau/kms/nve4-nv138: Fix > 64x64 cursors

[Lyude Paul]

While we do handle the additional cursor sizes introduced in NVE4, it looks
like we accidentally broke this when converting over to use Nvidia's
display headers. Since we now use NVVAL in dispnv50/head907d.c in order to
format the value for the cursor layout and NVD9 only had one byte reserved
vs. the 2 bytes reserved in later generations, we end up accidentally
stripping the second bit in the cursor layout format parameter - causing us
to set the wrong cursor size.

This fixes that by adding our own curs_set hook for 917d which uses the
NV917D headers.

Cc: Martin Peres <martin.peres-GANU6spQydw@public.gmane.org>
Cc: Jeremy Cline <jcline-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Simon Ser <contact-sV0wSBM+kKVWj0EZb7rXcA@public.gmane.org>
Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v5.9+
Signed-off-by: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Fixes: ed0b86a90bf9 ("drm/nouveau/kms/nv50-: use NVIDIA's headers for core head_curs_set()")
---
 drivers/gpu/drm/nouveau/dispnv50/head917d.c   | 28 ++++++++++++++++++-
 .../drm/nouveau/include/nvhw/class/cl917d.h   |  4 +++
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/head917d.c b/drivers/gpu/drm/nouveau/dispnv50/head917d.c
index a5d827403660..ea9f8667305e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head917d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head917d.c
@@ -22,6 +22,7 @@
 #include "head.h"
 #include "core.h"
 
+#include "nvif/push.h"
 #include <nvif/push507c.h>
 
 #include <nvhw/class/cl917d.h>
@@ -73,6 +74,31 @@ head917d_base(struct nv50_head *head, struct nv50_head_atom *asyh)
 	return 0;
 }
 
+static int
+head917d_curs_set(struct nv50_head *head, struct nv50_head_atom *asyh)
+{
+	struct nvif_push *push = nv50_disp(head->base.base.dev)->core->chan.push;
+	const int i = head->base.index;
+	int ret;
+
+	ret = PUSH_WAIT(push, 5);
+	if (ret)
+		return ret;
+
+	PUSH_MTHD(push, NV917D, HEAD_SET_CONTROL_CURSOR(i),
+		  NVDEF(NV917D, HEAD_SET_CONTROL_CURSOR, ENABLE, ENABLE) |
+		  NVVAL(NV917D, HEAD_SET_CONTROL_CURSOR, FORMAT, asyh->curs.format) |
+		  NVVAL(NV917D, HEAD_SET_CONTROL_CURSOR, SIZE, asyh->curs.layout) |
+		  NVVAL(NV917D, HEAD_SET_CONTROL_CURSOR, HOT_SPOT_X, 0) |
+		  NVVAL(NV917D, HEAD_SET_CONTROL_CURSOR, HOT_SPOT_Y, 0) |
+		  NVDEF(NV917D, HEAD_SET_CONTROL_CURSOR, COMPOSITION, ALPHA_BLEND),
+
+				HEAD_SET_OFFSET_CURSOR(i), asyh->curs.offset >> 8);
+
+	PUSH_MTHD(push, NV917D, HEAD_SET_CONTEXT_DMA_CURSOR(i), asyh->curs.handle);
+	return 0;
+}
+
 int
 head917d_curs_layout(struct nv50_head *head, struct nv50_wndw_atom *asyw,
 		     struct nv50_head_atom *asyh)
@@ -101,7 +127,7 @@ head917d = {
 	.core_clr = head907d_core_clr,
 	.curs_layout = head917d_curs_layout,
 	.curs_format = head507d_curs_format,
-	.curs_set = head907d_curs_set,
+	.curs_set = head917d_curs_set,
 	.curs_clr = head907d_curs_clr,
 	.base = head917d_base,
 	.ovly = head907d_ovly,
diff --git a/drivers/gpu/drm/nouveau/include/nvhw/class/cl917d.h b/drivers/gpu/drm/nouveau/include/nvhw/class/cl917d.h
index 2a2612d6e1e0..fb223723a38a 100644
--- a/drivers/gpu/drm/nouveau/include/nvhw/class/cl917d.h
+++ b/drivers/gpu/drm/nouveau/include/nvhw/class/cl917d.h
@@ -66,6 +66,10 @@
 #define NV917D_HEAD_SET_CONTROL_CURSOR_COMPOSITION_ALPHA_BLEND                  (0x00000000)
 #define NV917D_HEAD_SET_CONTROL_CURSOR_COMPOSITION_PREMULT_ALPHA_BLEND          (0x00000001)
 #define NV917D_HEAD_SET_CONTROL_CURSOR_COMPOSITION_XOR                          (0x00000002)
+#define NV917D_HEAD_SET_OFFSET_CURSOR(a)                                        (0x00000484 + (a)*0x00000300)
+#define NV917D_HEAD_SET_OFFSET_CURSOR_ORIGIN                                    31:0
+#define NV917D_HEAD_SET_CONTEXT_DMA_CURSOR(a)                                   (0x0000048C + (a)*0x00000300)
+#define NV917D_HEAD_SET_CONTEXT_DMA_CURSOR_HANDLE                               31:0
 #define NV917D_HEAD_SET_DITHER_CONTROL(a)                                       (0x000004A0 + (a)*0x00000300)
 #define NV917D_HEAD_SET_DITHER_CONTROL_ENABLE                                   0:0
 #define NV917D_HEAD_SET_DITHER_CONTROL_ENABLE_DISABLE                           (0x00000000)
-- 
2.29.2

Re: [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes

[Simon Ser]

On Tuesday, January 19th, 2021 at 2:54 AM, Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> Nvidia hardware doesn't actually support using tiling formats with the
> cursor plane, only linear is allowed. In the future, we should write a
> testcase for this.
>
> Fixes: c586f30bf74c ("drm/nouveau/kms: Add format mod prop to base/ovly/nvdisp")
> Cc: James Jones <jajones-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Cc: Martin Peres <martin.peres-GANU6spQydw@public.gmane.org>
> Cc: Jeremy Cline <jcline-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Simon Ser <contact-sV0wSBM+kKVWj0EZb7rXcA@public.gmane.org>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v5.8+
> Signed-off-by: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Together with [1], this patch allows me to run unpatched modifier-aware
user-space successfully, without a cursor visual glitch. drm_info
correctly reports the new modifier list, and wlroots logs confirm that
a flavor of NVIDIA_BLOCK_LINEAR_2D is used for the primary buffers and
LINEAR is used for cursor buffers.

Code looks good to me as well.

Reviewed-by: Simon Ser <contact-sV0wSBM+kKVWj0EZb7rXcA@public.gmane.org>

[1]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3724

Re: [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Simon Ser]

On Tuesday, January 19th, 2021 at 2:54 AM, Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> Cc: Martin Peres <martin.peres-GANU6spQydw@public.gmane.org>
> Cc: Jeremy Cline <jcline-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Simon Ser <contact-sV0wSBM+kKVWj0EZb7rXcA@public.gmane.org>
> Signed-off-by: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index c6367035970e..5f4f09a601d4 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -2663,6 +2663,14 @@ nv50_display_create(struct drm_device *dev)
>  	else
>  		nouveau_display(dev)->format_modifiers = disp50xx_modifiers;
>
> +	if (disp->disp->object.oclass >= GK104_DISP) {

I can confirm this works fine on GK208B. Tested with wlroots. I don't
have older cards to test, though.

Tested-by: Simon Ser <contact-sV0wSBM+kKVWj0EZb7rXcA@public.gmane.org>

> +		dev->mode_config.cursor_width = 256;
> +		dev->mode_config.cursor_height = 256;
> +	} else {
> +		dev->mode_config.cursor_width = 64;
> +		dev->mode_config.cursor_height = 64;
> +	}
> +
>  	/* create crtc objects to represent the hw heads */
>  	if (disp->disp->object.oclass >= GV100_DISP)
>  		crtcs = nvif_rd32(&device->object, 0x610060) & 0xff;
> --
> 2.29.2

Re: [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes

[Ville Syrjälä]

On Mon, Jan 18, 2021 at 08:54:12PM -0500, Lyude Paul wrote:
> Nvidia hardware doesn't actually support using tiling formats with the
> cursor plane, only linear is allowed. In the future, we should write a
> testcase for this.

There are a couple of old modifier/format sanity tests here:
https://patchwork.freedesktop.org/series/46876/

Couple of things missing that now came to my mind:
- test setplane/etc. rejects unsupported formats/modifiers even if
  addfb allowed them, exactly for the case where only a subset of
  planes support something
- validate the IN_FORMATS blob harder, eg. make sure each modifier
  listed there supports at least one format. IIRC this was busted on
  a few drivers last year, dunno if they got fixed or not. Hmm,
  actually since this is now using the pre-parsed stuff I guess we
  should just stick an assert into igt_fill_plane_format_mod() where
  the blob gets parsed

> 
> Fixes: c586f30bf74c ("drm/nouveau/kms: Add format mod prop to base/ovly/nvdisp")
> Cc: James Jones <jajones-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Cc: Martin Peres <martin.peres-GANU6spQydw@public.gmane.org>
> Cc: Jeremy Cline <jcline-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Simon Ser <contact-sV0wSBM+kKVWj0EZb7rXcA@public.gmane.org>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v5.8+
> Signed-off-by: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>  drivers/gpu/drm/nouveau/dispnv50/wndw.c | 17 +++++++++++++----
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> index ce451242f79e..271de3a63f21 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> @@ -702,6 +702,11 @@ nv50_wndw_init(struct nv50_wndw *wndw)
>  	nvif_notify_get(&wndw->notify);
>  }
>  
> +static const u64 nv50_cursor_format_modifiers[] = {
> +	DRM_FORMAT_MOD_LINEAR,
> +	DRM_FORMAT_MOD_INVALID,
> +};
> +
>  int
>  nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
>  	       enum drm_plane_type type, const char *name, int index,
> @@ -713,6 +718,7 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
>  	struct nvif_mmu *mmu = &drm->client.mmu;
>  	struct nv50_disp *disp = nv50_disp(dev);
>  	struct nv50_wndw *wndw;
> +	const u64 *format_modifiers;
>  	int nformat;
>  	int ret;
>  
> @@ -728,10 +734,13 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
>  
>  	for (nformat = 0; format[nformat]; nformat++);
>  
> -	ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw,
> -				       format, nformat,
> -				       nouveau_display(dev)->format_modifiers,
> -				       type, "%s-%d", name, index);
> +	if (type == DRM_PLANE_TYPE_CURSOR)
> +		format_modifiers = nv50_cursor_format_modifiers;
> +	else
> +		format_modifiers = nouveau_display(dev)->format_modifiers;
> +
> +	ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw, format, nformat,
> +				       format_modifiers, type, "%s-%d", name, index);
>  	if (ret) {
>  		kfree(*pwndw);
>  		*pwndw = NULL;
> -- 
> 2.29.2
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel

Re: [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes

[James Jones]

Gah, yes, good catch.

Reviewed-by: James Jones <jajones-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

On 1/18/21 5:54 PM, Lyude Paul wrote:
> Nvidia hardware doesn't actually support using tiling formats with the
> cursor plane, only linear is allowed. In the future, we should write a
> testcase for this.
> 
> Fixes: c586f30bf74c ("drm/nouveau/kms: Add format mod prop to base/ovly/nvdisp")
> Cc: James Jones <jajones-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Cc: Martin Peres <martin.peres-GANU6spQydw@public.gmane.org>
> Cc: Jeremy Cline <jcline-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Simon Ser <contact-sV0wSBM+kKVWj0EZb7rXcA@public.gmane.org>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v5.8+
> Signed-off-by: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
>   drivers/gpu/drm/nouveau/dispnv50/wndw.c | 17 +++++++++++++----
>   1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> index ce451242f79e..271de3a63f21 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
> @@ -702,6 +702,11 @@ nv50_wndw_init(struct nv50_wndw *wndw)
>   	nvif_notify_get(&wndw->notify);
>   }
>   
> +static const u64 nv50_cursor_format_modifiers[] = {
> +	DRM_FORMAT_MOD_LINEAR,
> +	DRM_FORMAT_MOD_INVALID,
> +};
> +
>   int
>   nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
>   	       enum drm_plane_type type, const char *name, int index,
> @@ -713,6 +718,7 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
>   	struct nvif_mmu *mmu = &drm->client.mmu;
>   	struct nv50_disp *disp = nv50_disp(dev);
>   	struct nv50_wndw *wndw;
> +	const u64 *format_modifiers;
>   	int nformat;
>   	int ret;
>   
> @@ -728,10 +734,13 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev,
>   
>   	for (nformat = 0; format[nformat]; nformat++);
>   
> -	ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw,
> -				       format, nformat,
> -				       nouveau_display(dev)->format_modifiers,
> -				       type, "%s-%d", name, index);
> +	if (type == DRM_PLANE_TYPE_CURSOR)
> +		format_modifiers = nv50_cursor_format_modifiers;
> +	else
> +		format_modifiers = nouveau_display(dev)->format_modifiers;
> +
> +	ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw, format, nformat,
> +				       format_modifiers, type, "%s-%d", name, index);
>   	if (ret) {
>   		kfree(*pwndw);
>   		*pwndw = NULL;
> 

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Alex Riesen]

Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index c6367035970e..5f4f09a601d4 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -2663,6 +2663,14 @@ nv50_display_create(struct drm_device *dev)
>  	else
>  		nouveau_display(dev)->format_modifiers = disp50xx_modifiers;
>  
> +	if (disp->disp->object.oclass >= GK104_DISP) {
> +		dev->mode_config.cursor_width = 256;
> +		dev->mode_config.cursor_height = 256;
> +	} else {
> +		dev->mode_config.cursor_width = 64;
> +		dev->mode_config.cursor_height = 64;
> +	}
> +
>  	/* create crtc objects to represent the hw heads */
>  	if (disp->disp->object.oclass >= GV100_DISP)
>  		crtcs = nvif_rd32(&device->object, 0x610060) & 0xff;

This change broke X cursor in my setup, and reverting the commit restores it.

Dell Precision M4800, issue ~2014 with GK106GLM [Quadro K2100M] (rev a1).
libdrm 2.4.91-1 (Debian 10.8 stable).
There are no errors or warnings in Xorg logs nor in the kernel log.

Regards,
Alex
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen
<alexander.riesen@cetitec.com> wrote:
>
> Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index c6367035970e..5f4f09a601d4 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -2663,6 +2663,14 @@ nv50_display_create(struct drm_device *dev)
> >       else
> >               nouveau_display(dev)->format_modifiers = disp50xx_modifiers;
> >
> > +     if (disp->disp->object.oclass >= GK104_DISP) {
> > +             dev->mode_config.cursor_width = 256;
> > +             dev->mode_config.cursor_height = 256;
> > +     } else {
> > +             dev->mode_config.cursor_width = 64;
> > +             dev->mode_config.cursor_height = 64;
> > +     }
> > +
> >       /* create crtc objects to represent the hw heads */
> >       if (disp->disp->object.oclass >= GV100_DISP)
> >               crtcs = nvif_rd32(&device->object, 0x610060) & 0xff;
>
> This change broke X cursor in my setup, and reverting the commit restores it.
>
> Dell Precision M4800, issue ~2014 with GK106GLM [Quadro K2100M] (rev a1).
> libdrm 2.4.91-1 (Debian 10.8 stable).
> There are no errors or warnings in Xorg logs nor in the kernel log.

Hi Alex,

Could you confirm which ddx is driving the nvidia hw? You can find
this out by running "xrandr --listproviders", or also in the xorg log.

Thanks,

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Alex Riesen]

Ilia Mirkin, Tue, Feb 23, 2021 15:56:21 +0100:
> On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> > Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > index c6367035970e..5f4f09a601d4 100644
> > > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > @@ -2663,6 +2663,14 @@ nv50_display_create(struct drm_device *dev)
> > >       else
> > >               nouveau_display(dev)->format_modifiers = disp50xx_modifiers;
> > >
> > > +     if (disp->disp->object.oclass >= GK104_DISP) {
> > > +             dev->mode_config.cursor_width = 256;
> > > +             dev->mode_config.cursor_height = 256;
> > > +     } else {
> > > +             dev->mode_config.cursor_width = 64;
> > > +             dev->mode_config.cursor_height = 64;
> > > +     }
> > > +
> > >       /* create crtc objects to represent the hw heads */
> > >       if (disp->disp->object.oclass >= GV100_DISP)
> > >               crtcs = nvif_rd32(&device->object, 0x610060) & 0xff;
> >
> > This change broke X cursor in my setup, and reverting the commit restores it.
> >
> > Dell Precision M4800, issue ~2014 with GK106GLM [Quadro K2100M] (rev a1).
> > libdrm 2.4.91-1 (Debian 10.8 stable).
> > There are no errors or warnings in Xorg logs nor in the kernel log.
> 
> Could you confirm which ddx is driving the nvidia hw? You can find
> this out by running "xrandr --listproviders", or also in the xorg log.

xrandr(1) does not seem to list much:

$ xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x48 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:modesetting

I failed to find a DDX in Xorg.0.log. Both Xorg.0.log and dmesg can be seen here:

    https://gist.github.com/ar-cetitec/68c27551d9a59b89dc73bffe0456bbef


_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Tue, Feb 23, 2021 at 10:36 AM Alex Riesen
<alexander.riesen@cetitec.com> wrote:
>
> Ilia Mirkin, Tue, Feb 23, 2021 15:56:21 +0100:
> > On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> > > Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> > > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > > index c6367035970e..5f4f09a601d4 100644
> > > > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > > @@ -2663,6 +2663,14 @@ nv50_display_create(struct drm_device *dev)
> > > >       else
> > > >               nouveau_display(dev)->format_modifiers = disp50xx_modifiers;
> > > >
> > > > +     if (disp->disp->object.oclass >= GK104_DISP) {
> > > > +             dev->mode_config.cursor_width = 256;
> > > > +             dev->mode_config.cursor_height = 256;
> > > > +     } else {
> > > > +             dev->mode_config.cursor_width = 64;
> > > > +             dev->mode_config.cursor_height = 64;
> > > > +     }
> > > > +
> > > >       /* create crtc objects to represent the hw heads */
> > > >       if (disp->disp->object.oclass >= GV100_DISP)
> > > >               crtcs = nvif_rd32(&device->object, 0x610060) & 0xff;
> > >
> > > This change broke X cursor in my setup, and reverting the commit restores it.
> > >
> > > Dell Precision M4800, issue ~2014 with GK106GLM [Quadro K2100M] (rev a1).
> > > libdrm 2.4.91-1 (Debian 10.8 stable).
> > > There are no errors or warnings in Xorg logs nor in the kernel log.
> >
> > Could you confirm which ddx is driving the nvidia hw? You can find
> > this out by running "xrandr --listproviders", or also in the xorg log.
>
> xrandr(1) does not seem to list much:
>
> $ xrandr --listproviders
> Providers: number : 1
> Provider 0: id: 0x48 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:modesetting

Thanks - this is what I was looking for. name:modesetting, i.e. the
modesetting ddx driver.

I checked nouveau source, and it seems like it uses a 64x64 cursor no
matter what. Not sure what the modesetting ddx does.

I'd recommend using xf86-video-nouveau in any case, but some distros
have decided to explicitly force modesetting in preference of nouveau.
Oh well. (And regardless, the regression should be addressed somehow,
but it's also good to understand what the problem is.)

Can you confirm what the problem with the cursor is?

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Alex Riesen]

Ilia Mirkin, Tue, Feb 23, 2021 16:46:52 +0100:
> On Tue, Feb 23, 2021 at 10:36 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> > Ilia Mirkin, Tue, Feb 23, 2021 15:56:21 +0100:
> > > On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> > > >
> > > > This change broke X cursor in my setup, and reverting the commit restores it.
> > > >
> > > > Dell Precision M4800, issue ~2014 with GK106GLM [Quadro K2100M] (rev a1).
> > > > libdrm 2.4.91-1 (Debian 10.8 stable).
> > > > There are no errors or warnings in Xorg logs nor in the kernel log.
> > >
> > > Could you confirm which ddx is driving the nvidia hw? You can find
> > > this out by running "xrandr --listproviders", or also in the xorg log.
> >
> > xrandr(1) does not seem to list much:
> >
> > $ xrandr --listproviders
> > Providers: number : 1
> > Provider 0: id: 0x48 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:modesetting
> 
> Thanks - this is what I was looking for. name:modesetting, i.e. the
> modesetting ddx driver.
> 
> I checked nouveau source, and it seems like it uses a 64x64 cursor no
> matter what. Not sure what the modesetting ddx does.
> 
> I'd recommend using xf86-video-nouveau in any case, but some distros

I would like try this out. Do you know how to force the xorg server to
choose this driver instead of modesetting?

> have decided to explicitly force modesetting in preference of nouveau.
> Oh well. (And regardless, the regression should be addressed somehow,
> but it's also good to understand what the problem is.)
>
> Can you confirm what the problem with the cursor is?

The cursor looks stretched vertically over a bigger matrix, while missing some
lines and being wrapped over the bottom on top of that matrix.

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Alex Riesen]

Alex Riesen, Tue, Feb 23, 2021 16:51:26 +0100:
> Ilia Mirkin, Tue, Feb 23, 2021 16:46:52 +0100:
> > I'd recommend using xf86-video-nouveau in any case, but some distros
> 
> I would like try this out. Do you know how to force the xorg server to
> choose this driver instead of modesetting?

Found that myself (a Device section with Driver set to "nouveau"):

    $ xrandr  --listproviders
    Providers: number : 1
    Provider 0: id: 0x68 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 5 associated providers: 0 name:nouveau

And yes, the cursor looks good in v5.11 even without reverting the commit.

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen
<alexander.riesen@cetitec.com> wrote:
>
> Alex Riesen, Tue, Feb 23, 2021 16:51:26 +0100:
> > Ilia Mirkin, Tue, Feb 23, 2021 16:46:52 +0100:
> > > I'd recommend using xf86-video-nouveau in any case, but some distros
> >
> > I would like try this out. Do you know how to force the xorg server to
> > choose this driver instead of modesetting?
>
> Found that myself (a Device section with Driver set to "nouveau"):
>
>     $ xrandr  --listproviders
>     Providers: number : 1
>     Provider 0: id: 0x68 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 5 associated providers: 0 name:nouveau
>
> And yes, the cursor looks good in v5.11 even without reverting the commit.

FWIW it's not immediately apparent to me what grave error modesetting
is committing in setting the cursor. The logic looks perfectly
reasonable. It's not trying to be fancy with rendering the cursor/etc.

The one thing is that it's using drmModeSetCursor2 which sets the
hotspot at the same time. But internally inside nouveau I think it
should work out to the same thing. Perhaps setting the hotspot, or
something in that path, doesn't quite work for 256x256? [Again, no
clue what that might be.]

It might also be worthwhile just testing if the 256x256 cursor works
quite the way one would want. If you're interested, grab libdrm,
there's a test called 'modetest', which has an option to enable a
moving cursor (-c iirc). It's hard-coded to 64x64, so you'll have to
modify it there too (and probably change the pattern from plain gray
to any one of the other ones).

Cheers,

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Alex Riesen]

Ilia Mirkin, Tue, Feb 23, 2021 19:13:59 +0100:
> On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> >
> >     $ xrandr  --listproviders
> >     Providers: number : 1
> >     Provider 0: id: 0x68 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 5 associated providers: 0 name:nouveau
> >
> > And yes, the cursor looks good in v5.11 even without reverting the commit.
> 
> FWIW it's not immediately apparent to me what grave error modesetting
> is committing in setting the cursor. The logic looks perfectly
> reasonable. It's not trying to be fancy with rendering the cursor/etc.
> 
> The one thing is that it's using drmModeSetCursor2 which sets the
> hotspot at the same time. But internally inside nouveau I think it
> should work out to the same thing. Perhaps setting the hotspot, or
> something in that path, doesn't quite work for 256x256? [Again, no
> clue what that might be.]
> 
> It might also be worthwhile just testing if the 256x256 cursor works
> quite the way one would want. If you're interested, grab libdrm,
> there's a test called 'modetest', which has an option to enable a
> moving cursor (-c iirc). It's hard-coded to 64x64, so you'll have to
> modify it there too (and probably change the pattern from plain gray
> to any one of the other ones).

I am interested, so I did.

If I start the test without X running, the sprite of 256x256 cursor always
contained horizontal lines across it, both with commit reverted and vanilla
v5.11. Similarly, the 64x64 cursor has no lines across it in both kernels.

The test does not seem to work at all if there is an X server running (using
modesetting driver): modetest complained about permission denied to set the
mode, and just sits there, drawing nothing on the displays.
So I could not run the test in the environment of original problem.
Am I starting it correctly? Is the change in modetest.c correct?

    $ ./modetest -c |grep '^[0-9]\|preferred'
    85	86	connected	LVDS-1         	340x190		13	86
      #0 1920x1080 60.01 1920 2010 2070 2226 1080 1086 1095 1142 152540 flags: phsync, nvsync; type: preferred, driver
    87	89	connected	DP-1           	470x300		18	88, 89
      #0 1680x1050 59.88 1680 1728 1760 1840 1050 1053 1059 1080 119000 flags: phsync, nvsync; type: preferred, driver
    90	0	disconnected	DP-2           	0x0		0	91, 92
    93	95	connected	DP-3           	520x320		10	94, 95
      #0 1920x1200 59.95 1920 1968 2000 2080 1200 1203 1209 1235 154000 flags: phsync, nvsync; type: preferred, driver
    96	0	disconnected	VGA-1          	0x0		0	97

    $ ./modetest -s 85:1920x1080 -s 93:1920x1200 -s 87:1680x1050  -C
    trying to open device 'i915'...failed
    trying to open device 'amdgpu'...failed
    trying to open device 'radeon'...failed
    trying to open device 'nouveau'...done
    setting mode 1920x1080-60.01Hz on connectors 85, crtc 50
    starting cursor

    cursor stopped

This is the change on top of 1225171b (master):

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index fc75383a..cdba7b4e 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1730,14 +1730,14 @@ static void set_cursors(struct device *dev, struct pipe_arg *pipes, unsigned int
 	int ret;
 
 	/* maybe make cursor width/height configurable some day */
-	uint32_t cw = 64;
-	uint32_t ch = 64;
+	uint32_t cw = 256;
+	uint32_t ch = 256;
 
 	/* create cursor bo.. just using PATTERN_PLAIN as it has
 	 * translucent alpha
 	 */
 	bo = bo_create(dev->fd, DRM_FORMAT_ARGB8888, cw, ch, handles, pitches,
-		       offsets, UTIL_PATTERN_PLAIN);
+		       offsets, UTIL_PATTERN_SMPTE);
 	if (bo == NULL)
 		return;

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

[+emersion, -various people and lists who definitely don't care]

On Wed, Feb 24, 2021 at 4:09 AM Alex Riesen
<alexander.riesen@cetitec.com> wrote:
>
> Ilia Mirkin, Tue, Feb 23, 2021 19:13:59 +0100:
> > On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> > >
> > >     $ xrandr  --listproviders
> > >     Providers: number : 1
> > >     Provider 0: id: 0x68 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 5 associated providers: 0 name:nouveau
> > >
> > > And yes, the cursor looks good in v5.11 even without reverting the commit.
> >
> > FWIW it's not immediately apparent to me what grave error modesetting
> > is committing in setting the cursor. The logic looks perfectly
> > reasonable. It's not trying to be fancy with rendering the cursor/etc.
> >
> > The one thing is that it's using drmModeSetCursor2 which sets the
> > hotspot at the same time. But internally inside nouveau I think it
> > should work out to the same thing. Perhaps setting the hotspot, or
> > something in that path, doesn't quite work for 256x256? [Again, no
> > clue what that might be.]
> >
> > It might also be worthwhile just testing if the 256x256 cursor works
> > quite the way one would want. If you're interested, grab libdrm,
> > there's a test called 'modetest', which has an option to enable a
> > moving cursor (-c iirc). It's hard-coded to 64x64, so you'll have to
> > modify it there too (and probably change the pattern from plain gray
> > to any one of the other ones).
>
> I am interested, so I did.
>
> If I start the test without X running, the sprite of 256x256 cursor always
> contained horizontal lines across it, both with commit reverted and vanilla
> v5.11. Similarly, the 64x64 cursor has no lines across it in both kernels.
>
> The test does not seem to work at all if there is an X server running (using
> modesetting driver): modetest complained about permission denied to set the
> mode, and just sits there, drawing nothing on the displays.
> So I could not run the test in the environment of original problem.
> Am I starting it correctly? Is the change in modetest.c correct?

Looks right. Although TBH I'd just start it on a single display (I
forgot you could even do multiple displays). You should be able to
start it with the X server running if you switch to a vt (and run it
as root). If you can't, that means the modesetting driver is
forgetting to do something in the LeaveVT function.

The fact that you're getting lines with modetest means there's
something wrong with 256x256. What if you do 128x128 -- does that work
OK?

Simon, you tested on a GK208, that has a slightly later display
controller than the GK104 -- can you try to reproduce Alex's results?
Perhaps there was a problem with the GK10x's and it starts working OK
with the GK110 disp.

I don't have any GK10x's in my posession (I have nearly every other
iteration of the display controller), but hopefully someone on the
nouveau team will be able to dig one up and reproduce.

Thanks for testing, Alex!

>
>     $ ./modetest -c |grep '^[0-9]\|preferred'
>     85  86      connected       LVDS-1          340x190         13      86
>       #0 1920x1080 60.01 1920 2010 2070 2226 1080 1086 1095 1142 152540 flags: phsync, nvsync; type: preferred, driver
>     87  89      connected       DP-1            470x300         18      88, 89
>       #0 1680x1050 59.88 1680 1728 1760 1840 1050 1053 1059 1080 119000 flags: phsync, nvsync; type: preferred, driver
>     90  0       disconnected    DP-2            0x0             0       91, 92
>     93  95      connected       DP-3            520x320         10      94, 95
>       #0 1920x1200 59.95 1920 1968 2000 2080 1200 1203 1209 1235 154000 flags: phsync, nvsync; type: preferred, driver
>     96  0       disconnected    VGA-1           0x0             0       97
>
>     $ ./modetest -s 85:1920x1080 -s 93:1920x1200 -s 87:1680x1050  -C
>     trying to open device 'i915'...failed
>     trying to open device 'amdgpu'...failed
>     trying to open device 'radeon'...failed
>     trying to open device 'nouveau'...done
>     setting mode 1920x1080-60.01Hz on connectors 85, crtc 50
>     starting cursor
>
>     cursor stopped
>
> This is the change on top of 1225171b (master):
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index fc75383a..cdba7b4e 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -1730,14 +1730,14 @@ static void set_cursors(struct device *dev, struct pipe_arg *pipes, unsigned int
>         int ret;
>
>         /* maybe make cursor width/height configurable some day */
> -       uint32_t cw = 64;
> -       uint32_t ch = 64;
> +       uint32_t cw = 256;
> +       uint32_t ch = 256;
>
>         /* create cursor bo.. just using PATTERN_PLAIN as it has
>          * translucent alpha
>          */
>         bo = bo_create(dev->fd, DRM_FORMAT_ARGB8888, cw, ch, handles, pitches,
> -                      offsets, UTIL_PATTERN_PLAIN);
> +                      offsets, UTIL_PATTERN_SMPTE);
>         if (bo == NULL)
>                 return;
>
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Alex Riesen]

Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> On Wed, Feb 24, 2021 at 4:09 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> > Ilia Mirkin, Tue, Feb 23, 2021 19:13:59 +0100:
> > > It might also be worthwhile just testing if the 256x256 cursor works
> > > quite the way one would want. If you're interested, grab libdrm,
> > > there's a test called 'modetest', which has an option to enable a
> > > moving cursor (-c iirc). It's hard-coded to 64x64, so you'll have to
> > > modify it there too (and probably change the pattern from plain gray
> > > to any one of the other ones).
> >
> > I am interested, so I did.
> >
> > If I start the test without X running, the sprite of 256x256 cursor always
> > contained horizontal lines across it, both with commit reverted and vanilla
> > v5.11. Similarly, the 64x64 cursor has no lines across it in both kernels.
> >
> > The test does not seem to work at all if there is an X server running (using
> > modesetting driver): modetest complained about permission denied to set the
> > mode, and just sits there, drawing nothing on the displays.
> > So I could not run the test in the environment of original problem.
> > Am I starting it correctly? Is the change in modetest.c correct?
> 
> Looks right. Although TBH I'd just start it on a single display (I
> forgot you could even do multiple displays). You should be able to
> start it with the X server running if you switch to a vt (and run it
> as root). If you can't, that means the modesetting driver is
> forgetting to do something in the LeaveVT function.

Tried that and yes, modetest works. Even without running it as root.

> The fact that you're getting lines with modetest means there's
> something wrong with 256x256. What if you do 128x128 -- does that work
> OK?

Yes. Unfortunately in both cases.

> Simon, you tested on a GK208, that has a slightly later display
> controller than the GK104 -- can you try to reproduce Alex's results?
> Perhaps there was a problem with the GK10x's and it starts working OK
> with the GK110 disp.
> 
> I don't have any GK10x's in my posession (I have nearly every other
> iteration of the display controller), but hopefully someone on the
> nouveau team will be able to dig one up and reproduce.
> 
> Thanks for testing, Alex!

You're welcome! As I'm stuck with this particular machine for foreseeable
future, you can count on mine GK10x as well.

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Wed, Feb 24, 2021 at 11:35 AM Alex Riesen
<alexander.riesen@cetitec.com> wrote:
> Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> > The fact that you're getting lines with modetest means there's
> > something wrong with 256x256. What if you do 128x128 -- does that work
> > OK?
>
> Yes. Unfortunately in both cases.

Just to be crystal clear -- are you saying that 128x128 works or does
not work? (You said "yes", which would imply it works OK, but then you
said both cases, which would imply doesn't work since 256x256 doesn't
work?)

Thanks,

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Alex Riesen]

Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> On Wed, Feb 24, 2021 at 11:35 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> > Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> > > The fact that you're getting lines with modetest means there's
> > > something wrong with 256x256. What if you do 128x128 -- does that work
> > > OK?
> >
> > Yes. Unfortunately in both cases.
> 
> Just to be crystal clear -- are you saying that 128x128 works or does
> not work? (You said "yes", which would imply it works OK, but then you
> said both cases, which would imply doesn't work since 256x256 doesn't
> work?)

Modetest with 128x128 cursor works. Without damage to the cursor: modetest
shows normal cursor in vanilla v5.11. Modetest also shows normal cursor in
vanilla v5.11 with the commit reverted.

Which is unfortunate, as the only way to see the damaged cursor is to start
the X environment with modesetting DDX driver.

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen
<alexander.riesen@cetitec.com> wrote:
>
> Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> > On Wed, Feb 24, 2021 at 11:35 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> > > Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> > > > The fact that you're getting lines with modetest means there's
> > > > something wrong with 256x256. What if you do 128x128 -- does that work
> > > > OK?
> > >
> > > Yes. Unfortunately in both cases.
> >
> > Just to be crystal clear -- are you saying that 128x128 works or does
> > not work? (You said "yes", which would imply it works OK, but then you
> > said both cases, which would imply doesn't work since 256x256 doesn't
> > work?)
>
> Modetest with 128x128 cursor works. Without damage to the cursor: modetest
> shows normal cursor in vanilla v5.11. Modetest also shows normal cursor in
> vanilla v5.11 with the commit reverted.

But modetest with 256x256 doesn't work (correctly) right? Or did I
misunderstand?

All the patch does is allow those large cursors to be used, which gets
reported via drm APIs and modesetting picks the largest cursor
available. (And actually I think it's even not required to use the
large cursors, it just controls what's reported in the defaults to
userspace.)

Thanks,

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Alex Riesen]

Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100:
> On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> > Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> > > Just to be crystal clear -- are you saying that 128x128 works or does
> > > not work? (You said "yes", which would imply it works OK, but then you
> > > said both cases, which would imply doesn't work since 256x256 doesn't
> > > work?)
> >
> > Modetest with 128x128 cursor works. Without damage to the cursor: modetest
> > shows normal cursor in vanilla v5.11. Modetest also shows normal cursor in
> > vanilla v5.11 with the commit reverted.
> 
> But modetest with 256x256 doesn't work (correctly) right? Or did I
> misunderstand?

Right. That's why I was asking if I did everything right: it was just corrupted
in both kernels.

> All the patch does is allow those large cursors to be used, which gets
> reported via drm APIs and modesetting picks the largest cursor
> available. (And actually I think it's even not required to use the
> large cursors, it just controls what's reported in the defaults to
> userspace.)

Maybe something in X code is not prepared to handle the kernel reporting
large cursor support? Even though 128x128 is pretty large, and I don't think
I even use that large cursors in X configuration. How can I check?

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Wed, Feb 24, 2021 at 12:03 PM Alex Riesen
<alexander.riesen@cetitec.com> wrote:
>
> Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100:
> > On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> > > Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> > > > Just to be crystal clear -- are you saying that 128x128 works or does
> > > > not work? (You said "yes", which would imply it works OK, but then you
> > > > said both cases, which would imply doesn't work since 256x256 doesn't
> > > > work?)
> > >
> > > Modetest with 128x128 cursor works. Without damage to the cursor: modetest
> > > shows normal cursor in vanilla v5.11. Modetest also shows normal cursor in
> > > vanilla v5.11 with the commit reverted.
> >
> > But modetest with 256x256 doesn't work (correctly) right? Or did I
> > misunderstand?
>
> Right. That's why I was asking if I did everything right: it was just corrupted
> in both kernels.

OK. So 128x128 works, 256x256 does not. Interesting.

>
> > All the patch does is allow those large cursors to be used, which gets
> > reported via drm APIs and modesetting picks the largest cursor
> > available. (And actually I think it's even not required to use the
> > large cursors, it just controls what's reported in the defaults to
> > userspace.)
>
> Maybe something in X code is not prepared to handle the kernel reporting
> large cursor support? Even though 128x128 is pretty large, and I don't think
> I even use that large cursors in X configuration. How can I check?

Yes, 64x64 is enough for anyone (or was it 640kb?) But it's unlikely
to be an issue. I believe that AMD also exposes 256x256 cursors
depending on the gen:

display/dc/dce100/dce100_resource.c:    dc->caps.max_cursor_size = 128;
display/dc/dce110/dce110_resource.c:    dc->caps.max_cursor_size = 128;
display/dc/dce112/dce112_resource.c:    dc->caps.max_cursor_size = 128;
display/dc/dce120/dce120_resource.c:    dc->caps.max_cursor_size = 128;
display/dc/dce60/dce60_resource.c:      dc->caps.max_cursor_size = 64;
display/dc/dce60/dce60_resource.c:      dc->caps.max_cursor_size = 64;
display/dc/dce60/dce60_resource.c:      dc->caps.max_cursor_size = 64;
display/dc/dce80/dce80_resource.c:      dc->caps.max_cursor_size = 128;
display/dc/dce80/dce80_resource.c:      dc->caps.max_cursor_size = 128;
display/dc/dce80/dce80_resource.c:      dc->caps.max_cursor_size = 128;
display/dc/dcn10/dcn10_resource.c:      dc->caps.max_cursor_size = 256;
display/dc/dcn20/dcn20_resource.c:      dc->caps.max_cursor_size = 256;
display/dc/dcn21/dcn21_resource.c:      dc->caps.max_cursor_size = 256;
display/dc/dcn30/dcn30_resource.c:      dc->caps.max_cursor_size = 256;

which should have the equivalent effect.

But since you're seeing issues with modetest as well (which uses the
ioctl's pretty directly), presumably Xorg is not to blame.

It's easy enough to adjust the kernel to report a lower size (and
reject the larger cursors), I just want to understand which gens are
affected by this.

Cheers,

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Uwe Sauter]

Hi Ilia,

Am 24.02.21 um 18:47 schrieb Ilia Mirkin:
> On Wed, Feb 24, 2021 at 12:03 PM Alex Riesen
> <alexander.riesen@cetitec.com> wrote:
>>
>> Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100:
>>> On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
>>>> Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
>>>>> Just to be crystal clear -- are you saying that 128x128 works or does
>>>>> not work? (You said "yes", which would imply it works OK, but then you
>>>>> said both cases, which would imply doesn't work since 256x256 doesn't
>>>>> work?)
>>>>
>>>> Modetest with 128x128 cursor works. Without damage to the cursor: modetest
>>>> shows normal cursor in vanilla v5.11. Modetest also shows normal cursor in
>>>> vanilla v5.11 with the commit reverted.
>>>
>>> But modetest with 256x256 doesn't work (correctly) right? Or did I
>>> misunderstand?
>>
>> Right. That's why I was asking if I did everything right: it was just corrupted
>> in both kernels.
> 
> OK. So 128x128 works, 256x256 does not. Interesting.
> 
>>
>>> All the patch does is allow those large cursors to be used, which gets
>>> reported via drm APIs and modesetting picks the largest cursor
>>> available. (And actually I think it's even not required to use the
>>> large cursors, it just controls what's reported in the defaults to
>>> userspace.)
>>
>> Maybe something in X code is not prepared to handle the kernel reporting
>> large cursor support? Even though 128x128 is pretty large, and I don't think
>> I even use that large cursors in X configuration. How can I check?
> 
> Yes, 64x64 is enough for anyone (or was it 640kb?) But it's unlikely
> to be an issue. I believe that AMD also exposes 256x256 cursors
> depending on the gen:
> 
> display/dc/dce100/dce100_resource.c:    dc->caps.max_cursor_size = 128;
> display/dc/dce110/dce110_resource.c:    dc->caps.max_cursor_size = 128;
> display/dc/dce112/dce112_resource.c:    dc->caps.max_cursor_size = 128;
> display/dc/dce120/dce120_resource.c:    dc->caps.max_cursor_size = 128;
> display/dc/dce60/dce60_resource.c:      dc->caps.max_cursor_size = 64;
> display/dc/dce60/dce60_resource.c:      dc->caps.max_cursor_size = 64;
> display/dc/dce60/dce60_resource.c:      dc->caps.max_cursor_size = 64;
> display/dc/dce80/dce80_resource.c:      dc->caps.max_cursor_size = 128;
> display/dc/dce80/dce80_resource.c:      dc->caps.max_cursor_size = 128;
> display/dc/dce80/dce80_resource.c:      dc->caps.max_cursor_size = 128;
> display/dc/dcn10/dcn10_resource.c:      dc->caps.max_cursor_size = 256;
> display/dc/dcn20/dcn20_resource.c:      dc->caps.max_cursor_size = 256;
> display/dc/dcn21/dcn21_resource.c:      dc->caps.max_cursor_size = 256;
> display/dc/dcn30/dcn30_resource.c:      dc->caps.max_cursor_size = 256;
> 
> which should have the equivalent effect.
> 
> But since you're seeing issues with modetest as well (which uses the
> ioctl's pretty directly), presumably Xorg is not to blame.
> 
> It's easy enough to adjust the kernel to report a lower size (and
> reject the larger cursors), I just want to understand which gens are
> affected by this.

I can also report that the modesetting ddx that comes with xorg-server 1.20.10-3 (Arch Linux package) shows this kind of 
cursor-cut-into-horizontal-stripes behavior. Changing to xf86-video-nouveau 1.0.17-1 solves this issue. But nouveau has 
issues with Mate 1.24 (as discussed earlier this month).

My hardware:
# lspci -s 3:0.0 -v
03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5
	Flags: bus master, fast devsel, latency 0, IRQ 36, IOMMU group 12
	Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
	Memory at fff0000000 (64-bit, prefetchable) [size=128M]
	Memory at fff8000000 (64-bit, prefetchable) [size=32M]
	I/O ports at f000 [size=128]
	Expansion ROM at fc000000 [disabled] [size=512K]
	Capabilities: [60] Power Management version 3
	Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [78] Express Legacy Endpoint, MSI 00
	Capabilities: [100] Virtual Channel
	Capabilities: [128] Power Budgeting <?>
	Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
	Capabilities: [900] Secondary PCI Express
	Kernel driver in use: nouveau
	Kernel modules: nouveau


If I can help in any way please let me know.

Regards,

	Uwe




> Cheers,
> 
>    -ilia
> _______________________________________________
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
> 
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Sat, Feb 27, 2021 at 7:28 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
>
> Hi Ilia,
>
> Am 24.02.21 um 18:47 schrieb Ilia Mirkin:
> > On Wed, Feb 24, 2021 at 12:03 PM Alex Riesen
> > <alexander.riesen@cetitec.com> wrote:
> >>
> >> Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100:
> >>> On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> >>>> Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> >>>>> Just to be crystal clear -- are you saying that 128x128 works or does
> >>>>> not work? (You said "yes", which would imply it works OK, but then you
> >>>>> said both cases, which would imply doesn't work since 256x256 doesn't
> >>>>> work?)
> >>>>
> >>>> Modetest with 128x128 cursor works. Without damage to the cursor: modetest
> >>>> shows normal cursor in vanilla v5.11. Modetest also shows normal cursor in
> >>>> vanilla v5.11 with the commit reverted.
> >>>
> >>> But modetest with 256x256 doesn't work (correctly) right? Or did I
> >>> misunderstand?
> >>
> >> Right. That's why I was asking if I did everything right: it was just corrupted
> >> in both kernels.
> >
> > OK. So 128x128 works, 256x256 does not. Interesting.
> >
> >>
> >>> All the patch does is allow those large cursors to be used, which gets
> >>> reported via drm APIs and modesetting picks the largest cursor
> >>> available. (And actually I think it's even not required to use the
> >>> large cursors, it just controls what's reported in the defaults to
> >>> userspace.)
> >>
> >> Maybe something in X code is not prepared to handle the kernel reporting
> >> large cursor support? Even though 128x128 is pretty large, and I don't think
> >> I even use that large cursors in X configuration. How can I check?
> >
> > Yes, 64x64 is enough for anyone (or was it 640kb?) But it's unlikely
> > to be an issue. I believe that AMD also exposes 256x256 cursors
> > depending on the gen:
> >
> > display/dc/dce100/dce100_resource.c:    dc->caps.max_cursor_size = 128;
> > display/dc/dce110/dce110_resource.c:    dc->caps.max_cursor_size = 128;
> > display/dc/dce112/dce112_resource.c:    dc->caps.max_cursor_size = 128;
> > display/dc/dce120/dce120_resource.c:    dc->caps.max_cursor_size = 128;
> > display/dc/dce60/dce60_resource.c:      dc->caps.max_cursor_size = 64;
> > display/dc/dce60/dce60_resource.c:      dc->caps.max_cursor_size = 64;
> > display/dc/dce60/dce60_resource.c:      dc->caps.max_cursor_size = 64;
> > display/dc/dce80/dce80_resource.c:      dc->caps.max_cursor_size = 128;
> > display/dc/dce80/dce80_resource.c:      dc->caps.max_cursor_size = 128;
> > display/dc/dce80/dce80_resource.c:      dc->caps.max_cursor_size = 128;
> > display/dc/dcn10/dcn10_resource.c:      dc->caps.max_cursor_size = 256;
> > display/dc/dcn20/dcn20_resource.c:      dc->caps.max_cursor_size = 256;
> > display/dc/dcn21/dcn21_resource.c:      dc->caps.max_cursor_size = 256;
> > display/dc/dcn30/dcn30_resource.c:      dc->caps.max_cursor_size = 256;
> >
> > which should have the equivalent effect.
> >
> > But since you're seeing issues with modetest as well (which uses the
> > ioctl's pretty directly), presumably Xorg is not to blame.
> >
> > It's easy enough to adjust the kernel to report a lower size (and
> > reject the larger cursors), I just want to understand which gens are
> > affected by this.
>
> I can also report that the modesetting ddx that comes with xorg-server 1.20.10-3 (Arch Linux package) shows this kind of
> cursor-cut-into-horizontal-stripes behavior. Changing to xf86-video-nouveau 1.0.17-1 solves this issue. But nouveau has
> issues with Mate 1.24 (as discussed earlier this month).
>
> My hardware:
> # lspci -s 3:0.0 -v
> 03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) (prog-if 00 [VGA controller])
>         Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5
>         Flags: bus master, fast devsel, latency 0, IRQ 36, IOMMU group 12
>         Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
>         Memory at fff0000000 (64-bit, prefetchable) [size=128M]
>         Memory at fff8000000 (64-bit, prefetchable) [size=32M]
>         I/O ports at f000 [size=128]
>         Expansion ROM at fc000000 [disabled] [size=512K]
>         Capabilities: [60] Power Management version 3
>         Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
>         Capabilities: [78] Express Legacy Endpoint, MSI 00
>         Capabilities: [100] Virtual Channel
>         Capabilities: [128] Power Budgeting <?>
>         Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
>         Capabilities: [900] Secondary PCI Express
>         Kernel driver in use: nouveau
>         Kernel modules: nouveau
>
>
> If I can help in any way please let me know.

Thanks, that's good info. Simon - you originally said that everything
looked good on your GK208, so a retest would be super.

I just double-checked on a GP108 (with an older kernel, but same idea
should apply), and it seems like 256x256 cursors are fine there.
However the display logic has gone through some ideally no-op updates
since that kernel version, but there could very easily be issues.

Can you try Alex's patch to modetest and confirm that you see issues
with modetest? If so, can you (and maybe Alex as well) try an older
kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
in question was to expose 256x256 as the 'preferred' size, but support
for the larger cursors has been around for a while.] Alex - if you
have time, same question to you.

You can find the patch here:
https://lists.x.org/archives/nouveau/2021-February/037992.html

Unfortunately I'm doing some other stuff, so it's not convenient for
me to hop to a different kernel version right now.

Cheers,

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Uwe Sauter]

Am 27.02.21 um 22:26 schrieb Ilia Mirkin:
> On Sat, Feb 27, 2021 at 7:28 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
>>
>> I can also report that the modesetting ddx that comes with xorg-server 1.20.10-3 (Arch Linux package) shows this kind of
>> cursor-cut-into-horizontal-stripes behavior. Changing to xf86-video-nouveau 1.0.17-1 solves this issue. But nouveau has
>> issues with Mate 1.24 (as discussed earlier this month).
>>
>> My hardware:
>> # lspci -s 3:0.0 -v
>> 03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) (prog-if 00 [VGA controller])
>>          Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5
>>          Flags: bus master, fast devsel, latency 0, IRQ 36, IOMMU group 12
>>          Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
>>          Memory at fff0000000 (64-bit, prefetchable) [size=128M]
>>          Memory at fff8000000 (64-bit, prefetchable) [size=32M]
>>          I/O ports at f000 [size=128]
>>          Expansion ROM at fc000000 [disabled] [size=512K]
>>          Capabilities: [60] Power Management version 3
>>          Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>          Capabilities: [78] Express Legacy Endpoint, MSI 00
>>          Capabilities: [100] Virtual Channel
>>          Capabilities: [128] Power Budgeting <?>
>>          Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
>>          Capabilities: [900] Secondary PCI Express
>>          Kernel driver in use: nouveau
>>          Kernel modules: nouveau
>>
>>
>> If I can help in any way please let me know.
> 
> Thanks, that's good info. Simon - you originally said that everything
> looked good on your GK208, so a retest would be super.
> 
> I just double-checked on a GP108 (with an older kernel, but same idea
> should apply), and it seems like 256x256 cursors are fine there.
> However the display logic has gone through some ideally no-op updates
> since that kernel version, but there could very easily be issues.
> 
> Can you try Alex's patch to modetest and confirm that you see issues
> with modetest? If so, can you (and maybe Alex as well) try an older
> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
> in question was to expose 256x256 as the 'preferred' size, but support
> for the larger cursors has been around for a while.] Alex - if you
> have time, same question to you.
> 
> You can find the patch here:
> https://lists.x.org/archives/nouveau/2021-February/037992.html

I had to install a parallel Arch Linux to my existing production system in order to keep it clean from all the 
development stuff.

System summary (most recent):
AMD Ryzen 3 3100
Gigabyte B550M S2H with BIOS F13c
Asus GT710-4H-SL-2GD5 (GK208B [GeForce GT 710] (rev a1)) using nouveau kernel module
32GB DDR4-3200MHz ECC

libdrm 2.4.104-1
linux 5.11.2.arch1-1
mesa 20.3.4-3
xf86-video-nouveau 1.0.17-1



I built libdrm 2.4.104.r16.ga9bb32cf in order to get modetest.

With unmodified kernel / modetest (cw=64, ch=64) I call:

$ ./modetest -c |grep '^[0-9]\|preferred'
85  86  connected HDMI-A-1        530x300   40  86
   #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: preferred, driver
87  0 disconnected  HDMI-A-2        0x0   0 88
89  0 disconnected  HDMI-A-3        0x0   0 90
91  0 disconnected  HDMI-A-4        0x0   0 92

./modetest -s 85:1920x1080 -C
trying to open device 'i915'...failed
trying to open device 'amdgpu'...failed
trying to open device 'radeon'...failed
trying to open device 'nouveau'...done
setting mode 1920x1080-60.00Hz on connectors 85, crtc 50
starting cursor
^C

This shows several things:
* There is a moving gray, half transparent square bouncing around. I believe that this is
   the mentioned cursor.

* The cursor movement happens at various speeds, sometimes staying half a second on the
   same position to then move quite fast to another, then slowing down.

* The cursor is flickering.

* When (forcefully) ending the test the screen is not properly reset, leaving the
   previous content in a state similar to the phenomenon with the mouse cursor that stated
   this discussion. On my FullHD display the console output is sliced horizontally and
   offset with about 1/5th of the screen width.

This also happens on my other machine with a Xeon E3-1245 v3 with integrated graphics on a ASRock C226 WS, using the 
i915 kernel module and same software versions as above.

Applying Alex' patch with (cw=128, ch=128) shows a cursor that contains the same test pattern as is shown in the 
background. The behavior is as jumpy and flickery as it was with size 64.
When killing the test the last position of the cursor still shows the test pattern while the background is again sliced 
and shuffled horizontally.

Setting the size to 256 shows an even larger cursor. It shows the same jumpy and flickery behavior as the other two. The 
cursor itself also shows a horizontal sliced in the lower half. After killing the test the cursor's last position still 
shows the test pattern while the background is sliced.

This testing was all conducted with packages from the Arch Linux distribution (but for modetest).

Questions:

1) Is this jumpy and flickery behavior expected or should the cursor move smoothly?

2) With unmodified modetest, what should the cursor look like? Without further inspection
    of the code I suspect that the change from UTIL_PATTERN_PLAIN to UTIL_PATTERN_SMPTE
    changed the cursor's appearance.

4) How long is modetest expected to run? On the first run I let it test for over 10min
    before deciding to kill it.

5) Is modetest expected to reset the display to the state it was before? Why doesn't it
    do that when being killed?

6) Where do you expect this bug to come from? Kernel nouveau driver, modesetting ddx,
    nouveau ddx?

7) Any proposal what kernel to test next?



Regards,

     Uwe

> Unfortunately I'm doing some other stuff, so it's not convenient for
> me to hop to a different kernel version right now.
> 
> Cheers,
> 
>    -ilia
> 
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Sun, Feb 28, 2021 at 10:10 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
>
>
>
> Am 27.02.21 um 22:26 schrieb Ilia Mirkin:
> > On Sat, Feb 27, 2021 at 7:28 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
> >>
> >> I can also report that the modesetting ddx that comes with xorg-server 1.20.10-3 (Arch Linux package) shows this kind of
> >> cursor-cut-into-horizontal-stripes behavior. Changing to xf86-video-nouveau 1.0.17-1 solves this issue. But nouveau has
> >> issues with Mate 1.24 (as discussed earlier this month).
> >>
> >> My hardware:
> >> # lspci -s 3:0.0 -v
> >> 03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) (prog-if 00 [VGA controller])
> >>          Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5
> >>          Flags: bus master, fast devsel, latency 0, IRQ 36, IOMMU group 12
> >>          Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
> >>          Memory at fff0000000 (64-bit, prefetchable) [size=128M]
> >>          Memory at fff8000000 (64-bit, prefetchable) [size=32M]
> >>          I/O ports at f000 [size=128]
> >>          Expansion ROM at fc000000 [disabled] [size=512K]
> >>          Capabilities: [60] Power Management version 3
> >>          Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
> >>          Capabilities: [78] Express Legacy Endpoint, MSI 00
> >>          Capabilities: [100] Virtual Channel
> >>          Capabilities: [128] Power Budgeting <?>
> >>          Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
> >>          Capabilities: [900] Secondary PCI Express
> >>          Kernel driver in use: nouveau
> >>          Kernel modules: nouveau
> >>
> >>
> >> If I can help in any way please let me know.
> >
> > Thanks, that's good info. Simon - you originally said that everything
> > looked good on your GK208, so a retest would be super.
> >
> > I just double-checked on a GP108 (with an older kernel, but same idea
> > should apply), and it seems like 256x256 cursors are fine there.
> > However the display logic has gone through some ideally no-op updates
> > since that kernel version, but there could very easily be issues.
> >
> > Can you try Alex's patch to modetest and confirm that you see issues
> > with modetest? If so, can you (and maybe Alex as well) try an older
> > kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
> > in question was to expose 256x256 as the 'preferred' size, but support
> > for the larger cursors has been around for a while.] Alex - if you
> > have time, same question to you.
> >
> > You can find the patch here:
> > https://lists.x.org/archives/nouveau/2021-February/037992.html
>
> I had to install a parallel Arch Linux to my existing production system in order to keep it clean from all the
> development stuff.
>
> System summary (most recent):
> AMD Ryzen 3 3100
> Gigabyte B550M S2H with BIOS F13c
> Asus GT710-4H-SL-2GD5 (GK208B [GeForce GT 710] (rev a1)) using nouveau kernel module
> 32GB DDR4-3200MHz ECC
>
> libdrm 2.4.104-1
> linux 5.11.2.arch1-1
> mesa 20.3.4-3
> xf86-video-nouveau 1.0.17-1
>
>
>
> I built libdrm 2.4.104.r16.ga9bb32cf in order to get modetest.
>
> With unmodified kernel / modetest (cw=64, ch=64) I call:
>
> $ ./modetest -c |grep '^[0-9]\|preferred'
> 85  86  connected HDMI-A-1        530x300   40  86
>    #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: preferred, driver
> 87  0 disconnected  HDMI-A-2        0x0   0 88
> 89  0 disconnected  HDMI-A-3        0x0   0 90
> 91  0 disconnected  HDMI-A-4        0x0   0 92
>
> ./modetest -s 85:1920x1080 -C
> trying to open device 'i915'...failed
> trying to open device 'amdgpu'...failed
> trying to open device 'radeon'...failed
> trying to open device 'nouveau'...done
> setting mode 1920x1080-60.00Hz on connectors 85, crtc 50
> starting cursor
> ^C
>
> This shows several things:
> * There is a moving gray, half transparent square bouncing around. I believe that this is
>    the mentioned cursor.
>
> * The cursor movement happens at various speeds, sometimes staying half a second on the
>    same position to then move quite fast to another, then slowing down.
>
> * The cursor is flickering.
>
> * When (forcefully) ending the test the screen is not properly reset, leaving the
>    previous content in a state similar to the phenomenon with the mouse cursor that stated
>    this discussion. On my FullHD display the console output is sliced horizontally and
>    offset with about 1/5th of the screen width.
>
> This also happens on my other machine with a Xeon E3-1245 v3 with integrated graphics on a ASRock C226 WS, using the
> i915 kernel module and same software versions as above.
>
> Applying Alex' patch with (cw=128, ch=128) shows a cursor that contains the same test pattern as is shown in the
> background. The behavior is as jumpy and flickery as it was with size 64.
> When killing the test the last position of the cursor still shows the test pattern while the background is again sliced
> and shuffled horizontally.
>
> Setting the size to 256 shows an even larger cursor. It shows the same jumpy and flickery behavior as the other two. The
> cursor itself also shows a horizontal sliced in the lower half. After killing the test the cursor's last position still
> shows the test pattern while the background is sliced.
>
> This testing was all conducted with packages from the Arch Linux distribution (but for modetest).
>
> Questions:
>
> 1) Is this jumpy and flickery behavior expected or should the cursor move smoothly?

Good question. It's definitely jumpy/flickery for me too. I haven't
looked at why, but I wouldn't worry about it. I suspect it has to do
with the mechanics of how it causes the cursor to be moved.

>
> 2) With unmodified modetest, what should the cursor look like? Without further inspection
>     of the code I suspect that the change from UTIL_PATTERN_PLAIN to UTIL_PATTERN_SMPTE
>     changed the cursor's appearance.

The PLAIN pattern is just gray, which isn't necessarily a great test
to see visual corruption.

>
> 4) How long is modetest expected to run? On the first run I let it test for over 10min
>     before deciding to kill it.

Until you hit enter (or escape or maybe any key, I forget).

>
> 5) Is modetest expected to reset the display to the state it was before? Why doesn't it
>     do that when being killed?

No. You can switch vt's back and forth to restore. It's just a test
application. It's unfortunately not an entirely trivial thing to do.

>
> 6) Where do you expect this bug to come from? Kernel nouveau driver, modesetting ddx,
>     nouveau ddx?

modetest interacts with the kernel directly. The bug is most likely in
the hardware, and we should just not use the 256x256 size even though
allegedly the hw supports it. But perhaps the kernel screws something
up.

>
> 7) Any proposal what kernel to test next?

If you could test modetest with 256x256 cursor on a pre-5.9 kernel and
ensure that you see the same corruption in the cursor image, that'd
confirm that we didn't just screw something up in the macro rework
which landed in 5.9, vs a hw issue.

Presumably the corruption you refer to in the cursor image at 256x256
is similar to what you see with Xorg + modesetting?

Thanks for your excellent testing!

Cheers,

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Uwe Sauter]

Am 28.02.21 um 18:02 schrieb Ilia Mirkin:
> On Sun, Feb 28, 2021 at 10:10 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
>>
>>
>>
>> Am 27.02.21 um 22:26 schrieb Ilia Mirkin:
>>> On Sat, Feb 27, 2021 at 7:28 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
>>>>
>>>> I can also report that the modesetting ddx that comes with xorg-server 1.20.10-3 (Arch Linux package) shows this kind of
>>>> cursor-cut-into-horizontal-stripes behavior. Changing to xf86-video-nouveau 1.0.17-1 solves this issue. But nouveau has
>>>> issues with Mate 1.24 (as discussed earlier this month).
>>>>
>>>> My hardware:
>>>> # lspci -s 3:0.0 -v
>>>> 03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) (prog-if 00 [VGA controller])
>>>>           Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5
>>>>           Flags: bus master, fast devsel, latency 0, IRQ 36, IOMMU group 12
>>>>           Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
>>>>           Memory at fff0000000 (64-bit, prefetchable) [size=128M]
>>>>           Memory at fff8000000 (64-bit, prefetchable) [size=32M]
>>>>           I/O ports at f000 [size=128]
>>>>           Expansion ROM at fc000000 [disabled] [size=512K]
>>>>           Capabilities: [60] Power Management version 3
>>>>           Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>>           Capabilities: [78] Express Legacy Endpoint, MSI 00
>>>>           Capabilities: [100] Virtual Channel
>>>>           Capabilities: [128] Power Budgeting <?>
>>>>           Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
>>>>           Capabilities: [900] Secondary PCI Express
>>>>           Kernel driver in use: nouveau
>>>>           Kernel modules: nouveau
>>>>
>>>>
>>>> If I can help in any way please let me know.
>>>
>>> Thanks, that's good info. Simon - you originally said that everything
>>> looked good on your GK208, so a retest would be super.
>>>
>>> I just double-checked on a GP108 (with an older kernel, but same idea
>>> should apply), and it seems like 256x256 cursors are fine there.
>>> However the display logic has gone through some ideally no-op updates
>>> since that kernel version, but there could very easily be issues.
>>>
>>> Can you try Alex's patch to modetest and confirm that you see issues
>>> with modetest? If so, can you (and maybe Alex as well) try an older
>>> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
>>> in question was to expose 256x256 as the 'preferred' size, but support
>>> for the larger cursors has been around for a while.] Alex - if you
>>> have time, same question to you.
>>>
>>> You can find the patch here:
>>> https://lists.x.org/archives/nouveau/2021-February/037992.html
>>
>> I had to install a parallel Arch Linux to my existing production system in order to keep it clean from all the
>> development stuff.
>>
>> System summary (most recent):
>> AMD Ryzen 3 3100
>> Gigabyte B550M S2H with BIOS F13c
>> Asus GT710-4H-SL-2GD5 (GK208B [GeForce GT 710] (rev a1)) using nouveau kernel module
>> 32GB DDR4-3200MHz ECC
>>
>> libdrm 2.4.104-1
>> linux 5.11.2.arch1-1
>> mesa 20.3.4-3
>> xf86-video-nouveau 1.0.17-1
>>
>>
>>
>> I built libdrm 2.4.104.r16.ga9bb32cf in order to get modetest.
>>
>> With unmodified kernel / modetest (cw=64, ch=64) I call:
>>
>> $ ./modetest -c |grep '^[0-9]\|preferred'
>> 85  86  connected HDMI-A-1        530x300   40  86
>>     #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: preferred, driver
>> 87  0 disconnected  HDMI-A-2        0x0   0 88
>> 89  0 disconnected  HDMI-A-3        0x0   0 90
>> 91  0 disconnected  HDMI-A-4        0x0   0 92
>>
>> ./modetest -s 85:1920x1080 -C
>> trying to open device 'i915'...failed
>> trying to open device 'amdgpu'...failed
>> trying to open device 'radeon'...failed
>> trying to open device 'nouveau'...done
>> setting mode 1920x1080-60.00Hz on connectors 85, crtc 50
>> starting cursor
>> ^C
>>
>> This shows several things:
>> * There is a moving gray, half transparent square bouncing around. I believe that this is
>>     the mentioned cursor.
>>
>> * The cursor movement happens at various speeds, sometimes staying half a second on the
>>     same position to then move quite fast to another, then slowing down.
>>
>> * The cursor is flickering.
>>
>> * When (forcefully) ending the test the screen is not properly reset, leaving the
>>     previous content in a state similar to the phenomenon with the mouse cursor that stated
>>     this discussion. On my FullHD display the console output is sliced horizontally and
>>     offset with about 1/5th of the screen width.
>>
>> This also happens on my other machine with a Xeon E3-1245 v3 with integrated graphics on a ASRock C226 WS, using the
>> i915 kernel module and same software versions as above.
>>
>> Applying Alex' patch with (cw=128, ch=128) shows a cursor that contains the same test pattern as is shown in the
>> background. The behavior is as jumpy and flickery as it was with size 64.
>> When killing the test the last position of the cursor still shows the test pattern while the background is again sliced
>> and shuffled horizontally.
>>
>> Setting the size to 256 shows an even larger cursor. It shows the same jumpy and flickery behavior as the other two. The
>> cursor itself also shows a horizontal sliced in the lower half. After killing the test the cursor's last position still
>> shows the test pattern while the background is sliced.
>>
>> This testing was all conducted with packages from the Arch Linux distribution (but for modetest).
>>
>> Questions:
>>
>> 1) Is this jumpy and flickery behavior expected or should the cursor move smoothly?
> 
> Good question. It's definitely jumpy/flickery for me too. I haven't
> looked at why, but I wouldn't worry about it. I suspect it has to do
> with the mechanics of how it causes the cursor to be moved.
> 
>>
>> 2) With unmodified modetest, what should the cursor look like? Without further inspection
>>      of the code I suspect that the change from UTIL_PATTERN_PLAIN to UTIL_PATTERN_SMPTE
>>      changed the cursor's appearance.
> 
> The PLAIN pattern is just gray, which isn't necessarily a great test
> to see visual corruption.
> 
>>
>> 4) How long is modetest expected to run? On the first run I let it test for over 10min
>>      before deciding to kill it.
> 
> Until you hit enter (or escape or maybe any key, I forget).
> 
>>
>> 5) Is modetest expected to reset the display to the state it was before? Why doesn't it
>>      do that when being killed?
> 
> No. You can switch vt's back and forth to restore. It's just a test
> application. It's unfortunately not an entirely trivial thing to do.
> 
>>
>> 6) Where do you expect this bug to come from? Kernel nouveau driver, modesetting ddx,
>>      nouveau ddx?
> 
> modetest interacts with the kernel directly. The bug is most likely in
> the hardware, and we should just not use the 256x256 size even though
> allegedly the hw supports it. But perhaps the kernel screws something
> up.
> 
>>
>> 7) Any proposal what kernel to test next?
> 
> If you could test modetest with 256x256 cursor on a pre-5.9 kernel and
> ensure that you see the same corruption in the cursor image, that'd
> confirm that we didn't just screw something up in the macro rework
> which landed in 5.9, vs a hw issue.


Ok, two more kernels tested.

5.10.19:
* modetest same as 5.11.2
* mouse pointer in X session is ok (both modesetting ddx and nouveau ddx)
* (Mate issue does appear with nouveau ddx but not with modesetting ddx)

5.4.101:
* modetest connector ID changed from 85 to 69
* other than that same as 5.11.2
* mouse pointer in X session is ok (both modesetting ddx and nouveau ddx)
* (Mate issue does appear with nouveau ddx but not with modesetting ddx)


Summary:
                   5.4.101  | 5.10.19  | 5.11.2
modetest-64       seems ok | seems ok | seems ok
modetest-128      seems ok | seems ok | seems ok
modetest-256      sliced   | sliced   | sliced
X mouse pointer   ok       | ok       | sliced
(modesetting ddx)
X mouse pointer   ok       | ok       | ok
(nouveau ddx)

Really strange that the issue only appears on 5.11 on my hardware.


> 
> Presumably the corruption you refer to in the cursor image at 256x256
> is similar to what you see with Xorg + modesetting?

In X the mouse pointer is sliced and somehow wraps in vertical direction so that
the tip of the arrow is about 1/3 from the top.

The sclicing in the modetest cursor appears in the area from about 1/2 to 3/4 from
the top of the cursor.

If it is any help I can photos.

Also, if I should test more kernels I can do that.

> 
> Thanks for your excellent testing!

You're welcome.

Regards,

	Uwe

> 
> Cheers,
> 
>    -ilia
> 
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Sun, Feb 28, 2021 at 12:59 PM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
>
>
>
> Am 28.02.21 um 18:02 schrieb Ilia Mirkin:
> > On Sun, Feb 28, 2021 at 10:10 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
> >>
> >>
> >>
> >> Am 27.02.21 um 22:26 schrieb Ilia Mirkin:
> >>> On Sat, Feb 27, 2021 at 7:28 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
> >>>>
> >>>> I can also report that the modesetting ddx that comes with xorg-server 1.20.10-3 (Arch Linux package) shows this kind of
> >>>> cursor-cut-into-horizontal-stripes behavior. Changing to xf86-video-nouveau 1.0.17-1 solves this issue. But nouveau has
> >>>> issues with Mate 1.24 (as discussed earlier this month).
> >>>>
> >>>> My hardware:
> >>>> # lspci -s 3:0.0 -v
> >>>> 03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) (prog-if 00 [VGA controller])
> >>>>           Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5
> >>>>           Flags: bus master, fast devsel, latency 0, IRQ 36, IOMMU group 12
> >>>>           Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
> >>>>           Memory at fff0000000 (64-bit, prefetchable) [size=128M]
> >>>>           Memory at fff8000000 (64-bit, prefetchable) [size=32M]
> >>>>           I/O ports at f000 [size=128]
> >>>>           Expansion ROM at fc000000 [disabled] [size=512K]
> >>>>           Capabilities: [60] Power Management version 3
> >>>>           Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
> >>>>           Capabilities: [78] Express Legacy Endpoint, MSI 00
> >>>>           Capabilities: [100] Virtual Channel
> >>>>           Capabilities: [128] Power Budgeting <?>
> >>>>           Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
> >>>>           Capabilities: [900] Secondary PCI Express
> >>>>           Kernel driver in use: nouveau
> >>>>           Kernel modules: nouveau
> >>>>
> >>>>
> >>>> If I can help in any way please let me know.
> >>>
> >>> Thanks, that's good info. Simon - you originally said that everything
> >>> looked good on your GK208, so a retest would be super.
> >>>
> >>> I just double-checked on a GP108 (with an older kernel, but same idea
> >>> should apply), and it seems like 256x256 cursors are fine there.
> >>> However the display logic has gone through some ideally no-op updates
> >>> since that kernel version, but there could very easily be issues.
> >>>
> >>> Can you try Alex's patch to modetest and confirm that you see issues
> >>> with modetest? If so, can you (and maybe Alex as well) try an older
> >>> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
> >>> in question was to expose 256x256 as the 'preferred' size, but support
> >>> for the larger cursors has been around for a while.] Alex - if you
> >>> have time, same question to you.
> >>>
> >>> You can find the patch here:
> >>> https://lists.x.org/archives/nouveau/2021-February/037992.html
> >>
> >> I had to install a parallel Arch Linux to my existing production system in order to keep it clean from all the
> >> development stuff.
> >>
> >> System summary (most recent):
> >> AMD Ryzen 3 3100
> >> Gigabyte B550M S2H with BIOS F13c
> >> Asus GT710-4H-SL-2GD5 (GK208B [GeForce GT 710] (rev a1)) using nouveau kernel module
> >> 32GB DDR4-3200MHz ECC
> >>
> >> libdrm 2.4.104-1
> >> linux 5.11.2.arch1-1
> >> mesa 20.3.4-3
> >> xf86-video-nouveau 1.0.17-1
> >>
> >>
> >>
> >> I built libdrm 2.4.104.r16.ga9bb32cf in order to get modetest.
> >>
> >> With unmodified kernel / modetest (cw=64, ch=64) I call:
> >>
> >> $ ./modetest -c |grep '^[0-9]\|preferred'
> >> 85  86  connected HDMI-A-1        530x300   40  86
> >>     #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: preferred, driver
> >> 87  0 disconnected  HDMI-A-2        0x0   0 88
> >> 89  0 disconnected  HDMI-A-3        0x0   0 90
> >> 91  0 disconnected  HDMI-A-4        0x0   0 92
> >>
> >> ./modetest -s 85:1920x1080 -C
> >> trying to open device 'i915'...failed
> >> trying to open device 'amdgpu'...failed
> >> trying to open device 'radeon'...failed
> >> trying to open device 'nouveau'...done
> >> setting mode 1920x1080-60.00Hz on connectors 85, crtc 50
> >> starting cursor
> >> ^C
> >>
> >> This shows several things:
> >> * There is a moving gray, half transparent square bouncing around. I believe that this is
> >>     the mentioned cursor.
> >>
> >> * The cursor movement happens at various speeds, sometimes staying half a second on the
> >>     same position to then move quite fast to another, then slowing down.
> >>
> >> * The cursor is flickering.
> >>
> >> * When (forcefully) ending the test the screen is not properly reset, leaving the
> >>     previous content in a state similar to the phenomenon with the mouse cursor that stated
> >>     this discussion. On my FullHD display the console output is sliced horizontally and
> >>     offset with about 1/5th of the screen width.
> >>
> >> This also happens on my other machine with a Xeon E3-1245 v3 with integrated graphics on a ASRock C226 WS, using the
> >> i915 kernel module and same software versions as above.
> >>
> >> Applying Alex' patch with (cw=128, ch=128) shows a cursor that contains the same test pattern as is shown in the
> >> background. The behavior is as jumpy and flickery as it was with size 64.
> >> When killing the test the last position of the cursor still shows the test pattern while the background is again sliced
> >> and shuffled horizontally.
> >>
> >> Setting the size to 256 shows an even larger cursor. It shows the same jumpy and flickery behavior as the other two. The
> >> cursor itself also shows a horizontal sliced in the lower half. After killing the test the cursor's last position still
> >> shows the test pattern while the background is sliced.
> >>
> >> This testing was all conducted with packages from the Arch Linux distribution (but for modetest).
> >>
> >> Questions:
> >>
> >> 1) Is this jumpy and flickery behavior expected or should the cursor move smoothly?
> >
> > Good question. It's definitely jumpy/flickery for me too. I haven't
> > looked at why, but I wouldn't worry about it. I suspect it has to do
> > with the mechanics of how it causes the cursor to be moved.
> >
> >>
> >> 2) With unmodified modetest, what should the cursor look like? Without further inspection
> >>      of the code I suspect that the change from UTIL_PATTERN_PLAIN to UTIL_PATTERN_SMPTE
> >>      changed the cursor's appearance.
> >
> > The PLAIN pattern is just gray, which isn't necessarily a great test
> > to see visual corruption.
> >
> >>
> >> 4) How long is modetest expected to run? On the first run I let it test for over 10min
> >>      before deciding to kill it.
> >
> > Until you hit enter (or escape or maybe any key, I forget).
> >
> >>
> >> 5) Is modetest expected to reset the display to the state it was before? Why doesn't it
> >>      do that when being killed?
> >
> > No. You can switch vt's back and forth to restore. It's just a test
> > application. It's unfortunately not an entirely trivial thing to do.
> >
> >>
> >> 6) Where do you expect this bug to come from? Kernel nouveau driver, modesetting ddx,
> >>      nouveau ddx?
> >
> > modetest interacts with the kernel directly. The bug is most likely in
> > the hardware, and we should just not use the 256x256 size even though
> > allegedly the hw supports it. But perhaps the kernel screws something
> > up.
> >
> >>
> >> 7) Any proposal what kernel to test next?
> >
> > If you could test modetest with 256x256 cursor on a pre-5.9 kernel and
> > ensure that you see the same corruption in the cursor image, that'd
> > confirm that we didn't just screw something up in the macro rework
> > which landed in 5.9, vs a hw issue.
>
>
> Ok, two more kernels tested.
>
> 5.10.19:
> * modetest same as 5.11.2
> * mouse pointer in X session is ok (both modesetting ddx and nouveau ddx)
> * (Mate issue does appear with nouveau ddx but not with modesetting ddx)
>
> 5.4.101:
> * modetest connector ID changed from 85 to 69
> * other than that same as 5.11.2
> * mouse pointer in X session is ok (both modesetting ddx and nouveau ddx)
> * (Mate issue does appear with nouveau ddx but not with modesetting ddx)
>
>
> Summary:
>                    5.4.101  | 5.10.19  | 5.11.2
> modetest-64       seems ok | seems ok | seems ok
> modetest-128      seems ok | seems ok | seems ok
> modetest-256      sliced   | sliced   | sliced
> X mouse pointer   ok       | ok       | sliced
> (modesetting ddx)
> X mouse pointer   ok       | ok       | ok
> (nouveau ddx)
>
> Really strange that the issue only appears on 5.11 on my hardware.
>
>
> >
> > Presumably the corruption you refer to in the cursor image at 256x256
> > is similar to what you see with Xorg + modesetting?
>
> In X the mouse pointer is sliced and somehow wraps in vertical direction so that
> the tip of the arrow is about 1/3 from the top.
>
> The sclicing in the modetest cursor appears in the area from about 1/2 to 3/4 from
> the top of the cursor.

It's probably the same corruption, just looks slightly different based
on the image. Kernel 5.11 made 256x256 cursors the default (which is
what xf86-video-modesetting uses to determine cursor size), hence the
change in behavior.

Thanks again for confirming.

So it sounds like all Kepler hardware has issues with 256x256. I've
tested on gp108 and did not observe any obvious issues. Probably good
to find a GM107 and GM200 to test on as well.

Cheers,

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Uwe Sauter]

Am 28.02.21 um 20:10 schrieb Ilia Mirkin:
> On Sun, Feb 28, 2021 at 12:59 PM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
>>
>>
>>
>> Am 28.02.21 um 18:02 schrieb Ilia Mirkin:
>>> On Sun, Feb 28, 2021 at 10:10 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> Am 27.02.21 um 22:26 schrieb Ilia Mirkin:
>>>>> On Sat, Feb 27, 2021 at 7:28 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
>>>>>>
>>>>>> I can also report that the modesetting ddx that comes with xorg-server 1.20.10-3 (Arch Linux package) shows this kind of
>>>>>> cursor-cut-into-horizontal-stripes behavior. Changing to xf86-video-nouveau 1.0.17-1 solves this issue. But nouveau has
>>>>>> issues with Mate 1.24 (as discussed earlier this month).
>>>>>>
>>>>>> My hardware:
>>>>>> # lspci -s 3:0.0 -v
>>>>>> 03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) (prog-if 00 [VGA controller])
>>>>>>            Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5
>>>>>>            Flags: bus master, fast devsel, latency 0, IRQ 36, IOMMU group 12
>>>>>>            Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
>>>>>>            Memory at fff0000000 (64-bit, prefetchable) [size=128M]
>>>>>>            Memory at fff8000000 (64-bit, prefetchable) [size=32M]
>>>>>>            I/O ports at f000 [size=128]
>>>>>>            Expansion ROM at fc000000 [disabled] [size=512K]
>>>>>>            Capabilities: [60] Power Management version 3
>>>>>>            Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>>>>            Capabilities: [78] Express Legacy Endpoint, MSI 00
>>>>>>            Capabilities: [100] Virtual Channel
>>>>>>            Capabilities: [128] Power Budgeting <?>
>>>>>>            Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
>>>>>>            Capabilities: [900] Secondary PCI Express
>>>>>>            Kernel driver in use: nouveau
>>>>>>            Kernel modules: nouveau
>>>>>>
>>>>>>
>>>>>> If I can help in any way please let me know.
>>>>>
>>>>> Thanks, that's good info. Simon - you originally said that everything
>>>>> looked good on your GK208, so a retest would be super.
>>>>>
>>>>> I just double-checked on a GP108 (with an older kernel, but same idea
>>>>> should apply), and it seems like 256x256 cursors are fine there.
>>>>> However the display logic has gone through some ideally no-op updates
>>>>> since that kernel version, but there could very easily be issues.
>>>>>
>>>>> Can you try Alex's patch to modetest and confirm that you see issues
>>>>> with modetest? If so, can you (and maybe Alex as well) try an older
>>>>> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
>>>>> in question was to expose 256x256 as the 'preferred' size, but support
>>>>> for the larger cursors has been around for a while.] Alex - if you
>>>>> have time, same question to you.
>>>>>
>>>>> You can find the patch here:
>>>>> https://lists.x.org/archives/nouveau/2021-February/037992.html
>>>>
>>>> I had to install a parallel Arch Linux to my existing production system in order to keep it clean from all the
>>>> development stuff.
>>>>
>>>> System summary (most recent):
>>>> AMD Ryzen 3 3100
>>>> Gigabyte B550M S2H with BIOS F13c
>>>> Asus GT710-4H-SL-2GD5 (GK208B [GeForce GT 710] (rev a1)) using nouveau kernel module
>>>> 32GB DDR4-3200MHz ECC
>>>>
>>>> libdrm 2.4.104-1
>>>> linux 5.11.2.arch1-1
>>>> mesa 20.3.4-3
>>>> xf86-video-nouveau 1.0.17-1
>>>>
>>>>
>>>>
>>>> I built libdrm 2.4.104.r16.ga9bb32cf in order to get modetest.
>>>>
>>>> With unmodified kernel / modetest (cw=64, ch=64) I call:
>>>>
>>>> $ ./modetest -c |grep '^[0-9]\|preferred'
>>>> 85  86  connected HDMI-A-1        530x300   40  86
>>>>      #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: preferred, driver
>>>> 87  0 disconnected  HDMI-A-2        0x0   0 88
>>>> 89  0 disconnected  HDMI-A-3        0x0   0 90
>>>> 91  0 disconnected  HDMI-A-4        0x0   0 92
>>>>
>>>> ./modetest -s 85:1920x1080 -C
>>>> trying to open device 'i915'...failed
>>>> trying to open device 'amdgpu'...failed
>>>> trying to open device 'radeon'...failed
>>>> trying to open device 'nouveau'...done
>>>> setting mode 1920x1080-60.00Hz on connectors 85, crtc 50
>>>> starting cursor
>>>> ^C
>>>>
>>>> This shows several things:
>>>> * There is a moving gray, half transparent square bouncing around. I believe that this is
>>>>      the mentioned cursor.
>>>>
>>>> * The cursor movement happens at various speeds, sometimes staying half a second on the
>>>>      same position to then move quite fast to another, then slowing down.
>>>>
>>>> * The cursor is flickering.
>>>>
>>>> * When (forcefully) ending the test the screen is not properly reset, leaving the
>>>>      previous content in a state similar to the phenomenon with the mouse cursor that stated
>>>>      this discussion. On my FullHD display the console output is sliced horizontally and
>>>>      offset with about 1/5th of the screen width.
>>>>
>>>> This also happens on my other machine with a Xeon E3-1245 v3 with integrated graphics on a ASRock C226 WS, using the
>>>> i915 kernel module and same software versions as above.
>>>>
>>>> Applying Alex' patch with (cw=128, ch=128) shows a cursor that contains the same test pattern as is shown in the
>>>> background. The behavior is as jumpy and flickery as it was with size 64.
>>>> When killing the test the last position of the cursor still shows the test pattern while the background is again sliced
>>>> and shuffled horizontally.
>>>>
>>>> Setting the size to 256 shows an even larger cursor. It shows the same jumpy and flickery behavior as the other two. The
>>>> cursor itself also shows a horizontal sliced in the lower half. After killing the test the cursor's last position still
>>>> shows the test pattern while the background is sliced.
>>>>
>>>> This testing was all conducted with packages from the Arch Linux distribution (but for modetest).
>>>>
>>>> Questions:
>>>>
>>>> 1) Is this jumpy and flickery behavior expected or should the cursor move smoothly?
>>>
>>> Good question. It's definitely jumpy/flickery for me too. I haven't
>>> looked at why, but I wouldn't worry about it. I suspect it has to do
>>> with the mechanics of how it causes the cursor to be moved.
>>>
>>>>
>>>> 2) With unmodified modetest, what should the cursor look like? Without further inspection
>>>>       of the code I suspect that the change from UTIL_PATTERN_PLAIN to UTIL_PATTERN_SMPTE
>>>>       changed the cursor's appearance.
>>>
>>> The PLAIN pattern is just gray, which isn't necessarily a great test
>>> to see visual corruption.
>>>
>>>>
>>>> 4) How long is modetest expected to run? On the first run I let it test for over 10min
>>>>       before deciding to kill it.
>>>
>>> Until you hit enter (or escape or maybe any key, I forget).
>>>
>>>>
>>>> 5) Is modetest expected to reset the display to the state it was before? Why doesn't it
>>>>       do that when being killed?
>>>
>>> No. You can switch vt's back and forth to restore. It's just a test
>>> application. It's unfortunately not an entirely trivial thing to do.
>>>
>>>>
>>>> 6) Where do you expect this bug to come from? Kernel nouveau driver, modesetting ddx,
>>>>       nouveau ddx?
>>>
>>> modetest interacts with the kernel directly. The bug is most likely in
>>> the hardware, and we should just not use the 256x256 size even though
>>> allegedly the hw supports it. But perhaps the kernel screws something
>>> up.
>>>
>>>>
>>>> 7) Any proposal what kernel to test next?
>>>
>>> If you could test modetest with 256x256 cursor on a pre-5.9 kernel and
>>> ensure that you see the same corruption in the cursor image, that'd
>>> confirm that we didn't just screw something up in the macro rework
>>> which landed in 5.9, vs a hw issue.
>>
>>
>> Ok, two more kernels tested.
>>
>> 5.10.19:
>> * modetest same as 5.11.2
>> * mouse pointer in X session is ok (both modesetting ddx and nouveau ddx)
>> * (Mate issue does appear with nouveau ddx but not with modesetting ddx)
>>
>> 5.4.101:
>> * modetest connector ID changed from 85 to 69
>> * other than that same as 5.11.2
>> * mouse pointer in X session is ok (both modesetting ddx and nouveau ddx)
>> * (Mate issue does appear with nouveau ddx but not with modesetting ddx)
>>
>>
>> Summary:
>>                     5.4.101  | 5.10.19  | 5.11.2
>> modetest-64       seems ok | seems ok | seems ok
>> modetest-128      seems ok | seems ok | seems ok
>> modetest-256      sliced   | sliced   | sliced
>> X mouse pointer   ok       | ok       | sliced
>> (modesetting ddx)
>> X mouse pointer   ok       | ok       | ok
>> (nouveau ddx)

One more data point:
Linus' vanilla kernel commit 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 (Sat Feb 27 08:29:02 2021 -0800) shows the same 
behavior.

I could try to bisect…

Regards,

	Uwe



>>
>> Really strange that the issue only appears on 5.11 on my hardware.
>>
>>
>>>
>>> Presumably the corruption you refer to in the cursor image at 256x256
>>> is similar to what you see with Xorg + modesetting?
>>
>> In X the mouse pointer is sliced and somehow wraps in vertical direction so that
>> the tip of the arrow is about 1/3 from the top.
>>
>> The sclicing in the modetest cursor appears in the area from about 1/2 to 3/4 from
>> the top of the cursor.
> 
> It's probably the same corruption, just looks slightly different based
> on the image. Kernel 5.11 made 256x256 cursors the default (which is
> what xf86-video-modesetting uses to determine cursor size), hence the
> change in behavior.
> 
> Thanks again for confirming.
> 
> So it sounds like all Kepler hardware has issues with 256x256. I've
> tested on gp108 and did not observe any obvious issues. Probably good
> to find a GM107 and GM200 to test on as well.
> 
> Cheers,
> 
>    -ilia
> 
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Sun, Feb 28, 2021 at 2:24 PM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
> >> Summary:
> >>                     5.4.101  | 5.10.19  | 5.11.2
> >> modetest-64       seems ok | seems ok | seems ok
> >> modetest-128      seems ok | seems ok | seems ok
> >> modetest-256      sliced   | sliced   | sliced
> >> X mouse pointer   ok       | ok       | sliced
> >> (modesetting ddx)
> >> X mouse pointer   ok       | ok       | ok
> >> (nouveau ddx)
>
> One more data point:
> Linus' vanilla kernel commit 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 (Sat Feb 27 08:29:02 2021 -0800) shows the same
> behavior.
>
> I could try to bisect…

There's nothing to bisect. The issue is exposed by advertising 256x256
cursors by default. But older kernels supported 256x256 cursors as
well, which is why modetest was a good test for it. modesetting ddx
takes the "default" cursor size.

It's just a matter of figuring out which hardware has the problem.

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Alex Riesen]

Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100:
> Can you try Alex's patch to modetest and confirm that you see issues
> with modetest? If so, can you (and maybe Alex as well) try an older
> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
> in question was to expose 256x256 as the 'preferred' size, but support
> for the larger cursors has been around for a while.] Alex - if you
> have time, same question to you.

Sorry that it took so long. I retestet with the same kernel as Uwe did
(5.4.101) and my results are the same: modetest with 64 and 128 cursors looks
good, 256 broken. Didn't test with X this time (this being my main office
machine), but can do later if required.

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
>
> Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100:
> > Can you try Alex's patch to modetest and confirm that you see issues
> > with modetest? If so, can you (and maybe Alex as well) try an older
> > kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
> > in question was to expose 256x256 as the 'preferred' size, but support
> > for the larger cursors has been around for a while.] Alex - if you
> > have time, same question to you.
>
> Sorry that it took so long. I retestet with the same kernel as Uwe did
> (5.4.101) and my results are the same: modetest with 64 and 128 cursors looks
> good, 256 broken. Didn't test with X this time (this being my main office
> machine), but can do later if required.

Thanks for confirming! No need to test X - that will work fine, since
we were reporting the smaller cursors on that kernel.

So I think we have definitive evidence that at least all Kepler
doesn't do 256x256 (and it's not just some bug in the display macro
rework that got introduced). And unless I'm blind and don't see the
corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs.
Unless someone has immediate plans to test on those, I'd recommend
bumping the minimum for 256x256 being reported to Pascal, and doing
128x128 for Kepler / Maxwell.

Simon, Lyude -- thoughts?

Cheers,

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Uwe Sauter]

Am 03.03.21 um 14:12 schrieb Ilia Mirkin:
> On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
>>
>> Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100:
>>> Can you try Alex's patch to modetest and confirm that you see issues
>>> with modetest? If so, can you (and maybe Alex as well) try an older
>>> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
>>> in question was to expose 256x256 as the 'preferred' size, but support
>>> for the larger cursors has been around for a while.] Alex - if you
>>> have time, same question to you.
>>
>> Sorry that it took so long. I retestet with the same kernel as Uwe did
>> (5.4.101) and my results are the same: modetest with 64 and 128 cursors looks
>> good, 256 broken. Didn't test with X this time (this being my main office
>> machine), but can do later if required.
> 
> Thanks for confirming! No need to test X - that will work fine, since
> we were reporting the smaller cursors on that kernel.
> 
> So I think we have definitive evidence that at least all Kepler
> doesn't do 256x256 (and it's not just some bug in the display macro
> rework that got introduced). And unless I'm blind and don't see the
> corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs.
> Unless someone has immediate plans to test on those, I'd recommend
> bumping the minimum for 256x256 being reported to Pascal, and doing
> 128x128 for Kepler / Maxwell.

The only older model I have access to would be a 6600GT (NV43). Don't know if this would have any
significance…

	Uwe


> Simon, Lyude -- thoughts?
> 
> Cheers,
> 
>   -ilia
> 

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Wed, Mar 3, 2021 at 8:25 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
>
> Am 03.03.21 um 14:12 schrieb Ilia Mirkin:
> > On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
> >>
> >> Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100:
> >>> Can you try Alex's patch to modetest and confirm that you see issues
> >>> with modetest? If so, can you (and maybe Alex as well) try an older
> >>> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
> >>> in question was to expose 256x256 as the 'preferred' size, but support
> >>> for the larger cursors has been around for a while.] Alex - if you
> >>> have time, same question to you.
> >>
> >> Sorry that it took so long. I retestet with the same kernel as Uwe did
> >> (5.4.101) and my results are the same: modetest with 64 and 128 cursors looks
> >> good, 256 broken. Didn't test with X this time (this being my main office
> >> machine), but can do later if required.
> >
> > Thanks for confirming! No need to test X - that will work fine, since
> > we were reporting the smaller cursors on that kernel.
> >
> > So I think we have definitive evidence that at least all Kepler
> > doesn't do 256x256 (and it's not just some bug in the display macro
> > rework that got introduced). And unless I'm blind and don't see the
> > corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs.
> > Unless someone has immediate plans to test on those, I'd recommend
> > bumping the minimum for 256x256 being reported to Pascal, and doing
> > 128x128 for Kepler / Maxwell.
>
> The only older model I have access to would be a 6600GT (NV43). Don't know if this would have any
> significance…

Nope, we want newer :) Maxwell came after Kepler. GTX 750 for Maxwell
1, and GTX 9xx for Maxwell 2. (GM10x and GM20x).

Cheers,

  -ilia
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Lyude Paul]

On Wed, 2021-03-03 at 08:12 -0500, Ilia Mirkin wrote:
> On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen <alexander.riesen@cetitec.com>
> wrote:
> > 
> > Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100:
> > > Can you try Alex's patch to modetest and confirm that you see issues
> > > with modetest? If so, can you (and maybe Alex as well) try an older
> > > kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
> > > in question was to expose 256x256 as the 'preferred' size, but support
> > > for the larger cursors has been around for a while.] Alex - if you
> > > have time, same question to you.
> > 
> > Sorry that it took so long. I retestet with the same kernel as Uwe did
> > (5.4.101) and my results are the same: modetest with 64 and 128 cursors
> > looks
> > good, 256 broken. Didn't test with X this time (this being my main office
> > machine), but can do later if required.
> 
> Thanks for confirming! No need to test X - that will work fine, since
> we were reporting the smaller cursors on that kernel.
> 
> So I think we have definitive evidence that at least all Kepler
> doesn't do 256x256 (and it's not just some bug in the display macro
> rework that got introduced). And unless I'm blind and don't see the
> corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs.
> Unless someone has immediate plans to test on those, I'd recommend
> bumping the minimum for 256x256 being reported to Pascal, and doing
> 128x128 for Kepler / Maxwell.

I'm fairly sure this will actually work fine on maxwell, I think Kepler is the
only one I'm aware of so far that has issues with this. I've got one of each gen
from kepler 1 up to ampere, so I'll try to find some today to test the cards
I've got and see where the support cutoff for this is and then submit a patch
for the time being.

It's also really strange to me that this would be present in the display classes
yet not be supported on the GPU, since there definitely aren't any capabilities
for this. I'll also send an email to Andy and see if he might know what's going
on here.
> 
> Simon, Lyude -- thoughts?
> 
> Cheers,
> 
>   -ilia
> 

-- 
Sincerely,
   Lyude Paul (she/her)
   Software Engineer at Red Hat
   
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Uwe Sauter]

Am 03.03.21 um 14:33 schrieb Ilia Mirkin:
> On Wed, Mar 3, 2021 at 8:25 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
>>
>> Am 03.03.21 um 14:12 schrieb Ilia Mirkin:
>>> On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen <alexander.riesen@cetitec.com> wrote:
>>>>
>>>> Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100:
>>>>> Can you try Alex's patch to modetest and confirm that you see issues
>>>>> with modetest? If so, can you (and maybe Alex as well) try an older
>>>>> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
>>>>> in question was to expose 256x256 as the 'preferred' size, but support
>>>>> for the larger cursors has been around for a while.] Alex - if you
>>>>> have time, same question to you.
>>>>
>>>> Sorry that it took so long. I retestet with the same kernel as Uwe did
>>>> (5.4.101) and my results are the same: modetest with 64 and 128 cursors looks
>>>> good, 256 broken. Didn't test with X this time (this being my main office
>>>> machine), but can do later if required.
>>>
>>> Thanks for confirming! No need to test X - that will work fine, since
>>> we were reporting the smaller cursors on that kernel.
>>>
>>> So I think we have definitive evidence that at least all Kepler
>>> doesn't do 256x256 (and it's not just some bug in the display macro
>>> rework that got introduced). And unless I'm blind and don't see the
>>> corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs.
>>> Unless someone has immediate plans to test on those, I'd recommend
>>> bumping the minimum for 256x256 being reported to Pascal, and doing
>>> 128x128 for Kepler / Maxwell.
>>
>> The only older model I have access to would be a 6600GT (NV43). Don't know if this would have any
>> significance…
> 
> Nope, we want newer :) Maxwell came after Kepler. GTX 750 for Maxwell
> 1, and GTX 9xx for Maxwell 2. (GM10x and GM20x).

I managed to get access to two much newer cards, RTK 1070 and the like.

Should I test these or is it not necessary?

Regards,

	Uwe


> Cheers,
> 
>   -ilia
> 

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[James Jones]

On 3/3/21 8:51 AM, Lyude Paul wrote:
> On Wed, 2021-03-03 at 08:12 -0500, Ilia Mirkin wrote:
>> On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen <alexander.riesen@cetitec.com>
>> wrote:
>>>
>>> Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100:
>>>> Can you try Alex's patch to modetest and confirm that you see issues
>>>> with modetest? If so, can you (and maybe Alex as well) try an older
>>>> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
>>>> in question was to expose 256x256 as the 'preferred' size, but support
>>>> for the larger cursors has been around for a while.] Alex - if you
>>>> have time, same question to you.
>>>
>>> Sorry that it took so long. I retestet with the same kernel as Uwe did
>>> (5.4.101) and my results are the same: modetest with 64 and 128 cursors
>>> looks
>>> good, 256 broken. Didn't test with X this time (this being my main office
>>> machine), but can do later if required.
>>
>> Thanks for confirming! No need to test X - that will work fine, since
>> we were reporting the smaller cursors on that kernel.
>>
>> So I think we have definitive evidence that at least all Kepler
>> doesn't do 256x256 (and it's not just some bug in the display macro
>> rework that got introduced). And unless I'm blind and don't see the
>> corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs.
>> Unless someone has immediate plans to test on those, I'd recommend
>> bumping the minimum for 256x256 being reported to Pascal, and doing
>> 128x128 for Kepler / Maxwell.
> 
> I'm fairly sure this will actually work fine on maxwell, I think Kepler is the
> only one I'm aware of so far that has issues with this. I've got one of each gen
> from kepler 1 up to ampere, so I'll try to find some today to test the cards
> I've got and see where the support cutoff for this is and then submit a patch
> for the time being.
> 
> It's also really strange to me that this would be present in the display classes
> yet not be supported on the GPU, since there definitely aren't any capabilities
> for this. I'll also send an email to Andy and see if he might know what's going
> on here.

FWIW, it's not my area, but I've been following, and forwarded this 
thread around internally.  We discussed a bit, and Kepler definitely 
supports 256x256 cursors. One suggestion was if you aren't already, try 
using 4k pages. The rest was a bit beyond me, so I'll let Andy and Lyude 
discuss further if needed.

Thanks,
-James

>> Simon, Lyude -- thoughts?
>>
>> Cheers,
>>
>>    -ilia
>>
> 
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Lyude Paul]

On Wed, 2021-03-03 at 18:02 +0100, Uwe Sauter wrote:
> Am 03.03.21 um 14:33 schrieb Ilia Mirkin:
> > On Wed, Mar 3, 2021 at 8:25 AM Uwe Sauter <uwe.sauter.de@gmail.com> wrote:
> > > 
> > > Am 03.03.21 um 14:12 schrieb Ilia Mirkin:
> > > > On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen
> > > > <alexander.riesen@cetitec.com> wrote:
> > > > > 
> > > > > Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100:
> > > > > > Can you try Alex's patch to modetest and confirm that you see issues
> > > > > > with modetest? If so, can you (and maybe Alex as well) try an older
> > > > > > kernel (I'm on 5.6) and see if modetest behaves well there. [The
> > > > > > patch
> > > > > > in question was to expose 256x256 as the 'preferred' size, but
> > > > > > support
> > > > > > for the larger cursors has been around for a while.] Alex - if you
> > > > > > have time, same question to you.
> > > > > 
> > > > > Sorry that it took so long. I retestet with the same kernel as Uwe did
> > > > > (5.4.101) and my results are the same: modetest with 64 and 128
> > > > > cursors looks
> > > > > good, 256 broken. Didn't test with X this time (this being my main
> > > > > office
> > > > > machine), but can do later if required.
> > > > 
> > > > Thanks for confirming! No need to test X - that will work fine, since
> > > > we were reporting the smaller cursors on that kernel.
> > > > 
> > > > So I think we have definitive evidence that at least all Kepler
> > > > doesn't do 256x256 (and it's not just some bug in the display macro
> > > > rework that got introduced). And unless I'm blind and don't see the
> > > > corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs.
> > > > Unless someone has immediate plans to test on those, I'd recommend
> > > > bumping the minimum for 256x256 being reported to Pascal, and doing
> > > > 128x128 for Kepler / Maxwell.
> > > 
> > > The only older model I have access to would be a 6600GT (NV43). Don't know
> > > if this would have any
> > > significance…
> > 
> > Nope, we want newer :) Maxwell came after Kepler. GTX 750 for Maxwell
> > 1, and GTX 9xx for Maxwell 2. (GM10x and GM20x).
> 
> I managed to get access to two much newer cards, RTK 1070 and the like.
> 
> Should I test these or is it not necessary?
Nah, everything volta+ is a completely different ballgame. Anyway, I don't think
we need more testing here anyhow, I just need to try what James Jones suggested
and if that doesn't work, write up a patch to limit the cursor size until we
figure out a proper solution for this.

> 
> Regards,
> 
>         Uwe
> 
> 
> > Cheers,
> > 
> >   -ilia
> > 
> 

-- 
Sincerely,
   Lyude Paul (she/her)
   Software Engineer at Red Hat
   
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau