https://bugzilla.novell.com/show_bug.cgi?id=706024 https://bugzilla.novell.com/show_bug.cgi?id=706024#c1 --- Comment #1 from Felix Miata <mrmazda@earthlink.net> 2011-07-15 05:28:15 UTC --- Created an attachment (id=440202) --> (http://bugzilla.novell.com/attachment.cgi?id=440202) 50-monitor.conf prepended to Xorg.0.log from 12.1m3 Unexpected 96 DPI produced. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=706024 https://bugzilla.novell.com/show_bug.cgi?id=706024#c3 --- Comment #3 from Felix Miata <mrmazda@earthlink.net> 2011-07-16 01:51:32 UTC --- Problem exists also with i865G, rv200 (AGP Radeon 7500), & rv380 (PCIe Radeon X600) GeForce2 MX 400 (nv11) with nv driver (nouveau.modeset=0) ignores both DisplaySize and PreferredMode in both 50-monitor.conf and xorg.conf. http://lists.opensuse.org/opensuse-factory/2011-07/msg00259.html explains my failed attempts with 8600GT. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=706024 https://bugzilla.novell.com/show_bug.cgi?id=706024#c5 Stefan Dirsch <sndirsch@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|NEW |ASSIGNED --- Comment #5 from Stefan Dirsch <sndirsch@novell.com> 2011-07-18 09:25:14 UTC --- Please *attach* *seperately* and in *plain/text* format the files 50-device.conf 50-monitor.conf 50-screen.conf from the affected system. Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=706024 https://bugzilla.novell.com/show_bug.cgi?id=706024#c6 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|mrmazda@earthlink.net | --- Comment #6 from Felix Miata <mrmazda@earthlink.net> 2011-07-18 18:22:48 UTC --- That you asked for all three made me investigate and think some more. I had always assumed that the reason for using xorg.conf.d/ was to make it easier to target one or a few elements of X configuration by having or altering only one or a few files there, and that each's presence or condition was autonomous. Now I can see that that is not true, and that device, monitor and screen are interdependent. I missed that in testing Fedora, because I copied only monitor from oS to it, and Fedora leaves that directory empty by default. I spend quite some time trying to figure out which 11.04 Kubuntu I tried before filing the upstream bug, with no success. Another machine with 11.04 I tried to reproduce on, and could not get it to react at all to anything in xorg.conf.d/. 12.1M0, labeled 11.5M0 at the time, came with 50-device.conf, 50-monitor.conf and 50-screen files over a year old on release, with same content as those in 11.4. Sometime after M0, those files were changed. The changes: 1-https://bugs.freedesktop.org/show_bug.cgi?id=32430 was referenced in warning 2-no lines were left uncommented 3-no mention was added in any that each depends on the others having appropriate lines uncommented Since the amount of current comments infinitely exceeds non-comments, it makes them appear to be substantially self-documenting. This problem this bug represents could probably be avoided in the future by incorporating mention of the interdependence. 11.4 had essential elements uncommented by default, and so worked, while sometime post-M0 12.1 quit working when the uncommented lines in device and screen disappeared. So, PreferredMode, TargetRefreshRate and DisplaySize in /etc/X11/xorg.conf.d/50-monitor.conf are _not_ignored, but _only_ if 50-device.conf and 50-screen.conf, or their equivalent, both exist, and contain all essential uncommented elements. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=706024 https://bugzilla.novell.com/show_bug.cgi?id=706024#c8 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|mrmazda@earthlink.net |sndirsch@novell.com --- Comment #8 from Felix Miata <mrmazda@earthlink.net> 2011-07-18 19:31:01 UTC --- (In reply to comment #7)

And still you didn't attach the requested files ...

On purpose I did not, because they seemed to be irrelevant after knowing the non-working, nothing but comments, and thus void, device and screen files are exactly those from xorg-x11-driver-video-7.6-74.3 that resulted from your 1 July changes, while the modified monitor does work fine once usably non-void device and screen files exist. All those I have now work. Do you want those? Unedited? Those I actually use contain the bulk of http://fm.no-ip.com/Share/DisplaySize with only the line(s) I want used uncommented. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=706024 https://bugzilla.novell.com/show_bug.cgi?id=706024#c10 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|mrmazda@earthlink.net | --- Comment #10 from Felix Miata <mrmazda@earthlink.net> 2011-07-19 10:15:58 UTC --- (In reply to comment #9)

So what's the remaining issue?

Since Fri Jul 1 10:51:57 UTC 2011 what seem to be self documenting config files leave out the key information that each depends on the others, formerly usable as-is, but no longer. IMO the ideal solution is to (upstream) eliminate the dependence, at least for systems with only one display, but if that can't be done, then add comments in each about the device-monitor-screen interdependence. As long as each requires the others, is there even any point in having /etc/X11/xorg.conf.d/?

