Op 25-01-17 om 19:05 schreef Sinclair Yeh:
> On Wed, Jan 25, 2017 at 09:36:36AM +0100, Maarten Lankhorst wrote:
>> 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@xxxxxxxx>
>>>>>>>
>>>>>>> This was somehow lost between v3 and the merged version in Maarten's
>>>>>>> patch merged as:
>>>>>>>
>>>>>>> commit f2d580b9a8149735cbc4b59c4a8df60173658140
>>>>>>> Author: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
>>>>>>> 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@xxxxxxxxx>
>>>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
>>>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
>>>>>> 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.
> FYI, we are in the process of converting things to atomic. This may happen
> around 4.12
>
Will the driver allow the crtc to be enabled without primary plane?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
