Bugzilla – Bug 27169
[gm45] the console output is not full screen due to spurious S-Video TV detection
Last modified: 2012-03-27 07:04:11 UTC
Distro: gentoo amd64
xf86-video-intel: 2.10.902 (2.11 RC2)
With kernel 2.6.32 I had no problems. I started having such a problem since earlier .33 rcs. Nothing is attached to the laptop.
xrandr shows TV output is on when I have such a issue (otherwise it is usually off).
This laptop (Samsung X360) doesn't even have a TV output!
- a photo of my laptop screen showing the problem
- dmesg (drm.debug=0x04)
- xrandr -q --verbose
- echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom && cat
/sys/devices/pci0000:00/0000:00:02.0/rom > vbios.dump
Created attachment 34203 [details]
A photo of the screen showing the problem
Created attachment 34204 [details]
Created attachment 34205 [details]
Created attachment 34206 [details]
Created attachment 34207 [details]
Created attachment 34208 [details]
The error is all due to the spurious TV detection; sometimes it is declared connected and sometimes disconnected. There has been some work in this area, but I can't find a patch that precisely matches.
This I think is promising for the misdetection:
Author: Zhenyu Wang <email@example.com>
Date: Tue Mar 30 14:06:33 2010 +0800
drm/i915: implement multifunction SDVO device support
With new intel_encoder/intel_connector structure change, each supported
connector type on SDVO device will be created as a new 'intel_connector',
and all attached to one 'intel_encoder' for its SDVO port.
The SDVO encoder will handle SDVO protocol stuff, and each connector does
its own part of work now, like detection is only to check if current active
output is itself, etc.
Update since last submit:
- Fixed SDVO TV property creation failure by incorrect set target output call
Signed-off-by: Zhenyu Wang <firstname.lastname@example.org>
darkbasic, can you check against the current bits to save me a wild goose chase?
Thank you for answering.
My adsl stopped working and I use my mobile phone to connect to the internet, so I can't download an entire kernel with git. Instead I downloaded a 2.6.35-rc5 tarball which is a lot smaller (I think this patch is in 2.6.35-rc5, am I right?)
I think it's the same commit I read of on phoronix in the 2.6.35-rc1 (or rc2?) changelog.
Unfortunately it did not solve the problem :(
This damn problem forces me to reboot and reboot and reboot again until it does not turn on the tv output, because if the tv output is on kde freezes when I start it.
I also cannot close the lid because otherwise the x server will freeze when I will open it.
I also cannot use latest stable xorg server because it gives me random freezes and xrandr does not work with it.
I also cannot change the display brightness without some ugly workarounds (but maybe there is a patch which will solve it) and I cannot watch movies on my tv because the intel driver does not work at 1360x768, even if I create the modeset.
The intel driver does not simply allow me to use my laptop.
It's funny to know that my laptop does not even have a tv out connector!
Is there a patch to DELETE tv out support from the intel driver?
I'm too much tired of this problem.
Yeah, should be easy enough to delete your TV output. Just comment out the line that calls tv_init in drivers/gpu/drm/i915/intel_display.c (intel_modeset_init I think).
Ah, I've seen other bug reports were .33 was reporting spurious TV connections fortunately since resolved. Can you please attach a drm.debug dmesg with current bits and lets have a look at the current status. Thanks.
Created attachment 37350 [details]
drm.debug for kernel 2.6.35-rc6
Distro: gentoo amd64
libdrm: git master
I attached drm.debug-2.6.35-rc6
Eek, still occasionally detecting the S-Video out.
Yes, it does :-(
Is there someone working on it?
If you need to test patches or if you want more logs let me know, I definitely want it fixed.
*** Bug 29314 has been marked as a duplicate of this bug. ***
2.6.36 (today's git snapshot) is stil bugged...
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>
Unfortunately drm-intel-fixes doesn't solve anything: still occasionally detecting the S-Video out :(
Oh well. Partly because it's not even an SDVO device...
!!!!!!!!*SOLVED* *SOLVED* *SOLVED* *SOLVED*!!!!!!!!
In my desperate search for a workaround I found a patch which does work: https://patchwork.kernel.org/patch/90982/
Unfortunately it has been reverted (http://email@example.com/msg00262.html) because Eric Anholt told it was bad (see the previous link).
I slightly modified it to apply against 2.6.38/drm-intel-fixes and it just works, 100% reliable!
If someone else is interested I uploaded the updated patch.
Created attachment 42814 [details]
Ok, the reason the patch was dropped is that we don't know whether it just turns off TV detection completely. Are you able to test hooking up your machine to a TV?
I can't because my laptop doesn't have a TV out connector.
What's the state of this bugreport? So far Archlinux and some other distributions have been carrying around this patch for ages without anyone complaining that the TV-Out doesn't work on his GM45. I don't think you'll find someone with GM45 and TV-Out anyways.
> So far Archlinux and some other
> distributions have been carrying around this patch for ages without anyone
> complaining that the TV-Out doesn't work on his GM45.
In this case it should go upstream I think.
Up! Daniel schedule this patch for -next and it should land on 3.5.
Awesome, thanks for pushing for mainline inclusion.
Queued for 3.5, I'll close this one as a duplicate of the bug I have in the commit message.
*** This bug has been marked as a duplicate of bug 25913 ***