From: Sven Joachim <svenjoac@gmx.de>
To: dri-devel@lists.freedesktop.org, Adam Jackson <ajax@redhat.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>,
Dave Airlie <airlied@redhat.com>, Takashi Iwai <tiwai@suse.de>,
linux-kernel@vger.kernel.org
Subject: Bogus video resolution in Linux 3.5-rc4
Date: Mon, 25 Jun 2012 16:03:36 +0200 [thread overview]
Message-ID: <874npzebev.fsf@turtle.gmx.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]
After upgrading to Linux 3.5-rc4 from 3.4.4, I noticed that my monitor
switched to a resolution of 1280x960 rather than the native 1280x1024,
and nouveau has set up a framebuffer of 1680x945. It goes without
saying that the result looks terrible.
Bisecting shows that the problem started with commit cb21aafe1:
--8<---------------cut here---------------start------------->8---
commit cb21aafe121b1c3ad4c77cc5c22320163f16ba42
Author: Adam Jackson <ajax@redhat.com>
Date: Fri Apr 13 16:33:36 2012 -0400
drm/edid: Do drm_dmt_modes_for_range() for all range descriptor types
EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is
continuous frequency", and moves the set of supported timing formulas
into the range descriptor itself. In any event, the range descriptor
can act as a filter on the DMT list without regard to a specific timing
formula.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cb40611..9363349 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1042,12 +1042,13 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
{
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = &timing->data.other_data;
- int gtf = (closure->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF);
- if (gtf && data->type == EDID_DETAIL_MONITOR_RANGE)
- closure->modes += drm_dmt_modes_for_range(closure->connector,
- closure->edid,
- timing);
+ if (data->type != EDID_DETAIL_MONITOR_RANGE)
+ return;
+
+ closure->modes += drm_dmt_modes_for_range(closure->connector,
+ closure->edid,
+ timing);
}
static int
--8<---------------cut here---------------end--------------->8---
With a kernel from this commit nouveau sets up a resolution of
1400x1050; kernels built from commits cffd754 and fc48f16 complain about
an invalid EDID and use the 1024x768 fallback.
Attached is the /sys/class/drm/card0-DVI-I-1/edid file from a working
kernel; in 3.5-rc4 it is identical.
Cheers,
Sven
[-- Attachment #2: edid --]
[-- Type: application/octet-stream, Size: 128 bytes --]
next reply other threads:[~2012-06-25 14:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-25 14:03 Sven Joachim [this message]
2012-06-25 15:53 ` Bogus video resolution in Linux 3.5-rc4 Takashi Iwai
2012-06-25 15:57 ` Takashi Iwai
2012-06-25 17:40 ` Sven Joachim
2012-06-25 19:22 ` Adam Jackson
2012-06-25 19:24 ` Takashi Iwai
2012-06-25 19:38 ` Sven Joachim
2012-06-26 7:21 ` Takashi Iwai
2012-06-30 18:46 ` Calvin Owens
2012-06-30 19:24 ` Takashi Iwai
2012-06-30 21:14 ` Sven Joachim
2012-07-02 19:46 ` Adam Jackson
2012-07-03 9:20 ` Takashi Iwai
2012-06-25 20:25 ` Andy Furniss
2012-06-25 21:03 ` Andy Furniss
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874npzebev.fsf@turtle.gmx.de \
--to=svenjoac@gmx.de \
--cc=airlied@redhat.com \
--cc=ajax@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox