Created attachment 122115 [details] .zip of 25 Xorg.0.logs Logs included in attachment have configuration used to produce them prepended to each. Filenames used include hostname and suggest OS & version, gfxchip, config type (xrandr vs xorg.conf), resulting mode & DPI, and success/fail state (19 success, 6 fail). To reproduce: 1-embed xrandr commands in /etc/X11/xinit/xinitrc.d/<someexectutable> to set resolution and DPI, e.g. 'xrandr --dpi 108 --output VGA1 --mode 1680x1050 # intel analog' 2-start an X session Actual behavior: 1-e.g. mode is 1440x900 (inherited from kernel cmdline) and DPI 96 (Xorg default) Expected behavior: 1-DPI is as configured, e.g. 108 2-resolution is as configured, e.g. 1680x1050 Comments: 1-Regression observed on Fedora 24 and openSUSE Tumbleweed installations 2-gfxchips tested: 915G (Optiplex 280, 32 bit), 945G (Optiplex 620), G41 (Biostar), G43 (Optiplex 760), ATI rv380 3-configuration equivalent to xrandr commands placed in their stead in /etc/X11/xorg.conf (PreferredMode and DisplaySize) produces expected behavior before and after the regression point, same as the xrandr commands produced before tonight's online updates 4-update date of last installation to function as expected: 23 Feb. 5-Radeon rv380 was temporarily installed in the Biostar to suggest the regression is limited to gfxchips running on Intel driver
The difference between the bad and good Xorg.log (looking at xorg.0.log-iG41-big41-stw20160303-xrandr-1680x1050-bad096 and xorg.0.log-iG41-big41-stw20160223-xrandr-1680x1050x108-OK) is whether or not the xrandr command is received (or acted upon). Especially as --dpi handling is not part of the -intel but core Xserver. A quick test would be adding sleep 5 before the xrandr command. I think perhaps strace'ing the whole startup (xinit + X + xrandr) would help identify the issue.
Created attachment 122123 [details] strace of Icewm session begun using startx (In reply to Chris Wilson from comment #1) > A quick test would be adding sleep 5 before the xrandr command. I think Tried on host big41 using Tumbleweed. Didn't help. > perhaps strace'ing the whole startup (xinit + X + xrandr) would help > identify the issue. I've been using this /usr/local/bin/startice script to speed up invocations: #!/bin/sh WINDOWMANAGER=/usr/bin/icewm startx So, I first, before remembering to remove the sleep, did: # strace startice I could see the mouse pointer disappear from center, then reappear upward and leftward, accompanying mode change from the cmdline's 1440x900 to xrandr's 1680x1050. IOW, using strace, xrandr was employed normally instead of ignored. Then, after remembering to remove the sleep, # strace -o somefile.txt startice Mouse pointer did not move. 1440x900 stuck. Somefile.txt attached. What clues it may contain I have no idea.
Can you please try with "strace -f" so that it traces the children as well?
Created attachment 122124 [details] bad & good F24 on big41 Xorg.0.logs prepended with applicable xrandr On host big41's F24 freshly updated, I found a difference between working and non-working xrandr, using: xrandr --dpi 108 --output HDMI1 --mode 1400x1050 --output VGA1 --mode 1680x1050 --primary --above HDMI1 # intel dual 1 xrandr failing: [ 567.401] Kernel command line: ro root=LABEL=f24p13sv5 ipv6.disable=1 net.ifnames=0 selinux=0 splash=0 vga=791 video=1280x720@60 video=1024x768@60 video=1440x900@60 3 xrandr succeeding: [ 44.192] Kernel command line: ro root=LABEL=f24p13sv5 ipv6.disable=1 net.ifnames=0 selinux=0 splash=0 3 Surely this explains at least in part the difference between Intel and non-Intel gfxchip behavior, as only with Intel driver does Xorg use video= from cmdline to supplant EDID preferred. As noted in https://bugs.freedesktop.org/show_bug.cgi?id=90842 xorg.conf on same big41 F24 installation can produce expected modes and virtual size, while its DisplaySize is ignored, with or without video= on cmdline. Could the root of both problems be the same?
Created attachment 122125 [details] strace -f of big41 Tumbleweed Icewm session begun using startx (In reply to Chris Wilson from comment #3) > Can you please try with "strace -f" so that it traces the children as well?
Buried deep in there is the error message: 1469 write(2, "xrandr: ", 8) = 8 1469 write(2, "cannot find mode 1680x1050\n", 27) = 27
A recent change to xrandr was not to do a forced query before setting the mode, so replace the sleep 5 with xrandr > /dev/null xrandr --dpi 108 --output VGA1 --mode 1680x1050
Interesting. Works in Tumbleweed (kernel-4.4.3). Fails in F24 (kernel-4.5rc6 & kernel-4.4rc6), even with a sleep 30 added following xrandr /dev/null.
(In reply to Felix Miata from comment #8) > Interesting. Works in Tumbleweed (kernel-4.4.3). Fails in F24 (kernel-4.5rc6 > & kernel-4.4rc6), even with a sleep 30 added following xrandr /dev/null. To clarify, does the F24 userspace setup work on kernel-4.4.3?
I don't know what "F24 userspace setup" means. AFAIK, 4.4.3 was never available in F24. I'm guessing 4.5rc0 was next to follow 4.4.0. Neither of the two kernels tried on host big41's F24 reproduced the success produced on Tumbleweed. On big41 I just booted Debian Stretch that was last updated 1 December, with kernel 4.2.0. It's lxde obeyed xrandr's 1680x1050 instead of kernel's 1440x900, as expected, with xrandr in /etc/Xsession.d/ script rather than /etc/X11/xinit/xinitrc.d/ script. After apt-get update, including kernel 4.3.5, lxde is 1440x900, unless xrandr > /dev/null is run first, in which case it's 1680x1050 as desired.
Created attachment 122157 [details] F24 host gx27c log from running 'strace -f startx /usr/bin/icewm' On 32bit Fedora 24 i865G host gx27c, icewm is 1440x900 via kernel cmdline rather than 1680x1050 from 'xrandr --dpi 108 --output VGA1 --mode 1680x1050' in /etc/X11/xinit/xinitrd.d/[01 or 90]xsetup, regardless whether xrandr > /dev/null is run first. String "cannot find mode" does not appear in log.
More info in downstream bug: https://bugzilla.opensuse.org/show_bug.cgi?id=971885
Downstream bug has patch/fix satisfactory only for most cases. On slow enough hardware, a workaround due to 2sec mode population delay from last September's https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=d50d336605e9be7280529b0eb565402d7646c913 may be required.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/89.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.