[Bug 971885] New: [regression][Intel gfx] KDE3 & Plasma5 sessions ignore xrandr resolution and DPI in Xorg startup script
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 Bug ID: 971885 Summary: [regression][Intel gfx] KDE3 & Plasma5 sessions ignore xrandr resolution and DPI in Xorg startup script Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: PC URL: https://bugs.freedesktop.org/show_bug.cgi?id=94403 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: xorg-maintainer-bugs@forge.provo.novell.com Reporter: mrmazda@earthlink.net QA Contact: xorg-maintainer-bugs@forge.provo.novell.com CC: eich@suse.com Found By: --- Blocker: --- To reproduce: 1-boot to multi-user.target on Intel gfxcard 2-put some valid xrandr command(s) in a file in /etc/X11/xinit/xinitrc.d/, at least one of which would override EDID and/or Xorg configuration defaults, e.g.: xrandr --dpi 108 --output VGA1 --mode 1680x1050 3-ensure no conflict exists in etc/X11/xorg.con* or by overriding user settings 4a-startx a K* session, e.g.: WINDOWMANAGER=/opt/kde3/bin/startkde startx WINDOWMANAGER=startkde startx startx /opt/kde3/bin/startkde startx startkde startx, or 4b1-start KDM4 or KDM3 4b2-start KDE3 or Plasma5 or IceWM session Actual results: 1-xrandr commands have been disregarded as of when session finishes initializing Expected results: 1-all valid xrandr commands in /etc/X11/xinit/xinitrc.d/ are in effect by the time the DE session finishes initializing (same as when using nouveau or radeon driver) Comments: 1-Hosts tested today: big41 ATI gfx & Intel gfx & Nouveau gfx 20160318 Plasma5, big31 Intel gfx 20160307 KDE3 & 20160307 Plasma5, gx27b ATI gfx 20160307 Plasma5, gx280 Intel gfx 201601## KDE3, gx28b ATI gfx 20160303, Intel gfx gx780 20160228 KDE3, hpg33 Intel gfx 20160318 Plasma5, hs80e ATI gfx 20160222 Plasma5, kt88b nouveau gfx 20160209 KDE3, msi85 Intel gfx 20160222 KDE3; various others KDE4, Plasma 5 and KDE3 in 42.1, 13.2, 13.1. 2-Initially I thought this was about bug 929016 but that seems to be a separate issue of old, while this is only a month or so old, broken as of TW 20160222, OK as of TW 20160209. Whether https://bugs.freedesktop.org/show_bug.cgi?id=94403 is truly identical or merely overlaps I'm not 100% sure, as not all types of X sessions pay any heed to scripted xrandr somewhere in /etc/X11/*. I only use TDE (not available for TW), KDE3 (primarily), Plasma and KDE4, except occasionally IceWM and rarely XFCE for comparing basic X behavior and bug triage. 3-As per comment 7 in upstream bug, xrandr > /dev/null preceding causes the subsequent otherwise failing xrandr command to be obeyed (on host big41 at least, not today tested elsewhere). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c1 Egbert Eich <eich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|X.Org |KDE Workspace (Plasma) Assignee|xorg-maintainer-bugs@forge. |opensuse-kde-bugs@opensuse. |provo.novell.com |org QA Contact|xorg-maintainer-bugs@forge. |qa-bugs@suse.de |provo.novell.com | --- Comment #1 from Egbert Eich <eich@suse.com> --- As described in boo#929016, with 'startx startkde' none of the xinitrc scripts are run by xinit as these scripts are replaced by 'startkde'. Thus 'startkde' would have to do it which IHMO never happened. With 'WINDOWMANAGER=startkde startx' the xinitrc scripts are run and the files in /etc/X11/xinit/xinitrc.d/ are run which I've verified on a TW 20160208 and a TW 20160318. Setting the video mode through a script in there also works. For KDE (like for most other desktop sessions) the setting is overridden after having been set by one of the xinit scripts by the desktop session which stores and restores the user preferred video mode (in most cases the native mode of the display). When looking through the messages 'startx' dumps to the console, you will also find this mentioned in there. This is the behaviour of a desktop *session* and has nothing to do with X. This behaviour is desired by most users and will likely not change. It should have worked on earlier TW versions the same way - in fact, I have verified this - if it hasn't for you, something else was broken which has gotten fixed in the mean time. In any case, let's reassign this to the KDE folks who may be able to give you more insight. I'm sure, however, that all other desktop sessions behave the same. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c2 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anixx@opensuse.org --- Comment #2 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Egbert Eich from comment #1)
As described in boo#929016, with 'startx startkde' none of the xinitrc scripts are run by xinit as these scripts are replaced by 'startkde'. Thus
To be clear, that bug is distinguishable from this: This applies only when using Intel driver This applies to X regardless whether using startx or KDM[3,4]
'startkde' would have to do it which IHMO never happened. With 'WINDOWMANAGER=startkde startx' the xinitrc scripts are run and the files in /etc/X11/xinit/xinitrc.d/ are run which I've verified on a TW 20160208 and a TW 20160318. Setting the video mode through a script in there also works.
At the point I began to bisect this, I thought I was looking at a KDE3-only bug, and it remains my primary interest to see that what used to work in KDE3 continues to work as in the past, with the content of /etc/X11/xinit/xinitrc.d/ in effect when a DE session completes initializing, no matter whether started by KDM or startx. ATM, with /etc/X11/xinit/xinitrc.d/setup containing: xrandr --dpi 108 --output VGA1 --mode 1680x1050 Results using 90.1 PPI 22" LCD, 1680x1050 native as per EDID: Host t2240, Intel gfx, TW32 20160203#1, vga=791 video=1440x900@60 on cmdline, KDE3: (simply) startx: 1680x1050@108 aka success from KDM3: 1680x1050@108 aka success Host t2240, Intel gfx, TW32 20160203#2, vga=791 video=1440x900@60 on cmdline, Plasma5: (simply) startx: 1680x1050@108 aka success from KDM4: 1680x1050@108 aka success Host gx270, Intel gfx, TW32 20160205, vga=791 video=1440x900@60 on cmdline, Plasma5: (simply) startx: 1680x1050@108 aka success from KDM4: 1680x1050@108 aka success Host gx28b, Intel gfx, TW32 20160303, vga=791 video=1440x900@60 on cmdline, Plasma5: (simply) startx: 1440x900@96 aka fail from KDM4: 1440x900@96 aka fail Host gx760, Intel gfx, TW64 20160303, vga=791 video=1440x900@60 on cmdline, Plasma5: (simply) startx: 1440x900@96 aka fail from KDM4: 1440x900@96 aka fail Host gx260, Intel gfx, TW32 20160307, vga=791 video=1440x900@60 on cmdline, KDE3: (simply) startx: 1440x900@96 aka fail from KDM3: 1440x900@96 aka fail With: xrandr --dpi 108 --output VGA1 --mode 1680x1050 Host fi965, Radeon gfx, TW64 20160222, vga=791 video=1440x900@60 on cmdline, Plasma5: (simply) startx: 1680x1050@108 aka success from KDM4: 1680x1050@108 aka success Host gx28b, Radeon gfx, TW32 20160303, vga=791 video=1440x900@60 on cmdline, Plasma5: (simply) startx: 1680x1050@108 aka success from KDM4: 1680x1050@108 aka success Host hpg33, Radeon gfx, TW64 20160318, vga=791 video=1440x900@60 on cmdline, KDE3: (simply) startx: 1680x1050@108 aka success from KDM3: 1680x1050@108 aka success With: xrandr --dpi 108 --output DVI-I-1 --mode 1680x1050 Host big31, Nouveau gfx, TW64 20160307, vga=791 video=1440x900@60 on cmdline, Plasma5: (simply) startx: 1680x1050@108 aka success from KDM4: 1680x1050@108 aka success
For KDE (like for most other desktop sessions) the setting is overridden
Overriding global configuration by default is one reason why I spend little time exposing myself to environments other than KDE* and TDE. I've observed nothing like universality in any mechanism to make desktop objects usably sized except via text editor in /etc.X11. Plasma I got figured out how to workaround. KDE3 and TDE simply obeyed, and both do still, as long as not using Intel gfx.
after having been set by one of the xinit scripts by the desktop session which stores and restores the user preferred video mode (in most cases the native mode of the display). When looking through the messages 'startx' dumps to the console, you will also find this mentioned in there. This is the behaviour of a desktop *session* and has nothing to do with X. This behaviour is desired by most users and will likely not change.
I'm not most users. I'm among the users with below median eyesight, and an advocate regarding a11y and u7y issues. I configure early and globally in order that initial sessions do not present the usability and accessibility inhibitions to finding and suitably changing settings into a usable state represented by the median or better eyesight developer majority's preferred tiny text and icons that have been becoming progressively more impeding as wider diversity of and higher average screen densities have proliferated. Thus, ever since krandr first appeared in a KDE release, in order to rely on global X configuration, I've employed the following configuration setting in an appropriate location or locations, kdedrc and/or kded5rc: [Module-kscreen] autoload=false This has overall been a fairly reliable means of having global Xorg settings obeyed in Plasma sessions that hasn't been necessary in KDE3 or TDE.
It should have worked on earlier TW versions the same way - in fact, I have verified this - if it hasn't for you, something else was broken which has gotten fixed in the mean time.
I'm unsure what "it" refers to here. It used to be that as long as broken features were not involved, such as https://bugs.kde.org/show_bug.cgi?id=317929 or bug 771521, that global X configuration capability was equivalent between xrandr among /etc/X11/ scripts and /etc/X11/xorg.con*, at least as regards KDE3, TDE and Plasma*.
In any case, let's reassign this to the KDE folks who may be able to give you more insight. I'm sure, however, that all other desktop sessions behave the same.
As the breakage is Intel gfx dependent, and affects KDE3 too, how could KDE people possibly help here? Initial indication from upstream is this is some sort of timing problem. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c3 --- Comment #3 from Egbert Eich <eich@suse.com> --- (In reply to Felix Miata from comment #2)
(In reply to Egbert Eich from comment #1)
As described in boo#929016, with 'startx startkde' none of the xinitrc scripts are run by xinit as these scripts are replaced by 'startkde'. Thus
To be clear, that bug is distinguishable from this:
This applies only when using Intel driver
I very much doubt this as I have conducted my tests on an AMD only system: it has an AMD GPU so no Intel graphics and a discrete Radeon card.
This applies to X regardless whether using startx or KDM[3,4]
This is correct.
'startkde' would have to do it which IHMO never happened. With 'WINDOWMANAGER=startkde startx' the xinitrc scripts are run and the files in /etc/X11/xinit/xinitrc.d/ are run which I've verified on a TW 20160208 and a TW 20160318. Setting the video mode through a script in there also works.
At the point I began to bisect this, I thought I was looking at a KDE3-only bug, and it remains my primary interest to see that what used to work in KDE3 continues to work as in the past, with the content of /etc/X11/xinit/xinitrc.d/ in effect when a DE session completes initializing, no matter whether started by KDM or startx. ATM, with /etc/X11/xinit/xinitrc.d/setup containing:
The list below is not really relevant, what you need to do is: xrandr -q >> /tmp/startx.log xrandr --dpi 108 --output VGA1 --mode 1680x1050 &>> /tmp/startx.log xrandr -q >> /tmp/startx.log Once the system has started, do another xrandr -q >> /tmp/startx.log from a terminal window.
xrandr --dpi 108 --output VGA1 --mode 1680x1050
Results using 90.1 PPI 22" LCD, 1680x1050 native as per EDID:
Host t2240, Intel gfx, TW32 20160203#1, vga=791 video=1440x900@60 on cmdline, KDE3: (simply) startx: 1680x1050@108 aka success from KDM3: 1680x1050@108 aka success
To set the console mode, you need to specify the output together with the 'video=' command. The output names differ between X and KMS. The KMS once you obtain by looking at /sys/class/drm/*. Remove the 'card<N>-' in front.
For KDE (like for most other desktop sessions) the setting is overridden
Overriding global configuration by default is one reason why I spend little time exposing myself to environments other than KDE* and TDE. I've observed nothing like universality in any mechanism to make desktop objects usably sized except via text editor in /etc.X11. Plasma I got figured out how to workaround. KDE3 and TDE simply obeyed, and both do still, as long as not using Intel gfx.
after having been set by one of the xinit scripts by the desktop session which stores and restores the user preferred video mode (in most cases the native mode of the display). When looking through the messages 'startx' dumps to the console, you will also find this mentioned in there. This is the behaviour of a desktop *session* and has nothing to do with X. This behaviour is desired by most users and will likely not change.
I'm not most users. I'm among the users with below median eyesight, and an advocate regarding a11y and u7y issues. I configure early and globally in order that initial sessions do not present the usability and accessibility inhibitions to finding and suitably changing settings into a usable state represented by the median or better eyesight developer majority's preferred tiny text and icons that have been becoming progressively more impeding as wider diversity of and higher average screen densities have proliferated.
Ok, I do understand this and you have a point there. There was a time when desktops were doing a lot to support people with certain impairments. I'm not sure how much effort is still put into this. Regarding low eyesight, it could be that there is a believe that it is good enough if people have their desktop set up once as it will (should!) remember its previous setting and restore this next time around. This doesn't solve the issue that the display manager (the KDMs, GDMs. or SDDMs of this world) may have a resolution not suitable for vision impaired people.
Thus, ever since krandr first appeared in a KDE release, in order to rely on global X configuration, I've employed the following configuration setting in an appropriate location or locations, kdedrc and/or kded5rc:
[Module-kscreen] autoload=false
Right - how long did you have to google to find that?
This has overall been a fairly reliable means of having global Xorg settings obeyed in Plasma sessions that hasn't been necessary in KDE3 or TDE.
It should have worked on earlier TW versions the same way - in fact, I have verified this - if it hasn't for you, something else was broken which has gotten fixed in the mean time.
I'm unsure what "it" refers to here. It used to be that as long as broken features were not involved, such as https://bugs.kde.org/show_bug.cgi?id=317929 or bug 771521, that global X configuration capability was equivalent between xrandr among /etc/X11/ scripts and /etc/X11/xorg.con*, at least as regards KDE3, TDE and Plasma*.
Yes. But you need to complain to the KDE folks about this. You initially complained to the X Window System folks.
In any case, let's reassign this to the KDE folks who may be able to give you more insight. I'm sure, however, that all other desktop sessions behave the same.
As the breakage is Intel gfx dependent, and affects KDE3 too, how could KDE people possibly help here? Initial indication from upstream is this is some sort of timing problem.
I'm fairly certain that this is not Intel specific. As mentioned, I've seen this on AMD graphics as well. I will conduct some more tests to be certain once I find time. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c4 --- Comment #4 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Egbert Eich from comment #3)
(In reply to Felix Miata from comment #2)
This applies only when using Intel driver
I very much doubt this as I have conducted my tests on an AMD only system: it has an AMD GPU so no Intel graphics and a discrete Radeon card.
Using the hardware, not a VM (if it could matter?)? No VMs used here except for running DOS apps using OS/2. ...
The list below is not really relevant...
Dunno exactly what you mean by list, but... ...
As the breakage is Intel gfx dependent,
I'm fairly certain that this is not Intel specific. As mentioned, I've seen this on AMD graphics as well. I will conduct some more tests to be certain once I find time.
I did show you 1 nouveau and 3 radeon TW installations updated post-February that work the same as in 42.1 and earlier, same as the Intels did before mid-February. Maybe hardware age would explain the difference if you see it on AMD. My newest AMD is HD5450. Could port choice could be involved, maybe you on HDMI or DisplayPort? All the tests I listed here were using the same VGA cable and LCD. Conversion from DVI output was needed only for the 8600GT.
[Module-kscreen] autoload=false
Right - how long did you have to google to find that?
Maybe none? :-) That was many moons ago. Could be that Alex Fiestas or Thomas Lübking told me on a KDE mailing list, or someone on KDE IRC. I was obviously well aware of it by 30 months ago: https://bugs.kde.org/show_bug.cgi?id=320561#c58 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c5 --- Comment #5 from Egbert Eich <eich@suse.com> --- (In reply to Felix Miata from comment #4)
(In reply to Egbert Eich from comment #3)
(In reply to Felix Miata from comment #2)
This applies only when using Intel driver
I very much doubt this as I have conducted my tests on an AMD only system: it has an AMD GPU so no Intel graphics and a discrete Radeon card.
Using the hardware, not a VM (if it could matter?)? No VMs used here except for running DOS apps using OS/2. ... I've tested on a VM first, but due to boo#971907 I moved to real hardware.
The list below is not really relevant...
Dunno exactly what you mean by list, but...
The one I've deleted as the comment was getting a bit lenghty.
...
As the breakage is Intel gfx dependent,
I'm fairly certain that this is not Intel specific. As mentioned, I've seen this on AMD graphics as well. I will conduct some more tests to be certain once I find time.
I did show you 1 nouveau and 3 radeon TW installations updated post-February that work the same as in 42.1 and earlier, same as the Intels did before mid-February. Maybe hardware age would explain the difference if you see it on AMD. My newest AMD is HD5450. Could port choice could be involved, maybe you on HDMI or DisplayPort? All the tests I listed here were using the same VGA cable and LCD. Conversion from DVI output was needed only for the 8600GT.
No, definitely not. The behaviour is more or less the same for all vintages and outputs. 'more or less' as different generations and different outputs may have different limitations and restrictions. It could well be that those limitations don't let you do what you would like to do. After all, the only pattern I see from your list in comment #2 is that some systems using Intel graphics are clamped to 1440x900 and don't get up to 1680x1050.
[Module-kscreen] autoload=false
Right - how long did you have to google to find that?
Maybe none? :-) That was many moons ago. Could be that Alex Fiestas or Thomas Lübking told me on a KDE mailing list, or someone on KDE IRC. I was obviously well aware of it by 30 months ago: https://bugs.kde.org/show_bug.cgi?id=320561#c58
Sure. The point I was trying to make was: this is nothing that's documented in one place and in a way that you'd just go to the documentation, read a bit and find the answer. Your approach didn't invalidate my point. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c6 --- Comment #6 from Egbert Eich <eich@suse.com> --- Felix, I've just retested this: setting the mode thru a script in /etc/X11/xinit/xinitrc.d/ works on Intel as well. It is very obvious though that the Plasma5 desktop will reset this to whatever has been configured in the user session. It is fairly obvious that first the mode configure thru 'xrandr ...' is set and then changed when the screen settings application starts. Adding a script to /etc/X11/xinit/xinitrc.d/ will however never affect any DM as these scripts only run after the user has logged in. This explains why you see the success /failure pattern in the list of comment #2: You get 1680x1050 on all systems which have this mode set before you run 'xrandr --dpi 108 --output ...'. It seems to be the preferred mode on these systems and is also picked by your desktop. So you don't get this mode because of your 'xrandr' command but because the screen setter of your desktop chose this. The 3 cases which fail have a mode of 1440x900 set - probably the limit for this hardware combo. So your desktop will choose this as well - your 'xrandr' command trying to set 1680x1050 most likely has failed anyway. Running an 'xrandr -q' on one of these and providing the output here may shed a lot more light on this. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c7 --- Comment #7 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Egbert Eich from comment #3)
The list below is not really relevant, what you need to do is: xrandr -q >> /tmp/startx.log xrandr --dpi 108 --output VGA1 --mode 1680x1050 &>> /tmp/startx.log xrandr -q >> /tmp/startx.log
Doing this amounts to a workaround equivalent to that described in https://bugs.freedesktop.org/show_bug.cgi?id=94403#c7 (tested only on Intel gfx TW Plasma5 hosts big41 and gx745) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c8 --- Comment #8 from Felix Miata <mrmazda@earthlink.net> --- Created attachment 670084 --> http://bugzilla.opensuse.org/attachment.cgi?id=670084&action=edit /etc/X11/xinit/xinitrc.d/setup Attachment is in raw condition. Before starting X, an appropriate xrandr line is uncommented, or not, as when /etc/X11/xorg.con* is used for global X configuration instead of xrandr. /etc/X11/xinit/xinitrc.d/setup is actually a symlink to the real file on a filesystem shared by all Linux installations on each of my many multiboot systems. ***** (In reply to Egbert Eich from comment #3)
(In reply to Felix Miata from comment #2)
Host t2240, Intel gfx, TW32 20160203#1, vga=791 video=1440x900@60 on cmdline, KDE3: (simply) startx: 1680x1050@108 aka success from KDM3: 1680x1050@108 aka success
To set the console mode, you need to specify the output together with the 'video=' command.
We seem to be from different planets on this (and possibly one or two other elements of the problem reported). Left to choose on their own, or use some defaults from whatever source, display outputs here are invariably uncomfortable, usually making everything too small, occasionally too big (e.g. BIOS 80x25 text mode on any but the tiniest of displays). Almost immediately on first use of Linux many moons ago, I discovered this discomfort WRT vttys, and only WRT vttys, was readily handled via the bootloader's kernel cmdline vga= option. Prior to KMS, it was rare to boot here without vga=<something> on kernel cmdline. Most often it was any of vga=0x314 or vga=0x317 or vga=791. Necessarily, vga= became inadequate for dealing with tiny vtty text with the advent of KMS, but I routinely continue to include it for its impact in the few seconds prior to KMS switching the console to the video= mode provided on the bootloader's kernel cmdline. With KMS, video=<horizontal-resolution>x<vertical-resolution> took over most of the duty from vga=. I habitually append @<refresh-rate> as insurance against the odd occasion when some happenstance causes an unsupported refresh that puts the display to sleep. Except in any test when the possibility exists that video= on cmdline may adversely impact the test, vga=<something> and video=<something> are virtually always present here, normally absent only when removed on the fly at boot time. Grub stanzas here number in the thousands. When using a 22" 1680x1050 LCD, my bootloader kernel cmdlines customarily include vga=791 and video=1440x900@60 Typically the latter is preceded by 1280x720@60 and/or 1024x768@60, and I backspace away when necessary at boot time to leave a more desired one last. Plymouth in openSUSE installations here does not exist, tabooed at installation time. Grub2, for several reasons, is also tabooed. For the entire life of KMS in openSUSE, I cannot remember video= on Grub's kernel cmdline ever being insufficient to produce a desired framebuffer (aka console) mode for the balance of init, and surviving on all 6 vttys. So, what is it you were telling me? (more follow-up to prior comments to come...) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c9 --- Comment #9 from Felix Miata <mrmazda@earthlink.net> --- Created attachment 670107 --> http://bugzilla.opensuse.org/attachment.cgi?id=670107&action=edit Xorg.0.log from TW host big41's DVI output connector to HDMI input on HDTV (In reply to Egbert Eich from comment #6)
Felix, I've just retested this: setting the mode thru a script in /etc/X11/xinit/xinitrc.d/ works on Intel as well. It is very obvious though that the Plasma5 desktop will reset this to whatever has been configured in the user session.
Except that here that does not happen due to [Module-kscreen] autoload=false With global configuration set, users ought not need to make resolution or DPI changes. Admins ought to both have control and be obeyed. Admins should not be forced to start a user's first session and mouse around to make it suitable for each user. If a user is subsequently allowed to customize, it's his own fault if he fouls up his session only. But this is dodging the issue, regressed behavior, behavior that differs according to gfx driver. Your lack of DPI mention makes it look to me like you are focused on resolution, and may not yet have closely enough duplicated my conditions here in experiencing this bug (which Chris Wilson in upstream bug seems to have been able to do ~27 hours after bug was filed). #1 - desired framebuffer mode and desired X mode differ #2 - all modes desired are supported by the display #3 - the framebuffer (vtty[1-6]) mode results from video= on bootloader's kernel cmdline #4 - both a desired X mode and a desired X DPI != 96 via xrandr are the intended result #5 - Intel gfx only, using video=HORIZxVERT@REF (Only the Intel X driver with all the Intel gfx I own inherits the non-preferred video= mode from the bootloader's kernel cmdline. Radeon and Nouveau on the NVidia and ATI cards I have disregard video=, using EDID preferred unless overridden, same as Intel used to)(e.g. xf86-video-intel-2.99.917-9.1 in 42.1 XFCE session; xf86-video-intel-2.99.916-27.1 in 13.2 KDE4 session; xf86-video-intel-2.99.906-15.1 in 13.1 IceWM and TDE sessions; not to mention TW 20160205's xf86-video-intel-2.99.917-4.3 in Plasma session). #6 - desired end result in X must equate to a result possible via /etc/X11/xorg.con*. So to possibly make easier, forget for the moment about my 1680x1050 LCD. Here's the xrandr line used for the attached Xorg.0.log (which has xrandr -q, xdpyinfo, xrdb -query and more prepended): xrandr --dpi 133 --output HDMI1 --mode 1920x1080 and highlights from kernel cmdline: ... splash=0 vga=791 video=1280x720@60 3 Result from simply startx: Plasma: 1280x720@96 aka fail
It is fairly obvious that first the mode configure thru 'xrandr ...' is set and then changed when the screen settings application starts.
But xrandr is not executing on 100% of a bunch of Intel installations here. The X mode with Intel is inherited from video=, then left unchanged by anything that happens in KDE3 (has no krandr or kscreen) or Plasma5 (kscreen is disabled).
Adding a script to /etc/X11/xinit/xinitrc.d/ will however never affect any DM as these scripts only run after the user has logged in.
This contradicts my experience with KDE3, TDE, KDE4 and Plasma5 (including Plasma5 on Fedora 23 & 24, where the upstream bug was precipitated).
This explains why you see the success /failure pattern in the list of comment #2: You get 1680x1050 on all systems which have this mode set before you run 'xrandr --dpi 108 --output ...'. It seems to be the preferred mode on these systems
1680x1050 is the native mode, the one wanted for X, but not for framebuffer.
and is also picked by your desktop.
The desktops here do not get to do any picking. The admin through /etc/X11/* is supposed to have already done the required configuration.
So you don't get this mode because of your 'xrandr' command but because the screen setter of your desktop chose this.
As indicated in upstream bug, there is a workaround that makes xrandr work in TW with Intel as it did 6 weeks ago: running an extra dummy xrandr command immediately before, meaning xrandr does run, and the desktop inherits what xrandr specified.
The 3 cases which fail have a mode of 1440x900 set - probably the limit for this hardware combo. So your desktop will choose this as well - your 'xrandr' command trying to set 1680x1050 most likely has failed anyway. Running an 'xrandr -q' on one of these and providing the output here may shed a lot more light on this.
Here's from middle fail case , TW 20160303 Plasma5 Intel gfx, same 1680x1050 LCD, connected via VGA. In /etc/X11/xinit/xinitrc.d/setup: xrandr --dpi 108 --output VGA1 --mode 1680x1050 # intel analog kernel cmdline tail: ...noresume splash=0 video=1440x900@60 3 # xrandr -q Screen 0: minimum 8 x 8, current 1440 x 900, maximum 32767 x 32767 DP1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) VGA1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97 + 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89* 59.98 1152x864 75.00 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 640x480 75.00 72.81 66.67 60.00 720x400 70.08 VIRTUAL1 disconnected (normal left inverted right x axis y axis) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c10 --- Comment #10 from Egbert Eich <eich@suse.com> --- (In reply to Felix Miata from comment #9)
# xrandr -q
Screen 0: minimum 8 x 8, current 1440 x 900, maximum 32767 x 32767 DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
VGA1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97 + 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89* 59.98 1152x864 75.00 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 640x480 75.00 72.81 66.67 60.00 720x400 70.08 VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Ok, what happens if you do a xrandr --dpi 108 --output VGA1 --mode 1680x1050 right after doing the 'xrandr -q' on the same machine? Does the mode change to 1680x1050 - or do you get an error message? Please also do what I've asked for in comment #3 on this machine. (The proposal in comment #3 was not meant as a workaround but as a debugging aid). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c11 --- Comment #11 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Egbert Eich from comment #10)
Ok, what happens if you do a xrandr --dpi 108 --output VGA1 --mode 1680x1050 right after doing the 'xrandr -q' on the same machine? Does the mode change to 1680x1050 - or do you get an error message?
Different machine, almost the same though, same CPU, Optiplex 780 instead of Optiplex 760. Main difference is DDR3 instead of DDR2, besides different HD, and much better availability for testing. The 760 is my TV's PC, normally used with HDTV, so needs to be off the 1680x1050 workspace rotation. This is the 4th official failure since opening this bug, on host gx780, also Intel gfx. It's fresh TW 20160321 KDE3 zypper up (sans 4.5.0 kernel). Same 1680x1050 LCD, but connected via DisplayPort. So in /etc/X11/xinit/xinitrc.d/setup, is xrandr --dpi 108 --output DP1 --mode 1680x1050 # Intel digital Producing same 1440x900@96DPI = failure. /proc/cmdline tail: ...splash=0 vga=791 video=1440x900@60 3 # xdpyinfo | egrep 'dimen|ution' dimensions: 1440x900 pixels (381x238 millimeters) resolution: 96x96 dots per inch # xrandr -q Screen 0: minimum 8 x 8, current 1440 x 900, maximum 32767 x 32767 DP1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97 + 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89* 59.98 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 DVI1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) # xrandr --dpi 108 --output DP1 --mode 1680x1050 # xdpyinfo | egrep 'dimen|ution' dimensions: 1680x1050 pixels (395x246 millimeters) resolution: 108x108 dots per inch So, yes it changes, as I would expect from a timing problem solved by running a dummy xrandr prior to a real one in the startup script.
Please also do what I've asked for in comment #3 on this machine. (The proposal in comment #3 was not meant as a workaround but as a debugging aid).
I did that on two machines several hours before comment 7, and couldn't see the point since there was no evidence of any bug. I prefaced the comment 3 commands with date commands for my own benefit, and used my own filename xstart.txt, but otherwise I think it's what you asked for (on host gx780): Wed Mar 23 03:30:10 EDT 2016 Screen 0: minimum 8 x 8, current 1440 x 900, maximum 32767 x 32767 DP1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97 + 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89* 59.98 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 DVI1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) Wed Mar 23 03:30:10 EDT 2016 Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 32767 x 32767 DP1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97*+ 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89 59.98 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 DVI1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) Wed Mar 23 03:31:09 EDT 2016 Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 32767 x 32767 DP1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97*+ 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89 59.98 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 DVI1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) Other than brief food and nature breaks, responding here has occupied the overwhelming majority of the past 9 hours or so of my time. I still have yet to finish responding to all Egbert Eich comments that I hope or intend to. Timezone here is -0500, so it's now past bedtime yet again. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c12 --- Comment #12 from Egbert Eich <eich@suse.com> --- (In reply to Felix Miata from comment #11)
(In reply to Egbert Eich from comment #10)
Ok, what happens if you do a xrandr --dpi 108 --output VGA1 --mode 1680x1050 right after doing the 'xrandr -q' on the same machine? Does the mode change to 1680x1050 - or do you get an error message?
Different machine, almost the same though, same CPU, Optiplex 780 instead of Optiplex 760. Main difference is DDR3 instead of DDR2, besides different HD, and much better availability for testing. The 760 is my TV's PC, normally used with HDTV, so needs to be off the 1680x1050 workspace rotation. This is the 4th official failure since opening this bug, on host gx780, also Intel gfx. It's fresh TW 20160321 KDE3 zypper up (sans 4.5.0 kernel). Same 1680x1050 LCD, but connected via DisplayPort. So in /etc/X11/xinit/xinitrc.d/setup, is
xrandr --dpi 108 --output DP1 --mode 1680x1050 # Intel digital
Producing same 1440x900@96DPI = failure.
OK.
/proc/cmdline tail: ...splash=0 vga=791 video=1440x900@60 3
# xdpyinfo | egrep 'dimen|ution' dimensions: 1440x900 pixels (381x238 millimeters) resolution: 96x96 dots per inch # xrandr -q Screen 0: minimum 8 x 8, current 1440 x 900, maximum 32767 x 32767 DP1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97 + 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89* 59.98 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 DVI1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Ok, so ...
# xrandr --dpi 108 --output DP1 --mode 1680x1050 # xdpyinfo | egrep 'dimen|ution' dimensions: 1680x1050 pixels (395x246 millimeters) resolution: 108x108 dots per inch So, yes it changes, as I would expect from a timing problem solved by running a dummy xrandr prior to a real one in the startup script.
... mode and dpi change work in principle, which indicates that this is not a problem of KMS, then Xserver or the driver.
Please also do what I've asked for in comment #3 on this machine. (The proposal in comment #3 was not meant as a workaround but as a debugging aid).
I did that on two machines several hours before comment 7, and couldn't see the point since there was no evidence of any bug. I prefaced the comment 3
Exactly. This was what I wanted to find out!
commands with date commands for my own benefit, and used my own filename xstart.txt, but otherwise I think it's what you asked for (on host gx780):
Yes, when I did this test, I've added the 'date' command as well. Granularity of the time stamp is not really high but sufficient.
Wed Mar 23 03:30:10 EDT 2016 Screen 0: minimum 8 x 8, current 1440 x 900, maximum 32767 x 32767 DP1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97 + 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89* 59.98 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 DVI1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis)
I assume you did the 'xrandr --dpi 108 --mode ...' command in here.
Wed Mar 23 03:30:10 EDT 2016 Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 32767 x 32767 DP1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97*+ 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89 59.98 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 DVI1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis)
This output shows that changing the resolution did succeed and you are in a 1680x1050 mode exactly at this point.
Wed Mar 23 03:31:09 EDT 2016 Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 32767 x 32767 DP1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97*+ 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89 59.98 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 DVI1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis)
Ok, you ran 'xrandr -q' again a second later. Mode is still the same, ie the one you were trying to set. If you are at a 1440x900 mode by the time your desktop is finally up, there is something else that changes your mode again. I'm sure, that the Xserver log file will show traces of this. Now, I don't know what this is what changes your mode. This is why I tried to get the KDE folks into the boat as well. Could it be that your: [Module-kscreen] autoload=false doesn't work any more? I don't know.
Other than brief food and nature breaks, responding here has occupied the overwhelming majority of the past 9 hours or so of my time. I still have yet to finish responding to all Egbert Eich comments that I hope or intend to. Timezone here is -0500, so it's now past bedtime yet again.
Please be assured that testing things for this ticket took me a considerable amount of time yesterday as well ;) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c13 --- Comment #13 from Felix Miata <mrmazda@earthlink.net> --- Created attachment 670155 --> http://bugzilla.opensuse.org/attachment.cgi?id=670155&action=edit raw /tmp/xstart.txt used in comment 11 (for new comment line referencing) (In reply to Egbert Eich from comment #12)
(In reply to Felix Miata from comment #11)
gfx. It's fresh TW 20160321 KDE3 zypper up (sans 4.5.0 kernel). Same
Did you miss the KDE3 part? There's never been any interference from KDE3 to global config settings that I can remember ever encountering? ...
... mode and dpi change work in principle, which indicates that this is not a problem of KMS, then Xserver or the driver.
I never had any doubt, after all, if in /etc/X11/xinit/xinitrc.d/setup: xrandr > /dev/null xrandr --dpi 108 --output VGA1 --mode 1680x1050 # intel analog then, the second xrandr in that script does produce the expected result.
Wed Mar 23 03:30:10 EDT 2016 ... VIRTUAL1 disconnected (normal left inverted right x axis y axis)
I assume you did the 'xrandr --dpi 108 --mode ...' command in here.
1440x900 in attachment lines 2 & 7 happened on account of video=1440x900@60 on cmdline 1680x1050 in attachment lines 21 & 23 happened on account of xrandr --dpi 108 --output VGA1 --mode 1680x1050 in /etc/X11/xinit/xinitrc.d/setup 1680x1050 in attachment lines 40 & 42 is ambiguous as to why, since the query was triggered from an xrandr command ostensibly setting mode and DPI equal to their current states.
Wed Mar 23 03:30:10 EDT 2016 ... VIRTUAL1 disconnected (normal left inverted right x axis y axis)
This output shows that changing the resolution did succeed and you are in a 1680x1050 mode exactly at this point.
Except that it was already 1680x1050 before Konsole opened. Hard for me to tell about a change being made when before = after.
Wed Mar 23 03:31:09 EDT 2016 Screen 0: minimum 8 x 8, current 1680 x 1050, maximum 32767 x 32767 DP1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97*+ 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89 59.98 ... Ok, you ran 'xrandr -q' again a second later. Mode is still the same, ie the one you were trying to set.
This one is 59 seconds after the previous, created from Konsole, following #2 from the setup script. TBC with another attachment... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c14 --- Comment #14 from Felix Miata <mrmazda@earthlink.net> --- Created attachment 670156 --> http://bugzilla.opensuse.org/attachment.cgi?id=670156&action=edit xrandr command used in /etc/X11/xinit/xinitrc.d/setup prepended to Xorg.0.log from host gx780 (failing as per comment 0) (continuing) (In reply to Egbert Eich from comment #12)
If you are at a 1440x900 mode by the time your desktop is finally up, there is something else that changes your mode again. I'm sure, that the Xserver log file will show traces of this.
Only things I recognize from it: [ 44.670] (II) intel(0): switch to mode 1440x900@59.9 on DP1 using pipe 0, position (0, 0), rotation normal, reflection none [ 84.972] (II) intel(0): switch to mode 1680x1050@60.0 on DP1 using pipe 0, position (0, 0), rotation normal, reflection none TBC with another attachment... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c15 --- Comment #15 from Felix Miata <mrmazda@earthlink.net> --- Created attachment 670157 --> http://bugzilla.opensuse.org/attachment.cgi?id=670157&action=edit xrandr command used in /etc/X11/xinit/xinitrc.d/setup prepended to Xorg.0.log from host gx780 (working as expected) (continuing) (In reply to Egbert Eich from comment #12)
Now, I don't know what this is what changes your mode.
It seems to me https://bugs.freedesktop.org/show_bug.cgi?id=94403#c7 addresses your puzzlement: "A recent change to xrandr was not to do a forced query before setting the mode."
This is why I tried to get the KDE folks into the boat as well. Could it be that your: [Module-kscreen] autoload=false doesn't work any more? I don't know.
Kscreen doesn't exist in KDE3. Xrandr from /etc/X11/xinit/xinitrc.d/setup *does* work as expected, as long as the dummy xrandr command preceeds the real one. KDE3 in TW 20160321 here started out in 1680x1050, same as it did without the dummy >6 weeks ago, same as it continues to do now in nouveau and radeon TW installations without the dummy. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c16 --- Comment #16 from Egbert Eich <eich@suse.com> --- (In reply to Felix Miata from comment #15)
Kscreen doesn't exist in KDE3. Xrandr from /etc/X11/xinit/xinitrc.d/setup *does* work as expected, as long as the dummy xrandr command preceeds the real one.
Ok, I seem to understand now. When adding the command sequence from comment #3, the first 'xrand -q >> ...' actually replaced the dummy command. This gave you the correct results then. - If you replace the 'xrandr > /dev/null' with 'sleep 2' on machines where you have tried this, does it work as well? - Could you do a: xrandr --dpi 108 --output VGA1 --mode 1680x1050 &>> /tmp/startx.log xrandr -q >> /tmp/startx.log in your setup script? (leave out the first 'xrandr -q' which may 'fix' things magically). I'd be curious if the output of the first command produces any error messages if it fails to set the mode. - Please get me the output of an 'lspci -nn' of the troubled system. I will see what I can do to get as close to the hardware you are using as possible. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c17 --- Comment #17 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Egbert Eich from comment #16)
Ok, I seem to understand now. When adding the command sequence from comment #3, the first 'xrand -q >> ...' actually replaced the dummy command. This gave you the correct results then. - If you replace the 'xrandr > /dev/null' with 'sleep 2' on machines where you have tried this, does it work as well?
According to https://bugs.freedesktop.org/show_bug.cgi?id=94403#c2 sleep 5 was tried only on TW host big41 and did not help. Now on TW 20160321 KDE3 host gx780 (the newest/fastest of my testing machines), precedent sleep 2=success (1680x1050@108DPI) for IceWM via scripted 'WINDOWMANAGER=/usr/bin/icewm startx', but neither for KDE3 either via startx nor via 'WINDOWMANAGER=/opt/kde3/bin/startkde startx' (1440x900@96DPI). Precendent 'xrandr > /dev/null' instead of 'sleep 2' =success (1680x1050@108DPI) for IceWM via scripted 'WINDOWMANAGER=/usr/bin/icewm startx', and =success (1680x1050@108DPI) for KDE3 either via startx or via 'WINDOWMANAGER=/opt/kde3/bin/startkde startx'. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c18 --- Comment #18 from Felix Miata <mrmazda@earthlink.net> --- Created attachment 670256 --> http://bugzilla.opensuse.org/attachment.cgi?id=670256&action=edit start script amended as comment 16 directs, its output, and lspci -nn output, all from TW20160321 KDE3 host gx780 (In reply to Egbert Eich from comment #16)
- Could you do a: xrandr --dpi 108 --output VGA1 --mode 1680x1050 &>> /tmp/startx.log xrandr -q >> /tmp/startx.log
in your setup script? (leave out the first 'xrandr -q' which may 'fix' things magically). I'd be curious if the output of the first command produces any error messages if it fails to set the mode.
xrandr: cannot find mode 1680x1050 Very unsurprising to me given upstream comment "A recent change to xrandr was not to do a forced query before setting the mode". This non-programmer can only guess it could not be found because when using Intel, where unlike with Nouveau and Radeon, the KMS framebuffer mode resulting from cmdline video= directive is inherited by Xorg, probably by KMS hiding higher res modes at handoff to Intel X driver (possibly affected due to absence of Plymouth involvement?). The other workaround that I'm aware of is not using xrandr in startup script at all, instead using /etc/X11/xorg.con* (on gx780, the following): Section "Device" Identifier "DefaultDevice" Option "monitor-DP1" "DefaultMonitor" EndSection Section "Monitor" Identifier "DefaultMonitor" Option "PreferredMode" "1680x1050" DisplaySize 394 247 # 108 DPI @ 1680x1050 EndSection Section "Screen" Identifier "DefaultScreen" Device "DefaultDevice" Monitor "DefaultMonitor" EndSection Because with FOSS drivers there is no explicit DPI option, it's more work to configure xorg.con* than xrandr in startup script (if it works at all), but it does result in initialization of both IceWM and KDE3 to 1680x1050@108DPI.
- Please get me the output of an 'lspci -nn' of the troubled system. I will see what I can do to get as close to the hardware you are using as possible.
Attachment tail. Still more Egbert Eich comments I have not yet addressed, but do any remain that I still need to? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c19 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|KDE Workspace (Plasma) |X.Org Assignee|opensuse-kde-bugs@opensuse. |xorg-maintainer-bugs@forge. |org |provo.novell.com QA Contact|qa-bugs@suse.de |xorg-maintainer-bugs@forge. | |provo.novell.com --- Comment #19 from Felix Miata <mrmazda@earthlink.net> --- Comment 2 failing Intel gfx hosts gx260, gx28b and gx760 join host gx780 in failing to respond as expected (1680x1050@108DPI) to 'xrandr --dpi 108 --output VGA1 --mode 1680x1050', instead inheriting 1440x900@96DPI from bootloader kernel cmdline parameter 'video=1440x900@60' in IceWM session, whether started from startx or from KDM, *unless* some other xrandr command precedes 'xrandr --dpi 108 --output VGA1 --mode 1680x1050' in the startup script. Host gx780 differs only in using DisplayPort connection vs. VGA for the other 3. Thus, this has nothing to do with KDE*. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c20 --- Comment #20 from Egbert Eich <eich@suse.com> --- This is actually the first tangible result after 19 (sometimes long) comments. xrandr --dpi 108 --output DP1 --mode 1680x1050 xrandr -q xrandr: cannot find mode 1680x1050 Screen 0: minimum 8 x 8, current 1440 x 900, maximum 32767 x 32767 DP1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 59.97 + 74.89 1600x1000 60.01 1280x1024 75.02 72.05 60.02 1440x900 74.98 59.89* 59.98 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 DVI1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) Seems to happen only on Intel, but an all generations. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c21 --- Comment #21 from Felix Miata <mrmazda@earthlink.net> --- Did you create that from scratch, or extract if from my attached log? ### TW 20160209 Plasma5 host gx620 had not yet regressed. ### Lest there be any doubt a native 1680x1050 display is not a material issue:
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 xrandr -q >> /tmp/xstart.txt date >> /tmp/xstart.txt Screen 0: minimum 8 x 8, current 1280 x 720, maximum 32767 x 32767 DP1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 1280x720+0+0 (normal left inverted right x axis y axis) 698mm x 393mm 1920x1080 60.00 + 60.00 59.94 24.00 23.98 1920x1080i 60.00 59.94 1280x720 59.97* 60.00 59.94 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 720x480 60.00 59.94 640x480 75.00 60.00 59.94 720x400 70.08 VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) Thu Mar 24 05:15:08 EDT 2016 In that session, same script manually run from Konsole: Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 DP1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 698mm x 393mm 1920x1080 60.00*+ 60.00 59.94 24.00 23.98 1920x1080i 60.00 59.94 1280x720 59.97 60.00 59.94 1024x768 75.08 70.07 60.00 800x600 72.19 75.00 60.32 720x480 60.00 59.94 640x480 75.00 60.00 59.94 720x400 70.08 VGA1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) Thu Mar 24 05:15:58 EDT 2016 I am surprised to see no "xrandr: cannot find mode" message. -- You are receiving this mail because: You are on the CC list for the bug.
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.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c23 --- Comment #23 from Egbert Eich <eich@suse.com> --- Ok, I've taken a look again and was able to condense it to 10 patches. It should be available at: http://download.opensuse.org/repositories/home:/eeich:/branches:/X11:/XOrg/o... for testing. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c24 Egbert Eich <eich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from Egbert Eich <eich@suse.com> --- Submitted to devel project: SR ID#382686. Accepted, forwarded to Factory: SR #382692. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=971885 http://bugzilla.opensuse.org/show_bug.cgi?id=971885#c25 --- Comment #25 from Egbert Eich <eich@suse.com> --- Note: These fixes will still not populate the mode list immediately on server startup. There will be a delay of 2 seconds which may be important for scripts run at startup. To overcome this delay, do: 'xrandr -q' before relying on a mode being present in the mode list. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com