System arch: i686
Machine: Thinkpad X41
When I run
xrandr --output LVDS1 --off
the LVDS output goes off (as expected), but then running
reenables it again (and thus behaves like
). This didn't happen on Debian's linux-image-2.6.32-5-686 (2.6.32-27) kernel.
Created attachment 40174 [details]
As requested by ickle in #intel-gfx the resulting kernel messages after:
# echo 0xe > /sys/module/drm/parameters/debug
$ xrandr --output LVDS1 --off
# echo 0 > /sys/module/drm/parameters/debug
Spurious SDVO TV detection. It comes, it goes, the display is reconfigured.
This [applied to -fixes] should fix the transient SDVO detections:
Author: Chris Wilson <email@example.com>
Date: Tue Jan 25 15:00:01 2011 +0000
drm/i915/sdvo: If at first we don't succeed in reading the response, wait
We were not pausing after detecting the response was pending and so did
not allow the hardware sufficient time to complete before aborting. This
lead to transient failures whilst probing SDVO devices.
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Chris Wilson <firstname.lastname@example.org>
Just tested current -fixes and this isn't resolved for me.
Can you attach the debug dmesg from early in the boot? I confused the integrated TV with an SDVO TV device on another bug, and I may have done the same here as well...
Created attachment 42888 [details]
dmesg with drm.debug=0xe
for your rainy afternoons :-)
One workaround would be to pass video=SVIDEO-1:d on the boot commandline. (Just fyi.)
Created attachment 70005 [details] [review]
fixup TV load detect
While strolling through docs I've noticed that we don't implement TV load detection according to what docs would have us do.
This patch attempts to fix that, but due to lack of hw totally untested. Testing feedback highly welcome.
(In reply to comment #8)
> This patch attempts to fix that, but due to lack of hw totally untested.
> Testing feedback highly welcome.
It must be fixed, right Uwe? :)
on Jul 28, 2016 at 18:19:43.
(provided by the Example extension).