Comment # 2 on bug 971885 from Felix Miata

(In reply to Egbert Eich from comment #1)
> As described in boo#929016, with 'startx startkde' none of the xinitrc
> scripts are run by xinit as these scripts are replaced by 'startkde'. Thus

To be clear, that bug is distinguishable from this:

    This applies only when using Intel driver

    This applies to X regardless whether using startx or KDM[3,4]

> 'startkde' would have to do it which IHMO never happened.
> With 'WINDOWMANAGER=startkde startx' the xinitrc scripts are run and the
> files in /etc/X11/xinit/xinitrc.d/ are run which I've verified on a TW
> 20160208 and a TW 20160318.
> Setting the video mode through a script in there also works.

At the point I began to bisect this, I thought I was looking at a KDE3-only
bug, and it remains my primary interest to see that what used to work in KDE3
continues to work as in the past, with the content of /etc/X11/xinit/xinitrc.d/
in effect when a DE session completes initializing, no matter whether started
by KDM or startx. ATM, with /etc/X11/xinit/xinitrc.d/setup containing:

    xrandr --dpi 108 --output VGA1 --mode 1680x1050

Results using 90.1 PPI 22" LCD, 1680x1050 native as per EDID:

Host t2240, Intel gfx, TW32 20160203#1, vga=791 video=1440x900@60 on cmdline,
KDE3:
    (simply) startx:    1680x1050@108 aka success
    from KDM3:    1680x1050@108 aka success

Host t2240, Intel gfx, TW32 20160203#2, vga=791 video=1440x900@60 on cmdline,
Plasma5:
    (simply) startx:    1680x1050@108 aka success
    from KDM4:    1680x1050@108 aka success

Host gx270, Intel gfx, TW32 20160205, vga=791 video=1440x900@60 on cmdline,
Plasma5:
    (simply) startx:    1680x1050@108 aka success
    from KDM4:    1680x1050@108 aka success

Host gx28b, Intel gfx, TW32 20160303, vga=791 video=1440x900@60 on cmdline,
Plasma5:
    (simply) startx:    1440x900@96 aka fail
    from KDM4:    1440x900@96 aka fail

Host gx760, Intel gfx, TW64 20160303, vga=791 video=1440x900@60 on cmdline,
Plasma5:
    (simply) startx:    1440x900@96 aka fail
    from KDM4:    1440x900@96 aka fail

Host gx260, Intel gfx, TW32 20160307, vga=791 video=1440x900@60 on cmdline,
KDE3:
    (simply) startx:    1440x900@96 aka fail
    from KDM3:    1440x900@96 aka fail

With:
    xrandr --dpi 108 --output VGA1 --mode 1680x1050

Host fi965, Radeon gfx, TW64 20160222, vga=791 video=1440x900@60 on cmdline,
Plasma5:
    (simply) startx:    1680x1050@108 aka success
    from KDM4:    1680x1050@108 aka success

Host gx28b, Radeon gfx, TW32 20160303, vga=791 video=1440x900@60 on cmdline,
Plasma5:
    (simply) startx:    1680x1050@108 aka success
    from KDM4:    1680x1050@108 aka success

Host hpg33, Radeon gfx, TW64 20160318, vga=791 video=1440x900@60 on cmdline,
KDE3:
    (simply) startx:    1680x1050@108 aka success
    from KDM3:    1680x1050@108 aka success

With:
    xrandr --dpi 108 --output DVI-I-1 --mode 1680x1050

Host big31, Nouveau gfx, TW64 20160307, vga=791 video=1440x900@60 on cmdline,
Plasma5:
    (simply) startx:    1680x1050@108 aka success
    from KDM4:    1680x1050@108 aka success

> For KDE (like for most other desktop sessions) the setting is overridden

Overriding global configuration by default is one reason why I spend little
time exposing myself to environments other than KDE* and TDE. I've observed
nothing like universality in any mechanism to make desktop objects usably sized
except via text editor in /etc.X11. Plasma I got figured out how to workaround.
KDE3 and TDE simply obeyed, and both do still, as long as not using Intel gfx.

> after having been set by one of the xinit scripts by the desktop session
> which stores and restores the user preferred video mode (in most cases the
> native mode of the display). When looking through the messages 'startx'
> dumps to the console, you will also find this mentioned in there.
> This is the behaviour of a desktop *session* and has nothing to do with X.
> This behaviour is desired by most users and will likely not change.

I'm not most users. I'm among the users with below median eyesight, and an
advocate regarding a11y and u7y issues. I configure early and globally in order
that initial sessions do not present the usability and accessibility
inhibitions to finding and suitably changing settings into a usable state
represented by the median or better eyesight developer majority's preferred
tiny text and icons that have been becoming progressively more impeding as
wider diversity of and higher average screen densities have proliferated.

Thus, ever since krandr first appeared in a KDE release, in order to rely on
global X configuration, I've employed the following configuration setting in an
appropriate location or locations, kdedrc and/or kded5rc:

    [Module-kscreen]
    autoload=false

This has overall been a fairly reliable means of having global Xorg settings
obeyed in Plasma sessions that hasn't been necessary in KDE3 or TDE.

> It should have worked on earlier TW versions the same way - in fact, I have
> verified this - if it hasn't for you, something else was broken which has
> gotten fixed in the mean time.

I'm unsure what "it" refers to here. It used to be that as long as broken
features were not involved, such as https://bugs.kde.org/show_bug.cgi?id=317929
or bug 771521, that global X configuration capability was equivalent between
xrandr among /etc/X11/ scripts and /etc/X11/xorg.con*, at least as regards
KDE3, TDE and Plasma*.

> In any case, let's reassign this to the KDE folks who may be able to give
> you more insight. I'm sure, however, that all other desktop sessions behave
> the same.

As the breakage is Intel gfx dependent, and affects KDE3 too, how could KDE
people possibly help here? Initial indication from upstream is this is some
sort of timing problem.