Skip to content

Full KMS driver cursor glitches #3618

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
pelwell opened this issue May 18, 2020 · 8 comments
Closed

Full KMS driver cursor glitches #3618

pelwell opened this issue May 18, 2020 · 8 comments

Comments

@pelwell
Copy link
Contributor

pelwell commented May 18, 2020

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
Copy link
Contributor

6by9 commented May 18, 2020

  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
Copy link
Contributor Author

pelwell commented May 18, 2020

  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
Copy link

Bleep42 commented May 20, 2020

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
Copy link
Collaborator

popcornmix commented May 20, 2020

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
Copy link
Contributor Author

pelwell commented May 20, 2020

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
Copy link

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
Copy link
Contributor Author

pelwell commented Jan 18, 2021

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
Copy link
Collaborator

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

@pelwell pelwell closed this as completed Jan 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants