All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/fb-helper: delay hotplug handling when partially bound
@ 2012-06-15  9:01 Daniel Vetter
  2012-06-15  9:32 ` Chris Wilson
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Vetter @ 2012-06-15  9:01 UTC (permalink / raw)
  To: Dave Airlie; +Cc: Daniel Vetter, DRI Development

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 <M.A.Nikulin@gmail.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 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

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] drm/fb-helper: delay hotplug handling when partially bound
  2012-06-15  9:01 [PATCH] drm/fb-helper: delay hotplug handling when partially bound Daniel Vetter
@ 2012-06-15  9:32 ` Chris Wilson
  2012-07-18 15:52   ` Daniel Vetter
  0 siblings, 1 reply; 4+ messages in thread
From: Chris Wilson @ 2012-06-15  9:32 UTC (permalink / raw)
  To: Dave Airlie; +Cc: Daniel Vetter, DRI Development

On Fri, 15 Jun 2012 11:01:22 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> 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 <M.A.Nikulin@gmail.com>
> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] drm/fb-helper: delay hotplug handling when partially bound
  2012-06-15  9:32 ` Chris Wilson
@ 2012-07-18 15:52   ` Daniel Vetter
  2012-07-20  1:16     ` Dave Airlie
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Vetter @ 2012-07-18 15:52 UTC (permalink / raw)
  To: Chris Wilson, Dave Airlie; +Cc: Daniel Vetter, DRI Development

On Fri, Jun 15, 2012 at 10:32:20AM +0100, Chris Wilson wrote:
> On Fri, 15 Jun 2012 11:01:22 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > 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 <M.A.Nikulin@gmail.com>
> > Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Hi Dave,

This one here fixes a bug where fbcon clobbers outputs even though a real
drm client is still displaying things. Please include for 3.6.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] drm/fb-helper: delay hotplug handling when partially bound
  2012-07-18 15:52   ` Daniel Vetter
@ 2012-07-20  1:16     ` Dave Airlie
  0 siblings, 0 replies; 4+ messages in thread
From: Dave Airlie @ 2012-07-20  1:16 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: Daniel Vetter, DRI Development

On Thu, Jul 19, 2012 at 1:52 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Jun 15, 2012 at 10:32:20AM +0100, Chris Wilson wrote:
>> On Fri, 15 Jun 2012 11:01:22 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> > 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 <M.A.Nikulin@gmail.com>
>> > Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>
> Hi Dave,
>
> This one here fixes a bug where fbcon clobbers outputs even though a real
> drm client is still displaying things. Please include for 3.6.
>

Okay merged to -next.

Dave.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-07-20  1:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-15  9:01 [PATCH] drm/fb-helper: delay hotplug handling when partially bound Daniel Vetter
2012-06-15  9:32 ` Chris Wilson
2012-07-18 15:52   ` Daniel Vetter
2012-07-20  1:16     ` Dave Airlie

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.