Anyone have some feedback on this? It seems Dave is the original author of
rrCrtcSetScanoutPixmap(), so maybe he could provide some input? It should be a
pretty straightforward fix, but I need to know the preferred usage of
rrCrtcSetScanoutPixmap(), or if I should bypass it altogether.
Also
> AFAICT RRReplaceScanoutPixmap may call set_scanout_pixmap while
> randr_crtc->scanout_pixmap is already non-NULL (and pointing to a
> different pixmap).
That seems to be true now that you mention it. I haven't paid that much
attention to RRReplaceScanoutPixmap(), since it doesn't seem to get
On 04.03.2016 11:47, Alex Goins wrote:
> 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
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
