[Bug 706024] New: DisplaySize in 50-monitor.conf is ignored
https://bugzilla.novell.com/show_bug.cgi?id=706024 https://bugzilla.novell.com/show_bug.cgi?id=706024#c0 Summary: DisplaySize in 50-monitor.conf is ignored Classification: openSUSE Product: openSUSE 12.1 Version: Factory Platform: x86 OS/Version: Other Status: NEW Keywords: Usability Severity: Normal Priority: P5 - None Component: X.Org AssignedTo: bnc-team-xorg-bugs@forge.provo.novell.com ReportedBy: mrmazda@earthlink.net QAContact: xorg-maintainer-bugs@forge.provo.novell.com CC: sndirsch@novell.com Found By: --- Blocker: --- Created an attachment (id=440201) --> (http://bugzilla.novell.com/attachment.cgi?id=440201) 50-monitor.conf prepended to Xorg.0.log from 11.4 on same i945G system To reproduce: 1-use 50-monitor.conf file that worked in 11.4 to produce a particular DPI result via DisplaySize 2-start X Actual result: 1-desktop objects and fonts too small 2-DTE is forced to 96 DPI Expected result: 1-desktop objects and fonts useful and pleasant sizes 2-DTE is DPI resulting from combining actual resolution with DisplaySize contained in 50-monitor.conf Comments: Same 50-monitor.conf file works on same system running 11.4. Same content resident in xorg.conf works as expected (in the instant case, 120 DPI forced on LCD). Actual display DPI is ~69 only kernel-desktop-2.6.30rc6 tested Smolt (i945G): 3c5235c2-5cf6-44f6-9ffc-2aced0c7ae5e__www.smolts.org = pub_082e4ac5-1864-4397-9a2a-2001438d4aac Also tested on i915G host gx280 with equivalent behavior for forcing 144 DPI on CRT. I may test on i865G, i845G, radeon and nv as time permits if no one beats me to them. -- 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#c1
--- Comment #1 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c2
--- Comment #2 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c3
--- Comment #3 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c4
Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c5
Stefan Dirsch
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c
Stefan Dirsch
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c6
Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c7
Stefan Dirsch
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c8
Felix Miata
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#c9
Stefan Dirsch
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c10
Felix Miata
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#c11
Stefan Dirsch
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c12
Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c13
Stefan Dirsch
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c14
Felix Miata
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#c15
Egbert Eich
(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
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.
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 (unless you want to do things like virtual where the screen size issue still isn't handled correctly. Most of what you are trying are corner cases anyhow.
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.
Fine, but please report those things to the upstream project. Maybe you can convince someone with developers skills and a lot of time on his hands that this seems worthwhile addressing. While I agree with you that this you are right I need to tell you that we here at SUSE are not staffed to deal with requests that address only minority use case. If you need something like this fixedd it's best to do it yourself and address this with the upstream project. Therefore reporting those issues here will most likely not get you the desired results and will only waste your time. -- 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
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.
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. Felix, I'd say it's save to say that at least 95 percent of the issues I see reported by you are in fact upstream bugs. There may be a misconception that distro patches rework half of the code. I can rest you assured distros generally don't do that. Moreover I have implemented the policy of minimum
https://bugzilla.novell.com/show_bug.cgi?id=706024
https://bugzilla.novell.com/show_bug.cgi?id=706024#c17
--- Comment #17 from Egbert Eich
I often file upstream instead, but figuring out whether upstream is kernel or freedesktop or driver isn't so easy either.
This is true. But you are not expected to identify the right component. X, Mesa and drm can all be handled in the same bugzilla.
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.
True. If there is a component I take strong ownership of I will also consider issues regarding policies, taste etc. and try to address them if I feel the reporter has a point. But as always opinions may differ and I may feel I have more urgent things on my plate. After all this is free software - the source is available, and often times if one comes with a patch things will be addressed a lot more quickly. If you don't code you need to solicit people who do to code something up for you. If you are not addressing a real bug which everyone is eager to fix this creates an additional hurdle.
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
Sure, but we usually cannot address those issues here. Therefore there is little use to report them here with the expectation that we do. There seems to exist a misconception that distro people are standing by waiting for reports to come in. I can rest you assured that this is not the case. openSUSE is some sort of best effort project, most of my time is devoted to addressing issues and features for enterprise products reported by their customers. The same is true for Stefan and Matthias. But this is why we are doing free software: everyone can step in and help. If more people did many things you report here would have been addresse a long time ago already.
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.
All sound and well, if there's a justifiable business case and an expected revenue this will become a feature for an enterprise product and someone will be tasked to address this. Before this it's an issue that may or may not be fixed depending on the workload and needs seen by developers. But please - before you go and try to convince me of the business case: you need to convince a product manager - and person is unlikely to read this ticket.
It isn't sufficient. Actual physical pixel density does not go hand in hand with human needs, and neither does assumed logical density.
Ineed. But none of what is really needed actually works well with how X handles things: X doesn't advertise a resolution. It advertises the root window dimensions and a resolution. The app needs to calculate the resolution. Internally X maintains a resolution - however on the way to the client this gets transformed to physical screen dimensions again. The optimal dpi value to choose depends very much on distance at which a user will place his monitor (including a personal factor). This distance again depends mostly on the physical size of the screen but also on the use case and to a limited extent also on the resolution. -- 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.
participants (1)
-
bugzilla_noreply@novell.com