[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
supported.
The list is:
640x480
800x600
1024x576 SD, 16:9
1024x768
1152x864
1280x720 720p 16:9 aspect ratio
1280x800
1280x1024
1366x768 HD, 16:9
1440x900
1600x900 HD+, 16:9
1600x1200
1680x945 HD+, 18.4" panel, 16:9
1680x1050
1920x1080 HDTV, 16:9
1920x1200
1920x1440
2048x1152 16:9 aspect ratio
2048x1536
2560x1600
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?
Thanks
Rodrigo.
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