From: Holly Bostick <motub@planet.nl>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Radeon 9200/Xorg refresh rate
Date: Fri, 18 Nov 2005 11:31:40 +0100 [thread overview]
Message-ID: <437DAD8C.60508@planet.nl> (raw)
In-Reply-To: <7573e9640511171729i5965a970o8dee15f647c809c7@mail.gmail.com>
Richard Fish schreef:
> On 11/17/05, Holly Bostick <motub@planet.nl> wrote:
>
>> The point being, you need to know your monitor's specs.
>
>
> Back in the day, that was true. But with modern monitors (I'm not
> sure of the spec, I think is part of the VESA compliance
> requirements) the video driver can query the monitor for what refresh
> rates and modes supported by the monitor.
"Back in the day", indeed! True, but all monitors currently in use or
available for sale are not necessarily compliant with the spec, or
with the current spec. Perhaps they're older models, hand-me-downs or
remaindered at a store. Compliance or incomplete compliance with specs
such as VESA are not particularly a deal-breaker (or even much
mentioned) when buying a monitor, and there's no explicit reason that
anyone might choose a "modern" monitor rather than a remaindered one (a
model that is no longer actively produced by the manufacturer, but
unused units of the product remain at the store's warehouse), and of
course if one buys an off-the-shelf computer (Compaq, HP, Packard Bell)
that comes with a monitor, you have no idea or choice what you in fact
are getting in terms of "modernity"-- most likely such a
no-longer-produced model is the one provided, to reduce costs. Because,
really, if the monitor displays acceptably, why should Compaq or HP or
PacBell particularly care to provide the very most recent model, for
which they must pay more (and pass the extra cost on to the end buyer)?
How many people actually ask the monitors specific specs in such a
situation?
And further, monitors may be actively limited in specification, the way
mine is. I'm almost sure that I've tried autodetection at least once
(when the head of the ATI team said that the new drivers were better
served by having a relatively empty xorg.conf, and that autodetection
was now working in fgrlxconfig/aticonfig). Unsurprisingly, my monitor
was again limited to 1024x768@75, and I had to insert my refresh rates
in order to get 1280x1024@60.
But of course, since the actual monitor specs are not all that critical
to "the average user", the average user who owns this model probably
doesn't even know that the monitor is capable of 1280x1024 (and if they
want that resolution, they buy a new monitor), and are satisfied to "eat
what they're given", as it were. That's fine for those who find it fine,
but I've gotta say, it really burned me, just on the principle of the
thing, to discover that my monitor was had capabilities that were
actively concealed from me, for my own "protection" I suppose.
> This is what the "DDC" module in X is for, and why monitors no longer
> require 'drivers' (which was never a 'driver' anyway, just a .inf
> that told the video driver what the possible modes were).
All monitors do not correctly report their DDC information, flatly put.
Sometimes because of active limitation as I experience, or because
they're cheaply made (just well enough to hit the mark, rather than with
strict compliance to spec), or simply because they were made before the
spec was implemented. After all, on anyone's standard upgrade list, how
high priority is really "the monitor", as opposed to the CPU, the mobo,
the memory, the video card-- even the sound card or network hardware?
Who really bothers if the monitor works (meaning, "displays without
corruption")?
All of which means, yes, you have a point, and in many (possibly even
most) situations you're probably right, but there is still a place for
knowing your monitor's actual specifications, and there is still a
place/reason for inserting such specs actively into xorg.conf. I stand
by "know your specs". :-) .
Holly
--
gentoo-user@gentoo.org mailing list
next prev parent reply other threads:[~2005-11-18 10:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-17 23:52 [gentoo-user] Radeon 9200/Xorg refresh rate Michael Kjorling
2005-11-18 0:04 ` Richard Fish
2005-11-18 0:50 ` Michael Kjorling
2005-11-18 0:13 ` Mark Knecht
2005-11-18 0:51 ` Holly Bostick
2005-11-18 1:29 ` Richard Fish
2005-11-18 10:31 ` Holly Bostick [this message]
2005-11-18 14:59 ` Richard Fish
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=437DAD8C.60508@planet.nl \
--to=motub@planet.nl \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox