[Intel-gfx] [PATCH] drm/core: Do not preserve framebuffer on rmfb, v4.

2016-05-05 Thread Daniel Vetter
On Thu, May 05, 2016 at 10:07:57AM +0100, Tvrtko Ursulin wrote: > > On 04/05/16 13:38, Maarten Lankhorst wrote: > >It turns out that preserving framebuffers after the rmfb call breaks > >vmwgfx userspace. This was originally introduced because it was thought > >nobody relied on the behavior, but u

[Intel-gfx] [PATCH] drm/core: Do not preserve framebuffer on rmfb, v4.

2016-05-05 Thread Tvrtko Ursulin
On 04/05/16 13:38, Maarten Lankhorst wrote: > It turns out that preserving framebuffers after the rmfb call breaks > vmwgfx userspace. This was originally introduced because it was thought > nobody relied on the behavior, but unfortunately it seems there are > exceptions. > > drm_framebuffer_remov

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v4.

2016-05-04 Thread Maarten Lankhorst
It turns out that preserving framebuffers after the rmfb call breaks vmwgfx userspace. This was originally introduced because it was thought nobody relied on the behavior, but unfortunately it seems there are exceptions. drm_framebuffer_remove may fail with -EINTR now, so a straight revert is impo

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

2016-05-03 Thread Thomas Hellstrom
Hi, Sorry for the late response, been very busy with other stuff lately. I've tested this version against drm-fixes and it indeed fixes the problem, as far as I can tell. Tested-by: Thomas Hellstrom On 03/31/2016 01:26 PM, Maarten Lankhorst wrote: > It turns out that preserving framebuffers a

[REBASED PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

2016-05-02 Thread Maarten Lankhorst
It turns out that preserving framebuffers after the rmfb call breaks vmwgfx userspace. This was originally introduced because it was thought nobody relied on the behavior, but unfortunately it seems there are exceptions. drm_framebuffer_remove may fail with -EINTR now, so a straight revert is impo

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

2016-04-12 Thread Daniel Vetter
On Thu, Mar 31, 2016 at 01:26:03PM +0200, Maarten Lankhorst wrote: > It turns out that preserving framebuffers after the rmfb call breaks > vmwgfx userspace. This was originally introduced because it was thought > nobody relied on the behavior, but unfortunately it seems there are > exceptions. >

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

2016-04-11 Thread Maarten Lankhorst
Op 31-03-16 om 13:26 schreef Maarten Lankhorst: > It turns out that preserving framebuffers after the rmfb call breaks > vmwgfx userspace. This was originally introduced because it was thought > nobody relied on the behavior, but unfortunately it seems there are > exceptions. > > drm_framebuffer_re

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

2016-03-31 Thread Maarten Lankhorst
It turns out that preserving framebuffers after the rmfb call breaks vmwgfx userspace. This was originally introduced because it was thought nobody relied on the behavior, but unfortunately it seems there are exceptions. drm_framebuffer_remove may fail with -EINTR now, so a straight revert is impo

[PATCH] drm/core: Do not preserve framebuffer on rmfb.

2016-03-22 Thread Maarten Lankhorst
Op 22-03-16 om 12:09 schreef Daniel Vetter: > On Tue, Mar 22, 2016 at 11:53:53AM +0100, Maarten Lankhorst wrote: >> Op 22-03-16 om 11:50 schreef Daniel Vetter: >>> On Tue, Mar 22, 2016 at 10:32:32AM +0100, Maarten Lankhorst wrote: Op 21-03-16 om 18:37 schreef Daniel Vetter: > On Mon, Mar 2

[PATCH] drm/core: Do not preserve framebuffer on rmfb.

2016-03-22 Thread Daniel Vetter
On Tue, Mar 22, 2016 at 11:53:53AM +0100, Maarten Lankhorst wrote: > Op 22-03-16 om 11:50 schreef Daniel Vetter: > > On Tue, Mar 22, 2016 at 10:32:32AM +0100, Maarten Lankhorst wrote: > >> Op 21-03-16 om 18:37 schreef Daniel Vetter: > >>> On Mon, Mar 21, 2016 at 03:11:17PM +0100, Maarten Lankhorst

[PATCH] drm/core: Do not preserve framebuffer on rmfb.

2016-03-22 Thread Maarten Lankhorst
Op 22-03-16 om 11:50 schreef Daniel Vetter: > On Tue, Mar 22, 2016 at 10:32:32AM +0100, Maarten Lankhorst wrote: >> Op 21-03-16 om 18:37 schreef Daniel Vetter: >>> On Mon, Mar 21, 2016 at 03:11:17PM +0100, Maarten Lankhorst wrote: It turns out that preserving framebuffers after the rmfb call b

[PATCH] drm/core: Do not preserve framebuffer on rmfb.

2016-03-22 Thread Daniel Vetter
On Tue, Mar 22, 2016 at 10:32:32AM +0100, Maarten Lankhorst wrote: > Op 21-03-16 om 18:37 schreef Daniel Vetter: > > On Mon, Mar 21, 2016 at 03:11:17PM +0100, Maarten Lankhorst wrote: > >> It turns out that preserving framebuffers after the rmfb call breaks > >> vmwgfx userspace. This was originall

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v2.

2016-03-22 Thread Maarten Lankhorst
It turns out that preserving framebuffers after the rmfb call breaks vmwgfx userspace. This was originally introduced because it was thought nobody relied on the behavior, but unfortunately it seems there are exceptions. drm_framebuffer_remove may fail with -EINTR now, so a straight revert is impo

[PATCH] drm/core: Do not preserve framebuffer on rmfb.

2016-03-22 Thread Maarten Lankhorst
Op 21-03-16 om 18:37 schreef Daniel Vetter: > On Mon, Mar 21, 2016 at 03:11:17PM +0100, Maarten Lankhorst wrote: >> It turns out that preserving framebuffers after the rmfb call breaks >> vmwgfx userspace. This was originally introduced because it was thought >> nobody relied on the behavior, but u

[PATCH] drm/core: Do not preserve framebuffer on rmfb.

2016-03-21 Thread Daniel Vetter
On Mon, Mar 21, 2016 at 03:11:17PM +0100, Maarten Lankhorst wrote: > It turns out that preserving framebuffers after the rmfb call breaks > vmwgfx userspace. This was originally introduced because it was thought > nobody relied on the behavior, but unfortunately it seems there are > exceptions. > >

[PATCH] drm/core: Do not preserve framebuffer on rmfb.

2016-03-21 Thread Maarten Lankhorst
It turns out that preserving framebuffers after the rmfb call breaks vmwgfx userspace. This was originally introduced because it was thought nobody relied on the behavior, but unfortunately it seems there are exceptions. drm_framebuffer_remove may fail with -EINTR now, so a straight revert is impo