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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
