Change Details

There is code for some yet not fixed bug in XRandRConfig::applyKScreenConfig that should print debug information in case of currentMode is NULL. This situation should not happen but was seen in the past. After printing the debug info, the method directly returned from applyKScreenConfig, omitting all the other potentially useful initializations code that comes afterwards. 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".

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. 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". Analysis of the underlying inconsistency: The debugging led me from libkscreen to xrandr to libxrandr (XRRGetOutputInfo) to the kernel. Here I noticed the following things: 1) outputInfo = XRRGetOutputInfo(outputId) returns some outputInfo that dosn't contain the mode it should contain (concrete the ID 77). It was simply missing. 2) crtcInfo = XRRGetCrtcInfo(outputInfo->crtc) But this crtcInfo-Objekt does reference the mode 77: crtcInfo->mode is 77 3) XRRGetScreenResourcesCurrent() also thinks that mode 77 should be present 4) Because mode 77 was not in outputInfo, XRandROutput::updateModes could not re-add this mode to the map m_modes and XRandROutput::currentMode() had to return NULL. Nothing wrong in updateModes! Because libxrandr in 1) also delegates the above mentioned requests directly to the CRTC-driver of the kernel, I came to the conclusion that the inconsistency behind this situation comes from the kernel. It was also hard to reproduce on side of the kernel since multiple requests returned different results (kind of sporadic). As mentioned above, I could sporadically reproduce the inconsistency with kernel 3.13.0 and as I tried a newer kernel the issue seemed to be vanished. This is the point where I decided to not dig deeper into such an old kernel version. 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. 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.

There is code for some yet not fixed bug in XRandRConfig::applyKScreenConfig that should print debug information in case of currentMode is NULL.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. 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". Analysis of the underlying inconsistency: The debugging led me from libkscreen to xrandr to libxrandr (XRRGetOutputInfo) to the kernel. Here I noticed the following things: 1) outputInfo = XRRGetOutputInfo(outputId) returns some outputInfo that dosn't contain the mode it should contain (concrete the ID 77). It was simply missing. 2) crtcInfo = XRRGetCrtcInfo(outputInfo->crtc) But this crtcInfo-Objekt does reference the mode 77: crtcInfo->mode is 77 3) XRRGetScreenResourcesCurrent() also thinks that mode 77 should be present 4) Because mode 77 was not in outputInfo, XRandROutput::updateModes could not re-add this mode to the map m_modes and XRandROutput::currentMode() had to return NULL. Nothing wrong in updateModes! Because libxrandr in 1) also delegates the above mentioned requests directly to the CRTC-driver of the kernel, This situatI came to the conclusion should not happen but was seen inthat the inconsistency behind this situation comes from the pastkernel. After printing the debug infoIt was also hard to reproduce on side of the kernel since multiple requests returned different results (kind of sporadic). As mentioned above, the method directly returned from applyKScreenConfig,I could sporadically reproduce the inconsistency with kernel 3.13.0 and as I tried a newer kernel the issue seemed to be vanished. omitting allThis is the other potentially useful initializations code that comes afterwardspoint where I decided to not dig deeper into such an old kernel version. From my POV this is wrong and we had situations in which desktop initialization works better if we don't return hereSo 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. That's why I changed "return" into "continue"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.