Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes
On Thu, Apr 19, 2012 at 1:03 PM, Takashi Iwai ti...@suse.de 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? Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes
On Thu, Apr 19, 2012 at 3:58 PM, Takashi Iwai ti...@suse.de wrote: At Thu, 19 Apr 2012 14:03:58 +0200, Takashi Iwai 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 ;) I've pulled the series into -next along with the NULL check fix. the only outstanding bit is the hack. Thanks, Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes
At Fri, 20 Apr 2012 13:04:42 +0100,
Dave Airlie wrote:
On Thu, Apr 19, 2012 at 1:03 PM, Takashi Iwai ti...@suse.de 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 ti...@suse.de
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 ti...@suse.de
---
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes
At Fri, 20 Apr 2012 13:05:48 +0100,
Dave Airlie wrote:
On Thu, Apr 19, 2012 at 3:58 PM, Takashi Iwai ti...@suse.de wrote:
At Thu, 19 Apr 2012 14:03:58 +0200,
Takashi Iwai 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 ;)
I've pulled the series into -next along with the NULL check fix.
Thanks!
the only outstanding bit is the hack.
Also the packed attributes are missing in the new structs.
The fix patch is below.
Takashi
---
From: Takashi Iwai ti...@suse.de
Subject: [PATCH 2/2] drm/edid: Add packed attribute to new gtf2 and cvt structs
The new structs added in struct detailed_data_monitor_range must be
marked with packed attribute although the outer struct itself is
already marked as packed. Otherwise these 7-bytes structs may be
aligned, and give the wrong position and size for the data.
Signed-off-by: Takashi Iwai ti...@suse.de
---
include/drm/drm_edid.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 8cefbbe..0cac551 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -99,7 +99,7 @@ struct detailed_data_monitor_range {
__le16 m;
u8 k;
u8 j; /* need to divide by 2 */
- } gtf2;
+ } __attribute__((packed)) gtf2;
struct {
u8 version;
u8 data1; /* high 6 bits: extra clock resolution */
@@ -108,7 +108,7 @@ struct detailed_data_monitor_range {
u8 flags; /* preferred aspect and blanking support */
u8 supported_scalings;
u8 preferred_refresh;
- } cvt;
+ } __attribute__((packed)) cvt;
} formula;
} __attribute__((packed));
--
1.7.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes
At Thu, 19 Apr 2012 14:03:58 +0200,
Takashi Iwai 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.
In addition, there are some missing NULL checks...
Takashi
---
---
drivers/gpu/drm/drm_edid.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -789,6 +789,8 @@ drm_mode_std(struct drm_connector *conne
* secondary GTF curve. Please don't do that.
*/
mode = drm_gtf_mode(dev, hsize, vsize, vrefresh_rate, 0, 0);
+ if (!mode)
+ return NULL;
if (drm_mode_hsync(mode) drm_gtf2_hbreak(edid)) {
kfree(mode);
mode = drm_gtf_mode_complex(dev, hsize, vsize,
@@ -1071,6 +1073,8 @@ drm_gtf_modes_for_range(struct drm_conne
for (i = 0; i num_extra_modes; i++) {
const struct minimode *m = extra_modes[i];
newmode = drm_gtf_mode(dev, m-w, m-h, m-r, 0, 0);
+ if (!newmode)
+ return modes;
fixup_mode_1366x768(newmode);
if (!mode_in_range(newmode, edid, timing)) {
@@ -1097,6 +1101,8 @@ drm_cvt_modes_for_range(struct drm_conne
for (i = 0; i num_extra_modes; i++) {
const struct minimode *m = extra_modes[i];
newmode = drm_cvt_mode(dev, m-w, m-h, m-r, rb, 0, 0);
+ if (!newmode)
+ return modes;
fixup_mode_1366x768(newmode);
if (!mode_in_range(newmode, edid, timing)) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes
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 ;) Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes
At Fri, 13 Apr 2012 16:33:28 -0400, 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. I tried these patches now with a few monitors here and it looks working well (after fixing the alignment as I posted in another mail). I got new 1600x900 output on two monitors. Yay! I guess this will solve major of problems we've face for HD+ panel. The rest is the 1366x768 mode, but it's often covered by 1360x768. So, once when LVDS gets additional de facto standard modes, it'll be fixed as well. thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes
At Tue, 17 Apr 2012 17:33:17 +0200, Takashi Iwai wrote: At Fri, 13 Apr 2012 16:33:28 -0400, 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. I tried these patches now with a few monitors here and it looks working well (after fixing the alignment as I posted in another mail). I got new 1600x900 output on two monitors. Yay! Oh, feel free to add my tested-by tag: Tested-by: Takashi Iwai ti...@suse.de thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes
Thanks for the patches ajax Feel free to use Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com On Tue, Apr 17, 2012 at 12:50 PM, Takashi Iwai ti...@suse.de wrote: At Tue, 17 Apr 2012 17:33:17 +0200, Takashi Iwai wrote: At Fri, 13 Apr 2012 16:33:28 -0400, 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. I tried these patches now with a few monitors here and it looks working well (after fixing the alignment as I posted in another mail). I got new 1600x900 output on two monitors. Yay! Oh, feel free to add my tested-by tag: Tested-by: Takashi Iwai ti...@suse.de thanks, Takashi ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Rodrigo Vivi Blog: http://blog.vivi.eng.br GPG: 0x905BE242 @ wwwkeys.pgp.net ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/12] Add more DMT and common modes
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. - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Add more DMT and common modes
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. - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
