All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] xf86-video-intel: deactivate unused CRTCs
@ 2011-12-15 12:46 Helge Bahmann
  2012-03-26 12:22 ` Chris Wilson
  0 siblings, 1 reply; 3+ messages in thread
From: Helge Bahmann @ 2011-12-15 12:46 UTC (permalink / raw)
  To: intel-gfx

Hi everyone,

would you mind putting something along the following into xf86-video-intel?

Thanks!
Helge Bahmann

---
Deactivate unused CRTCs

Have intel_crtc_dpms actually do something and deactivate CRTCs
on demand. This allows the X-Server to actually deactivate all
unused CRTCs, avoiding the following bug scenario:

- boot system with only internal LVDS display
- start X
- attach external display
- use xrandr to turn off internal LVDS, and turn on external display
- switch to console
- switch back to X
- use xrandr to turn off external display, turn an internal LVDS

At this point X believes that internal LVDS is active, when in fact it is not 
displaying any image. The root cause appears to be that X and kernel disagree 
on CRTC states.

This problem is verifiable on some notebooks (e.g. ThinkPad T400) but not all. 
I guess this is due to varying crtc selection logic.
---
 src/intel_display.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/src/intel_display.c b/src/intel_display.c
index b6592c4..f771df8 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -324,9 +324,15 @@ mode_to_kmode(ScrnInfoPtr scrn,
 }
 
 static void
-intel_crtc_dpms(xf86CrtcPtr intel_crtc, int mode)
+intel_crtc_dpms(xf86CrtcPtr crtc, int mode)
 {
-
+	struct intel_crtc *intel_crtc = crtc->driver_private;
+	struct intel_mode *modeset = intel_crtc->mode;
+	if (mode == DPMSModeOff) {
+		drmModeSetCrtc(modeset->fd, crtc_id(intel_crtc),
+				0, 0, 0, NULL, 0,
+				NULL);
+	}
 }
 
 static Bool
-- 
1.7.2.5

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

* Re: [PATCH] xf86-video-intel: deactivate unused CRTCs
  2011-12-15 12:46 [PATCH] xf86-video-intel: deactivate unused CRTCs Helge Bahmann
@ 2012-03-26 12:22 ` Chris Wilson
  2012-03-26 13:30   ` Helge Bahmann
  0 siblings, 1 reply; 3+ messages in thread
From: Chris Wilson @ 2012-03-26 12:22 UTC (permalink / raw)
  To: Helge Bahmann, intel-gfx

On Thu, 15 Dec 2011 13:46:28 +0100, Helge Bahmann <helge.bahmann@secunet.com> wrote:
> Hi everyone,
> 
> would you mind putting something along the following into xf86-video-intel?

A few months later... I looked at this and concluded that it is just
working around a kernel bug, which I'm always optimistic will be
resolved in the next release.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

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

* Re: [PATCH] xf86-video-intel: deactivate unused CRTCs
  2012-03-26 12:22 ` Chris Wilson
@ 2012-03-26 13:30   ` Helge Bahmann
  0 siblings, 0 replies; 3+ messages in thread
From: Helge Bahmann @ 2012-03-26 13:30 UTC (permalink / raw)
  To: intel-gfx

On Monday 26 March 2012 14:22:02 Chris Wilson wrote:
> On Thu, 15 Dec 2011 13:46:28 +0100, Helge Bahmann <helge.bahmann@secunet.com> wrote:
> > Hi everyone,
> >
> > would you mind putting something along the following into
> > xf86-video-intel?
>
> A few months later... I looked at this and concluded that it is just
> working around a kernel bug, which I'm always optimistic will be
> resolved in the next release.
> -Chris

Most likely there is a "bug" in my understandig of how X-Server and drm console layer are supposed 
to cooperate:

- how does the kernel layer reliably distinguish between the states "userspace manages display heads 
vs. "kernel console layer manages display heads" ?
- how does the kernel layer reliably detect the "ground state" from which userspace starts setting 
up things ?
- what assumptions may user-space make on the "left-over" state when it takes over responsibility?

I don't think kernel code currently handles these issues too well, resulting in a number of odd 
corner cases when plugging/unplugging displays at the "right" times (while switched away from X, 
while in suspend-to-ram state, while X server resumes but is slow to re-setup things because it got 
paged out...). My best shot at fixing this was to have X not make too many assumptions on the state 
after taking over, and bring everything into a well-defined state.

Could you perhaps briefly explain how the interaction is supposed to look? I would really like to 
provide a more "correct" fix, but I don't fully grasp the intended model so far.

Best regards
Helge
-- 
Dr.-Ing.
Helge Bahmann
Berater
Geschäftsbereich Hochsicherheit
secunet Security Networks AG
Ammonstraße 74
01067 Dresden, Germany
Fon: +49 201 54 54-3586
Fax: +49 201 54 54-1323
Email: helge.bahmann@secunet.com

Sitz: Kronprinzenstraße 30, 45128 Essen
Amtsgericht Essen HRB 13615
Vorstand: Dr. Rainer Baumgart, Thomas Koelzer, Thomas Pleines
Aufsichtsratsvorsitzender: Dr. Karsten Ottenberg
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

end of thread, other threads:[~2012-03-26 13:31 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-15 12:46 [PATCH] xf86-video-intel: deactivate unused CRTCs Helge Bahmann
2012-03-26 12:22 ` Chris Wilson
2012-03-26 13:30   ` Helge Bahmann

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.