I've verified that it doesn't break our existing code, but I'm in the process of rebasing my atomic enabling patch series onto drm-next along with this. I should be able to get this done by tomorrow morning. ________________________________________ From: Maarten Lankhorst maarten.lankhorst@linux.intel.com Sent: Thursday, February 9, 2017 4:29:49 AM To: Sinclair Yeh Cc: Thomas Hellstrom; Daniel Vetter; Matt Roper; Daniel Vetter; intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Daniel Vetter Subject: Re: [PATCH 4/4] drm: Resurrect atomic rmfb code, v2
Op 26-01-17 om 19:39 schreef Sinclair Yeh:
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@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.
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.
Any update on this?
~Maarten