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

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

[Andrew Shadura]

[-- Attachment #1.1: Type: text/plain, Size: 814 bytes --]

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;
 	}
-- 
WBR, Andrew

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Fix the HDTV hack yet more.

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 644 bytes --]

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Fix the HDTV hack yet more.

[Andrew Shadura]

[-- Attachment #1.1: Type: text/plain, Size: 957 bytes --]

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.

-- 
WBR, Andrew

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Fix the HDTV hack yet more.

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 660 bytes --]

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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel