Asymmetric overscan prevents mouse from reaching the desktop edge #4447

Botspot · 2021-07-10T20:02:34Z

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)

The text was updated successfully, but these errors were encountered:

Botspot · 2021-07-10T20:04:06Z

Curious onlookers can review my forum post as well.

6by9 · 2021-07-12T07:43:59Z

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 · 2021-07-12T07:47:57Z

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

6by9 · 2021-07-12T10:36:13Z

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 · 2021-07-12T11:09:17Z

Same error on line 320 in the vertical coordinates.

6by9 · 2021-07-12T11:09:27Z

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 · 2021-07-12T11:10:13Z

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

6by9 · 2021-07-12T11:10:24Z

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 · 2021-07-12T11:11:34Z

Yes, sorry, missed that bit.

6by9 · 2021-07-12T11:13:15Z

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 · 2021-07-12T11:17:57Z

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.

The calulations clipped the right/bottom edge of the clipped range based on the left/top margins. raspberrypi#4447 Signed-off-by: Dave Stevenson <[email protected]>

6by9 · 2021-07-12T12:27:34Z

PR up for the basic issue in #4451

The calulations clipped the right/bottom edge of the clipped range based on the left/top margins. raspberrypi#4447 Signed-off-by: Dave Stevenson <[email protected]>

The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. raspberrypi#4447 Signed-off-by: Dave Stevenson <[email protected]>

The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. #4447 Signed-off-by: Dave Stevenson <[email protected]>

Botspot · 2021-07-12T13:51:24Z

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

coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:640x480M@60,margin_left=180,margin_right=180,margin_top=0,margin_bottom=0 smsc95xx.macaddr=DC:A6:32:B2:F2:2B vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000  usb-storage.quirks=174c:1153:u console=ttyS0,115200 console=tty1 root=PARTUUID=4b002859-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. #4447 Signed-off-by: Dave Stevenson <[email protected]>

pelwell · 2021-07-12T14:01:59Z

The PR that fixes this problem has been merged - future kernel builds should allow you to reach all corners of the desktop.

The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. #4447 Signed-off-by: Dave Stevenson <[email protected]>

Botspot · 2021-07-12T14:09:21Z

The PR that fixes this problem has been merged - future kernel builds should allow you to reach all corners of the desktop.

Thank you guys so much!
Before I close this issue, I was wondering if the X server could be changed so that it was not being squished by overscan. Right now, all "circles" on my screen appear like ovals, some rectangles look like squares, and everything is blurry compared to before applying overscan.
Would it be possible to tell my X server to subtract the overscan values from it's own dimensions so that everything stays crisp and square?

6by9 · 2021-07-12T14:16:58Z

Sorry, that's inherent in the way mainline Linux has implemented overscan.

The original framebuffer driver implementation reduced the frame buffer size to compensate for overscan, and kept the pixel mapping at 1:1. eg 1920x1080 with 48 pixel on each side ended up with a 1824x984 frame buffer.

The mainline Linux implementation keeps the display as being at the native resolution, and then scales and offsets all planes to the appropriate margins. It would have been nice to have tweaked all the modes advertised to userspace to be cropped as before, but doing that now is going to be tricky.

Botspot · 2021-07-12T14:20:55Z

Sorry, that's inherent in the way mainline Linux has implemented overscan.

The original framebuffer driver implementation reduced the frame buffer size to compensate for overscan, and kept the pixel mapping at 1:1. eg 1920x1080 with 48 pixel on each side ended up with a 1824x984 frame buffer.

The mainline Linux implementation keeps the display as being at the native resolution, and then scales and offsets all planes to the appropriate margins. It would have been nice to have tweaked all the modes advertised to userspace to be cropped as before, but doing that now is going to be tricky.

Can you think of any messy workarounds? To me it seems like many people would appreciate the pixel mapping being kept at 1:1 for clarity.

Botspot · 2021-07-14T00:45:35Z

Would it be possible to manually override the x server/framebuffer dimensions?

The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. #4447 Signed-off-by: Dave Stevenson <[email protected]>

This is a squash of all firmware-kms related patches from previous branches, up to and including "drm/vc4: Set the possible crtcs mask correctly for planes with FKMS" plus a couple of minor fixups for the 5.9 branch. Please refer to earlier branches for full history. This patch includes work by Eric Anholt, James Hughes, Phil Elwell, Dave Stevenson, Dom Cobley, and Jonathon Bell. Signed-off-by: Dave Stevenson <[email protected]> drm/vc4: Fixup firmware-kms after "drm/atomic: Pass the full state to CRTC atomic enable/disable" Prototype for those calls changed, so amend fkms (which isn't upstream) to match. Signed-off-by: Dave Stevenson <[email protected]> drm/vc4: Fixup fkms for API change Atomic flush and check changed API, so fix up the downstream-only FKMS driver. Signed-off-by: Dave Stevenson <[email protected]> drm/vc4: Make normalize_zpos conditional on using fkms Eric's view was that there was no point in having zpos support on vc4 as all the planes had the same functionality. Can be later squashed into (and fixes): drm/vc4: Add firmware-kms mode Signed-off-by: Dom Cobley <[email protected]> drm/vc4: FKMS: Change of Broadcast RGB mode needs a mode change The Broadcast RGB (aka HDMI limited/full range) property is only notified to the firmware on mode change, so this needs to be signalled when set. raspberrypi/firmware#1580 Signed-off-by: Dave Stevenson <[email protected]> vc4/drv: Only notify firmware of display done with kms fkms driver still wants firmware display to be active Signed-off-by: Dom Cobley <[email protected]> ydrm/vc4: fkms: Fix margin calculations for the right/bottom edges The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. #4447 Signed-off-by: Dave Stevenson <[email protected]> drm/vc4: fkms: Use new devm_rpi_firmware_get api drm/kms: Add allow_fb_modifiers Signed-off-by: Dom Cobley <[email protected]> drm/vc4: Add async update support for cursor planes Now that cursors are implemented as regular planes, all cursor movements result in atomic updates. As the firmware-kms driver doesn't support asynchronous updates, these are synchronous, which limits the update rate to the screen refresh rate. Xorg seems unaware of this (or at least of the effect of this), because if the mouse is configured with a higher update rate than the screen then continuous mouse movement results in an increasing backlog of mouse events - cue extreme lag. Add minimal support for asynchronous updates - limited to cursor planes - to eliminate the lag. See: #4971 #4988 Signed-off-by: Phil Elwell <[email protected]> drivers/gpu/drm/vc4: Add missing 32-bit RGB formats The missing 32-bit per pixel ABGR and various "RGB with an X value" formats are added. Change sent by Dave Stevenson. Signed-off-by: David Plowman <[email protected]> drm: vc4: Fixup duplicated macro definition in vc4_firmware_kms Both vc4_drv.h and vc4_firmware_kms.c had definitions for to_vc4_crtc. Rename the fkms one to make it unique, and drop the magic define vc4_crtc vc4_kms_crtc define to_vc4_crtc to_vc4_kms_crtc that renamed half the variable and function names in a slightly unexpected way. Signed-off-by: Dave Stevenson <[email protected]> drm/vc4: Fix FKMS for when the YUV chroma planes are different buffers The code was assuming that it was a single buffer with offsets, when kmstest uses separate buffers and 0 offsets for each plane. Signed-off-by: Dave Stevenson <[email protected]> drm/vc4: fkms: Rename plane related functions The name collide with the Full KMS functions that are going to be made public. Signed-off-by: Maxime Ripard <[email protected]> drm/vc4_fkms: Fix up interrupt handler for both 2835/2711 and 2712 2712 has switched from using the SMI peripheral to another interrupt source for the vsync interrupt, so handle both sources cleanly. Signed-off-by: Dave Stevenson <[email protected]>

Botspot changed the title ~~Asymmetric overscan prevents mouse from touching screen edge~~ Asymmetric overscan prevents mouse from reaching the desktop edge Jul 10, 2021

6by9 mentioned this issue Jul 12, 2021

KMS and FKMS right/bottom margin fixes #4451

Merged

pelwell pushed a commit that referenced this issue Jul 12, 2021

ydrm/vc4: fkms: Fix margin calculations for the right/bottom edges

0088c16

The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. #4447 Signed-off-by: Dave Stevenson <[email protected]>

pelwell pushed a commit that referenced this issue Jul 12, 2021

ydrm/vc4: fkms: Fix margin calculations for the right/bottom edges

26acf89

The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. #4447 Signed-off-by: Dave Stevenson <[email protected]>

pelwell pushed a commit that referenced this issue Jul 12, 2021

ydrm/vc4: fkms: Fix margin calculations for the right/bottom edges

5c804c8

The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. #4447 Signed-off-by: Dave Stevenson <[email protected]>

pelwell pushed a commit that referenced this issue Jul 12, 2021

ydrm/vc4: fkms: Fix margin calculations for the right/bottom edges

e54f7c3

The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. #4447 Signed-off-by: Dave Stevenson <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Asymmetric overscan prevents mouse from reaching the desktop edge #4447

Asymmetric overscan prevents mouse from reaching the desktop edge #4447

Botspot commented Jul 10, 2021

Botspot commented Jul 10, 2021

6by9 commented Jul 12, 2021

6by9 commented Jul 12, 2021

6by9 commented Jul 12, 2021

JamesH65 commented Jul 12, 2021

6by9 commented Jul 12, 2021

JamesH65 commented Jul 12, 2021

6by9 commented Jul 12, 2021

JamesH65 commented Jul 12, 2021

6by9 commented Jul 12, 2021

6by9 commented Jul 12, 2021

6by9 commented Jul 12, 2021

Botspot commented Jul 12, 2021

pelwell commented Jul 12, 2021

Botspot commented Jul 12, 2021

6by9 commented Jul 12, 2021

Botspot commented Jul 12, 2021

Botspot commented Jul 14, 2021

Asymmetric overscan prevents mouse from reaching the desktop edge #4447

Asymmetric overscan prevents mouse from reaching the desktop edge #4447

Comments

Botspot commented Jul 10, 2021

Botspot commented Jul 10, 2021

6by9 commented Jul 12, 2021

6by9 commented Jul 12, 2021

6by9 commented Jul 12, 2021

JamesH65 commented Jul 12, 2021

6by9 commented Jul 12, 2021

JamesH65 commented Jul 12, 2021

6by9 commented Jul 12, 2021

JamesH65 commented Jul 12, 2021

6by9 commented Jul 12, 2021

6by9 commented Jul 12, 2021

6by9 commented Jul 12, 2021

Botspot commented Jul 12, 2021

pelwell commented Jul 12, 2021

Botspot commented Jul 12, 2021

6by9 commented Jul 12, 2021

Botspot commented Jul 12, 2021

Botspot commented Jul 14, 2021