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.