Were you mixing screen/device/monitor sections of xorg.conf and the ones of the files in xorg.conf.d?

Not in recent memory...

Did you see the comment?

# Having multiple "Device" sections is known to be problematic. Make # sure you don't have in use another one laying around e.g. in another # xorg.conf.d file or even a generic xorg.conf file. More details can # be found in https://bugs.freedesktop.org/show_bug.cgi?id=32430.

Hard to miss, though it was I that filed it, and so I am more familiar with it than Joe Average. :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=706024 https://bugzilla.novell.com/show_bug.cgi?id=706024#c12 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|mrmazda@earthlink.net | --- Comment #12 from Felix Miata <mrmazda@earthlink.net> 2011-07-21 05:35:46 UTC --- I thought so for a long time, but apparently it's video chip and/or driver dependent. It turns out copy & paste from old working xorg.conf files is an Intel booby trap: using 'Identifier "Monitor[0]"' instead of 'Identifier "Default Monitor"' is a cause of unexpected results. It took a while to respond because I was vexed by the differences between DVI NVidia behavior & those of Intel & ATI, plus TargetRefreshRate, PreferredMode & DisplaySize not always obeyed or not uniformly as a group. To reproduce: 1-Connect KMS-supported Intel or ATI video 12.1M3 system to a CRT supporting 1600x1200, 1792x1536, 1856x1392, 1920x1440 & 2048x1536 at up to at least 85 refresh 2-Start X with no xorg.conf, and no regular files in xorg.conf.d/ except a valid 50-monitor.conf containing: Section "Monitor" Identifier "Monitor[0]" # Identifier "Default Monitor" HorizSync 30-120 VertRefresh 56-86 Option "TargetRefreshRate" "60" Option "DDC" "off" Option "DefaultModes" "on" DisplaySize 378 284 # 120 DPI @ 1792x1344 Option "PreferredMode" "1792x1344" EndSection Actual results: 1-96 DPI (intel, radeon) 2-1600x1200 resolution (intel, radeon) 3-85 refresh (intel, radeon) 4-black screen (nv/nouveau) Expected results: 1-120 DPI 2-1792x1344 resolution 3-60 refresh Comments: 1-exiting X, moving the comment from the Default Monitor line to the Monitor[0] line, then startx produces expected results with intel, but not with radeon or nouveau. 2-exiting X, leaving the comment at the Default Monitor line or moving it to the Monitor[0] line, placing in xorg.conf.d/ the 1 July 50-device.conf & 50-screen.conf files from M3 rpms, then startx produces unexpected results with radeon. 3-exiting X, moving the comment from the Default Monitor line to the Monitor[0] line, placing in xorg.conf.d/ the 22 April 2010 50-device.conf & 50-screen.conf files from M0 rpms (identical to 11.3's), then startx produces expected results with radeon. 4-As long as there is no more than one 'Section "Monitor"' anywhere in xorg.conf or /xorg.conf.d/, it ought not matter the identifier used in that one and only non-default section, regardless of driver. 5-I still don't know why DVI 8600GT works in WinXP, 11.4 and Fedora 15 but not 12.1. 6-for purposes of this comment not taking any further time to formulate, I used only 3 systems, i865G for intel (gx27b), rv200 for radeon (m7ncd), DVI 8600GT for nouveau (gx28b). i915G, i845G, i945G, i810, iG31, nv11 & rv380 remain available to further test if necessary. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=706024 https://bugzilla.novell.com/show_bug.cgi?id=706024#c14 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | --- Comment #14 from Felix Miata <mrmazda@earthlink.net> 2011-07-21 15:05:55 UTC --- (In reply to comment #13)

Better get rid of your old CRTs with broken or non-existing DDC.

