Asymmetric overscan prevents mouse from reaching the desktop edge

[Botspot]

Is this the right place for my bug report?
Yes, either here or firmware.
Jamesh suggested I try opening an issue here first.

Describe the bug
If left overscan and right overscan are not equal to one another, the mouse pointer will not be able to cover the entire desktop area.

To reproduce

overscan_left=190
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

Expected behaviour
Mouse pointer can move freely across the entire screen.

Actual behaviour
Mouse pointer cannot approach the right side of the screen. The closest it can get to the edge is 190px away.

System

• Raspberry Pi 4
• Latest Raspberry Pi OS Buster. Original image file version was 2019-09-26.
• FKMS is enabled.
• Firmware:

May 27 2021 14:02:15 
Copyright (c) 2012 Broadcom
version 7d9a298cda813f747b51fe17e1e417e7bf5ca94d (clean) (release) (start)

[Botspot]

Curious onlookers can review my forum post as well.

[6by9]

As a quick test can you try altering /boot/config.txt so that you have dtoverlay=vc4-kms-v3d instead of vc4-fkms-v3d, reboot, and see if that has the same issue? That'll allow us to narrow it down between fkms/firmware and kernel framework.

[6by9]

Can you also give us the output from cat /proc/cmdline?

[6by9]

To answer my own questions, /proc/cmdline is correct for me in having

 video=HDMI-A-1:3840x2160M@30,margin_left=170,margin_right=0,margin_top=0,margin_bottom=0

And vc4-kms-v3d behaves the same - it clips the X offset to too low a value.
X is still moving the mouse pointer off beyond the limit, as if there is something that changes when you hover over it, you see that happen even if it's in the bit the pointer can't get to. Also true in the Y direction if you set overscan_top.

Looking at the code I do see the obvious error
https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/gpu/drm/vc4/vc4_plane.c#L313

	vc4_pstate->crtc_x += left;
	if (vc4_pstate->crtc_x > crtc_state->mode.hdisplay - left)
		vc4_pstate->crtc_x = crtc_state->mode.hdisplay - left;

That's wrong and I believe should be simply checking crtc_x against hdisplay without subtracting left. Same for the check on crtc_y a few lines later.

The only check that may be valid is to clip the bits of the image that then fall off the screen, but I think the display list generation does that anyway.

vc4_firmware_kms margins support was copied from vc4_planes, which explains why they both have the same issue.

[JamesH65]

Same error on line 320 in the vertical coordinates.

[6by9]

I'll correct myself before someone else does it for me.

if (vc4_pstate->crtc_x > crtc_state->mode.hdisplay - right)
		vc4_pstate->crtc_x = crtc_state->mode.hdisplay - right;

Mentally running through the combinations, I think there is still an issue if we take the example of a 1280x720 display, overscan defined as 100 off the right or bottom, and the application tries to push the image off the right/bottom edge. The source rectangle isn't being cropped, therefore part of the image will be visible in the overscan border.

[JamesH65]

Reading that function it all seems a bit weird to me.

[6by9]

Same error on line 320 in the vertical coordinates.

Wasn't that covered by:

That's wrong and I believe should be simply checking crtc_x against hdisplay without subtracting left. Same for the check on crtc_y a few lines later

[JamesH65]

Yes, sorry, missed that bit.

[6by9]

Reading that function it all seems a bit weird to me.

Margins in DRM are all a little icky in that they scale the image, but that's the way mainline chose to solve the problem :-/
Getting the maths right to clip every thing correctly is non-trivial, and mistakes are easy to make. This one has been in there since December 2018 and no one has noticed until now!

[6by9]

I've confirmed via modetest that I can display an image in the overscan region with FKMS (almost certainly applies to KMS too), so that ought to be fixed.

[6by9]

PR up for the basic issue in #4451