On Thu, Jan 26, 2017 at 10:55:51AM +0100, Maarten Lankhorst wrote:
> 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?
Give me a few days to get back to you. I'm reworking some patches right now.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