What makes you think DDC (EDID?) has anything to do with this? CRTs offer a major feature lacking in mainstream LCDs: configurability. That means one using a CRT is not forced to use a particular (native) resolution that may not suit his requirements, lest choose from a limited number of poor quality (usually inappropriate aspect ratio) alternatives. Forcing resolution up to the maximum the physics support (or even above) along with forcing logical density up, enables one to enjoy the maximum quality afforded by the hardware, without giving up quality and legibly sized text and other objects. FWIW, the most used displays in this building actually have working EDID, but all of those can be made to pretend they don't via a cable swap, thus facilitating testing to see whether software behaves acceptably when good EDID is not present, something most driver & X devs are apparently loathe or unequipped to do themselves. Consequently, I've been acquiring additional (free) CRTs as opportunity presents in order to ensure I need never do without before affordable fully configurable alternatives appear in the marketplace. Whether any hardware I use for testing has working EDID or not shouldn't bear on the resolution of this. Broken EDID exists outside this building, and likely will for many moons to come. As previously noted via Keyword, this is a usability (aka configurability) issue. Automagic results simply do not suit everyone. The visually challenged do not deserve zero action on this. 1-How to configure configurable hardware with supported drivers via xorg.conf.d/ files should not depend on which hardware one has the misfortune to be faced with: a-Choice of monitor identifier string shouldn't produce different behaviors among available chips or drivers. As long as it does, the sample files should address it, or the doc portions of them should be removed in favor of nudging users toward more complete documentation. b-[not addressed by comment 13]While on Intel (865G at least) it is sufficient to have only 50-monitor.conf for DisplaySize and PreferredMode to be applied as expected, on both rv200 and rv380 radeon it is required to also have both 50-device.conf and 50-screen.conf, each with appropriate lines uncommented, lest the entirety of 50-monitor.conf be ignored. 2-Some users will at least for a time try to copy and paste from what used to work, given that comprehensive X configuration tools users used to depend on don't even exist any more. 3-Until DTEs provide a big single easy to find knob to scale all desktop sizing up or down, manual X configuration, which is global, will remain more efficacious for (arguably most) visually challenged users than hunting down font size, theme and other settings in settings windows that initialize at sizes too small or otherwise difficult for them to navigate without pain, or at all. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=706024 https://bugzilla.novell.com/show_bug.cgi?id=706024#c16 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |UPSTREAM --- Comment #16 from Felix Miata <mrmazda@earthlink.net> 2011-07-24 18:20:09 UTC --- Egbert, I filed upstream, and reported the upstream bug URL here before Stefan ever started replying, and he kept on replying here rather than there, and he never suggested there might be more appropriate. Based upon sampling of Fedora 15 and Mandriva 2011, which leave xorg.conf.d/ empty, and *buntu 11.04, which doesn't even provide xorg.conf.d/, it seems unlikely initially testing anywhere but Factory would make any sense for any like me who don't program or build, but depend on rpms to be able to hunt for bugs. It's rarely a given whether a bug I encounter is a bug on the distro's own patches packaging or upstream unless I can test on other distros, while some things aren't even testable on others, as in this case, where the others don't provide xorg.conf.d/ skeletons. I often file upstream instead, but figuring out whether upstream is kernel or freedesktop or driver isn't so easy either. This bug doesn't belong WONTFIX. It belongs either open pending action on the indicated upstream bug, or less logically, resolved UPSTREAM. WONTFIX doesn't make a problem a non-bug, and alludes to a position that it shouldn't get fixed, unlike UPSTREAM. I understand the distro's resource limitations, but when an openSUSE dev who seems also to be upstream active (e.g. eich@pdx.freedesktop.org, sndirsch@suse.de or mhopf@suse.de), thus looking like one who wears multiple hats, fails to point upstream, it seems there could be good reason not to. I wish you people would quit applying the term "corner case" or "minority" to nearly every usability issue I raise, unless ease of use is not a significant goal of the openSUSE project. The US at least has a large and rapidly growing number of retiring and retired baby boomers, a huge number of which no longer have the luxury of good eyesight. This minority, and the younger who also have imperfect vision, do not not deserve short-shrifting of obstacles (like expensive high quality screens that get their quality from high density) to usable systems. (In reply to comment #15)

A CRT usually provides a list of modes for it's aspect ratio which is in most cases just 4:3. It also presents preffered modes and even modes with detailed timing data to be used. In the vast majority you cannot get any better modes without excessive hand tuning.

This isn't about CRTs. It's about HDTVs marketed as computer screens, with a preferred mode of 16:9 aspect, and all optional modes of lower resolution _and_ distorting 4:3 aspect. It's become customary to provide only 1920x1080 plus legacy vesa modes (1024x768, 800x600, 640x480 & sometimes 1280x1024, which @ 5:4 is even worse) on these devices, or 136Xx768 instead of 1920x1080. The distortion provided by 4:3 modes is simply unacceptable to many who are used to enlarging the desktop via the only means they have known, resolution reduction. I know resolution reduction is the wrong way to enlarge the desktop, but vast numbers of people do it anyway. Forcing an artificially large DPI is a much better means to their ends, so until a simpler _global_ method of controlling overall desktop sizing appears, it needs to work, and keep enabled whatever the display's native mode happens to be.

...

the physics support (or even above) along with forcing logical density up, enables one to enjoy the maximum quality afforded by the hardware, without giving up quality and legibly sized text and other objects.

True, this is a corner case - but what does this have to do with the screen size? The monitor advertises a screen size which should be sufficient for dpi calculation

It isn't sufficient. Actual physical pixel density does not go hand in hand with human needs, and neither does assumed logical density. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.