Skip to contentSkip to conversation

drm/edid: Fix the HDTV hack yet more.

PATCH In review Andrew Shadura 2 participants 4 messages Feb 22, 2012

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 drm/edid: Fix the HDTV hack yet more.

Checking for just two variants of standard timings for 1366x768 isn't quite correct, let's check for ranges instead.

---
 drivers/gpu/drm/drm_edid.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/drm_edid.c +2 -2
index 3e927ce..49d784d 100644
@@ -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;
 	}
Signature · 1 line
WBR, Andrew

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

#1 lore raw
Quoted 3 lines · Andrew Shadura

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

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

#2 lore raw

Hello,

Quoted 11 lines · On Wed, 22 Feb 2012 13:05:34 -0500 Adam Jackson <[email protected]> wrote:
Quoted 3 lines · Andrew Shadura

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

Quoted 8 lines

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.

Signature · 1 line
WBR, Andrew

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel

#3 lore raw
Quoted 3 lines · Andrew Shadura

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 mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel