[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