[Kde-hardware-devel] kscreen overrides xorg.con*

[Àlex Fiestas]

On Friday 21 June 2013 12:53:31 Felix Miata wrote:
> I use many systems for testing various software. None use more than one
> display at once. I use KDE 99%+, Gnome 0%, and others less than 1%. Quite
> often my testing requires specific configuration be maintained across
> various distros and/or versions and/or hardware. Doing this is typically
> facilitated via /etc/X11/xorg.con* far more readily than via xrandr, the
> latter of which often cannot be used due to lack of KMS support for a
> non-Intel, non-AMD, non-NVidia gfxchip.
> 
> In the process of trying to define a problem with Nouveau, DVI-I output and
> CRT, I just spent the better part of two days swapping gfxcards in different
> systems, booting different distros, and restarting X with various config
> options or not, trying to figure out why a two month old Fedora 19's KDE
> behaves the same as other distros while a newer one does not. Finally @
> 2013-06-20 21:03 (GMT-0700) on the Fedora test mailing list, the answer was
> provided. KScreen (reported by yum.log as 0.0.92-1.fc19) went into Fedora
> 19's 4.10.4 sometime in the past two months, while openSUSE 13.1 won't have
> it until it acquires 4.11. 'rpm -e --nodeps kscreen' solved the problem for
> the present.
> 
> The question is, on systems that for whatever reason do have any of
> /etc/X11/xorg.con*, is $SUBJECT necessary?
Yes
> If yes generally:
> 
> A-should it do so even on initial KDE (Plasma?) startup (aka empty ~/.kde/)
> by any given user?
Yes, Xorg gets it wrong most of the times when having more than one screen.
> B-what should it do on any startup directly subsequent to a global X
> configuration change?
We have to assume that all configuration in Xorg are wrong (when it comes to 
things that reaches the user like Fonts, dpi and the like).

Certainly your case is one of those that have not been taken into 
consideration while developing KScreen, reason being that KScreen is focused 
on those users that are not able to write their own Xorg.conf files.

Said that, we do want to cover all cases so let's see what we can do to 
improve your situation.

One solution would be disable kscreen manually in those systems, after all it 
is a manual configuration what is causing your problems. Will that work for 
you?

For KSCreen 1.1, we are considering doing the following to improve the 
situation in virtual machines that could apply in your case as well:

-On first boot if there is only one screen, do nothing since Xorg/Drivers 
generally get this right.

Cheers.