Full KMS driver cursor glitches

[pelwell]

With the full KMS driver enabled on a Pi 4 (dtoverlay=vc4-kms-v3d, or dtoverlay=vc4-kms-v3d-pi4 on older systems) I see two different graphical glitches related to the cursor.

1. Immediately after booting to the desktop (with auto-login, although that may not be relevant), the window manager positions the cursor above the Raspberry menu. with full KMS enabled the cursor image looks like random junk (it reminds me of playing with sprites on a C64). The correct image can be restored by movnig the cursor to the the edge of the screen.

2. Watching a YouTube clip in chromium, when the cursor is moved over the video window, my monitor blanks (not so) briefly. I would guess this is because an extra GUI layer is added to the video area, perhaps causing HVS underflow. The picture returns after a second or two, but the GUI is absent, as if adding the layer has failed.

[6by9]

1. Sounds like an X issue, although it's slightly odd that you don't see it on FKMS.
   I know I've just closed arm: dt: For 2711 move vc4 gpu node under soc to get correct dma-ranges #3617, but does that help? Using a cached alias could potentially lead to that sort of thing.

2. This depends on what code of John's is active, but Chromium should be using GL to do all composition as X doesn't know how to handle planes. It should only be seeing the two layers therefore, GUI and cursor.
   There is a sysfs node that gives a summary of the entire drm driver view of the world - /sys/kernel/debug/dri/1/state looks like the appropriate candidate.

[pelwell]

1. Interesting thought, but arm: dt: For 2711 move vc4 gpu node under soc to get correct dma-ranges #3617 makes no difference.

2. Grabbing a sequence of captures from the debug sysfs shows that some of them - those corresponding to screen blanking - are shorter.
   An example diff is:

224,242c224,227
<       crtc=crtc-2
<       fb=206
<               allocated by = Xorg
<               refcount=1
<               format=AR24 little-endian (0x34325241)
<               modifier=0x0
<               size=64x64
<               layers:
<                       size[0]=64x64
<                       pitch[0]=256
<                       offset[0]=0
<                       obj[0]:
<                               name=0
<                               refcount=3
<                               start=00010be7
<                               size=16384
<                               imported=no
<       crtc-pos=64x64+915+236
<       src-pos=64.000000x64.000000+0.000000+0.000000
---
>       crtc=(null)
>       fb=0
>       crtc-pos=0x0+0+0
>       src-pos=0.000000x0.000000+0.000000+0.000000
300c285
<       plane_mask=800004
---
>       plane_mask=4

I've attached the two files in question for more context.
comp_5.txt
comp_6.txt

[Bleep42]

While getting my Mandelbrot program to work using the new kernel and "dtoverlay=vc4-kms-v3d" ie, non fake kms I have come across a problem.
If I use VLC to play a video with the current release kernel "Linux raspberrypi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux" with "dtoverlay=vc4-kms-v3d" everything works as expected, both 32 and 64bit.

However if I use the new kernel "Linux raspberrypi 5.4.40-v7l+ #1316 SMP Tue May 12 13:10:42 BST 2020 armv7l GNU/Linux" with "dtoverlay=vc4-kms-v3d", I have found that if I move the mouse, inside the active VLC video display area, the whole screen disappears, as though its disconnected, I think this because, when I stop moving the mouse the display pops up a message saying 'HDMI reconnected' and the screen reappears. Interestingly, if I move the mouse outside the active video display area, everything works just fine, by that I mean within the VLC menu area is fine, as is its blue bar at the top of the window and the player controls at the bottom of the window, or anywhere outside the VLC window; this is true for both 32 and 64bit. However if I use "dtoverlay=vc4-fkms-v3d" with the new kernel the problem does not exist. This is on a Pi4 fully updated.

Hope that all makes sense and is of use. If you need any further info. let me know.

[popcornmix]

Thanks. VLC doesn't use planes for the view (unless running fullscreen).

So the only change I can see when entering VLC (or Chromium) video window is the app requests a different mouse pointer and KMS is not altering display list correctly.

(I'm assuming kms uses cursor plane in similar way to fkms? Can cursor plane acceleration be disabled?)

[pelwell]

Here's the simple script I used to poll the composition information:

#!/bin/sh
i=0
while [ $i -lt 100 ]; do
    sudo cat /sys/kernel/debug/dri/1/state > comp_$i.txt
    i=`expr $i + 1`
done

I think that if you were to run it (possibly reducing the iteration count) while triggering the screen blanking you would see similar short logs.

[fossfreedom]

Watching a YouTube clip in chromium, when the cursor is moved over the video window, my monitor blanks (not so) briefly. I would guess this is because an extra GUI layer is added to the video area, perhaps causing HVS underflow. The picture returns after a second or two, but the GUI is absent, as if adding the layer has failed.

I can confirm this as well with both Firefox & chromium with Ubuntu 21.04 pi image (kernel 5.8 + Nov 2020 kernel pi patchset)

dtoverlay=vc4-kms-v3d is ok with no screen-blanking issues - I'm guessing because the window manager GNOMEs mutter defaults to llvmpipe software acceleration - so youtube is pretty much unusable at that point anyway. dtoverlay=vc4-kms-v3d-pi4 gives full 3D accel - but with the youtube screen-blanking observation. Going you-tube full screen just gives a blank screen and usually at that point I have to force power off and on again.

[pelwell]

Unless you are running old firmware or an old set of overlays, vc4-kms-v3d and vc4-kms-v3d-pi4 should be identical on a 2711-based device (Pi 4B, Pi 400 and CM4). Run sudo vcdbg log msg |& grep File to see what is actually being loaded.

[popcornmix]

@pelwell I think this has been resolved (a few different ways). Is it okay to close?