Comment 32 for bug 898390

Revision history for this message
In , linux fan (linuxscratch) wrote :

(In reply to comment #25)
> (to linuxfan mostly), I tried giving the supplied patch a try, and it doesn't
> seem to work. See downstream tracking bug,
> https://bugzilla.redhat.com/show_bug.cgi?id=607180
>
> Any suggestions?

Er, umphhh, uh,

In the first place, startkde, which is a shell script that is generated by startkde.cmake, has: "kcmrandrrc Display ApplyOnStartup false" which caused (at least for me) no possibility to apply the settings on startup no matter what.

In the second place, there never is or was any file named kcmrandrrc in any subdirectory of ~/.kde and so it would never be read no matter what.

In the third place, even if the first two obstacles were magically overcome, kdostartupconfig4, which is generated from kdostartupconfig.cpp, has absolutely no method for parsing krandrrc in ~/.kde subdir and thus there is no magic key to unlock the magic black box.

Those are the facts with respect to my particular encounter.

Looking at comment #7 , I found that setting particular environment variables durin the "login" had the effect of utimately executing an xrandr command with the settings that I wanted to be applied.

Further tearing out hair led me to the patch which worked in my particular encounter.

I had only one screen which was named "Output default" by kde "display settings" which appeared in the krandrrc file in the subdir of ~/.kde.

So, for me, the patch altered the name kcmrandrrc to krandrrc which is a file that actually exists. It then plows through that file to parse out the display settings. It is possible that in other installations, the format of the entries in krandrrc may be vastly different than what I encountered.

Due to there being only 80 votes on this bug, I can only imaging that everybody else has a magic system, and I do not.