Bug 49789 - External monitor flickers on xrandr or cat /sys/class/drm/card0-VGA-1/status
Summary: External monitor flickers on xrandr or cat /sys/class/drm/card0-VGA-1/status
Status: RESOLVED NOTABUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-11 04:37 UTC by Harald Judt
Modified: 2012-05-15 02:01 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg.log (53.37 KB, text/plain)
2012-05-11 04:37 UTC, Harald Judt
no flags Details
xdpyinfo (24.92 KB, text/plain)
2012-05-11 04:38 UTC, Harald Judt
no flags Details

Description Harald Judt 2012-05-11 04:37:34 UTC
Created attachment 61441 [details]
Xorg.log

This issue is not reproducible with every external monitor, as far as I could determine only projectors are concerned:

When I connect a monitor/projector to the VGA port of the Lenovo T400 and perform "xrandr" or "cat /sys/class/drm/card0-VGA-1/status", the external monitor flickers (parts of the screen black out horizontally). Since I use a script which performs these commands periodically to detect whether the monitor is still connected, this is obviously very annoying.

Changing the power profile doesn't have any effect.

lspci:
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 [Mobility Radeon HD 3400 Series] (prog-if 00 [VGA controller])
        Subsystem: Lenovo Device 210e
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 45
        Region 0: Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Region 1: I/O ports at 2000 [size=256]
        Region 2: Memory at cfff0000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at cff00000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000fee0100c  Data: 41a1
        Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Kernel driver in use: radeon
Comment 1 Harald Judt 2012-05-11 04:38:17 UTC
Created attachment 61442 [details]
xdpyinfo
Comment 2 Alex Deucher 2012-05-11 07:50:48 UTC
The driver uses load detection to see if a monitor is connected if it does not provide an EDID.  The process of detecting load on the pins will cause a momentary distortion of the image in some cases.  There's not much else you can do if you want to be able to detect the presence or lack of a monitor without an EDID.  BTW, for monitors with an EDID the driver will automatically generate events when they are connected or disconnected so there is no need to poll.  Unfortunately, load detection is the only option for analog monitors that have no EDID.  Digital monitors will generate a hotplug interrupt.
Comment 3 Harald Judt 2012-05-11 08:10:30 UTC
Can I somehow find out (log files, whatever), whether the monitor has an EDID or not, after it has been connected? Because then I could turn off the polling for the time being, or at least reduce the polling interval.

With regard to the events: I've tried using udev to react to the hotplug events, but it wouldn't work reliably. It would successfully recognize a monitor the first time, but fail to trigger on disconnect or later connect attempts. So unfortunately, my approach was and probably is the only viable/reliable here to do it automatically.
Comment 4 Alex Deucher 2012-05-11 10:23:56 UTC
(In reply to comment #3)
> Can I somehow find out (log files, whatever), whether the monitor has an EDID
> or not, after it has been connected? Because then I could turn off the polling
> for the time being, or at least reduce the polling interval.
> 

You can check the `xrandr --verbose` output.

> With regard to the events: I've tried using udev to react to the hotplug
> events, but it wouldn't work reliably. It would successfully recognize a
> monitor the first time, but fail to trigger on disconnect or later connect
> attempts. So unfortunately, my approach was and probably is the only
> viable/reliable here to do it automatically.

What kernel are you using?  There were some problems with disconnects not getting detected in certain cases with that were fixed in 3.3 IIRC.
Comment 5 Harald Judt 2012-05-15 02:01:59 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Can I somehow find out (log files, whatever), whether the monitor has an EDID
> > or not, after it has been connected? Because then I could turn off the polling
> > for the time being, or at least reduce the polling interval.
> > 
> 
> You can check the `xrandr --verbose` output.

Thanks, that will help.

> > With regard to the events: I've tried using udev to react to the hotplug
> > events, but it wouldn't work reliably. It would successfully recognize a
> > monitor the first time, but fail to trigger on disconnect or later connect
> > attempts. So unfortunately, my approach was and probably is the only
> > viable/reliable here to do it automatically.
> 
> What kernel are you using?  There were some problems with disconnects not
> getting detected in certain cases with that were fixed in 3.3 IIRC.

I've tried again with 3.4.0-rc7, but nothing changed. This is on a different system though, so I filed another bug #49943.


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.