Subsequent commits will involve multiple calls to rrCrtcSetScanoutPixmap(ppix) without a call to rrCrtcSetScanoutPixmap(NULL) in between. This causes drmmode_set_scanout_pixmap_gpu() to track damage multiple times but ultimately only stop tracking on one, which could lead to dangling pointers.
I don't intend to support PRIME synchronization with reverse PRIME at this time, so just fail in this case. It's probably a bad idea to rely on randr setting randr_crtc->scanout_pixmap in order to know which pixmap to stop damage tracking on, but I'll keep it that way for now to stay consistent. v1: N/A v2: N/A v3: N/A v4: Initial commit Signed-off-by: Alex Goins <[email protected]> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86/drivers/modesetting/drmmode_display.c index 0d34ca1..ed67dbe 100644 --- a/hw/xfree86/drivers/modesetting/drmmode_display.c +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c @@ -586,6 +586,11 @@ drmmode_set_scanout_pixmap_gpu(xf86CrtcPtr crtc, PixmapPtr ppix) drmmode_crtc->prime_pixmap_x = 0; return TRUE; } + + /* Currently supports only one scanout pixmap */ + if (crtc->randr_crtc->scanout_pixmap) + return FALSE; + /* iterate over all the attached crtcs to work out the bounding box */ for (c = 0; c < xf86_config->num_crtc; c++) { xf86CrtcPtr iter = xf86_config->crtc[c]; -- 1.9.1 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
