http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c22 --- Comment #22 from Egbert Eich <eich@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.