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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

On Wed, Feb 24, 2021 at 4:09 AM Alex Riesen
<alexander.riesen@xxxxxxxxxxx> wrote:
>
> Ilia Mirkin, Tue, Feb 23, 2021 19:13:59 +0100:
> > On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen <alexander.riesen@xxxxxxxxxxx> 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;
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux