[PATCH xserver] randr: Stop dirty tracking for shared pixmap being destroyed

[Michel Dänzer]

On 08.12.2015 07:02, Alex Goins wrote:
> Are you sure about this? rrCreateSharedPixmap() does not actually start pixmap
> tracking, rather it is done later in rrSetupPixmapSharing(). It's not a given
> that a 'shared pixmap' is being tracked when it is destroyed.

That's fine, StopPixmapTracking is just a no-op in that case.


> The regression was introduced when that patch was taken by itself without
> subsequent patches, didn't notice the bug since I was mostly testing with all
> the patches together.

FWIW, patches should always be as self-contained as possible even as
part of a series. In particular, introducing a regression like this in
one patch and fixing it in a subsequent patch of a series is no good.


> A better solution would be to re-introduce the master->StopPixmapTracking() call
> in front of rrDestroySharedPixmap() in RRCrtcDetachScanoutPixmap().

That would leave the risk of StopPixmapTracking never getting called,
leaving a dangling reference to the destroyed pixmap.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer