Nouveau Archive on lore.kernel.org
 help / color / Atom feed
From: Uwe Sauter <uwe.sauter.de@gmail.com>
To: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Alex Riesen <alexander.riesen@cetitec.com>,
	nouveau <nouveau@lists.freedesktop.org>,
	Simon Ser <contact@emersion.fr>
Subject: Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace
Date: Sun, 28 Feb 2021 18:59:50 +0100
Message-ID: <a4b52255-5b09-4eaa-8a35-81c1c062b462@gmail.com> (raw)
In-Reply-To: <CAKb7UvjYcrqzbyRCZDcO=hA3R4pF2hzEdjqMHgRGuYQPYSqKmQ@mail.gmail.com>



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

  reply index

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19  1:54 [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes Lyude Paul
     [not found] ` <20210119015415.2511028-1-lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2021-01-19  1:54   ` [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace Lyude Paul
     [not found]     ` <20210119015415.2511028-2-lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2021-01-19 10:22       ` Simon Ser
2021-02-23 14:15     ` [Nouveau] " Alex Riesen
2021-02-23 14:56       ` Ilia Mirkin
2021-02-23 15:36         ` Alex Riesen
2021-02-23 15:46           ` Ilia Mirkin
2021-02-23 15:51             ` Alex Riesen
2021-02-23 16:22               ` Alex Riesen
2021-02-23 18:13                 ` Ilia Mirkin
2021-02-24  9:08                   ` Alex Riesen
2021-02-24 15:10                     ` Ilia Mirkin
2021-02-24 16:35                       ` Alex Riesen
2021-02-24 16:48                         ` Ilia Mirkin
2021-02-24 16:53                           ` Alex Riesen
2021-02-24 16:57                             ` Ilia Mirkin
2021-02-24 17:02                               ` Alex Riesen
2021-02-24 17:47                                 ` Ilia Mirkin
2021-02-27 12:28                                   ` Uwe Sauter
2021-02-27 21:26                                     ` Ilia Mirkin
2021-02-28 15:10                                       ` Uwe Sauter
2021-02-28 17:02                                         ` Ilia Mirkin
2021-02-28 17:59                                           ` Uwe Sauter [this message]
2021-02-28 19:10                                             ` Ilia Mirkin
2021-02-28 19:24                                               ` Uwe Sauter
2021-02-28 20:38                                                 ` Ilia Mirkin
2021-03-03 12:41                                       ` Alex Riesen
2021-03-03 13:12                                         ` Ilia Mirkin
2021-03-03 13:25                                           ` Uwe Sauter
2021-03-03 13:33                                             ` Ilia Mirkin
2021-03-03 17:02                                               ` Uwe Sauter
2021-03-03 17:11                                                 ` Lyude Paul
2021-03-03 16:51                                           ` Lyude Paul
2021-03-03 17:05                                             ` James Jones
2021-01-19  1:54   ` [PATCH 3/3] drm/nouveau/kms/nve4-nv138: Fix > 64x64 cursors Lyude Paul
2021-01-19 10:18   ` [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes Simon Ser
2021-01-19 15:50   ` Ville Syrjälä
2021-01-19 15:52   ` James Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4b52255-5b09-4eaa-8a35-81c1c062b462@gmail.com \
    --to=uwe.sauter.de@gmail.com \
    --cc=alexander.riesen@cetitec.com \
    --cc=contact@emersion.fr \
    --cc=imirkin@alum.mit.edu \
    --cc=nouveau@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Nouveau Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/nouveau/0 nouveau/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 nouveau nouveau/ https://lore.kernel.org/nouveau \
		nouveau@lists.freedesktop.org
	public-inbox-index nouveau

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.freedesktop.lists.nouveau


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git