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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
