<table><tr><td style="">clutz edited the summary of this revision. <a href="https://phabricator.kde.org/transactions/detail/PHID-XACT-DREV-lx7esb2oydogbdz/" rel="noreferrer">(Show Details)</a>
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D6011" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>CHANGES TO REVISION SUMMARY</strong><div><div style="white-space: pre-wrap; color: #74777D;"><span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">There is code for some yet not fixed bug in XRandRConfig::applyKScreenConfig that should print debug information in case of currentMode is NULL.</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">In XRandRConfig::applyKScreenConfig there is some debug code for a situation that should not really happen (but that was seen in the past) in which currentMode is NULL. After printing the debug info, the method directly returned from applyKScreenConfig, omitting all the other potentially useful initializations code that comes afterwards.<br />
<br />
>From my POV this is wrong and we had situations in which desktop initialization works better if we don't return here. That's why I changed "return" into "continue".<br />
<br />
Analysis of the underlying inconsistency:<br />
<br />
The debugging led me from libkscreen to xrandr to libxrandr (XRRGetOutputInfo) to the kernel. Here I noticed the following things:<br />
<br />
1) outputInfo = XRRGetOutputInfo(outputId) returns some outputInfo that dosn't contain<br />
the mode it should contain (concrete the ID 77). It was simply missing.<br />
<br />
2) crtcInfo = XRRGetCrtcInfo(outputInfo->crtc) But this crtcInfo-Objekt does reference<br />
the mode 77: crtcInfo->mode is 77<br />
<br />
3) XRRGetScreenResourcesCurrent() also thinks that mode 77 should be present<br />
<br />
4) Because mode 77 was not in outputInfo, XRandROutput::updateModes could not re-add<br />
this mode to the map m_modes and XRandROutput::currentMode() had to return NULL.<br />
Nothing wrong in updateModes!<br />
<br />
Because libxrandr in 1) also delegates the above mentioned requests directly to the CRTC-driver of the kernel,</span> <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">This situat</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">I came to the conclus</span>ion <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">should not happen but was seen in</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">that the inconsistency behind this situation comes from</span> the <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">past</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">kernel</span>. <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">After printing the debug info</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">It was also hard to reproduce on side of the kernel since multiple requests returned different results (kind of sporadic).<br />
<br />
As mentioned above</span>, <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">the method directly returned from applyKScreenConfig,</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">I could sporadically reproduce the inconsistency with kernel 3.13.0 and as I tried a newer kernel the issue seemed to be vanished.</span> <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">omitting all</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">This is</span> the <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">other potentially useful initializations code that comes afterwards</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">point where I decided to not dig deeper into such an old kernel version</span>.<br />
<br />
<span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">From my POV this is wrong and we had situations in which desktop initialization works better if we don't return here</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">So in conclusion for me the underlying bug seems to be a kernel bug and not a libkscreen-bug. Maybe in the meanwhile nobody will ever cross the debug code again</span>. <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">That's why I changed "return" into "continue"</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">BUT in my concrete situation libkscreen seems to be able to recover things from this inconsistency and "continuing" instead of "returning" simply improves the behaviour of the complete system</span>.</div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R110 KScreen Library</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D6011" rel="noreferrer">https://phabricator.kde.org/D6011</a></div></div><br /><div><strong>To: </strong>clutz, davidedmundson<br /><strong>Cc: </strong>davidedmundson, plasma-devel, ZrenBot, spstarr, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas<br /></div>