Skip to content
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

Display Corruptions with KMS and Overscan Margins on the RaspberryPi 4 #4475

Closed
mripard opened this issue Jul 26, 2021 · 10 comments · Fixed by #4776
Closed

Display Corruptions with KMS and Overscan Margins on the RaspberryPi 4 #4475

mripard opened this issue Jul 26, 2021 · 10 comments · Fixed by #4776

Comments

@mripard
Copy link
Contributor

mripard commented Jul 26, 2021

Moving the cursor along the edges of the display creates some visual artifacts when disable_overscan isn't set.

To reproduce

Build a kernel based on current the rpi-5.10.y branch (7aa66c0 in my case), start X and move the cursor along the edges. Complete corruption of the display should occur.

Adding disable_overscan=1 to config.txt makes it behave properly.

@timg236
Copy link
Contributor

timg236 commented Jul 26, 2021

Yes, we can see that here

@popcornmix
Copy link
Collaborator

Also noticed that top right corner causes:

[  227.049120] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:76:crtc-3] flip_done timed out
[  227.049163] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:76:crtc-3] flip_done timed out
[  237.289091] vc4-drm gpu: [drm] *ERROR* Timed out waiting for flip_done

@mripard
Copy link
Contributor Author

mripard commented Jul 26, 2021

For the record, I noticed this this morning while debugging something else and just opened the issue so that it doesn't get forgotten.

@timg236
Copy link
Contributor

timg236 commented Jul 26, 2021

I'm finding that when the mouse is stationary everything is ok. However, if it moves and is within 62 pixels of the bottom or right edge then the corrupt appears.
This seems to correspond with the scaling mode changing from zero to 4 or 5 for that d-list element. In the stationary state the scaling mode is always zero.
scl0_mode, scl1_mode in controlword0

@popcornmix
Copy link
Collaborator

popcornmix commented Jul 26, 2021

A possibly related issue is with kms, and two displays, from desktop rapidly switching mouse pointer between displays results in occasional glitches (on the framebuffer). It doesn't seem to be clock related (forcing it high doesn't avoid it).
I'm suspicious that the mouse overlay being removed/added is causing a one frame glitch.
When it doesn't change screen it presumably uses the simpler code path allowed by vc4_plane_atomic_async_check.

@popcornmix
Copy link
Collaborator

I've reverted most of #4441 and the screen corruption when cursor near edges and glitches when mouse pointer switches screens issues are gone.

@popcornmix
Copy link
Collaborator

This should be resolved with latest rpi-update kernel.

@mripard
Copy link
Contributor Author

mripard commented Aug 30, 2021

I reverted your revert and tried to fix all the pending bugs we had. I've been working on this one today and followed the suggestion from @timg236 on #4465 that it might be related to the core clock being too low on 4k.

I'm seeing this on 1080p, but I still raised the core clock to 500MHz which is more than the double of what is computed (220MHz). I'm still getting both the corruptions (even though I'm getting less corruptions, possibly from my other fixes), and some timeouts.

Moving the cursor in itself (using xdotool mousemove) doesn't trigger it, so it looks like it's the sequence of commits when moving the cursor that triggers it.

@mripard
Copy link
Contributor Author

mripard commented Nov 18, 2021

For the record, this also affects rpi-5.15.y with a single display

@mripard
Copy link
Contributor Author

mripard commented Mar 2, 2022

This was fixed by the PR #4895

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

Successfully merging a pull request may close this issue.

3 participants