Comment # 3 on bug 971885 from Egbert Eich

(In reply to Felix Miata from comment #2)
> (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

I very much doubt this as I have conducted my tests on an AMD only system:
it has an AMD GPU so no Intel graphics and a discrete Radeon card.

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

This is correct.

> 
> > '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:

The list below is not really relevant, what you need to do is:
xrandr -q >> /tmp/startx.log
xrandr --dpi 108 --output VGA1 --mode 1680x1050 &>> /tmp/startx.log
xrandr -q >> /tmp/startx.log

Once the system has started, do another
xrandr -q >> /tmp/startx.log 
from a terminal window.

> 
> 	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

To set the console mode, you need to specify the output together with the
'video=' command. The output names differ between X and KMS. The KMS once you
obtain by looking at /sys/class/drm/*. Remove the 'card<N>-' in front.

> 
> > 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.

Ok, I do understand this and you have a point there. There was a time when
desktops were doing a lot to support people with certain impairments. I'm not
sure how much effort is still put into this. Regarding low eyesight, it could
be that there is a believe that it is good enough if people have their desktop
set up once as it will (should!) remember its previous setting and restore this
next time around.
This doesn't solve the issue that the display manager (the KDMs, GDMs. or SDDMs
of this world) may have a resolution not suitable for vision impaired people.

> 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

Right - how long did you have to google to find that?

> 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*.

Yes. But you need to complain to the KDE folks about this. You initially
complained to the X Window System folks. 

> > 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.

I'm fairly certain that this is not Intel specific. As mentioned, I've seen
this on AMD graphics as well. I will conduct some more tests to be certain once
I find time.