Bug 112340 - Properties neither applied nor reset after monitor hotplug
Summary: Properties neither applied nor reset after monitor hotplug
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: not set minor
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-19 16:47 UTC by Simon Richter
Modified: 2019-11-29 19:50 UTC (History)
1 user (show)

See Also:
i915 platform: IVB
i915 features: display/HDMI


Attachments
Kernel log (864.67 KB, text/plain)
2019-11-20 10:48 UTC, Simon Richter
no flags Details

Description Simon Richter 2019-11-19 16:47:54 UTC
I have a laptop with HD4000 display connected to an AV receiver. When the receiver is turned on or off, the display link is interrupted shortly to communicate that the EDID has changed (in standby mode, the monitor is passed through directly).

Since the receiver adds an EIA extension block, the normal modes are interpreted as EIA modes with limited RGB range, but the respective bit is not set in the output stream in Automatic mode, so I have to manually specify Full range by setting the property through xrandr.

This property setting is conserved over the cable hotplug events, but not reapplied to the data stream, i.e. if I turn the receiver off and back on, the properties show Full range, but no indication to use full range is added to the stream.

Setting the property to Full again has no effect, as that is the current value, so no change. In order to get full range output again I have to reset the property to Automatic and then to Full again.

If the properties should be reset during hotplug events, that should be done; if they shouldn't be reset, they should be reapplied after the stream is reestablished.
Comment 1 Chris Wilson 2019-11-19 16:52:19 UTC
randr properties are pass-through from the kernel. When RRGetInfo() is called we fill in the details with a call to drmModeGetConnector. So X here is just reflecting the state stored in the kernel.
Comment 2 Ville Syrjala 2019-11-19 17:09:57 UTC
How old is your kernel? Try with something recent if it already isn't.

To see what's going on please do the following:
1. reboot and pass drm.debug=0xe to the kernel cmdline (may need to also pass eg. log_buf_len=2M to make sure the log doesn't get cut off)
2. configure the prop
3. toggle the receiver off+on
4. collect dmesg and attach to the bug
Comment 3 Simon Richter 2019-11-20 10:48:11 UTC
Created attachment 146002 [details]
Kernel log
Comment 4 Simon Richter 2019-11-20 10:49:26 UTC
Hm, it seems that this only happens when coming out of standby while the receiver is off, when the receiver is turned on afterwards.

The kernel log has the following events:

 - Boot [0 - 24]
 - X startup [36 - 39]
 - disabling the internal LVDS display [57 - 62]
 - setting quantization range from Automatic to Full [72 - 73]
 - turning the receiver off and on [81 - 114]
 - forcing DPMS off and on [272 - 288]
 - forcing DPMS off, turning off the receiver, forcing DPMS on and turning on the receiver [306 - 366]

The error manifests in the last case only, i.e. when the display comes out of standby while the receiver is still off.

There seems to be a lot happening after the receiver is turned on, which kind of explains why it often takes several seconds until I can get a picture, especially the first time I cycled the receiver the whole experiment took thirty seconds until I had a stable picture again.
Comment 5 Lakshmi 2019-11-21 11:10:05 UTC
Simon, Can you please verify the issue with drmtip https://cgit.freedesktop.org/drm-tip?
Comment 6 Martin Peres 2019-11-29 19:50:30 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/621.


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.