Bug 94403 - [regression] scripted xrandr commands in /etc/X11/xinit/xinitrc.d/ are disregarded
Summary: [regression] scripted xrandr commands in /etc/X11/xinit/xinitrc.d/ are disreg...
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL: https://bugzilla.opensuse.org/show_bu...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-05 09:48 UTC by Felix Miata
Modified: 2016-04-01 18:29 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
.zip of 25 Xorg.0.logs (151.10 KB, text/plain)
2016-03-05 09:48 UTC, Felix Miata
no flags Details
strace of Icewm session begun using startx (12.55 KB, text/plain)
2016-03-06 04:09 UTC, Felix Miata
no flags Details
bad & good F24 on big41 Xorg.0.logs prepended with applicable xrandr (35.90 KB, text/plain)
2016-03-06 09:23 UTC, Felix Miata
no flags Details
strace -f of big41 Tumbleweed Icewm session begun using startx (4.70 MB, text/plain)
2016-03-06 09:36 UTC, Felix Miata
no flags Details
F24 host gx27c log from running 'strace -f startx /usr/bin/icewm' (5.48 MB, text/plain)
2016-03-08 05:09 UTC, Felix Miata
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Miata 2016-03-05 09:48:51 UTC
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
Comment 1 Chris Wilson 2016-03-05 11:04:37 UTC
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.
Comment 2 Felix Miata 2016-03-06 04:09:07 UTC
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.
Comment 3 Chris Wilson 2016-03-06 09:16:09 UTC
Can you please try with "strace -f" so that it traces the children as well?
Comment 4 Felix Miata 2016-03-06 09:23:15 UTC
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?
Comment 5 Felix Miata 2016-03-06 09:36:43 UTC
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?
Comment 6 Chris Wilson 2016-03-06 12:51:44 UTC
Buried deep in there is the error message:

1469  write(2, "xrandr: ", 8)           = 8
1469  write(2, "cannot find mode 1680x1050\n", 27) = 27
Comment 7 Chris Wilson 2016-03-06 12:55:11 UTC
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
Comment 8 Felix Miata 2016-03-06 18:05:31 UTC
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.
Comment 9 Chris Wilson 2016-03-07 09:30:19 UTC
(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?
Comment 10 Felix Miata 2016-03-07 10:51:03 UTC
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.
Comment 11 Felix Miata 2016-03-08 05:09:52 UTC
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.
Comment 12 Felix Miata 2016-03-21 05:39:08 UTC
More info in downstream bug:
https://bugzilla.opensuse.org/show_bug.cgi?id=971885
Comment 13 Felix Miata 2016-04-01 18:29:16 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.