Bug 94403

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.