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@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@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to