| Summary: | External monitor flickers on xrandr or cat /sys/class/drm/card0-VGA-1/status | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Harald Judt <h.judt> | ||||||
| Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||
| Status: | RESOLVED NOTABUG | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | medium | ||||||||
| Version: | XOrg git | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
Created attachment 61442 [details]
xdpyinfo
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. 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. (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. (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.
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