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 <eich@novell.com> 2011-07-25 05:11:19 UTC --- (In reply to comment #16) patches in X11:XOrg now meaning that the general rule will be that a patch has to either go upstream or will get removed. If there is a real bug we try to fix it but many things you are asking for are taste, nice to have or corner cases. There I'm sorry to have to tell you that unless these things are giving me the creeps, too I don't bother to address them.
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.