On Thu, Sep 23, 2004 at 10:32:52PM -0400, Jay Berkenbilt wrote:
> Reading through the code, I have a couple of quick comments. I'll
> also test on a few machines and post additional comments even if they
> are limited to saying that it works well.
>
> * My guess is that several people out there have monitors whose
> refresh rates are suboptimal but whose rates will not get fixed
> during the upgrade because there are already answers in debconf to
> some questions. If my understanding is correct, this could be
> partially mitigated by changing the names of the some of the
> variables.
Yikes; I think *that* is a really bad idea. It's a kludge.
> I haven't actually looked to see whether this is the case, but it may
> be worth considering if it isn't. Stated differently, it may be worth
> seeing whether there is something that could make it possible to
> automatically fix suboptimal data left over from older versions of the
> package. (I'm going to dpkg -P --force-depends xserver-xfree86 and
> reinstall just to be sure.)
That's difficult. We don't how to recognize "suboptimal" data when we see
it. What you consider "suboptimal" may be what the user saw, accepted, and
liked.
One big challenge in using debconf as I am is that one has to manage up to
three sources of information:
1) what is autodetected
2) what the package falls back to when autodetection fails
3) what the user wants
The principle of debconf (and configuration in Debian in general) is that
3) should always trump 1) and 2). The thing is, I think debconf was mainly
designed for case 2) -- more specifically, for situations where user
preferences are all that matter, and "autodetection" is an inapplicable
concept. Sometimes the user wants the wrong thing because he or she is
unaware that the defaults came from 1).
In re-envisioning the X server debconfage for post-sarge, I am considering
a design along the lines of:
* Dumbing the interaction down to just the setting of parameters.
* Providing fallback question defaults to address 2).
* Providing user-invisible templates that "shadow" certain questions, which
will exist to let autodetection tools poke values into them.
We can then allow for competition in the area of configuration frontends.
I'd really like to get that mess out of the X server config scripts. This
is an area that needs vigorous development, and X server packages -- even
after X.Org's much-vaunted "modularization" takes place, are likely going
to be big and slow. A X server debconf configurator package can be small
and nimble.
> * In the Medium monitor selection code, there are 60Hz and 85Hz
> choices for 1280x960 but only a 60Hz choice for 1280x1024.
> Personally, my eyes hurt looking at any screen whose refresh rate
> is less than about 75Hz (which is what motivated me to post this
> bug in the first place). I think it would be best if there were a
> 75Hz rate at all common resolutions. 1280x1024 is the native
> resolution on almost all 17" and 19" flat panels, so it is a pretty
> important one to have in there. There is also no option to have
> 1024x768 at anything higher than 75Hz. I guess, ideally, there
> should be a 60Hz, 75Hz, and 85Hz for all resolutions.
I agree, but I think you're overlooking the large comment in the code
you're talking about.
# The mode and range information below is adapted from the built-in
# modeline definitions in the XFree86 source tree; specifically
# xc/programs/Xserver/hw/xfree86/etc/vesamodes and
# xc/programs/Xserver/hw/xfree86/etc/extramodes. The rule of thumb is to
# set the sync ranges based on the hsync and vrefresh values used by the
# selected mode, plus a little bit of "headroom" to allow other modes to
# be used (as long as they don't push the hardware much harder than the
# selected one) and a margin of error (e.g., if the video driver or video
# card overdrives the monitor just a little bit).
I'd supply the choices you're asking for if the built-in mode list
supported them.
> I should have time in the next day or two to test this on a few different
> machines. If I have access to check out from subversion, I'll try
> checking out the maintainer scripts and testing with all of them.
> Otherwise, I'll just drop this config_monitor into the version in the
> current package. (I'm trying to check svn now but alioth is too slow.)
Debian's XFree86 SVN repo is not hosted on alioth (fortunately?). It's
hosted at necrotic.deadbeast.net.
http://necrotic.deadbeast.net/xsf/XFree86/README.txt
> I'll try to get back to you after testing on three machines: a laptop
> with a Radeon Mobility M6, my desktop machine with a Radeon 9600, and
> my work machine with a built-in Intel video. I am no longer using the
> Rage Pro card I was using when I posted the original report.
I understand. Thanks a lot for your help!
--
G. Branden Robinson | If you have the slightest bit of
Debian GNU/Linux | intellectual integrity you cannot
branden@debian.org | support the government.
http://people.debian.org/~branden/ | -- anonymous
Attachment:
signature.asc
Description: Digital signature