From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 31943] drm EDID checking is too strict
Date: Fri, 8 Apr 2011 09:05:29 -0700 (PDT)
Message-ID: <20110408160530.83A8F13004F@annarchy.freedesktop.org>
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path:
Received: from annarchy.freedesktop.org (annarchy.freedesktop.org
[131.252.210.176])
by gabe.freedesktop.org (Postfix) with ESMTP id 3C0649E988
for ;
Fri, 8 Apr 2011 09:05:31 -0700 (PDT)
In-Reply-To:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=31943
--- Comment #12 from Alex Deucher 2011-04-08 09:05:29 PDT ---
(In reply to comment #11)
> I've got the problem as well. I've got an older Hanns G JC199D, and apparently
> nouveau doesn't like its checksum either.
The edid parser is shared by all kms drm drivers.
> Is this a version problem, btw? What is so offensive about these older EDID
> versions that the drivers are crapping out on (other than the checksum)? Could
> the code validate the other sections to at least *see* if the data is garbage
> before throwing the whole block out?
Ideally, we implement some basic sanity checks to avoid reading past the end of
an edid with a bad checksum. Usually the checksum problems are something
stupid like a vendor made a last minute change one of the fields or a
tv/receiver mangles something when updating hdmi fields. IMHO, it would be
better to use the EDID than not.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.