[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

Rodrigo Vivi rodrigo.vivi at gmail.com
Fri Apr 13 12:05:04 PDT 2012

So, the modes that I added in that list was half got from windows on
my monitor and half requested by HP.

So let forget about other modes and focus on the one required by HP.
HP has requested the same list for everybody 3 years ago and it was
added by Windows and AMD at that time but our open drivers never

The list is:

1024x576	SD, 16:9
1280x720	720p 16:9 aspect ratio
1366x768	HD, 16:9
1600x900	HD+, 16:9
1680x945	HD+, 18.4" panel, 16:9
1920x1080	HDTV, 16:9
2048x1152	16:9 aspect ratio

So I'm in favor of doing something to catch up closed drivers in terms
of giving our customers the same kind of resolutions.
I'm not saying that we are worst because we don't add something that
is not a standard as others do, but I do think we could provide the
customers and final users all the options that he might be expecting,
once everybody else on the market is also doing.

Ok, I didn't want to add it blindly as well, so I got the edid and
verified that we can add any mode checking the range when the range
flag is set using gtf or cvt depending on monitor and for cvt we
weren't adding any mode at all. ok ok... this bug is more easy to
fix.. renaming it for dmt and applying it for cvt solves this bug..
However it does'' t solve the HP request for all those modes in the
list... So, do you have an idea about how to add those modes?

Takashi's patch on X probably fixes the critical part for HP, but they
still wants to see those modes added by default. So.. any other ideas?


On Fri, Apr 13, 2012 at 2:16 PM, Adam Jackson <ajax at redhat.com> wrote:
> On 4/13/12 11:25 AM, David Airlie wrote:
>> I'm still intrigued about what hardware exists with a panel with a native
>> mode it doesn't describe.
>> How are we to know what the panel preferred mode is in this case?
>> Or is this for larger panels wanting to use smaller modes?
> AFAICT, yes, this last one.  For asymmetric cloning, a misfeature exceeded
> in stupidity only by panning.  Because you have a panel with a bizarre size
> and then an external that's sane, and you try to clone, and even though the
> bizarre size would fit it's not available on both mode lists.
> And at _that_ point, this isn't an EDID parser issue at all, it's driver
> policy.
> - ajax
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Rodrigo Vivi
Blog: http://blog.vivi.eng.br
GPG: 0x905BE242 @ wwwkeys.pgp.net

More information about the dri-devel mailing list