* [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.