Summary: | [915] querying Randr enables LVDS output. Spurious TV detection?! | ||
---|---|---|---|
Product: | DRI | Reporter: | Uwe Kleine-König <uwe+bugsfreenode> |
Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Status: | CLOSED INVALID | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | intel-gfx-bugs, ricardo.vega, uwe+bugsfreenode |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
URL: | http://patchwork.freedesktop.org/patch/51176/ | ||
Whiteboard: | |||
i915 platform: | I915GM | i915 features: | display/Other |
Attachments: |
Description
Uwe Kleine-König
2014-12-06 14:34:42 UTC
Created attachment 110508 [details]
dmesg of boot, with drm.debug=0xe
Adding video=SVIDEO-1:d as kernel parameter seems to fix (or work around) the issue. (Thanks to Chris Wilson for pointing that out in #31519) What's the output of that sequence of xrandr? ( xrandr --output LVDS1 --off; xrandr --current; xrandr ) >& attachme.txt Created attachment 110540 [details]
xrandr --output LVDS1 --off; xrandr --current; xrandr
This is the requested output. Note that this command sequence doesn't trigger the problem, i.e. the LVDS output stays off.
See next attachment that was generated with a sleep between the commands.
Not sure this is related, but I got the following in dmesg (during login):
[ 41.996076] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 26
[ 41.996089] Raw EDID:
[ 41.996097] 00 ff ff ff ff ff ff 00 4c 2d 6b 03 36 32 49 4b
[ 41.996104] 17 13 01 03 0e 37 22 a0 2a fe 21 a8 53 37 ae 24
[ 41.996110] 11 50 54 bf ef 80 a9 40 81 80 81 40 71 4f 01 01
[ 41.996116] 01 01 01 01 01 01 28 3c 80 a0 70 b0 23 40 30 20
[ 41.996123] 36 00 26 57 21 00 00 1a 00 00 00 fd 00 38 4b 1e
[ 41.996129] 51 11 00 0a 41 ff ff ff ff ff ff ff ff ff ff ff
[ 41.996135] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 41.996141] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Created attachment 110541 [details]
xrandr --output LVDS1 --off; sleep 2; xrandr --current; sleep 2; xrandr
This triggers the bug, the LVDS output is reenabled during the last call to xrandr.
From #intel-gfx 1417982504 < ickle> ukleinek: I suspect that it is you DE responding to the RandR notifications and resetting the outputs [...] 1417986438 * ukleinek goes, installs openbox and plugs the external monitor into the X41 again 1417987536 < ukleinek> ickle: doesn't happen on openbox 1417987648 < ukleinek> ickle: output of xrandr --current and xrandr are identical then. (In reply to Uwe Kleine-König from comment #6) > From #intel-gfx > > 1417982504 < ickle> ukleinek: I suspect that it is you DE responding to the > RandR notifications and resetting the outputs > [...] > 1417986438 * ukleinek goes, installs openbox and plugs the external monitor > into the X41 again > 1417987536 < ukleinek> ickle: doesn't happen on openbox > 1417987648 < ukleinek> ickle: output of xrandr --current and xrandr are > identical then. In light of this, do we still consider this a bug? (In reply to Jani Nikula from comment #7) > (In reply to Uwe Kleine-König from comment #6) > > From #intel-gfx > > > > 1417982504 < ickle> ukleinek: I suspect that it is you DE responding to the > > RandR notifications and resetting the outputs > > [...] > > 1417986438 * ukleinek goes, installs openbox and plugs the external monitor > > into the X41 again > > 1417987536 < ukleinek> ickle: doesn't happen on openbox > > 1417987648 < ukleinek> ickle: output of xrandr --current and xrandr are > > identical then. > > In light of this, do we still consider this a bug? No answer, presuming it isn't. There is still the issue that S-Video fluctuates between unknown and disconnected which causes the undesired behaviour, i.e. it would be fixed by: diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c index 8b9d325bda3c..f15683a489fb 100644 --- a/drivers/gpu/drm/i915/intel_tv.c +++ b/drivers/gpu/drm/i915/intel_tv.c @@ -1337,12 +1337,12 @@ intel_tv_detect(struct drm_connector *connector, bool force) connector_status_disconnected : connector_status_connected; } else - status = connector_status_unknown; + status = connector->status; drm_modeset_drop_locks(&ctx); drm_modeset_acquire_fini(&ctx); } else - return connector->status; + status = connector->status; if (status != connector_status_connected) return status; There's just a small debate over what is the correct status value to return when the output detection is forced but we are unable to do so. I think not wilfully converting to unknown is beneficial. Please try kernel v4.4. The request to test with latest kernel was made months ago, please update kernel and update bug. If there is no response within a month the bug will be closed uwe+bugsfreenode@kleine-koenig.org This bug is now been closed because of the lack of activity and response from submitter in order to test in recent configuration. Closing bug |
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.