modesetting: HWCursor and rotation

Carsten Behling carsten.behling at googlemail.com
Fri Jul 6 14:23:38 UTC 2018


Hi,

I ran into a problem with the modesetting driver if using HWCursor with
rotation.

The PreInit function retrieves initially the default cursor height/width:

    ret = drmGetCap(ms->fd, DRM_CAP_CURSOR_WIDTH, &value);
    if (!ret) {
        ms->cursor_width = value;
    }
    ret = drmGetCap(ms->fd, DRM_CAP_CURSOR_HEIGHT, &value);
    if (!ret) {
        ms->cursor_height = value;
    }



DRM returns 64/64 from Freedreno driver which is later used as

cursor_info->MaxWidth and cursor_info->MaxHeight in upper left corner
calculation

if rotation is set with xrandr.


As a result I get e.g. negative cursor postion in x/y if the HW cursor buffer

is moved in display rotation of 180 degrees towards the lower/right corner.

The cursor move is ignored in this case:


static void
drmmode_set_cursor_position(xf86CrtcPtr crtc, int x, int y)
{
    drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
    drmmode_ptr drmmode = drmmode_crtc->drmmode;

    drmModeMoveCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, x, y);
}


So the upper left corner of the default cursor arrow never pointed to lower

right positions that are beyond screen positions 64/64

(Note: on 180 degree rotation we are on the upper left corner of the

framebuffer).


So my question is :


Where should that be fixed?:


a) Should my DRM driver allow to move the HW cursor buffer partially
outside the frambuffer?

   Without rotation it does (towards higher addresses of the
framebuffer). With rotation

   it would go beyond the frambuffer start address (I think this is
the reason why the cursor

   move is ignored). I don't know if GPU should composite and cut off
the HWCursor buffer borders

   that fall out of the frambuffer borders.

b) Should the HW cursor buffer be resized if that positions are
reached? I don't know if DRM/GPU

   allows it and there is no code in modesetting driver that wrapes such a call.

c) Anywhere else?


Best regards

-Carsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg/attachments/20180706/bdd63e40/attachment.html>


More information about the xorg mailing list