Skip to content

Asymmetric overscan prevents mouse from reaching the desktop edge #4447

Open

Description

@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)

Activity

  1. changed the title [-]Asymmetric overscan prevents mouse from touching screen edge [/-] [+]Asymmetric overscan prevents mouse from reaching the desktop edge[/+] on Jul 10, 2021
  2. Botspot commented on Jul 10, 2021

    @Botspot
    Author

    Curious onlookers can review my forum post as well.

  3. 6by9 commented on Jul 12, 2021

    @6by9
    Contributor

    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.

  4. 6by9 commented on Jul 12, 2021

    @6by9
    Contributor

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

  5. 6by9 commented on Jul 12, 2021

    @6by9
    Contributor

    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.

  6. JamesH65 commented on Jul 12, 2021

    @JamesH65
    Contributor

    Same error on line 320 in the vertical coordinates.

  7. 6by9 commented on Jul 12, 2021

    @6by9
    Contributor

    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.

  8. JamesH65 commented on Jul 12, 2021

    @JamesH65
    Contributor

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

  9. 6by9 commented on Jul 12, 2021

    @6by9
    Contributor

    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

  10. JamesH65 commented on Jul 12, 2021

    @JamesH65
    Contributor

    Yes, sorry, missed that bit.

  11. 6by9 commented on Jul 12, 2021

    @6by9
    Contributor

    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!

  12. 6by9 commented on Jul 12, 2021

    @6by9
    Contributor

    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.

  13. 6by9 commented on Jul 12, 2021

    @6by9
    Contributor

    PR up for the basic issue in #4451

  14. 288 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions