[PATCH 4/4] drm: Resurrect atomic rmfb code, v2

[Thomas Hellstrom]

On 01/25/2017 05:54 AM, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 01:44:54PM -0800, Matt Roper wrote:
>> On Wed, Jan 11, 2017 at 05:15:47PM +0100, Daniel Vetter wrote:
>>> On Thu, Dec 15, 2016 at 03:29:45PM +0100, Maarten Lankhorst wrote:
>>>> From: Daniel Vetter <daniel.vetter at ffwll.ch>
>>>>
>>>> This was somehow lost between v3 and the merged version in Maarten's
>>>> patch merged as:
>>>>
>>>> commit f2d580b9a8149735cbc4b59c4a8df60173658140
>>>> Author: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>>>> Date:   Wed May 4 14:38:26 2016 +0200
>>>>
>>>>     drm/core: Do not preserve framebuffer on rmfb, v4.
>>>>
>>>> Actual code copied from Maarten's patch, but with the slight change to
>>>> just use dev->mode_config.funcs->atomic_commit to decide whether to
>>>> use the atomic path or not.
>>>>
>>>> v2:
>>>> - Remove plane->fb assignment, done by drm_atomic_clean_old_fb.
>>>> - Add WARN_ON when atomic_remove_fb fails.
>>>> - Always call drm_atomic_state_put.
>>>>
>>>> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
>>>> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>>> Would be great if someone else could r-b this, I've proven pretty well
>>> that I don't understand the complexity here :(
>>> -Daniel
>> It looks like this will change the behavior slightly in that rmfb will
>> cause primary planes to be disabled, but no longer cause the entire CRTC
>> to be turned off.  You'll probably want to note that in the commit
>> message, along with the justification on why this is okay ABI-wise.
>>
>> I know that 13803132818c ("drm/core: Preserve the framebuffer after
>> removing it.") was initially trying to not only leave the CRTC on, but
>> also preserve the framebuffer and leave the planes on; that wound up
>> causing some kind of regression for vmwgfx, but I'm unclear on the
>> details there.  I'd suggest getting an Ack from one of the vmware guys
>> to ensure that the less drastic change in behavior here won't cause them
>> any problems.
The vmware Xorg driver is currently relying on rmfb to turn all attached
crtcs off. Even if we were to fix that in the Xorg driver now, older
Xorgs with newer kernels still would break.

/Thomas