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 20:24:47 +0100
Message-ID: <b7f1d101-36e5-c7ef-9b7c-5d4162a8c68b@gmail.com> (raw)
In-Reply-To: <CAKb7Uvh5T-B37yTeky7keXYZQEd8B8=sqKbQ7TsD0W83HbanWg@mail.gmail.com>



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

  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
2021-02-28 19:10                                             ` Ilia Mirkin
2021-02-28 19:24                                               ` Uwe Sauter [this message]
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=b7f1d101-36e5-c7ef-9b7c-5d4162a8c68b@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