Bug 13502 - [TV]Video output causes external VGA to turn off and on
Summary: [TV]Video output causes external VGA to turn off and on
Status: RESOLVED DUPLICATE of bug 17405
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: low normal
Assignee: Wang Zhenyu
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 13907 (view as bug list)
Depends on:
Blocks: 15000
  Show dependency treegraph
 
Reported: 2007-12-03 10:00 UTC by Andreas Kloeckner
Modified: 2009-02-05 23:13 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Log file without fbc and with modedebug (164.90 KB, text/plain)
2007-12-04 08:12 UTC, Andreas Kloeckner
no flags Details

Description Andreas Kloeckner 2007-12-03 10:00:43 UTC
When I play back video (say totem something.avi), the monitor (a Samsung LCD) attached to my external VGA port turns off and back on, as if synchronizing to a new mode. Not horrible, but annoying.

System info is same as in bug #13500. Might be related. :?
Comment 1 Michael Fu 2007-12-03 23:20:24 UTC
again, would you please try if turn framebuffer compression off helps?
Comment 2 Andreas Kloeckner 2007-12-04 08:11:29 UTC
Turning off fbc does not help this (but improves animation smoothness in Compiz a *lot*).
Comment 3 Andreas Kloeckner 2007-12-04 08:12:35 UTC
Created attachment 12930 [details]
Log file without fbc and with modedebug
Comment 4 tomg 2007-12-06 19:19:55 UTC
I am also experiencing this bug.  I am using Fedora 8 (with all updates applied) on an HP slimline s7700y with an intel 945GM graphics and a Dell E172FP LCD.  Here is the output from lscpi -v

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA])
        Subsystem: Hewlett-Packard Company Unknown device 2a44
        Flags: bus master, fast devsel, latency 0, IRQ 19
        Memory at ffa80000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at ec00 [size=8]
        Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Memory at ffa40000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
        Capabilities: [d0] Power Management version 2

When I switch back to the i810 driver, I do not see this issue with totem.
Comment 5 Jesse Barnes 2007-12-11 17:16:05 UTC
Yeah, our mode setting code disables outputs and CRTCs a bit too easily.  We need some improvements there (may require server changes too).

Andreas, can you file a new bug for the framebuffer compression sluggishness problem?  You can assign it to me.
Comment 6 Andreas Kloeckner 2007-12-11 17:27:50 UTC
Wrt the sluggishness issue--once many applications are open, it's just as sluggish as before. Don't think it made a difference. Sorry for the noise.
Comment 7 Hong Liu 2008-02-28 01:18:04 UTC
Would you please elaborate on what steps you did to trigger the problem?

I've tried to use totem to play something on my 945GM machine, no off/on on external monitor.

Thanks,
Hong
Comment 8 Andreas Kloeckner 2008-02-28 06:44:18 UTC
Steps to reproduce:

1. Run totem. (no need to specify a movie file or anything)

My version of totem is 2.20.3. Trying this with a cheapo external LCD like mine probably helps. (a SAMSUNG SyncMaster 940B)

(fyi, by now i'm on debian version 2.2.1-1 of the driver)
Comment 9 Hong Liu 2008-02-28 17:25:30 UTC
Would you please ignore your TV output in your xorg.conf?

What you should do is:

1. add Option "Monitor-TV" "TV" to your device section.
2. add a monitor section
Section "Monitor"
        Identifier      "TV"
        option  "ignore" "true"
EndSection

Thanks,
Hong
Comment 10 Andreas Kloeckner 2008-03-04 08:30:43 UTC
That does away with the screen blanking. Nice.

However, while I don't really understand what those options do, it seems like they disable TV-Out, which I use occasionally. Do I have to take them out every time I want to use the S-Video port?
Comment 11 Hong Liu 2008-03-04 17:18:37 UTC
(In reply to comment #10)
> That does away with the screen blanking. Nice.
> 
> However, while I don't really understand what those options do, it seems like
> they disable TV-Out, which I use occasionally. Do I have to take them out every
> time I want to use the S-Video port?
> 

Yes, these options disable the TV output. I am afraid you have to remove these options when you want to use S-Vido.

The problem is: When you execute the xrandr tool, it will try to detect the status of each output. For the TV output, we must find a pipe (which is already used for your external monitor) for it to do a status detection. So your external VGA will be disabled at that time.

Nanhai, is there any other ways to do a TV output status detection?

Thanks,
Hong
Comment 12 Andreas Kloeckner 2008-03-04 17:38:07 UTC
Using ltrace, I found out that totem makes these two calls to Xrandr. Do these necessarily involve detecting whether a TV is connected?

XRRQueryExtension(0x80bced0, 0xbff4fa58, 0xbff4fa54, 0x8072d41, 0x841e0c0) = 1
XRRGetScreenInfo(0x80bced0, 151, 0xbff4fa54, 0x8072d41, 0x841e0c0) = 0x80c1ee0
Comment 13 Hong Liu 2008-03-04 19:13:46 UTC
(In reply to comment #12)
> XRRGetScreenInfo(0x80bced0, 151, 0xbff4fa54, 0x8072d41, 0x841e0c0) = 0x80c1ee0
> 

Yes, this call causes the symptom, the call chain is:
ProcRRGetScreenInfo -> RRGetInfo -> xf86RandR12GetInfo12 -> xf86ProbeOutputModes

We will do connection status detection when probing output modes.

Thanks,
Hong
Comment 14 Ross Burton 2008-03-05 12:36:12 UTC
*** Bug 13907 has been marked as a duplicate of this bug. ***
Comment 15 Hong Liu 2008-03-14 02:13:22 UTC
(In reply to comment #4)
> When I switch back to the i810 driver, I do not see this issue with totem.
> 

Does i810 driver support dual-head display? what is the xrandr -q output when using i810 driver.

I am afraid this issue will exist until we can find any other way to detect TV connection status.

Comment 16 Wang Zhenyu 2009-02-05 23:13:34 UTC

*** This bug has been marked as a duplicate of bug 17405 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.