Comment # 9 on bug 971885 from Felix Miata

Created attachment 670107 [details]
Xorg.0.log from TW host big41's DVI output connector to HDMI input on HDTV

(In reply to Egbert Eich from comment #6)
> Felix, I've just retested this: setting the mode thru a script in
> /etc/X11/xinit/xinitrc.d/ works on Intel as well. It is very obvious though
> that the Plasma5 desktop will reset this to whatever has been configured in
> the user session.

Except that here that does not happen due to 

    [Module-kscreen]
    autoload=false

With global configuration set, users ought not need to make resolution or DPI
changes. Admins ought to both have control and be obeyed. Admins should not be
forced to start a user's first session and mouse around to make it suitable for
each user. If a user is subsequently allowed to customize, it's his own fault
if he fouls up his session only.

But this is dodging the issue, regressed behavior, behavior that differs
according to gfx driver. Your lack of DPI mention makes it look to me like you
are focused on resolution, and may not yet have closely enough duplicated my
conditions here in experiencing this bug (which Chris Wilson in upstream bug
seems to have been able to do ~27 hours after bug was filed).

#1 - desired framebuffer mode and desired X mode differ

#2 - all modes desired are supported by the display

#3 - the framebuffer (vtty[1-6]) mode results from video= on bootloader's
kernel cmdline

#4 - both a desired X mode and a desired X DPI != 96 via xrandr are the
intended result

#5 - Intel gfx only, using video=HORIZxVERT@REF (Only the Intel X driver with
all the Intel gfx I own inherits the non-preferred video= mode from the
bootloader's kernel cmdline. Radeon and Nouveau on the NVidia and ATI cards I
have disregard video=, using EDID preferred unless overridden, same as Intel
used to)(e.g. xf86-video-intel-2.99.917-9.1 in 42.1 XFCE session;
xf86-video-intel-2.99.916-27.1 in 13.2 KDE4 session;
xf86-video-intel-2.99.906-15.1 in 13.1 IceWM and TDE sessions; not to mention
TW 20160205's xf86-video-intel-2.99.917-4.3 in Plasma session).

#6 - desired end result in X must equate to a result possible via
/etc/X11/xorg.con*.

So to possibly make easier, forget for the moment about my 1680x1050 LCD.
Here's the xrandr line used for the attached Xorg.0.log (which has xrandr -q,
xdpyinfo, xrdb -query and more prepended):

    xrandr --dpi 133 --output HDMI1 --mode 1920x1080

and highlights from kernel cmdline:

    ... splash=0 vga=791 video=1280x720@60 3

Result from simply startx:

    Plasma: 1280x720@96 aka fail

> It is fairly obvious that first the mode configure thru 'xrandr ...' is set
> and then changed when the screen settings application starts.

But xrandr is not executing on 100% of a bunch of Intel installations here. The
X mode with Intel is inherited from video=, then left unchanged by anything
that happens in KDE3 (has no krandr or kscreen) or Plasma5 (kscreen is
disabled).

> Adding a script to /etc/X11/xinit/xinitrc.d/ will however never affect any
> DM as these scripts only run after the user has logged in.

This contradicts my experience with KDE3, TDE, KDE4 and Plasma5 (including
Plasma5 on Fedora 23 & 24, where the upstream bug was precipitated).

> This explains why you see the success /failure pattern in the list of
> comment #2:
> You get 1680x1050 on all systems which have this mode set before you run
> 'xrandr --dpi 108 --output ...'. It seems to be the preferred mode on these
> systems

1680x1050 is the native mode, the one wanted for X, but not for framebuffer.

> and is also picked by your desktop.

The desktops here do not get to do any picking. The admin through /etc/X11/* is
supposed to have already done the required configuration.

> So you don't get this mode
> because of your 'xrandr' command but because the screen setter of your
> desktop chose this.

As indicated in upstream bug, there is a workaround that makes xrandr work in
TW with Intel as it did 6 weeks ago: running an extra dummy xrandr command
immediately before, meaning xrandr does run, and the desktop inherits what
xrandr specified.

> The 3 cases which fail have a mode of 1440x900 set - probably the limit for
> this hardware combo. So your desktop will choose this as well - your
> 'xrandr' command trying to set 1680x1050 most likely has failed anyway.
> Running an 'xrandr -q' on one of these and providing the output here may
> shed a lot more light on this.

Here's from middle fail case , TW 20160303 Plasma5 Intel gfx, same 1680x1050
LCD, connected via VGA.

In /etc/X11/xinit/xinitrc.d/setup:

    xrandr --dpi 108 --output VGA1 --mode 1680x1050 # intel analog

kernel cmdline tail:

    ...noresume splash=0 video=1440x900@60 3

# xrandr -q

Screen 0: minimum 8 x 8, current 1440 x 900, maximum 32767 x 32767
DP1 disconnected (normal left inverted right x axis y axis)                     
HDMI1 disconnected (normal left inverted right x axis y axis)                   
VGA1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 474mm x
296mm                                   
   1680x1050     59.97 +  74.89
   1600x1000     60.01
   1280x1024     75.02    72.05    60.02
   1440x900      74.98    59.89*   59.98
   1152x864      75.00
   1024x768      75.08    70.07    60.00
   800x600       72.19    75.00    60.32
   640x480       75.00    72.81    66.67    60.00
   720x400       70.08
VIRTUAL1 disconnected (normal left inverted right x axis y axis)