Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Fri, 20 Apr 2012 13:04:42 +0100,
Dave Airlie wrote:
> 
> On Thu, Apr 19, 2012 at 1:03 PM, Takashi Iwai <tiwai@xxxxxxx> wrote:
> > At Tue, 17 Apr 2012 17:26:26 +0200,
> > Takashi Iwai wrote:
> >>
> >> At Fri, 13 Apr 2012 16:56:26 -0400,
> >> Adam Jackson wrote:
> >> >
> >> > On 4/13/12 4:33 PM, Adam Jackson wrote:
> >> > > Incorporates some feedback from Rodrigo and Takashi.  Major themes of the
> >> > > series:
> >> > >
> >> > > - Fix the DMT list to include reduced-blanking modes
> >> > > - Add modes from DMT for any range descriptor type
> >> > > - Add an extra modes list for things not in DMT
> >> > > - For ranges that specify a formula, generate timings from the extra modes
> >> > >
> >> > > This still doesn't address the driver policy decision of "I know I have
> >> > > a scaler, add modes as if there were a range descriptor even if there's
> >> > > not one".  But it should at least make clear what such a helper function
> >> > > should do.
> >> >
> >> > One minor buglet in this series that's not obvious from inspection (and
> >> > that I didn't realize until just now) is that putting 1366x768 in the
> >> > minimode list won't do what you want, since the mode you get back will
> >> > be 1368x768.  Probably we should move the manual-underscan hack into the
> >> > timing generators themselves.
> >>
> >> Sounds like a good compromise.  We have already hacks in drm_edid.c
> >> for HDMI TV, so one exception more isn't that bad ;)
> >
> > FYI, I tried the hack below and it seems working.
> >
> Is this hack going to be a real patch? ajax care to review?

For the easiness, below is the patch with my sign-off.


thanks,

Takashi

---

From: Takashi Iwai <tiwai@xxxxxxx>
Subject: [PATCH 1/2] drm/edid: Add a workaround for 1366x768 HD panel

HD panel (1366x768) found most commonly on laptops can't be represented
exactly in CVT/DMT expression, which leads to 1368x768 instead, because
1366 can't be divided by 8.

Add a hack to convert to 1366x768 manually as an exception.

Signed-off-by: Takashi Iwai <tiwai@xxxxxxx>
---
 drivers/gpu/drm/drm_edid.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bad2f11..c6366e9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1039,6 +1039,19 @@ drm_dmt_modes_for_range(struct drm_connector *connector, struct edid *edid,
 	return modes;
 }
 
+/* fix up 1366x768 mode from 1368x768;
+ * GFT/CVT can't express 1366 width which isn't dividable by 8
+ */
+static void fixup_mode_1366x768(struct drm_display_mode *mode)
+{
+	if (mode->hdisplay == 1368 && mode->vdisplay == 768) {
+		mode->hdisplay = 1366;
+		mode->hsync_start--;
+		mode->hsync_end--;
+		drm_mode_set_name(mode);
+	}
+}
+
 static int
 drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
 			struct detailed_timing *timing)
@@ -1053,6 +1066,7 @@ drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
 		if (!newmode)
 			return modes;
 
+		fixup_mode_1366x768(newmode);
 		if (!mode_in_range(newmode, edid, timing)) {
 			drm_mode_destroy(dev, newmode);
 			continue;
@@ -1080,6 +1094,7 @@ drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
 		if (!newmode)
 			return modes;
 
+		fixup_mode_1366x768(newmode);
 		if (!mode_in_range(newmode, edid, timing)) {
 			drm_mode_destroy(dev, newmode);
 			continue;
-- 
1.7.9.2

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



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux