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

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

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

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. The regression was introduced when that patch was taken by itself without

Re: [PATCH xserver] prime: Damage full destination rectangle when we start dirty tracking

On Thu, 2015-12-03 at 12:38 -0500, Alex Deucher wrote: > On Thu, Dec 3, 2015 at 3:04 AM, Michel Dänzer wrote: > > From: Michel Dänzer > > > > This makes sure that the destination pixmap contents will be fully > > initialized. Without this, a PRIME

[PATCH RFC kdrive/ephyr] Match host X server's keymap

Analogous to Xnest implementation at 83fef4235db86343477b4ec9858c6ba35e1aa7d9. Signed-off-by: Laércio de Sousa --- configure.ac| 2 +- hw/kdrive/ephyr/ephyr.c | 19 +++--- hw/kdrive/ephyr/hostx.c | 98

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

On Tue, 8 Dec 2015, 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. > > > >

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

> > 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

Re: [PATCH 04/11] xf86: Add PRIME flipping functions to ScreenRec

On 26.11.2015 11:39, Alex Goins wrote: > > (Start/Stop)FlippingPixmapTracking are merely the double-buffered > equivalents of (Start/Stop)PixmapTracking, allowing the source driver to do > whatever setup and teardown necessary for presenting on the two shared > pixmaps. AFAICT there's no