Comment # 22 on bug 971885 from Egbert Eich

(In reply to Felix Miata from comment #21)
> Did you create that from scratch, or extract if from my attached log?

This was extracted from the log but I can create the same on any Intel system
using TW.
> 
> ###
> 
> TW 20160209 Plasma5 host gx620 had not yet regressed.

I don't think we keep a package list for each TW release (to be useful we'd
also need diffs of the changelogs). I can only assume that 'xrandr' has been
updated since then.

> 
> Lest there be any doubt a native 1680x1050 display is not a material issue:

I now know what is happening: the driver only gets the current mode but doesn't
populate the mode list at startup. The mode list also gets populated/updated
when someone calls 'xrandr -q' ie. queries the available modes.
'xrandr --output ... --mode ...' used to implicitly query the available modes
as well - before it sets a new mode, but no longer does - as you found out
already. 

> 
> From Intel 4 series (rev 03) host big41 TW 20160318, with video=1280x720@60
> on bootloader kernel cmdline, using a slight variation on comment 16 setup
> script edition:
> 
> 	xrandr --dpi 133 --output HDMI1 --mode 1920x1080 >> /tmp/xstart.txt
[..]
> 
> I am surprised to see no "xrandr: cannot find mode" message.
The reason for this is that you didn't put the ampersand in front of '>>' - ie.
'&>>', the error messages are correctly sent to stderr which is not captured by
'>>' unless redirected by using the ampersand.

Felix, I have some bad news:

There would be a bunch of patches to be backported up to at least
2c08d72393e4c8ddf5926571b087459aaa225cb1
to get this fixed. At one point I gave up collecting more: there is no issue 
with Leap 42.1 we don't need to get this fixed for TW. Instead I've pinged  
Intel about a new driver release since 2.99.917 is quite dated already.

Closing as WONTFIX.