From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: [PATCH] drm/fb-helper: delay hotplug handling when partially bound Date: Fri, 15 Jun 2012 11:01:22 +0200 Message-ID: <1339750882-23398-1-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by gabe.freedesktop.org (Postfix) with ESMTP id BD42E9E79C for ; Fri, 15 Jun 2012 01:59:53 -0700 (PDT) Received: by bkwj4 with SMTP id j4so2481372bkw.36 for ; Fri, 15 Jun 2012 01:59:52 -0700 (PDT) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Dave Airlie Cc: Daniel Vetter , DRI Development List-Id: dri-devel@lists.freedesktop.org Ok, this requires quite a dance to actually hit: 1) We plug in a 2nd screen, enable it in both X and (by vt-switching) in the fbcon. 2) We disable that screen again in with xrandr. 3) We vt-switch again, so that fbcon displays on the 2nd screen, but X on the first screen. This obviously needs a driver that doesn't switch off unused functions when regaining the VT. 3) When X controls the vt, we unplug that screen. Now drm_fb_helper_hotplug_event we noticed that that some crtcs are bound, but because we still have the fbcon on the 2nd screeen we also have bound set. Which means the fbcon wrongly assumes it's in control of everything an happily disables the output on the 2nd screen, but enables its fb on the first screen. Work around this issue by counting how many crtcs are bound and how many are bound to fbcon and assuming that when fbcon isn't bound to all of them, it better not touch the output configuration. Conceptually this is the same as only restoring the fbcon output configuration on the driver's ->lastclose, when we're sure that no one else is using kms. So this should be consistent with existing kms drivers. Chris has created a separate patch for the intel ddx, but I think we should fix this issue here regardless - the fbcon messing with the output config while it's not fully in control simply isn't a too polite behaviour. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50772 Tested-by: Maxim A. Nikulin Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_helper.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 5683b7f..d3f15b9 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1353,7 +1353,7 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper) struct drm_device *dev = fb_helper->dev; int count = 0; u32 max_width, max_height, bpp_sel; - bool bound = false, crtcs_bound = false; + int bound = 0, crtcs_bound = 0; struct drm_crtc *crtc; if (!fb_helper->fb) @@ -1362,12 +1362,12 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper) mutex_lock(&dev->mode_config.mutex); list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { if (crtc->fb) - crtcs_bound = true; + crtcs_bound++; if (crtc->fb == fb_helper->fb) - bound = true; + bound++; } - if (!bound && crtcs_bound) { + if (bound < crtcs_bound) { fb_helper->delayed_hotplug = true; mutex_unlock(&dev->mode_config.mutex); return 0; -- 1.7.10