[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.
Adam Jackson
ajax at redhat.com
Fri Apr 13 16:14:46 CEST 2012
On 4/12/12 7:09 PM, Rodrigo Vivi wrote:
>> CVT monitors _must_ accept GTF as well, EDID says so. So functionally
>> there's nothing wrong with the existing code.
>
> Actually the current code just check for gtf flag... so if a monitor
> is gtf2 or cvt this dmt modes are not being added.
Yeah, that's a bug. That's why I said it should be renamed
drm_dmt_modes_for_range and run unconditionally if we find a range
descriptor.
>> The thing you're trying
>> to sneak in here is a 1600x900 timing that doesn't correspond to
>> anything in DMT (at least, not in the copy of DMT that I have handy).
>> It's fine to want to add more modes - although I'm still unclear exactly
>> which machine you're trying to compensate for here - but not if it comes
>> by sacrificing the DMT list, which is there for a reason.
>
> There are customers complaining about lots of missing modes that are
> supported by windows and/or other drivers and we are missing. If this
> modes are ok on edid spec I se no problem in add them... ok.. I don't
> like hardcoded as well... I think we could find another way to invent
> this modes and use the cvt function to calculate timings... or
> something like that.
Why are they complaining, and why do you think you're obligated to care?
If it's not the native panel size and it's not a commonly found size in
the wild, why are we obligated to provide them for every user? Remember
that userspace has the ability to hand in modes from above.
>>> + /* 1024x576 at 60Hz */
>>> + { DRM_MODE("1024x576", DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
>>> + 1160, 1296, 0, 576, 579, 584, 599, 0,
>>> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
>>> + /* 2560x1600 at 60Hz */
>>> + { DRM_MODE("2560x1600", DRM_MODE_TYPE_DRIVER, 348500, 2560, 2760,
>>> + 3032, 3504, 0, 1600, 1603, 1609, 1658, 0,
>>> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
>
> These ones came as request from HP.
> I'll check how they made that list.
1024x576 almost makes some sense, it's the fat-pixel version of
2048x1152. Except that you typically do fat-pixel modes like 1280x800
on a 2560x1600 screen because you're compensating for the host not being
able to do dual-link DVI (cough Intel), but 2048x1152 fits in a single link.
That 2560 mode appears to have been copied from the DMT list, but
seriously nobody does that size without doing reduced blanking. So if
we took my series to add the RB modes to the DMT list, and fixed that
bug I mentioned above...
- ajax
More information about the Intel-gfx
mailing list