From: Adam Jackson <ajax@redhat.com>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: -next queue and EDID stuff
Date: Mon, 27 Aug 2012 16:47:50 -0400 [thread overview]
Message-ID: <503BDCF6.5020607@redhat.com> (raw)
In-Reply-To: <CADnq5_OfrBh2T4LAOs+fYeKXsH0jN_4e1uTuAWg16W5r5MORwA@mail.gmail.com>
On 8/27/12 4:34 PM, Alex Deucher wrote:
> On Mon, Aug 27, 2012 at 4:24 PM, Adam Jackson <ajax@redhat.com> wrote:
>> Paul's FORCE_REDUCED_BLANKING series makes me nervous about what those
>> monitors will do over VGA, since from a conversation we had on IRC he hasn't
>> been able to test that.
>
> I asked the closed driver display team about these to see if we had
> any generic rules for whole classes of monitors and they do not. They
> keep a small database of displays that need special tweaking and then
> have a set of options that can be enabled by the user (always use
> CVT-RB rather than GTF, etc.). There's no generic solution since EDID
> 1.3 doesn't give us enough info to really enable generic rules on
> whole classes of monitors and most VGA connectors still use EDID 1.3
> with no extension blocks. EDID 1.4 is better, but few VGA connectors
> on monitors uses it. Other than that, they also rely on the EDID.
I really wish there were a useful way to identify the display controller
on the other end. DDC/CI will give it to you, kind of, but any monitor
that supports CI probably doesn't need quirking, at least not at this level.
Paul's series does pick specific vendor/model IDs as much as it can, but
when the model is "0" one is a little wary about whether the vendor
bothers to set the model ID meaningfully at all.
- ajax
next prev parent reply other threads:[~2012-08-27 20:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-23 23:50 -next queue and EDID stuff Dave Airlie
2012-08-27 20:24 ` Adam Jackson
2012-08-27 20:34 ` Alex Deucher
2012-08-27 20:47 ` Adam Jackson [this message]
2012-08-27 21:51 ` Daniel Vetter
2012-08-27 23:04 ` Ben Skeggs
2012-08-28 23:33 ` Ian Pilcher
2012-08-29 0:13 ` Adam Jackson
2012-08-29 4:18 ` Ian Pilcher
2012-08-29 7:56 ` Daniel Vetter
2012-08-29 19:53 ` Ian Pilcher
2012-08-29 21:38 ` Adam Jackson
2012-08-30 5:23 ` Ian Pilcher
2012-08-30 7:41 ` Daniel Vetter
2012-09-04 14:02 ` Ian Pilcher
2012-09-11 13:59 ` Ian Pilcher
2012-08-28 8:41 ` Baurzhan Ismagulov
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=503BDCF6.5020607@redhat.com \
--to=ajax@redhat.com \
--cc=alexdeucher@gmail.com \
--cc=dri-devel@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.