Checking for just two variants of standard timings for 1366x768 isn't quite correct, let's check for ranges instead.
Signed-off-by: Andrew Shadura andrew@beldisplaytech.com --- drivers/gpu/drm/drm_edid.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 3e927ce..49d784d 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -714,8 +714,8 @@ static int standard_timing_level(struct edid *edid)
/* HDTV hack, part 1 */ if (vrefresh_rate == 60 && - ((hsize == 1360 && vsize == 765) || - (hsize == 1368 && vsize == 769))) { + ((hsize >= 1360 && hsize <= 1368) && + (vsize >= 765 && vsize <= 769))) { hsize = 1366; vsize = 768; }
On Wed, 2012-02-22 at 19:08 +0300, Andrew Shadura wrote:
Checking for just two variants of standard timings for 1366x768 isn't quite correct, let's check for ranges instead.
I... doubt it? Standard timing descriptors are a tuple of
* width in character cells (ie, 8 pixels) * one of four aspect ratios * refresh rate
So you're only ever going to have 1360 or 1368, and then in integer math I think you could only possibly ever get:
a) 1360 * 9 / 16 = 765 b) 1368 * 9 / 16 = 769
If you're managing to get something else I'm a little concerned, and would really be delighted to see the EDID block for it.
- ajax
Hello,
On Wed, 22 Feb 2012 13:05:34 -0500 Adam Jackson ajax@redhat.com wrote:
On Wed, 2012-02-22 at 19:08 +0300, Andrew Shadura wrote:
Checking for just two variants of standard timings for 1366x768 isn't quite correct, let's check for ranges instead.
I... doubt it? Standard timing descriptors are a tuple of
- width in character cells (ie, 8 pixels)
- one of four aspect ratios
- refresh rate
So you're only ever going to have 1360 or 1368, and then in integer math I think you could only possibly ever get:
a) 1360 * 9 / 16 = 765 b) 1368 * 9 / 16 = 769
If you're managing to get something else I'm a little concerned, and would really be delighted to see the EDID block for it.
Well, my fault, I haven't read the code 10 lines above :) Indeed, that's not STD, it's DTD. And I'm not sure how to fix it then, but DTD gives 1360x768, and that isn't quite correct.
On Wed, 2012-02-22 at 23:56 +0300, Andrew Shadura wrote:
Well, my fault, I haven't read the code 10 lines above :) Indeed, that's not STD, it's DTD. And I'm not sure how to fix it then, but DTD gives 1360x768, and that isn't quite correct.
Yeah, that's a different class of bug, that's the monitor vendor refusing to use the precision that the DTD has.
The usual method for fixing that is the quirks table. My concern in this particular case is whether it's better to just always disbelieve 1360x768 in DTDs or whether we should build up a ton of quirks. I've tended to side with not second-guessing DTD modes out of caution.
- ajax
dri-devel@lists.freedesktop.org
-
Adam Jackson -
Andrew Shadura