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

[Maarten Lankhorst <maarten.lankhorst@linux.intel.com>]

Op 25-01-17 om 09:09 schreef 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@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@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@intel.com>
>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@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.
Is it allowed for vmwgfx to keep the crtc enabled, but the primary plane disabled?

If so, when vmwgfx is eventually converted to atomic then we need to special-case rmfb for them somehow.
However for right now vmwgfx uses the legacy rmfb, which does disable all crtc's. :)

~Maarten
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel