Re: [RFC] drm: emit change events when mode config changes
On 4/14/11 1:42 PM, Jesse Barnes wrote: We've already seen that apps want to monitor the display config, and some (like upowerd) poll for changes since we don't provide a notification for general mode config changes, just hotplug events. So add a new drm event, with CHANGE=1 set in the event, to allow for it. Signed-off-by: Jesse Barnesjbar...@virtuousgeek.org Reviewed-by: Adam Jackson a...@redhat.com - ajax -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] libdrm: Fix PCI domain domain support
On Fri, 2010-08-06 at 13:55 +1000, Benjamin Herrenschmidt wrote: This works in conjunction with newer kernels. If we succeed in requesting interface 1.4, the we know the kernel provides proper domain numbers. If not, ignore the domain number as it's bogus (except on Alpha). Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Applied, thanks! - ajax signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] drm_edid: There should be 6 Standard Timings
On Fri, 2010-05-14 at 13:06 +0200, Dan Carpenter wrote: Smatch complained that we initialize 6 elements in add_detailed_modes() but the timings[] array is declared with 5 elements. Adam Jackson verified that 6 is the correct number of timings. On Mon, May 10, 2010 at 12:08:24PM -0400, Adam Jackson wrote: struct std_timing timings[5]; ^ This decl is wrong, should be 6. From the 1.4 spec: Six additional Standard Timings may be listed as a display descriptor (tag #FAh). The 1.3 spec is a little less explicit about it, but does show 6 standard timing codes in the 0xFA detailed subblock, terminated by 0x0A in the 18th byte. I don't have the docs for 1.2 or earlier, but we're paranoid enough about not adding broken timings that we should be fine. This patch is basically a clean up, because timings[] is declared inside a union and increasing the number of elements here doesn't change the overall size of the union. Signed-off-by: Dan Carpenter erro...@gmail.com Reviewed-by: Adam Jackson a...@redhat.com - ajax signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch -next] drm: off by one in drm_edid.c
On Fri, 2010-05-07 at 10:38 +0200, Dan Carpenter wrote:
m == num_est3_modes is one past the end of the est3_modes[].
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7188674..46447b0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1383,7 +1383,7 @@ drm_est3_modes(struct drm_connector *connector, struct
detailed_timing *timing)
for (i = 0; i 6; i++) {
for (j = 7; j 0; j--) {
m = (i * 8) + (7 - j);
- if (m num_est3_modes)
+ if (m = num_est3_modes)
break;
if (est[i] (1 j)) {
mode = drm_find_dmt(connector-dev,
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed message part
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm_edid: potential range checking issue?
On Fri, 2010-05-07 at 10:35 +0200, Dan Carpenter wrote:
In include/drm/drm_edid.h this array has 5 elements not 6.
struct detailed_non_pixel {
u8 pad1;
u8 type; /* ff=serial, fe=string, fd=monitor range, fc=monitor name
fb=color point data, fa=standard timing data,
f9=undefined, f8=mfg. reserved */
u8 pad2;
union {
struct detailed_data_string str;
struct detailed_data_monitor_range range;
struct detailed_data_wpindex color;
struct std_timing timings[5];
^
This decl is wrong, should be 6. From the 1.4 spec:
Six additional Standard Timings may be listed as a display descriptor
(tag #FAh).
The 1.3 spec is a little less explicit about it, but does show 6
standard timing codes in the 0xFA detailed subblock, terminated by 0x0A
in the 18th byte. I don't have the docs for 1.2 or earlier, but we're
paranoid enough about not adding broken timings that we should be fine.
- ajax
signature.asc
Description: This is a digitally signed message part
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/edid: When checking duplicate standard modes, walked the probed list
... and not the global list. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index c4a578e..b407eef 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -694,7 +694,7 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, * instead. This way we don't have to guess at interlace or * reduced blanking. */ - list_for_each_entry(m, connector-modes, head) + list_for_each_entry(m, connector-probed_modes, head) if (m-hdisplay == hsize m-vdisplay == vsize drm_mode_vrefresh(m) == vrefresh_rate) return NULL; -- 1.6.6.1 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/edid: Fix sync polarity for secondary GTF curve
Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_modes.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 8840066..f1f473e 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -452,7 +452,10 @@ drm_gtf_mode_complex(struct drm_device *dev, int hdisplay, int vdisplay, } drm_mode_set_name(drm_mode); - drm_mode-flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC; + if (GTF_M == 600 GTF_2C == 80 GTF_K == 128 GTF_2J == 40) + drm_mode-flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC; + else + drm_mode-flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC; return drm_mode; } -- 1.6.6.1 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/edid/quirks: Envision EN2028
Claims 1280x1024 preferred, physically 1600x1200
cf. http://bugzilla.redhat.com/530399
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7e608f4..e661e4c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -84,6 +84,8 @@ static struct edid_quirk {
/* Envision Peripherals, Inc. EN-7100e */
{ EPI, 59264, EDID_QUIRK_135_CLOCK_TOO_HIGH },
+ /* Envision EN2028 */
+ { EPI, 8232, EDID_QUIRK_PREFER_LARGE_60 },
/* Funai Electronics PM36B */
{ FCM, 13600, EDID_QUIRK_PREFER_LARGE_75 |
--
1.6.5.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 02/14] drm/edid: Remove some misleading comments
Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 8e3bd50..7707a6a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -34,11 +34,6 @@ #include drm_edid.h /* - * TODO: - * - support EDID 1.4 (incl. CE blocks) - */ - -/* * EDID blocks out in the wild have a variety of bugs, try to collect * them here (note that userspace may work around broken monitors first, * but fixes should make their way here so that the kernel just works @@ -697,9 +692,6 @@ bad_std_timing(u8 a, u8 b) * * Take the standard timing params (in this case width, aspect, and refresh) * and convert them into a real mode using CVT/GTF/DMT. - * - * Punts for now, but should eventually use the FB layer's CVT based mode - * generation code. */ struct drm_display_mode *drm_mode_std(struct drm_device *dev, struct std_timing *t, -- 1.6.6.1 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 01/14] drm/edid: Fix secondary block fetch.
This makes fetching the second EDID block on HDMI monitors actually
work. DDC can't transfer more than 128 bytes at a time. Also,
rearrange the code so the pure DDC bits are separate from block parse.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 337 +---
include/drm/drm_crtc.h |2 -
2 files changed, 192 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f97e7c4..8e3bd50 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2,6 +2,7 @@
* Copyright (c) 2006 Luc Verhaegen (quirks list)
* Copyright (c) 2007-2008 Intel Corporation
* Jesse Barnes jesse.bar...@intel.com
+ * Copyright 2010 Red Hat, Inc.
*
* DDC probing routines (drm_ddc_read drm_do_probe_ddc_edid) originally from
* FB layer.
@@ -106,36 +107,39 @@ static struct edid_quirk {
{ SAM, 638, EDID_QUIRK_PREFER_LARGE_60 },
};
+/*** DDC fetch and block validation ***/
-/* Valid EDID header has these bytes */
static const u8 edid_header[] = {
0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00
};
-/**
- * drm_edid_is_valid - sanity check EDID data
- * @edid: EDID data
- *
- * Sanity check the EDID block by looking at the header, the version number
- * and the checksum. Return 0 if the EDID doesn't check out, or 1 if it's
- * valid.
+/*
+ * Sanity check the EDID block (base or extension). Return 0 if the block
+ * doesn't check out, or 1 if it's valid.
*/
-bool drm_edid_is_valid(struct edid *edid)
+static bool
+drm_edid_block_valid(u8 *raw_edid)
{
- int i, score = 0;
+ int i;
u8 csum = 0;
- u8 *raw_edid = (u8 *)edid;
-
- for (i = 0; i sizeof(edid_header); i++)
- if (raw_edid[i] == edid_header[i])
- score++;
-
- if (score == 8) ;
- else if (score = 6) {
- DRM_DEBUG(Fixing EDID header, your hardware may be failing\n);
- memcpy(raw_edid, edid_header, sizeof(edid_header));
- } else
- goto bad;
+ struct edid *edid = (struct edid *)raw_edid;
+
+ if (raw_edid[0] == 0x00) {
+ int score = 0;
+
+ for (i = 0; i sizeof(edid_header); i++)
+ if (raw_edid[i] == edid_header[i])
+ score++;
+
+ if (score == 8) ;
+ else if (score = 6) {
+ DRM_DEBUG(Fixing EDID header,
+ your hardware may be failing\n);
+ memcpy(raw_edid, edid_header, sizeof(edid_header));
+ } else {
+ goto bad;
+ }
+ }
for (i = 0; i EDID_LENGTH; i++)
csum += raw_edid[i];
@@ -144,13 +148,23 @@ bool drm_edid_is_valid(struct edid *edid)
goto bad;
}
- if (edid-version != 1) {
- DRM_ERROR(EDID has major version %d, instead of 1\n,
edid-version);
- goto bad;
- }
+ /* per-block-type checks */
+ switch (raw_edid[0]) {
+ case 0: /* base */
+ if (edid-version != 1) {
+ DRM_ERROR(EDID has major version %d,
+ instead of 1\n, edid-version);
+ goto bad;
+ }
- if (edid-revision 4)
- DRM_DEBUG(EDID minor 4, assuming backward compatibility\n);
+ if (edid-revision 4)
+ DRM_DEBUG(EDID minor 4,
+ assuming backward compatibility\n);
+ break;
+
+ default:
+ break;
+ }
return 1;
@@ -162,8 +176,158 @@ bad:
}
return 0;
}
+
+/**
+ * drm_edid_is_valid - sanity check EDID data
+ * @edid: EDID data
+ *
+ * Sanity-check an entire EDID record (including extensions)
+ */
+bool drm_edid_is_valid(struct edid *edid)
+{
+ int i;
+ u8 *raw = (u8 *)edid;
+
+ if (!edid)
+ return false;
+
+ for (i = 0; i = edid-extensions; i++)
+ if (!drm_edid_block_valid(raw + i * EDID_LENGTH))
+ return false;
+
+ return true;
+}
EXPORT_SYMBOL(drm_edid_is_valid);
+#define DDC_ADDR 0x50
+#define DDC_SEGMENT_ADDR 0x30
+/**
+ * Get EDID information via I2C.
+ *
+ * \param adapter : i2c device adaptor
+ * \param buf : EDID data buffer to be filled
+ * \param len : EDID data buffer length
+ * \return 0 on success or -1 on failure.
+ *
+ * Try to fetch EDID information by calling i2c driver function.
+ */
+static int
+drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf,
+ int block, int len)
+{
+ unsigned char start = block * EDID_LENGTH;
+ struct i2c_msg msgs[] = {
+ {
+ .addr = DDC_ADDR,
+ .flags = 0
[PATCH 03/14] drm/edid: Remove a redundant check
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7707a6a..a465c1d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1028,10 +1028,6 @@ static int add_standard_modes(struct drm_connector
*connector, struct edid *edid
struct std_timing *t = edid-standard_timings[i];
struct drm_display_mode *newmode;
- /* If std timings bytes are 1, 1 it's empty */
- if (t-hsize == 1 t-vfreq_aspect == 1)
- continue;
-
newmode = drm_mode_std(dev, edid-standard_timings[i],
edid-revision, timing_level);
if (newmode) {
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 05/14] drm/edid: Add modes for Established Timings III section
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 91
1 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3ecddbb..e0c37fb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1146,6 +1146,94 @@ static int drm_cvt_modes(struct drm_connector *connector,
return modes;
}
+static const struct {
+ short w;
+ short h;
+ short r;
+ short rb;
+} est3_modes[] = {
+ /* byte 6 */
+ { 640, 350, 85, 0 },
+ { 640, 400, 85, 0 },
+ { 720, 400, 85, 0 },
+ { 640, 480, 85, 0 },
+ { 848, 480, 60, 0 },
+ { 800, 600, 85, 0 },
+ { 1024, 768, 85, 0 },
+ { 1152, 864, 75, 0 },
+ /* byte 7 */
+ { 1280, 768, 60, 1 },
+ { 1280, 768, 60, 0 },
+ { 1280, 768, 75, 0 },
+ { 1280, 768, 85, 0 },
+ { 1280, 960, 60, 0 },
+ { 1280, 960, 85, 0 },
+ { 1280, 1024, 60, 0 },
+ { 1280, 1024, 85, 0 },
+ /* byte 8 */
+ { 1360, 768, 60, 0 },
+ { 1440, 900, 60, 1 },
+ { 1440, 900, 60, 0 },
+ { 1440, 900, 75, 0 },
+ { 1440, 900, 85, 0 },
+ { 1400, 1050, 60, 1 },
+ { 1400, 1050, 60, 0 },
+ { 1400, 1050, 75, 0 },
+ /* byte 9 */
+ { 1400, 1050, 85, 0 },
+ { 1680, 1050, 60, 1 },
+ { 1680, 1050, 60, 0 },
+ { 1680, 1050, 75, 0 },
+ { 1680, 1050, 85, 0 },
+ { 1600, 1200, 60, 0 },
+ { 1600, 1200, 65, 0 },
+ { 1600, 1200, 70, 0 },
+ /* byte 10 */
+ { 1600, 1200, 75, 0 },
+ { 1600, 1200, 85, 0 },
+ { 1792, 1344, 60, 0 },
+ { 1792, 1344, 85, 0 },
+ { 1856, 1392, 60, 0 },
+ { 1856, 1392, 75, 0 },
+ { 1920, 1200, 60, 1 },
+ { 1920, 1200, 60, 0 },
+ /* byte 11 */
+ { 1920, 1200, 75, 0 },
+ { 1920, 1200, 85, 0 },
+ { 1920, 1440, 60, 0 },
+ { 1920, 1440, 75, 0 },
+};
+static const int num_est3_modes = sizeof(est3_modes) / sizeof(est3_modes[0]);
+
+static int
+drm_est3_modes(struct drm_connector *connector, struct detailed_timing *timing)
+{
+ int i, j, m, modes = 0;
+ struct drm_display_mode *mode;
+ u8 *est = ((u8 *)timing) + 5;
+
+ for (i = 0; i 6; i++) {
+ for (j = 7; j 0; j--) {
+ m = (i * 8) + (7 - j);
+ if (m num_est3_modes)
+ break;
+ if (est[i] (1 j)) {
+ mode = drm_find_dmt(connector-dev,
+ est3_modes[m].w,
+ est3_modes[m].h,
+ est3_modes[m].r
+ /*, est3_modes[m].rb */);
+ if (mode) {
+ drm_mode_probed_add(connector, mode);
+ modes++;
+ }
+ }
+ }
+ }
+
+ return modes;
+}
+
static int add_detailed_modes(struct drm_connector *connector,
struct detailed_timing *timing,
struct edid *edid, u32 quirks, int preferred)
@@ -1193,6 +1281,9 @@ static int add_detailed_modes(struct drm_connector
*connector,
case EDID_DETAIL_CVT_3BYTE:
modes += drm_cvt_modes(connector, timing);
break;
+ case EDID_DETAIL_EST_TIMINGS:
+ modes += drm_est3_modes(connector, timing);
+ break;
default:
break;
}
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 04/14] drm/edid: Reshuffle mode list construction to closer match the spec
Also, document what the spec says to do. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/drm_edid.c | 18 -- 1 files changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index a465c1d..3ecddbb 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1389,10 +1389,24 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) quirks = edid_get_quirks(edid); - num_modes += add_established_modes(connector, edid); - num_modes += add_standard_modes(connector, edid); + /* +* EDID spec says modes should be preferred in this order: +* - preferred detailed mode +* - other detailed modes from base block +* - detailed modes from extension blocks +* - CVT 3-byte code modes +* - standard timing codes +* - established timing codes +* - modes inferred from GTF or CVT range information +* +* We don't quite implement this yet, but we're close. +* +* XXX order for additional mode types in extension blocks? +*/ num_modes += add_detailed_info(connector, edid, quirks); num_modes += add_detailed_info_eedid(connector, edid, quirks); + num_modes += add_standard_modes(connector, edid); + num_modes += add_established_modes(connector, edid); if (quirks (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75)) edid_fixup_preferred(connector, quirks); -- 1.6.6.1 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 06/14] drm/edid: Remove arbitrary EDID extension limit
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_crtc.c |7 +--
drivers/gpu/drm/drm_edid.c | 19 +--
drivers/gpu/drm/drm_sysfs.c |2 +-
drivers/gpu/drm/radeon/radeon_combios.c |8
include/drm/drm_edid.h |3 ---
5 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d91fb8c..aa24f2f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -33,6 +33,7 @@
#include drm.h
#include drmP.h
#include drm_crtc.h
+#include drm_edid.h
struct drm_prop_enum_list {
int type;
@@ -2349,7 +2350,7 @@ int drm_mode_connector_update_edid_property(struct
drm_connector *connector,
struct edid *edid)
{
struct drm_device *dev = connector-dev;
- int ret = 0;
+ int ret = 0, size;
if (connector-edid_blob_ptr)
drm_property_destroy_blob(dev, connector-edid_blob_ptr);
@@ -2361,7 +2362,9 @@ int drm_mode_connector_update_edid_property(struct
drm_connector *connector,
return ret;
}
- connector-edid_blob_ptr = drm_property_create_blob(connector-dev,
128, edid);
+ size = EDID_LENGTH * (1 + edid-extensions);
+ connector-edid_blob_ptr = drm_property_create_blob(connector-dev,
+ size, edid);
ret = drm_connector_property_set_value(connector,
dev-mode_config.edid_property,
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e0c37fb..9974638 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1337,7 +1337,6 @@ static int add_detailed_info_eedid(struct drm_connector
*connector,
int i, modes = 0;
char *edid_ext = NULL;
struct detailed_timing *timing;
- int edid_ext_num;
int start_offset, end_offset;
int timing_level;
@@ -1354,19 +1353,15 @@ static int add_detailed_info_eedid(struct drm_connector
*connector,
return 0;
}
- /* Chose real EDID extension number */
- edid_ext_num = edid-extensions DRM_MAX_EDID_EXT_NUM ?
- DRM_MAX_EDID_EXT_NUM : edid-extensions;
-
/* Find CEA extension */
- for (i = 0; i edid_ext_num; i++) {
+ for (i = 0; i edid-extensions; i++) {
edid_ext = (char *)edid + EDID_LENGTH * (i + 1);
/* This block is CEA extension */
if (edid_ext[0] == 0x02)
break;
}
- if (i == edid_ext_num) {
+ if (i == edid-extensions) {
/* if there is no additional timing EDID block, return */
return 0;
}
@@ -1405,7 +1400,7 @@ static int add_detailed_info_eedid(struct drm_connector
*connector,
bool drm_detect_hdmi_monitor(struct edid *edid)
{
char *edid_ext = NULL;
- int i, hdmi_id, edid_ext_num;
+ int i, hdmi_id;
int start_offset, end_offset;
bool is_hdmi = false;
@@ -1413,19 +1408,15 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
if (edid == NULL || edid-extensions == 0)
goto end;
- /* Chose real EDID extension number */
- edid_ext_num = edid-extensions DRM_MAX_EDID_EXT_NUM ?
- DRM_MAX_EDID_EXT_NUM : edid-extensions;
-
/* Find CEA extension */
- for (i = 0; i edid_ext_num; i++) {
+ for (i = 0; i edid-extensions; i++) {
edid_ext = (char *)edid + EDID_LENGTH * (i + 1);
/* This block is CEA extension */
if (edid_ext[0] == 0x02)
break;
}
- if (i == edid_ext_num)
+ if (i == edid-extensions)
goto end;
/* Data block offset in CEA extension block */
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 014ce24..7b7c83f 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -332,7 +332,7 @@ static struct device_attribute connector_attrs_opt1[] = {
static struct bin_attribute edid_attr = {
.attr.name = edid,
.attr.mode = 0444,
- .size = 128,
+ .size = 0,
.read = edid_show,
};
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index e9ea38e..9949ae7 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -450,17 +450,17 @@ bool radeon_combios_check_hardcoded_edid(struct
radeon_device *rdev)
{
int edid_info;
struct edid *edid;
+ unsigned char *raw;
edid_info = combios_get_table_offset(rdev-ddev,
COMBIOS_HARDCODED_EDID_TABLE);
if (!edid_info)
return false;
- edid = kmalloc(EDID_LENGTH * (DRM_MAX_EDID_EXT_NUM + 1
[PATCH 07/14] drm/edid: Remove some silly comments
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 17 +++--
1 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9974638..c052623 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1340,31 +1340,20 @@ static int add_detailed_info_eedid(struct drm_connector
*connector,
int start_offset, end_offset;
int timing_level;
- if (edid-version == 1 edid-revision 3) {
- /* If the EDID version is less than 1.3, there is no
-* extension EDID.
-*/
+ if (edid-version == 1 edid-revision 3)
return 0;
- }
- if (!edid-extensions) {
- /* if there is no extension EDID, it is unnecessary to
-* parse the E-EDID to get detailed info
-*/
+ if (!edid-extensions)
return 0;
- }
/* Find CEA extension */
for (i = 0; i edid-extensions; i++) {
edid_ext = (char *)edid + EDID_LENGTH * (i + 1);
- /* This block is CEA extension */
if (edid_ext[0] == 0x02)
break;
}
- if (i == edid-extensions) {
- /* if there is no additional timing EDID block, return */
+ if (i == edid-extensions)
return 0;
- }
/* Get the start offset of detailed timing block */
start_offset = edid_ext[2];
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 08/14] drm/edid: Fix preferred mode parse for EDID 1.4
In 1.4, the first detailed mode is always the preferred mode. The bit
that used to mean that, now means this mode is the physical size in
pixels.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c052623..fb7c2fc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1307,7 +1307,10 @@ static int add_detailed_info(struct drm_connector
*connector,
for (i = 0; i EDID_DETAILED_TIMINGS; i++) {
struct detailed_timing *timing = edid-detailed_timings[i];
- int preferred = (i == 0) (edid-features
DRM_EDID_FEATURE_PREFERRED_TIMING);
+ int preferred = (i == 0);
+
+ if (preferred edid-version == 1 edid-revision 4)
+ preferred = (edid-features
DRM_EDID_FEATURE_PREFERRED_TIMING);
/* In 1.0, only timings are allowed */
if (!timing-pixel_clock edid-version == 1
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 10/14] drm/edid: Extend range-based mode addition for EDID 1.4
1.4 adds better pixel clock precision, explicit reduced blanking
awareness, and extended sync ranges. It's almost like a real spec.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 101 ++--
1 files changed, 78 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ead57ab..5ba470e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1078,36 +1078,89 @@ static int add_standard_modes(struct drm_connector
*connector, struct edid *edid
return modes;
}
-/*
- * XXX fix this for:
- * - GTF secondary curve formula
- * - EDID 1.4 range offsets
- * - CVT extended bits
- */
static bool
-mode_in_range(struct drm_display_mode *mode, struct detailed_timing *timing)
+mode_is_rb(struct drm_display_mode *mode)
{
- struct detailed_data_monitor_range *range;
- int hsync, vrefresh;
-
- range = timing-data.other_data.data.range;
+ return (mode-htotal - mode-hdisplay == 160)
+ (mode-hsync_end - mode-hdisplay == 80)
+ (mode-hsync_end - mode-hsync_start == 32)
+ (mode-vsync_start - mode-vdisplay == 3);
+}
+static bool
+mode_in_hsync_range(struct drm_display_mode *mode, struct edid *edid, u8 *t)
+{
+ int hsync, hmin, hmax;
+
+ hmin = t[7];
+ if (edid-revision = 4)
+ hmin += ((t[4] 0x04) ? 255 : 0);
+ hmax = t[8];
+ if (edid-revision = 4)
+ hmax += ((t[4] 0x08) ? 255 : 0);
hsync = drm_mode_hsync(mode);
- vrefresh = drm_mode_vrefresh(mode);
- if (hsync range-min_hfreq_khz || hsync range-max_hfreq_khz)
+ return (hsync = hmax hsync = hmin);
+}
+
+static bool
+mode_in_vsync_range(struct drm_display_mode *mode, struct edid *edid, u8 *t)
+{
+ int vsync, vmin, vmax;
+
+ vmin = t[5];
+ if (edid-revision = 4)
+ vmin += ((t[4] 0x01) ? 255 : 0);
+ vmax = t[6];
+ if (edid-revision = 4)
+ vmax += ((t[4] 0x02) ? 255 : 0);
+ vsync = drm_mode_vrefresh(mode);
+
+ return (vsync = vmax vsync = vmin);
+}
+
+static u32
+range_pixel_clock(struct edid *edid, u8 *t)
+{
+ /* unspecified */
+ if (t[9] == 0 || t[9] == 255)
+ return 0;
+
+ /* 1.4 with CVT support gives us real precision, yay */
+ if (edid-revision = 4 t[10] == 0x04)
+ return (t[9] * 1) - ((t[12] 2) * 250);
+
+ /* 1.3 is pathetic, so fuzz up a bit */
+ return t[9] * 1 + 5001;
+}
+
+/*
+ * XXX fix this for GTF secondary curve formula
+ */
+static bool
+mode_in_range(struct drm_display_mode *mode, struct edid *edid,
+ struct detailed_timing *timing)
+{
+ u32 max_clock;
+ u8 *t = (u8 *)timing;
+
+ if (!mode_in_hsync_range(mode, edid, t))
return false;
- if (vrefresh range-min_vfreq || vrefresh range-max_vfreq)
+ if (!mode_in_vsync_range(mode, edid, t))
return false;
- if (range-pixel_clock_mhz range-pixel_clock_mhz != 0xff) {
- /* be forgiving since it's in units of 10MHz */
- int max_clock = range-pixel_clock_mhz * 10 + 9;
- max_clock *= 1000;
+ if ((max_clock = range_pixel_clock(edid, t)))
if (mode-clock max_clock)
return false;
- }
+
+ /* 1.4 max horizontal check */
+ if (edid-revision = 4 t[10] == 0x04)
+ if (t[13] mode-hdisplay 8 * (t[13] + (256 * (t[12]0x3
+ return false;
+
+ if (mode_is_rb(mode) !drm_monitor_supports_rb(edid))
+ return false;
return true;
}
@@ -1116,15 +1169,16 @@ mode_in_range(struct drm_display_mode *mode, struct
detailed_timing *timing)
* XXX If drm_dmt_modes ever regrows the CVT-R modes (and it will) this will
* need to account for them.
*/
-static int drm_gtf_modes_for_range(struct drm_connector *connector,
- struct detailed_timing *timing)
+static int
+drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
+ struct detailed_timing *timing)
{
int i, modes = 0;
struct drm_display_mode *newmode;
struct drm_device *dev = connector-dev;
for (i = 0; i drm_num_dmt_modes; i++) {
- if (mode_in_range(drm_dmt_modes + i, timing)) {
+ if (mode_in_range(drm_dmt_modes + i, edid, timing)) {
newmode = drm_mode_duplicate(dev, drm_dmt_modes[i]);
if (newmode) {
drm_mode_probed_add(connector, newmode);
@@ -1300,7 +1354,8 @@ static int add_detailed_modes(struct drm_connector
*connector,
switch (data-type) {
case EDID_DETAIL_MONITOR_RANGE:
if (gtf)
- modes += drm_gtf_modes_for_range(connector, timing
[PATCH 09/14] drm/edid: Add test for monitor reduced blanking support.
The generic block walk callback looks like overkill, but we'll need it
for other detailed block walks in the future.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 47 ---
1 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fb7c2fc..ead57ab 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -33,6 +33,10 @@
#include drmP.h
#include drm_edid.h
+#define EDID_EST_TIMINGS 16
+#define EDID_STD_TIMINGS 8
+#define EDID_DETAILED_TIMINGS 4
+
/*
* EDID blocks out in the wild have a variety of bugs, try to collect
* them here (note that userspace may work around broken monitors first,
@@ -673,6 +677,45 @@ static struct drm_display_mode *drm_find_dmt(struct
drm_device *dev,
return mode;
}
+typedef void detailed_cb(struct detailed_timing *timing, void *closure);
+
+static void
+drm_for_each_detailed_block(u8 *raw_edid, detailed_cb *cb, void *closure)
+{
+ int i;
+ struct edid *edid = (struct edid *)raw_edid;
+
+ if (edid == NULL)
+ return;
+
+ for (i = 0; i EDID_DETAILED_TIMINGS; i++)
+ cb((edid-detailed_timings[i]), closure);
+
+ /* XXX extension block walk */
+}
+
+static void
+is_rb(struct detailed_timing *t, void *data)
+{
+ u8 *r = (u8 *)t;
+ if (r[3] == EDID_DETAIL_MONITOR_RANGE)
+ if (r[15] 0x10)
+ *(bool *)data = true;
+}
+
+/* EDID 1.4 defines this explicitly. For EDID 1.3, we guess, badly. */
+static bool
+drm_monitor_supports_rb(struct edid *edid)
+{
+ if (edid-revision = 4) {
+ bool ret;
+ drm_for_each_detailed_block((u8 *)edid, is_rb, ret);
+ return ret;
+ }
+
+ return ((edid-input DRM_EDID_INPUT_DIGITAL) != 0);
+}
+
/*
* 0 is reserved. The spec says 0x01 fill for unused timings. Some old
* monitors fill with ascii space (0x20) instead.
@@ -964,10 +1007,6 @@ static struct drm_display_mode edid_est_modes[] = {
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) }, /*
1152x...@75hz */
};
-#define EDID_EST_TIMINGS 16
-#define EDID_STD_TIMINGS 8
-#define EDID_DETAILED_TIMINGS 4
-
/**
* add_established_modes - get est. modes from EDID and add them
* @edid: EDID block to scan
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 11/14] drm/edid: Fix the HDTV hack.
Standard timings don't let you say 1366. Both 1360 and 1368 have been
seen in the wild. So invent a CVT timing for it. CVT will round 1366 up
to 1368; we'll then manually underscan it.
Split this into two parts, since we need to do something sneaky between
them in the future.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5ba470e..93ddc9a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -768,15 +768,25 @@ struct drm_display_mode *drm_mode_std(struct drm_device
*dev,
vsize = (hsize * 4) / 5;
else
vsize = (hsize * 9) / 16;
- /* HDTV hack */
- if (hsize == 1360 vsize == 765 vrefresh_rate == 60) {
- mode = drm_cvt_mode(dev, hsize, vsize, vrefresh_rate, 0, 0,
+
+ /* HDTV hack, part 1 */
+ if (vrefresh_rate == 60
+ ((hsize == 1360 vsize == 765) ||
+(hsize == 1368 vsize == 769))) {
+ hsize = 1366;
+ vsize = 768;
+ }
+
+ /* HDTV hack, part 2 */
+ if (hsize == 1366 vsize == 768 vrefresh_rate == 60) {
+ mode = drm_cvt_mode(dev, 1366, 768, vrefresh_rate, 0, 0,
false);
mode-hdisplay = 1366;
mode-vsync_start = mode-vsync_start - 1;
mode-vsync_end = mode-vsync_end - 1;
return mode;
}
+
mode = NULL;
/* check whether it can be found in default mode table */
mode = drm_find_dmt(dev, hsize, vsize, vrefresh_rate);
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 13/14] drm/edid: Add secondary GTF curve support
Before CVT-R, some monitors would advertise support for an alternative
GTF formula with lower blanking intervals. Correctly identify such
monitors, and use the alternative formula when generating modes for
them.
Note that we only do this for standard timing descriptors (tuples of
hsize in characters / aspect ratio / vertical refresh). Range-based
mode lists still only refer to the primary GTF curve. It would be
possible to do better for the latter case, but monitors are required to
support the primary curve over the entire advertised range, so all it
would win you is a lower pixel clock and therefore possibly better image
quality on analog links.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 119 +--
drivers/gpu/drm/drm_modes.c | 81 +++--
include/drm/drm_crtc.h |4 ++
3 files changed, 150 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8c8acfe..1b1c9d2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -64,7 +64,8 @@
#define LEVEL_DMT 0
#define LEVEL_GTF 1
-#define LEVEL_CVT 2
+#define LEVEL_GTF2 2
+#define LEVEL_CVT 3
static struct edid_quirk {
char *vendor;
@@ -716,6 +717,71 @@ drm_monitor_supports_rb(struct edid *edid)
return ((edid-input DRM_EDID_INPUT_DIGITAL) != 0);
}
+static void
+find_gtf2(struct detailed_timing *t, void *data)
+{
+ u8 *r = (u8 *)t;
+ if (r[3] == EDID_DETAIL_MONITOR_RANGE r[10] == 0x02)
+ *(u8 **)data = r;
+}
+
+/* Secondary GTF curve kicks in above some break frequency */
+static int
+drm_gtf2_hbreak(struct edid *edid)
+{
+ u8 *r = NULL;
+ drm_for_each_detailed_block((u8 *)edid, find_gtf2, r);
+ return r ? (r[12] * 2) : 0;
+}
+
+static int
+drm_gtf2_2c(struct edid *edid)
+{
+ u8 *r = NULL;
+ drm_for_each_detailed_block((u8 *)edid, find_gtf2, r);
+ return r ? r[13] : 0;
+}
+
+static int
+drm_gtf2_m(struct edid *edid)
+{
+ u8 *r = NULL;
+ drm_for_each_detailed_block((u8 *)edid, find_gtf2, r);
+ return r ? (r[15] 8) + r[14] : 0;
+}
+
+static int
+drm_gtf2_k(struct edid *edid)
+{
+ u8 *r = NULL;
+ drm_for_each_detailed_block((u8 *)edid, find_gtf2, r);
+ return r ? r[16] : 0;
+}
+
+static int
+drm_gtf2_2j(struct edid *edid)
+{
+ u8 *r = NULL;
+ drm_for_each_detailed_block((u8 *)edid, find_gtf2, r);
+ return r ? r[17] : 0;
+}
+
+/**
+ * standard_timing_level - get std. timing level(CVT/GTF/DMT)
+ * @edid: EDID block to scan
+ */
+static int standard_timing_level(struct edid *edid)
+{
+ if (edid-revision = 2) {
+ if (edid-revision = 4 (edid-features
DRM_EDID_FEATURE_DEFAULT_GTF))
+ return LEVEL_CVT;
+ if (drm_gtf2_hbreak(edid))
+ return LEVEL_GTF2;
+ return LEVEL_GTF;
+ }
+ return LEVEL_DMT;
+}
+
/*
* 0 is reserved. The spec says 0x01 fill for unused timings. Some old
* monitors fill with ascii space (0x20) instead.
@@ -737,8 +803,8 @@ bad_std_timing(u8 a, u8 b)
* and convert them into a real mode using CVT/GTF/DMT.
*/
static struct drm_display_mode *
-drm_mode_std(struct drm_connector *connector, struct std_timing *t,
-int revision, int timing_level)
+drm_mode_std(struct drm_connector *connector, struct edid *edid,
+struct std_timing *t, int revision)
{
struct drm_device *dev = connector-dev;
struct drm_display_mode *m, *mode = NULL;
@@ -748,6 +814,7 @@ drm_mode_std(struct drm_connector *connector, struct
std_timing *t,
EDID_TIMING_ASPECT_SHIFT;
unsigned vfreq = (t-vfreq_aspect EDID_TIMING_VFREQ_MASK)
EDID_TIMING_VFREQ_SHIFT;
+ int timing_level = standard_timing_level(edid);
if (bad_std_timing(t-hsize, t-vfreq_aspect))
return NULL;
@@ -809,6 +876,23 @@ drm_mode_std(struct drm_connector *connector, struct
std_timing *t,
case LEVEL_GTF:
mode = drm_gtf_mode(dev, hsize, vsize, vrefresh_rate, 0, 0);
break;
+ case LEVEL_GTF2:
+ /*
+* This is potentially wrong if there's ever a monitor with
+* more than one ranges section, each claiming a different
+* secondary GTF curve. Please don't do that.
+*/
+ mode = drm_gtf_mode(dev, hsize, vsize, vrefresh_rate, 0, 0);
+ if (drm_mode_hsync(mode) drm_gtf2_hbreak(edid)) {
+ kfree(mode);
+ mode = drm_gtf_mode_complex(dev, hsize, vsize,
+ vrefresh_rate, 0, 0,
+ drm_gtf2_m(edid),
+ drm_gtf2_2c(edid
[PATCH 12/14] drm/edid: Strengthen the algorithm for standard mode codes
If you have 1920x1200 in both detailed (probably RB) and standard
variants, you probably only want the RB version. But we have no way of
guessing that from standard mode parse. So, if a mode already exists
for a given w/h/r, skip adding it.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 28 ++--
1 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 93ddc9a..8c8acfe 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -736,12 +736,12 @@ bad_std_timing(u8 a, u8 b)
* Take the standard timing params (in this case width, aspect, and refresh)
* and convert them into a real mode using CVT/GTF/DMT.
*/
-struct drm_display_mode *drm_mode_std(struct drm_device *dev,
- struct std_timing *t,
- int revision,
- int timing_level)
+static struct drm_display_mode *
+drm_mode_std(struct drm_connector *connector, struct std_timing *t,
+int revision, int timing_level)
{
- struct drm_display_mode *mode;
+ struct drm_device *dev = connector-dev;
+ struct drm_display_mode *m, *mode = NULL;
int hsize, vsize;
int vrefresh_rate;
unsigned aspect_ratio = (t-vfreq_aspect EDID_TIMING_ASPECT_MASK)
@@ -777,6 +777,17 @@ struct drm_display_mode *drm_mode_std(struct drm_device
*dev,
vsize = 768;
}
+ /*
+* If this connector already has a mode for this size and refresh
+* rate (because it came from detailed or CVT info), use that
+* instead. This way we don't have to guess at interlace or
+* reduced blanking.
+*/
+ list_for_each_entry(m, connector-modes, head)
+ if (m-hdisplay == hsize m-vdisplay == vsize
+ drm_mode_vrefresh(m) == vrefresh_rate)
+ return NULL;
+
/* HDTV hack, part 2 */
if (hsize == 1366 vsize == 768 vrefresh_rate == 60) {
mode = drm_cvt_mode(dev, 1366, 768, vrefresh_rate, 0, 0,
@@ -787,7 +798,6 @@ struct drm_display_mode *drm_mode_std(struct drm_device
*dev,
return mode;
}
- mode = NULL;
/* check whether it can be found in default mode table */
mode = drm_find_dmt(dev, hsize, vsize, vrefresh_rate);
if (mode)
@@ -1067,17 +1077,15 @@ static int standard_timing_level(struct edid *edid)
*/
static int add_standard_modes(struct drm_connector *connector, struct edid
*edid)
{
- struct drm_device *dev = connector-dev;
int i, modes = 0;
int timing_level;
timing_level = standard_timing_level(edid);
for (i = 0; i EDID_STD_TIMINGS; i++) {
- struct std_timing *t = edid-standard_timings[i];
struct drm_display_mode *newmode;
- newmode = drm_mode_std(dev, edid-standard_timings[i],
+ newmode = drm_mode_std(connector, edid-standard_timings[i],
edid-revision, timing_level);
if (newmode) {
drm_mode_probed_add(connector, newmode);
@@ -1374,7 +1382,7 @@ static int add_detailed_modes(struct drm_connector
*connector,
struct drm_display_mode *newmode;
std = data-data.timings[i];
- newmode = drm_mode_std(dev, std, edid-revision,
+ newmode = drm_mode_std(connector, std, edid-revision,
timing_level);
if (newmode) {
drm_mode_probed_add(connector, newmode);
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 14/14] drm/modes: Fix interlaced mode names
Height in frame size, not field size, and trailed with an 'i'. Matches
the X server behaviour.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |4 ++--
drivers/gpu/drm/drm_modes.c | 21 -
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1b1c9d2..a2a0873 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1025,10 +1025,10 @@ static struct drm_display_mode
*drm_mode_detailed(struct drm_device *dev,
if (mode-vsync_end mode-vtotal)
mode-vtotal = mode-vsync_end + 1;
- drm_mode_set_name(mode);
-
drm_mode_do_interlace_quirk(mode, pt);
+ drm_mode_set_name(mode);
+
if (quirks EDID_QUIRK_DETAILED_SYNC_PP) {
pt-misc |= DRM_EDID_PT_HSYNC_POSITIVE |
DRM_EDID_PT_VSYNC_POSITIVE;
}
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d460b6c..8840066 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -258,8 +258,10 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device
*dev, int hdisplay,
drm_mode-clock -= drm_mode-clock % CVT_CLOCK_STEP;
/* 18/16. Find actual vertical frame frequency */
/* ignore - just set the mode flag for interlaced */
- if (interlaced)
+ if (interlaced) {
drm_mode-vtotal *= 2;
+ drm_mode-flags |= DRM_MODE_FLAG_INTERLACE;
+ }
/* Fill the mode line name */
drm_mode_set_name(drm_mode);
if (reduced)
@@ -268,10 +270,8 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device
*dev, int hdisplay,
else
drm_mode-flags |= (DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_NHSYNC);
- if (interlaced)
- drm_mode-flags |= DRM_MODE_FLAG_INTERLACE;
-return drm_mode;
+ return drm_mode;
}
EXPORT_SYMBOL(drm_cvt_mode);
@@ -446,14 +446,14 @@ drm_gtf_mode_complex(struct drm_device *dev, int
hdisplay, int vdisplay,
drm_mode-clock = pixel_freq;
- drm_mode_set_name(drm_mode);
- drm_mode-flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC;
-
if (interlaced) {
drm_mode-vtotal *= 2;
drm_mode-flags |= DRM_MODE_FLAG_INTERLACE;
}
+ drm_mode_set_name(drm_mode);
+ drm_mode-flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC;
+
return drm_mode;
}
EXPORT_SYMBOL(drm_gtf_mode_complex);
@@ -509,8 +509,11 @@ EXPORT_SYMBOL(drm_gtf_mode);
*/
void drm_mode_set_name(struct drm_display_mode *mode)
{
- snprintf(mode-name, DRM_DISPLAY_MODE_LEN, %dx%d, mode-hdisplay,
-mode-vdisplay);
+ bool interlaced = !!(mode-flags DRM_MODE_FLAG_INTERLACE);
+
+ snprintf(mode-name, DRM_DISPLAY_MODE_LEN, %dx%d%s,
+mode-hdisplay, mode-vdisplay,
+interlaced ? i : );
}
EXPORT_SYMBOL(drm_mode_set_name);
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 2010-03-05 at 06:24 -0500, Jeff Garzik wrote: On 03/04/2010 05:59 PM, Adam Jackson wrote: in which you merely remove the nouveau userspace component, and in which I can't tell if you built nouveau into the kernel or not, but I assume you didn't based on your previous post. The X server does only try the one driver before falling back to vesa, which is a bug in the fallback logic I suppose. I've (blindly) fixed that for F13 now. Thanks. Can this be put into F12 too? Sure, why not. - you didn't try writing an xorg.conf fragment - you did, and it didn't work anyway The latter case is entirely plausible, as nv is not the sort of driver that gets a lot of love, but I'm not aware of any open bugs about gf9800 in particular in nv. The latter... would modeset in grub interfere, perhaps? It's not going to do anything if you didn't build a KMS driver. It's just a kcmdline option like any other; if there's no module to honor it, then it doesn't do anything. grub doesn't have any particular KMS awareness. I'm really going to have to see an X log and dmesg from the failure mode when actually using nv to diagnose this any further. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 15:03 -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Adam Jackson wrote: On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: Two wrong choices don't make a right. So unmerge it. That's what I told people I can do (I'd just revert that commit). Read it more strongly: drop nouveau from your tree entirely. Don't give me any not a solution nonsense about that. The problem is entirely that your expectations for interface stability [1] in your tree do not match nouveau's development model and will not for the forseeable future. Yes, they should htfu and version interfaces like real men. But they're not going to, so either enforce your rule or don't. [1] - apparently ignorable when it's inconvenient, but let's not turn this into a sysfs argument. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 14:32 -0500, Jeff Garzik wrote: On 03/04/2010 02:04 PM, Matthew Garrett wrote: F-12 continues to ship the -nv driver, which will work fine with any kernel version as long as nouveau is disabled. FAIL. I actually tried that. Have you? Do you think it is remotely easy for a technically component, non-Xorg-hacker type to accomplish? # cat EOF /etc/X11/xorg.conf Section Device Identifier Card0 Driver nv EndSection EOF # sed -i 's/\kernel\.*/ nouveau.modeset=0/g' /etc/grub.conf # telinit 6 HTH. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 17:21 -0500, Jeff Garzik wrote: # sed -i 's/\kernel\.*/ nouveau.modeset=0/g' /etc/grub.conf Never tried this part. The bug I'm assuming you're referring to is https://bugzilla.redhat.com/show_bug.cgi?id=519298 in which you merely remove the nouveau userspace component, and in which I can't tell if you built nouveau into the kernel or not, but I assume you didn't based on your previous post. The X server does only try the one driver before falling back to vesa, which is a bug in the fallback logic I suppose. I've (blindly) fixed that for F13 now. However, the log in that bug only shows you using the built-in autoconfig logic, and not an xorg.conf file. So, given you were talking about a kernel without nouveau, I am left to assume one of: - you didn't try writing an xorg.conf fragment - you did, and it didn't work anyway The latter case is entirely plausible, as nv is not the sort of driver that gets a lot of love, but I'm not aware of any open bugs about gf9800 in particular in nv. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote: On Thu, 4 Mar 2010, Matthew Garrett wrote: If you'd made it clear that you wanted the interface to be stable before it got merged, I suspect that it simply wouldn't have been merged until the interface was stable. What kind of excuse is that? It's we did bad things, but if we didn't do those bad things, we'd have done _other_ bad things? Two wrong choices don't make a right. So unmerge it. - ajax signature.asc Description: This is a digitally signed message part -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/edid: Fix interlaced detailed timings to be frame size, not field.
cf. https://bugzilla.redhat.com/show_bug.cgi?id=533561
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 47 ++-
1 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f665b05..ab6c973 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -598,6 +598,50 @@ struct drm_display_mode *drm_mode_std(struct drm_device
*dev,
return mode;
}
+/*
+ * EDID is delightfully ambiguous about how interlaced modes are to be
+ * encoded. Our internal representation is of frame height, but some
+ * HDTV detailed timings are encoded as field height.
+ *
+ * The format list here is from CEA, in frame size. Technically we
+ * should be checking refresh rate too. Whatever.
+ */
+static void
+drm_mode_do_interlace_quirk(struct drm_display_mode *mode,
+ struct detailed_pixel_timing *pt)
+{
+ int i;
+ static const struct {
+ int w, h;
+ } cea_interlaced[] = {
+ { 1920, 1080 },
+ { 720, 480 },
+ { 1440, 480 },
+ { 2880, 480 },
+ { 720, 576 },
+ { 1440, 576 },
+ { 2880, 576 },
+ };
+ static const int n_sizes =
+ sizeof(cea_interlaced)/sizeof(cea_interlaced[0]);
+
+ if (!(pt-misc DRM_EDID_PT_INTERLACED))
+ return;
+
+ for (i = 0; i n_sizes; i++) {
+ if ((mode-hdisplay == cea_interlaced[i].w)
+ (mode-vdisplay == cea_interlaced[i].h / 2)) {
+ mode-vdisplay *= 2;
+ mode-vsync_start *= 2;
+ mode-vsync_end *= 2;
+ mode-vtotal *= 2;
+ mode-vtotal |= 1;
+ }
+ }
+
+ mode-flags |= DRM_MODE_FLAG_INTERLACE;
+}
+
/**
* drm_mode_detailed - create a new mode from an EDID detailed timing section
* @dev: DRM device (needed to create new mode)
@@ -680,8 +724,7 @@ static struct drm_display_mode *drm_mode_detailed(struct
drm_device *dev,
drm_mode_set_name(mode);
- if (pt-misc DRM_EDID_PT_INTERLACED)
- mode-flags |= DRM_MODE_FLAG_INTERLACE;
+ drm_mode_do_interlace_quirk(mode, pt);
if (quirks EDID_QUIRK_DETAILED_SYNC_PP) {
pt-misc |= DRM_EDID_PT_HSYNC_POSITIVE |
DRM_EDID_PT_VSYNC_POSITIVE;
--
1.6.5.2
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/edid: Fix CVT width/height decode
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9402b92..3a8b648 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -920,18 +920,18 @@ static int drm_cvt_modes(struct drm_connector *connector,
if (!memcmp(cvt-code, empty, 3))
continue;
- height = (cvt-code[0] + ((cvt-code[1] 0xf0) 8) + 1) * 2;
- switch (cvt-code[1] 0xc0) {
+ height = (cvt-code[0] + ((cvt-code[1] 0xf0) 4) + 1) * 2;
+ switch (cvt-code[1] 0x0c) {
case 0x00:
width = height * 4 / 3;
break;
- case 0x40:
+ case 0x04:
width = height * 16 / 9;
break;
- case 0x80:
+ case 0x08:
width = height * 16 / 10;
break;
- case 0xc0:
+ case 0x0c:
width = height * 15 / 9;
break;
}
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/edid: Skip empty CVT codepoints
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5c9f798..9402b92 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -911,11 +911,15 @@ static int drm_cvt_modes(struct drm_connector *connector,
struct drm_device *dev = connector-dev;
struct cvt_timing *cvt;
const int rates[] = { 60, 85, 75, 60, 50 };
+ const u8 empty[3] = { 0, 0, 0 };
for (i = 0; i 4; i++) {
int uninitialized_var(width), height;
cvt = (timing-data.other_data.data.cvt[i]);
+ if (!memcmp(cvt-code, empty, 3))
+ continue;
+
height = (cvt-code[0] + ((cvt-code[1] 0xf0) 8) + 1) * 2;
switch (cvt-code[1] 0xc0) {
case 0x00:
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/5] drm/edid: Add new detailed block types from EDID 1.4
Signed-off-by: Adam Jackson a...@redhat.com
---
include/drm/drm_edid.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 7d6c9a2..9087557 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -120,6 +120,9 @@ struct detailed_non_pixel {
} data;
} __attribute__((packed));
+#define EDID_DETAIL_EST_TIMINGS 0xf7
+#define EDID_DETAIL_CVT_3BYTE 0xf8
+#define EDID_DETAIL_COLOR_MGMT_DATA 0xf9
#define EDID_DETAIL_STD_MODES 0xfa
#define EDID_DETAIL_MONITOR_CPDATA 0xfb
#define EDID_DETAIL_MONITOR_NAME 0xfc
--
1.6.5.2
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/5] drm/edid: Add DMT modes to the pool if the monitor is GTF-capable
See also: http://bugzilla.redhat.com/539785
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 69 +--
1 files changed, 65 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 999571a..cc8e696 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -491,16 +491,17 @@ static struct drm_display_mode drm_dmt_modes[] = {
3048, 3536, 0, 1600, 1603, 1609, 1682, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
};
+static const int drm_num_dmt_modes =
+ sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
static struct drm_display_mode *drm_find_dmt(struct drm_device *dev,
int hsize, int vsize, int fresh)
{
- int i, count;
+ int i;
struct drm_display_mode *ptr, *mode;
- count = sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
mode = NULL;
- for (i = 0; i count; i++) {
+ for (i = 0; i drm_num_dmt_modes; i++) {
ptr = drm_dmt_modes[i];
if (hsize == ptr-hdisplay
vsize == ptr-vdisplay
@@ -838,6 +839,64 @@ static int add_standard_modes(struct drm_connector
*connector, struct edid *edid
return modes;
}
+/*
+ * XXX fix this for:
+ * - GTF secondary curve formula
+ * - EDID 1.4 range offsets
+ * - CVT extended bits
+ */
+static bool
+mode_in_range(struct drm_display_mode *mode, struct detailed_timing *timing)
+{
+ struct detailed_data_monitor_range *range;
+ int hsync, vrefresh;
+
+ range = timing-data.other_data.data.range;
+
+ hsync = drm_mode_hsync(mode);
+ vrefresh = drm_mode_vrefresh(mode);
+
+ if (hsync range-min_hfreq_khz || hsync range-max_hfreq_khz)
+ return false;
+
+ if (vrefresh range-min_vfreq || vrefresh range-max_vfreq)
+ return false;
+
+ if (range-pixel_clock_mhz range-pixel_clock_mhz != 0xff) {
+ /* be forgiving since it's in units of 10MHz */
+ int max_clock = range-pixel_clock_mhz * 10 + 9;
+ max_clock *= 1000;
+ if (mode-clock max_clock)
+ return false;
+ }
+
+ return true;
+}
+
+/*
+ * XXX If drm_dmt_modes ever regrows the CVT-R modes (and it will) this will
+ * need to account for them.
+ */
+static int drm_gtf_modes_for_range(struct drm_connector *connector,
+ struct detailed_timing *timing)
+{
+ int i, modes = 0;
+ struct drm_display_mode *newmode;
+ struct drm_device *dev = connector-dev;
+
+ for (i = 0; i drm_num_dmt_modes; i++) {
+ if (mode_in_range(drm_dmt_modes + i, timing)) {
+ newmode = drm_mode_duplicate(dev, drm_dmt_modes[i]);
+ if (newmode) {
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ }
+
+ return modes;
+}
+
static int add_detailed_modes(struct drm_connector *connector,
struct detailed_timing *timing,
struct edid *edid, u32 quirks, int preferred)
@@ -845,6 +904,7 @@ static int add_detailed_modes(struct drm_connector
*connector,
int i, modes = 0;
struct detailed_non_pixel *data = timing-data.other_data;
int timing_level = standard_timing_level(edid);
+ int gtf = (edid-features DRM_EDID_FEATURE_DEFAULT_GTF);
struct drm_display_mode *newmode;
struct drm_device *dev = connector-dev;
@@ -863,7 +923,8 @@ static int add_detailed_modes(struct drm_connector
*connector,
/* other timing types */
switch (data-type) {
case EDID_DETAIL_MONITOR_RANGE:
- /* Get monitor range data */
+ if (gtf)
+ modes += drm_gtf_modes_for_range(connector, timing);
break;
case EDID_DETAIL_STD_MODES:
/* Six modes per detailed section */
--
1.6.5.2
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/5] drm/modes: Add drm_mode_hsync()
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_modes.c | 28 +++-
include/drm/drm_crtc.h |7 ---
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 51f6772..6d81a02 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -553,6 +553,32 @@ int drm_mode_height(struct drm_display_mode *mode)
}
EXPORT_SYMBOL(drm_mode_height);
+/** drm_mode_hsync - get the hsync of a mode
+ * @mode: mode
+ *
+ * LOCKING:
+ * None.
+ *
+ * Return @modes's hsync rate in kHz, rounded to the nearest int.
+ */
+int drm_mode_hsync(struct drm_display_mode *mode)
+{
+ unsigned int calc_val;
+
+ if (mode-hsync)
+ return mode-hsync;
+
+ if (mode-htotal 0)
+ return 0;
+
+ calc_val = (mode-clock * 1000) / mode-htotal; /* hsync in Hz */
+ calc_val += 500;/* round to 1000Hz */
+ calc_val /= 1000; /* truncate to kHz */
+
+ return calc_val;
+}
+EXPORT_SYMBOL(drm_mode_hsync);
+
/**
* drm_mode_vrefresh - get the vrefresh of a mode
* @mode: mode
@@ -560,7 +586,7 @@ EXPORT_SYMBOL(drm_mode_height);
* LOCKING:
* None.
*
- * Return @mode's vrefresh rate or calculate it if necessary.
+ * Return @mode's vrefresh rate in Hz or calculate it if necessary.
*
* FIXME: why is this needed? shouldn't vrefresh be set already?
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index d84fba1..938f327 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -123,7 +123,7 @@ struct drm_display_mode {
int type;
/* Proposed mode values */
- int clock;
+ int clock; /* in kHz */
int hdisplay;
int hsync_start;
int hsync_end;
@@ -164,8 +164,8 @@ struct drm_display_mode {
int *private;
int private_flags;
- int vrefresh;
- float hsync;
+ int vrefresh; /* in Hz */
+ int hsync; /* in kHz */
};
enum drm_connector_status {
@@ -681,6 +681,7 @@ extern void drm_mode_validate_size(struct drm_device *dev,
extern void drm_mode_prune_invalid(struct drm_device *dev,
struct list_head *mode_list, bool verbose);
extern void drm_mode_sort(struct list_head *mode_list);
+extern int drm_mode_hsync(struct drm_display_mode *mode);
extern int drm_mode_vrefresh(struct drm_display_mode *mode);
extern void drm_mode_set_crtcinfo(struct drm_display_mode *p,
int adjust_flags);
--
1.6.5.2
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/5] drm/edid: Unify detailed block parsing between base and extension blocks
Also fix an embarassing bug in standard timing subblock parsing that
would result in an infinite loop.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 163 ---
1 files changed, 61 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bdea313..999571a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -838,8 +838,57 @@ static int add_standard_modes(struct drm_connector
*connector, struct edid *edid
return modes;
}
+static int add_detailed_modes(struct drm_connector *connector,
+ struct detailed_timing *timing,
+ struct edid *edid, u32 quirks, int preferred)
+{
+ int i, modes = 0;
+ struct detailed_non_pixel *data = timing-data.other_data;
+ int timing_level = standard_timing_level(edid);
+ struct drm_display_mode *newmode;
+ struct drm_device *dev = connector-dev;
+
+ if (timing-pixel_clock) {
+ newmode = drm_mode_detailed(dev, edid, timing, quirks);
+ if (!newmode)
+ return 0;
+
+ if (preferred)
+ newmode-type |= DRM_MODE_TYPE_PREFERRED;
+
+ drm_mode_probed_add(connector, newmode);
+ return 1;
+ }
+
+ /* other timing types */
+ switch (data-type) {
+ case EDID_DETAIL_MONITOR_RANGE:
+ /* Get monitor range data */
+ break;
+ case EDID_DETAIL_STD_MODES:
+ /* Six modes per detailed section */
+ for (i = 0; i 6; i++) {
+ struct std_timing *std;
+ struct drm_display_mode *newmode;
+
+ std = data-data.timings[i];
+ newmode = drm_mode_std(dev, std, edid-revision,
+ timing_level);
+ if (newmode) {
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ break;
+ default:
+ break;
+ }
+
+ return modes;
+}
+
/**
- * add_detailed_modes - get detailed mode info from EDID data
+ * add_detailed_info - get detailed mode info from EDID data
* @connector: attached connector
* @edid: EDID block to scan
* @quirks: quirks to apply
@@ -850,67 +899,24 @@ static int add_standard_modes(struct drm_connector
*connector, struct edid *edid
static int add_detailed_info(struct drm_connector *connector,
struct edid *edid, u32 quirks)
{
- struct drm_device *dev = connector-dev;
- int i, j, modes = 0;
- int timing_level;
-
- timing_level = standard_timing_level(edid);
+ int i, modes = 0;
for (i = 0; i EDID_DETAILED_TIMINGS; i++) {
struct detailed_timing *timing = edid-detailed_timings[i];
- struct detailed_non_pixel *data = timing-data.other_data;
- struct drm_display_mode *newmode;
-
- /* X server check is version 1.1 or higher */
- if (edid-version == 1 edid-revision = 1
- !timing-pixel_clock) {
- /* Other timing or info */
- switch (data-type) {
- case EDID_DETAIL_MONITOR_SERIAL:
- break;
- case EDID_DETAIL_MONITOR_STRING:
- break;
- case EDID_DETAIL_MONITOR_RANGE:
- /* Get monitor range data */
- break;
- case EDID_DETAIL_MONITOR_NAME:
- break;
- case EDID_DETAIL_MONITOR_CPDATA:
- break;
- case EDID_DETAIL_STD_MODES:
- for (j = 0; j 6; i++) {
- struct std_timing *std;
- struct drm_display_mode *newmode;
-
- std = data-data.timings[j];
- newmode = drm_mode_std(dev, std,
- edid-revision,
- timing_level);
- if (newmode) {
- drm_mode_probed_add(connector,
newmode);
- modes++;
- }
- }
- break;
- default:
- break;
- }
- } else {
- newmode
[PATCH 5/5] drm/edid: Decode 3-byte CVT codes from EDID 1.4
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 48
include/drm/drm_edid.h |5
2 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cc8e696..30af8f3 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -897,6 +897,51 @@ static int drm_gtf_modes_for_range(struct drm_connector
*connector,
return modes;
}
+static int drm_cvt_modes(struct drm_connector *connector,
+struct detailed_timing *timing)
+{
+ int i, j, modes = 0;
+ struct drm_display_mode *newmode;
+ struct drm_device *dev = connector-dev;
+ struct cvt_timing *cvt;
+ const int rates[] = { 60, 85, 75, 60, 50 };
+
+ for (i = 0; i 4; i++) {
+ int width, height;
+ cvt = (timing-data.other_data.data.cvt[i]);
+
+ height = (cvt-code[0] + ((cvt-code[1] 0xf0) 8) + 1) * 2;
+ switch (cvt-code[1] 0xc0) {
+ case 0x00:
+ width = height * 4 / 3;
+ break;
+ case 0x40:
+ width = height * 16 / 9;
+ break;
+ case 0x80:
+ width = height * 16 / 10;
+ break;
+ case 0xc0:
+ width = height * 15 / 9;
+ break;
+ }
+
+ for (j = 1; j 5; j++) {
+ if (cvt-code[2] (1 j)) {
+ newmode = drm_cvt_mode(dev, width, height,
+ rates[j], j == 0,
+ false, false);
+ if (newmode) {
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ }
+ }
+
+ return modes;
+}
+
static int add_detailed_modes(struct drm_connector *connector,
struct detailed_timing *timing,
struct edid *edid, u32 quirks, int preferred)
@@ -941,6 +986,9 @@ static int add_detailed_modes(struct drm_connector
*connector,
}
}
break;
+ case EDID_DETAIL_CVT_3BYTE:
+ modes += drm_cvt_modes(connector, timing);
+ break;
default:
break;
}
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 9087557..d33c3e0 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -106,6 +106,10 @@ struct detailed_data_color_point {
u8 wpindex2[3];
} __attribute__((packed));
+struct cvt_timing {
+ u8 code[3];
+} __attribute__((packed));
+
struct detailed_non_pixel {
u8 pad1;
u8 type; /* ff=serial, fe=string, fd=monitor range, fc=monitor name
@@ -117,6 +121,7 @@ struct detailed_non_pixel {
struct detailed_data_monitor_range range;
struct detailed_data_wpindex color;
struct std_timing timings[5];
+ struct cvt_timing cvt[4];
} data;
} __attribute__((packed));
--
1.6.5.2
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/4] drm/modes: Limit fallback modes to 60Hz
On Mon, 2009-11-23 at 20:32 +0100, Rafał Miłecki wrote:
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cea665d..dd95edf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1290,6 +1290,8 @@ int drm_add_modes_noedid(struct drm_connector
*connector,
ptr-vdisplay vdisplay)
continue;
}
+ if (drm_mode_vrefresh(ptr) 61)
+ continue;
mode = drm_mode_duplicate(dev, ptr);
if (mode) {
drm_mode_probed_add(connector, mode);
Did you use 61 on purpose?
Is that typo ( 60, or = 61) or do you expect modes like 60.1Hz we
want to survive?
Mostly just paranoia, since drm_mode_vrefresh returns an int.
- ajax
signature.asc
Description: This is a digitally signed message part
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/5] drm/edid: Unify detailed block parsing between base and extension blocks
Also fix an embarassing bug in standard timing subblock parsing that
would result in an infinite loop.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 159 +---
1 files changed, 61 insertions(+), 98 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cea665d..e655916 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -828,8 +828,57 @@ static int add_standard_modes(struct drm_connector
*connector, struct edid *edid
return modes;
}
+static int add_detailed_modes(struct drm_connector *connector,
+ struct detailed_timing *timing,
+ struct edid *edid, u32 quirks, int preferred)
+{
+ int i, modes = 0;
+ struct detailed_non_pixel *data = timing-data.other_data;
+ int timing_level = standard_timing_level(edid);
+ struct drm_display_mode *newmode;
+ struct drm_device *dev = connector-dev;
+
+ if (timing-pixel_clock) {
+ newmode = drm_mode_detailed(dev, edid, timing, quirks);
+ if (!newmode)
+ return 0;
+
+ if (preferred)
+ newmode-type |= DRM_MODE_TYPE_PREFERRED;
+
+ drm_mode_probed_add(connector, newmode);
+ return 1;
+ }
+
+ /* other timing types */
+ switch (data-type) {
+ case EDID_DETAIL_MONITOR_RANGE:
+ /* Get monitor range data */
+ break;
+ case EDID_DETAIL_STD_MODES:
+ /* Six modes per detailed section */
+ for (i = 0; i 6; i++) {
+ struct std_timing *std;
+ struct drm_display_mode *newmode;
+
+ std = data-data.timings[i];
+ newmode = drm_mode_std(dev, std, edid-revision,
+ timing_level);
+ if (newmode) {
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ break;
+ default:
+ break;
+ }
+
+ return modes;
+}
+
/**
- * add_detailed_modes - get detailed mode info from EDID data
+ * add_detailed_info - get detailed mode info from EDID data
* @connector: attached connector
* @edid: EDID block to scan
* @quirks: quirks to apply
@@ -841,66 +890,24 @@ static int add_detailed_info(struct drm_connector
*connector,
struct edid *edid, u32 quirks)
{
struct drm_device *dev = connector-dev;
- int i, j, modes = 0;
- int timing_level;
-
- timing_level = standard_timing_level(edid);
+ int i, modes = 0;
for (i = 0; i EDID_DETAILED_TIMINGS; i++) {
struct detailed_timing *timing = edid-detailed_timings[i];
- struct detailed_non_pixel *data = timing-data.other_data;
- struct drm_display_mode *newmode;
-
- /* X server check is version 1.1 or higher */
- if (edid-version == 1 edid-revision = 1
- !timing-pixel_clock) {
- /* Other timing or info */
- switch (data-type) {
- case EDID_DETAIL_MONITOR_SERIAL:
- break;
- case EDID_DETAIL_MONITOR_STRING:
- break;
- case EDID_DETAIL_MONITOR_RANGE:
- /* Get monitor range data */
- break;
- case EDID_DETAIL_MONITOR_NAME:
- break;
- case EDID_DETAIL_MONITOR_CPDATA:
- break;
- case EDID_DETAIL_STD_MODES:
- for (j = 0; j 6; i++) {
- struct std_timing *std;
- struct drm_display_mode *newmode;
-
- std = data-data.timings[j];
- newmode = drm_mode_std(dev, std,
- edid-revision,
- timing_level);
- if (newmode) {
- drm_mode_probed_add(connector,
newmode);
- modes++;
- }
- }
- break;
- default:
- break;
- }
- } else {
- newmode = drm_mode_detailed(dev, edid, timing, quirks);
- if (!newmode
[PATCH 2/5] drm/modes: Add drm_mode_hsync()
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_modes.c | 28 +++-
include/drm/drm_crtc.h |7 ---
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 51f6772..6d81a02 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -553,6 +553,32 @@ int drm_mode_height(struct drm_display_mode *mode)
}
EXPORT_SYMBOL(drm_mode_height);
+/** drm_mode_hsync - get the hsync of a mode
+ * @mode: mode
+ *
+ * LOCKING:
+ * None.
+ *
+ * Return @modes's hsync rate in kHz, rounded to the nearest int.
+ */
+int drm_mode_hsync(struct drm_display_mode *mode)
+{
+ unsigned int calc_val;
+
+ if (mode-hsync)
+ return mode-hsync;
+
+ if (mode-htotal 0)
+ return 0;
+
+ calc_val = (mode-clock * 1000) / mode-htotal; /* hsync in Hz */
+ calc_val += 500;/* round to 1000Hz */
+ calc_val /= 1000; /* truncate to kHz */
+
+ return calc_val;
+}
+EXPORT_SYMBOL(drm_mode_hsync);
+
/**
* drm_mode_vrefresh - get the vrefresh of a mode
* @mode: mode
@@ -560,7 +586,7 @@ EXPORT_SYMBOL(drm_mode_height);
* LOCKING:
* None.
*
- * Return @mode's vrefresh rate or calculate it if necessary.
+ * Return @mode's vrefresh rate in Hz or calculate it if necessary.
*
* FIXME: why is this needed? shouldn't vrefresh be set already?
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4cc8a32..af3967c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -123,7 +123,7 @@ struct drm_display_mode {
int type;
/* Proposed mode values */
- int clock;
+ int clock; /* in kHz */
int hdisplay;
int hsync_start;
int hsync_end;
@@ -164,8 +164,8 @@ struct drm_display_mode {
int *private;
int private_flags;
- int vrefresh;
- float hsync;
+ int vrefresh; /* in Hz */
+ int hsync; /* in kHz */
};
enum drm_connector_status {
@@ -681,6 +681,7 @@ extern void drm_mode_validate_size(struct drm_device *dev,
extern void drm_mode_prune_invalid(struct drm_device *dev,
struct list_head *mode_list, bool verbose);
extern void drm_mode_sort(struct list_head *mode_list);
+extern int drm_mode_hsync(struct drm_display_mode *mode);
extern int drm_mode_vrefresh(struct drm_display_mode *mode);
extern void drm_mode_set_crtcinfo(struct drm_display_mode *p,
int adjust_flags);
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 5/5] drm/edid: Decode 3-byte CVT codes from EDID 1.4
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 48
include/drm/drm_edid.h |5
2 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ee84ffe..0f00fa0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -887,6 +887,51 @@ static int drm_gtf_modes_for_range(struct drm_connector
*connector,
return modes;
}
+static int drm_cvt_modes(struct drm_connector *connector,
+struct detailed_timing *timing)
+{
+ int i, j, modes = 0;
+ struct drm_display_mode *newmode;
+ struct drm_device *dev = connector-dev;
+ struct cvt_timing *cvt;
+ const int rates[] = { 60, 85, 75, 60, 50 };
+
+ for (i = 0; i 4; i++) {
+ int width, height;
+ cvt = timing-data.other_data.data.cvt + i;
+
+ height = (cvt-code[0] + ((cvt-code[1] 0xf0) 8) + 1) * 2;
+ switch (cvt-code[1] 0xc0) {
+ case 0x00:
+ width = height * 4 / 3;
+ break;
+ case 0x40:
+ width = height * 16 / 9;
+ break;
+ case 0x80:
+ width = height * 16 / 10;
+ break;
+ case 0xc0:
+ width = height * 15 / 9;
+ break;
+ }
+
+ for (j = 1; j 5; j++) {
+ if (cvt-code[2] (1 j)) {
+ newmode = drm_cvt_mode(dev, width, height,
+ rates[j], j == 0,
+ false, false);
+ if (newmode) {
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ }
+ }
+
+ return modes;
+}
+
static int add_detailed_modes(struct drm_connector *connector,
struct detailed_timing *timing,
struct edid *edid, u32 quirks, int preferred)
@@ -931,6 +976,9 @@ static int add_detailed_modes(struct drm_connector
*connector,
}
}
break;
+ case EDID_DETAIL_CVT_3BYTE:
+ modes += drm_cvt_modes(connector, timing);
+ break;
default:
break;
}
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 9087557..d33c3e0 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -106,6 +106,10 @@ struct detailed_data_color_point {
u8 wpindex2[3];
} __attribute__((packed));
+struct cvt_timing {
+ u8 code[3];
+} __attribute__((packed));
+
struct detailed_non_pixel {
u8 pad1;
u8 type; /* ff=serial, fe=string, fd=monitor range, fc=monitor name
@@ -117,6 +121,7 @@ struct detailed_non_pixel {
struct detailed_data_monitor_range range;
struct detailed_data_wpindex color;
struct std_timing timings[5];
+ struct cvt_timing cvt[4];
} data;
} __attribute__((packed));
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/5] drm/edid: Add new detailed block types from EDID 1.4
Signed-off-by: Adam Jackson a...@redhat.com
---
include/drm/drm_edid.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 7d6c9a2..9087557 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -120,6 +120,9 @@ struct detailed_non_pixel {
} data;
} __attribute__((packed));
+#define EDID_DETAIL_EST_TIMINGS 0xf7
+#define EDID_DETAIL_CVT_3BYTE 0xf8
+#define EDID_DETAIL_COLOR_MGMT_DATA 0xf9
#define EDID_DETAIL_STD_MODES 0xfa
#define EDID_DETAIL_MONITOR_CPDATA 0xfb
#define EDID_DETAIL_MONITOR_NAME 0xfc
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/5] drm/edid: Add DMT modes to the pool if the monitor is GTF-capable
See also: http://bugzilla.redhat.com/539785
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 69 +--
1 files changed, 65 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e655916..ee84ffe 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -481,16 +481,17 @@ static struct drm_display_mode drm_dmt_modes[] = {
3048, 3536, 0, 1600, 1603, 1609, 1682, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
};
+static const int drm_num_dmt_modes =
+ sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
static struct drm_display_mode *drm_find_dmt(struct drm_device *dev,
int hsize, int vsize, int fresh)
{
- int i, count;
+ int i;
struct drm_display_mode *ptr, *mode;
- count = sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
mode = NULL;
- for (i = 0; i count; i++) {
+ for (i = 0; i drm_num_dmt_modes; i++) {
ptr = drm_dmt_modes[i];
if (hsize == ptr-hdisplay
vsize == ptr-vdisplay
@@ -828,6 +829,64 @@ static int add_standard_modes(struct drm_connector
*connector, struct edid *edid
return modes;
}
+/*
+ * XXX fix this for:
+ * - GTF secondary curve formula
+ * - EDID 1.4 range offsets
+ * - CVT extended bits
+ */
+static bool
+mode_in_range(struct drm_display_mode *mode, struct detailed_timing *timing)
+{
+ struct detailed_data_monitor_range *range;
+ int hsync, vrefresh;
+
+ range = timing-data.other_data.data.range;
+
+ hsync = drm_mode_hsync(mode);
+ vrefresh = drm_mode_vrefresh(mode);
+
+ if (hsync range-min_hfreq_khz || hsync range-max_hfreq_khz)
+ return false;
+
+ if (vrefresh range-min_vfreq || vrefresh range-max_vfreq)
+ return false;
+
+ if (range-pixel_clock_mhz range-pixel_clock_mhz != 0xff) {
+ /* be forgiving since it's in units of 10MHz */
+ int max_clock = range-pixel_clock_mhz * 10 + 9;
+ max_clock *= 1000;
+ if (mode-clock max_clock)
+ return false;
+ }
+
+ return true;
+}
+
+/*
+ * XXX If drm_dmt_modes ever regrows the CVT-R modes (and it will) this will
+ * need to account for them.
+ */
+static int drm_gtf_modes_for_range(struct drm_connector *connector,
+ struct detailed_timing *timing)
+{
+ int i, modes = 0;
+ struct drm_display_mode *newmode;
+ struct drm_device *dev = connector-dev;
+
+ for (i = 0; i drm_num_dmt_modes; i++) {
+ if (mode_in_range(drm_dmt_modes + i, timing)) {
+ newmode = drm_mode_duplicate(dev, drm_dmt_modes[i]);
+ if (newmode) {
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+ }
+ }
+
+ return modes;
+}
+
static int add_detailed_modes(struct drm_connector *connector,
struct detailed_timing *timing,
struct edid *edid, u32 quirks, int preferred)
@@ -835,6 +894,7 @@ static int add_detailed_modes(struct drm_connector
*connector,
int i, modes = 0;
struct detailed_non_pixel *data = timing-data.other_data;
int timing_level = standard_timing_level(edid);
+ int gtf = (edid-features DRM_EDID_FEATURE_DEFAULT_GTF);
struct drm_display_mode *newmode;
struct drm_device *dev = connector-dev;
@@ -853,7 +913,8 @@ static int add_detailed_modes(struct drm_connector
*connector,
/* other timing types */
switch (data-type) {
case EDID_DETAIL_MONITOR_RANGE:
- /* Get monitor range data */
+ if (gtf)
+ modes += drm_gtf_modes_for_range(connector, timing);
break;
case EDID_DETAIL_STD_MODES:
/* Six modes per detailed section */
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/4] drm/modes: Fall back to 1024x768 instead of 800x600
This matches the X server's fallback modes when using RANDR 1.2.
See also: http://bugzilla.redhat.com/538761
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_crtc_helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 1fe4e1d..c5bd50c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -109,7 +109,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
count = (*connector_funcs-get_modes)(connector);
if (!count) {
- count = drm_add_modes_noedid(connector, 800, 600);
+ count = drm_add_modes_noedid(connector, 1024, 768);
if (!count)
return 0;
}
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/4] drm/modes: Limit fallback modes to 60Hz
See also: http://bugzilla.redhat.com/514600
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cea665d..dd95edf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1290,6 +1290,8 @@ int drm_add_modes_noedid(struct drm_connector *connector,
ptr-vdisplay vdisplay)
continue;
}
+ if (drm_mode_vrefresh(ptr) 61)
+ continue;
mode = drm_mode_duplicate(dev, ptr);
if (mode) {
drm_mode_probed_add(connector, mode);
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/4] drm/edid: Retry EDID fetch up to four times
This matches the X server's retry logic. Note that we'll only retry if
we get a DDC response but fail validation; legitimately disconnected
outputs will bomb out early.
See also: http://bugzilla.redhat.com/532957
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dd95edf..2820082 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -133,9 +133,6 @@ static bool edid_is_valid(struct edid *edid)
DRM_ERROR(EDID has major version %d, instead of 1\n,
edid-version);
goto bad;
}
- if (edid-revision 4)
- DRM_DEBUG(EDID minor 4, assuming backward compatibility\n);
-
for (i = 0; i EDID_LENGTH; i++)
csum += raw_edid[i];
if (csum) {
@@ -143,6 +140,9 @@ static bool edid_is_valid(struct edid *edid)
goto bad;
}
+ if (edid-revision 4)
+ DRM_DEBUG(EDID minor 4, assuming backward compatibility\n);
+
return 1;
bad:
@@ -1060,19 +1060,19 @@ static int drm_ddc_read_edid(struct drm_connector
*connector,
struct i2c_adapter *adapter,
char *buf, int len)
{
- int ret;
+ int i;
- ret = drm_do_probe_ddc_edid(adapter, buf, len);
- if (ret != 0) {
- goto end;
- }
- if (!edid_is_valid((struct edid *)buf)) {
- dev_warn(connector-dev-pdev-dev, %s: EDID invalid.\n,
-drm_get_connector_name(connector));
- ret = -1;
+ for (i = 0; i 4; i++) {
+ if (drm_do_probe_ddc_edid(adapter, buf, len))
+ return -1;
+ if (edid_is_valid((struct edid *)buf))
+ return 0;
}
-end:
- return ret;
+
+ /* repeated checksum failures; warn, but carry on */
+ dev_warn(connector-dev-pdev-dev, %s: EDID invalid.\n,
+drm_get_connector_name(connector));
+ return -1;
}
/**
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/4] drm/edid: Fix up partially corrupted headers
We'll still fail the block if it fails the EDID checksum though.
See also: http://bugzilla.redhat.com/534120
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 22 --
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2820082..bdea313 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -123,16 +123,21 @@ static const u8 edid_header[] = {
*/
static bool edid_is_valid(struct edid *edid)
{
- int i;
+ int i, score = 0;
u8 csum = 0;
u8 *raw_edid = (u8 *)edid;
- if (memcmp(edid-header, edid_header, sizeof(edid_header)))
- goto bad;
- if (edid-version != 1) {
- DRM_ERROR(EDID has major version %d, instead of 1\n,
edid-version);
+ for (i = 0; i sizeof(edid_header); i++)
+ if (raw_edid[i] == edid_header[i])
+ score++;
+
+ if (score == 8) ;
+ else if (score = 6) {
+ DRM_DEBUG(Fixing EDID header, your hardware may be failing\n);
+ memcpy(raw_edid, edid_header, sizeof(edid_header));
+ } else
goto bad;
- }
+
for (i = 0; i EDID_LENGTH; i++)
csum += raw_edid[i];
if (csum) {
@@ -140,6 +145,11 @@ static bool edid_is_valid(struct edid *edid)
goto bad;
}
+ if (edid-version != 1) {
+ DRM_ERROR(EDID has major version %d, instead of 1\n,
edid-version);
+ goto bad;
+ }
+
if (edid-revision 4)
DRM_DEBUG(EDID minor 4, assuming backward compatibility\n);
--
1.6.5.2
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/4] drm/edid: Fix standard timing parse for EDID = 1.2
Aspect ratio code of 0 means 1:1 before EDID 1.3.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8ed732a..9888c20 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -528,6 +528,7 @@ bad_std_timing(u8 a, u8 b)
*/
struct drm_display_mode *drm_mode_std(struct drm_device *dev,
struct std_timing *t,
+ int revision,
int timing_level)
{
struct drm_display_mode *mode;
@@ -546,9 +547,12 @@ struct drm_display_mode *drm_mode_std(struct drm_device
*dev,
/* vrefresh_rate = vfreq + 60 */
vrefresh_rate = vfreq + 60;
/* the vdisplay is calculated based on the aspect ratio */
- if (aspect_ratio == 0)
- vsize = (hsize * 10) / 16;
- else if (aspect_ratio == 1)
+ if (aspect_ratio == 0) {
+ if (revision 3)
+ vsize = hsize;
+ else
+ vsize = (hsize * 10) / 16;
+ } else if (aspect_ratio == 1)
vsize = (hsize * 3) / 4;
else if (aspect_ratio == 2)
vsize = (hsize * 4) / 5;
@@ -797,7 +801,7 @@ static int add_standard_modes(struct drm_connector
*connector, struct edid *edid
continue;
newmode = drm_mode_std(dev, edid-standard_timings[i],
- timing_level);
+ edid-revision, timing_level);
if (newmode) {
drm_mode_probed_add(connector, newmode);
modes++;
@@ -853,6 +857,7 @@ static int add_detailed_info(struct drm_connector
*connector,
std = data-data.timings[j];
newmode = drm_mode_std(dev, std,
+ edid-revision,
timing_level);
if (newmode) {
drm_mode_probed_add(connector,
newmode);
@@ -981,7 +986,9 @@ static int add_detailed_info_eedid(struct drm_connector
*connector,
struct drm_display_mode *newmode;
std = data-data.timings[j];
- newmode = drm_mode_std(dev, std, timing_level);
+ newmode = drm_mode_std(dev, std,
+ edid-revision,
+ timing_level);
if (newmode) {
drm_mode_probed_add(connector, newmode);
modes++;
--
1.6.4.2
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/4] drm/edid: Ignore bad standard timings.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3326987..dd35dc1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -502,6 +502,19 @@ static struct drm_display_mode *drm_find_dmt(struct
drm_device *dev,
}
return mode;
}
+
+/*
+ * 0 is reserved. The spec says 0x01 fill for unused timings. Some old
+ * monitors fill with ascii space (0x20) instead.
+ */
+static int
+bad_std_timing(u8 a, u8 b)
+{
+ return (a == 0x00 b == 0x00) ||
+ (a == 0x01 b == 0x01) ||
+ (a == 0x20 b == 0x20);
+}
+
/**
* drm_mode_std - convert standard mode info (width, height, refresh) into mode
* @t: standard timing params
@@ -525,6 +538,9 @@ struct drm_display_mode *drm_mode_std(struct drm_device
*dev,
unsigned vfreq = (t-vfreq_aspect EDID_TIMING_VFREQ_MASK)
EDID_TIMING_VFREQ_SHIFT;
+ if (bad_std_timing(t-hsize, t-vfreq_aspect))
+ return NULL;
+
/* According to the EDID spec, the hdisplay = hsize * 8 + 248 */
hsize = t-hsize * 8 + 248;
/* vrefresh_rate = vfreq + 60 */
--
1.6.4.2
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/4] drm/edid: const cleanup
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 90d76ba..3326987 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -109,7 +109,9 @@ static struct edid_quirk {
/* Valid EDID header has these bytes */
-static u8 edid_header[] = { 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00 };
+static const u8 edid_header[] = {
+ 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00
+};
/**
* edid_is_valid - sanity check EDID data
--
1.6.4.2
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/4] drm/edid: Detailed standard timing blocks have six timings, not five.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dd35dc1..8ed732a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -847,8 +847,7 @@ static int add_detailed_info(struct drm_connector
*connector,
case EDID_DETAIL_MONITOR_CPDATA:
break;
case EDID_DETAIL_STD_MODES:
- /* Five modes per detailed section */
- for (j = 0; j 5; i++) {
+ for (j = 0; j 6; i++) {
struct std_timing *std;
struct drm_display_mode *newmode;
--
1.6.4.2
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[ANNOUNCE] libdrm 2.0.2
Disable building static library by default. Updated kernel DRM headers. http://dri.freedesktop.org/libdrm/libdrm-2.0.2.tar.gz f198bf2dfa224e1fbe6aa9c0df08cbfe libdrm-2.0.2.tar.gz 99f406e2bbc6ee1f87e32d0c815ba8b6454fed1d libdrm-2.0.2.tar.gz http://dri.freedesktop.org/libdrm/libdrm-2.0.2.tar.bz2 db7f1f89d2571427d6ea1feb2466f577 libdrm-2.0.2.tar.bz2 99ed33bfd0fa41e8db0ad7d226f33f7546063a1a libdrm-2.0.2.tar.bz2 - ajax pgpH2oI3ls0Uh.pgp Description: PGP signature Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] problems leaving the game (Quake 3 + Doom 3)
On Wednesday 26 April 2006 10:14, Rune Petersen wrote: Hi, Since the 12 of April there has been a change that causes Quake 3 and Doom 3 (demo)not to exit properly. Quake 3 locks up the system, and Doom 3 does a double fault. The suspect as I see it is: Ensure all GART allocations are freed on context destruction But I have yet to confirm it. If you are unable to confirm it, I'll try to track it down myself. That patch was admittedly rather brute-force, but I've not had any issues with it locally. - ajax pgp6pp5v21lDM.pgp Description: PGP signature
Re: two X servers
On Tuesday 18 April 2006 10:05, Alex Deucher wrote: On 4/18/06, Adam Sulmicki [EMAIL PROTECTED] wrote: hello, It seems only the first copy of X gets drm enabled. Is this something to live with or this can be fixed? Currently only one instance of the X server can have the DRI enabled. It can be fixed with only moderate work, I think. The only architectural issue would be introducing the concept of multiple DRI servers (here defined to mean: window system servers that can mediate the creation and management of DRM drawables) in the DRM, and then deciding on what semantics you want when the DRI server is switched away. Some of the drivers have hardcoded context numbers in the server, which is totally broken. Radeon in particular. - ajax pgpjCJZhGqMRI.pgp Description: PGP signature
Re: PCI Express command paths?
On Wednesday 22 March 2006 09:55, [EMAIL PROTECTED] wrote: Hey all, I was wondering, how exactly do DRI drivers interact with the PCIe bus? Pretty much the same way they interact with the PCI or AGP busses. Various resource ranges of each device are memory-mapped into the drivers' address space and the registers poked. The thought occurred to me that if the kernel provides the functionality to call the bus, then perhaps there is a slim chance that if I hack the kernel and intercept the command stream, I can learn how fglrx sets up the video card. Maybe I'm totally off on my DRI theory here; if so, please correct me. The r300 project has already done this. - ajax pgpRkpd6fPCCf.pgp Description: PGP signature
Re: libglx requires new symbol in loader (Was: problem with binary dri snapshots)
On Thursday 23 March 2006 11:33, Felix Kühling wrote: It looks like adding indirect acceleration added a new function to the loader that is used by libglx.so. So the new libglx won't work with older Xservers and I will have to build a new Xserver binary for snapshots/extras or add the Xserver to the snapshots. Yay! The problem with that is that the default ModulePath, RgbPath etc. I build with will only work with either one of Xorg 6.9 or 7.0, but not both. Hmm ... testing the latest and greatest stuff is getting messier. Why won't it work with both? I see this as an argument for more frequent server releases though. Server development seems to be grinding out at a pace that wants more frequent releases than the biannual Xorg rollups. I plan to address this at least partially by starting doing upstream server snapshots again; I'm open to suggestions on whether we should do something more formal. - ajax pgpOvkwddjexz.pgp Description: PGP signature
Re: DMA scheduling
On Thursday 16 March 2006 14:03, Felix Kühling wrote: Am Donnerstag, den 16.03.2006, 15:52 + schrieb Keith Whitwell: 1) Fairness. We can currently have situations where one 3d applications manages to dominate the GPU while a second app in another window is locked out entirely. 2) Interactivity. It is quite possible to have one application which does so little rendering per frame that it can run at 3000fps while another eg, video-based application does a lot more and can just about keep up a 30fps framerate. Consider a situation where both applications are running at once. Simple fairness criteria would have them running at 1500fps and 15fps respectively - but it seems that fairness isn't what is required here. It would be preferable give the slower application a greater percentage of the GPU, so that it manages eg. 27fps, while the other is scaled down to only 300fps or so. Note that we currently don't even have the fair situation... 3) Resource management. Imagine two applications each of which has a texture working set of 90% of the available video ram. Even a smart replacement algorithm will end up thrashing if the applications are able to rapidly grab the DRI lock from each other and enqueue buffer loads and rendering. A scheduler could recognize the thrashing and improve matters by giving each app a longer timeslice on the GPU to minimize texture reloads. 4) Latency. There are currently frame throttling hacks in place to limit the latency, or IOW how far the CPU can be ahead of the GPU. If the scheduler were to get involved in this activity it would not only schedule queued commands to the hardware but also throttle (block) clients whose command stream processing is too far behind. 5) Dispatch optimization. When multiple buffers are enqueued from different clients, their dispatch could be ordered to minimize the cost of state emission between context switches. For hardware with multiple contexts, this generalizes to picking the hw context to replace with the smallest switch cost vector. 6) Proper support for NV_fence / GL2_async_core / etc. 7) Greatly simplified support for swap groups and swap barriers. Probably some other stuff I'm forgetting. - ajax pgpWSX7KLJgCP.pgp Description: PGP signature
Re: radeon page flipping fixed BUT ...
On Sunday 26 February 2006 05:16, Benjamin Herrenschmidt wrote: Now I move the window around, the content heavily flickers, alternating between the gears and a black content. When I drop the window (stop moving it), it will either be the gears running happily ... or the black content. In that later case, it will stay black until I move the window again and drop it at the right time to get the gears back. I don't know much about what's going on with DRI when moving windows around so I would appreciate if somebody more familiar with that stuff could help me figure that one out. Basically, every time a DRI drawable's clip list changes, the server sets a flag in the SAREA to notify the client of this fact. The client then asks the server for the updated clip list via the XF86DRIGetDrawableInfo protocol request. It sounds like either the client is thinking it's getting a bogus clip list, or the client and server are getting confused about which buffer is the front buffer. - ajax pgp5QeVOPQBky.pgp Description: PGP signature
Re: Enabling Direct Rendering at CVS tip
On Wednesday 15 February 2006 20:34, Alan Hourihane wrote: Already fixed in CVS. Some code got away that's in-progress for the front buffer removal from the DRI. I'll be uploading a much larger patch to remove front buffer mapping from libdri and push that down into the drivers very soon to a bug report I opened explicitly for this. Is this major enough to warrant bumping the libdri major number? It certainly sounds like it if all the drivers have to be touched. - ajax pgpC567CkXMy6.pgp Description: PGP signature
Re: Enabling Direct Rendering at CVS tip
On Saturday 18 February 2006 19:41, Adam Jackson wrote: On Wednesday 15 February 2006 20:34, Alan Hourihane wrote: Already fixed in CVS. Some code got away that's in-progress for the front buffer removal from the DRI. I'll be uploading a much larger patch to remove front buffer mapping from libdri and push that down into the drivers very soon to a bug report I opened explicitly for this. Is this major enough to warrant bumping the libdri major number? It certainly sounds like it if all the drivers have to be touched. Never mind me, hadn't read through to your patch yet. - ajax pgpxTuaDg3bXM.pgp Description: PGP signature
Re: libdrm, memory manager
On Friday 13 January 2006 11:09, Keith Whitwell wrote: Yes, that seems to be the best approach. The only wrinkle is that if you're doing fences, it'd be nice to have a regularly updated completed fence id in the device independent sarea, which is currently full. So maybe a new shared area is needed. Full? Yikes. What's eating it? I thought we had a full page and were only using 256 slots for drawable IDs plus a few for the locks. That said, we do have drmSetVersion, so drivers can ask for a new-format sarea if they want. - ajax pgpF9u0idNrm3.pgp Description: PGP signature
Re: [Bug 1709] mesa_test_os_sse_exception_support fails inside gdb
On Thursday 15 December 2005 19:18, Sergio Monteiro Basto wrote: Hi Ajax, Please also see bug #5057 At my point of view defines IN_DRI_DRIVER and USE_EXTERNAL_DXTN_LIB=1 are very specific and only used in Mesa. So the patch on bug #5057 ( the last one ) or something similar, don't see what problems can cause on applying it. The problem in applying it is that we are in RCfinal now. This was a known issue for over a month and was never put on the release blocker, so apparently wasn't critical enough to block the release. Yes, this sucks. But we have process rules for a reason. - ajax pgp1bBm3w3nrr.pgp Description: PGP signature
Re: Tiny patch for a typedef...
On Thursday 08 December 2005 09:13, Brian Paul wrote: I've checked in the fix. It was a typo. I'm curious what platform you're compiling on that C99 isn't supported. Strictly speaking, no shipping compiler implements all of c99, gcc included. - ajax pgp3VFzPkbiL6.pgp Description: PGP signature
libdrm 2.0
It turns out Egbert's changes to enable mixed 32 and 64 bit client and server represent an ABI break for libdrm, since they hadn't made their way into the libdrm upstream before now. D'oh. libdrm 2.0 is out, having been resynced with all the changes from Xorg CVS (I hope). The 2.0 branch is actually a sub-branch of the 1.0 branch, not that anyone should care too much, and HEAD is now leading to 2.1. I've bumped the libdrm dependency for all the 2d drivers in modular, and I'll try to figure out a way to stick a useful pkgconfig check into the Mesa build. libdrm 2.0 import should land in xc shortly. Get it from the usual place: http://dri.freedesktop.org/libdrm/libdrm-2.0.tar.gz - ajax pgpf1g1ZiiErr.pgp Description: PGP signature
Re: drm_handle_t vs. unsigned long
On Tuesday 29 November 2005 10:52, Brian Paul wrote: Looks like the whole Mesa/src/mesa/drivers/dri/dri_client/ directory should go away. Is that right? Yes. - ajax pgpGtCkbkGN4s.pgp Description: PGP signature
Re: [PATCH] drmStrdup doesn't check for failed allocation
On Tuesday 29 November 2005 14:38, Tilman Sauerbeck wrote: Hi, drmStrdup() doesn't check for an allocation failure. I attached a patch that also tries to improve readability of the code. Feel free to disagree on that :) I realize the chances of drmStrdup() failing are probably low, but it should be corrected anyway. Applied, thanks. - ajax pgpqZyu3hwEfC.pgp Description: PGP signature
Re: drm_handle_t vs. unsigned long
On Friday 25 November 2005 17:51, Brian Paul wrote: I've been poking around in the DRM code a bit. One thing I've noticed is that the xf86drm.h file in the DRI/drm tree is a bit out of sync with the xf86drm.h file in the X.org tree. In particular, the use of unsigned long vs. drm_handle_t. It looks like the later (drm_handle_t in the X.org tree) is the better code. I'm a bit rusty on the DRM but it looks like the changes are minor so I may do the updates unless someone beats me to it, or indicates there's a reason for things as they are. I'm still catching up on email from the holiday weekend, but I plan to import a new libdrm into the monolith this week. - ajax pgpAdUbMJqSJs.pgp Description: PGP signature
Re: Mach64 still not in kernel tree
On Wednesday 23 November 2005 07:48, Michael Frank wrote: Testing 2.6.15-rc2 in-kernel DRM, why still no mach64 support which works fine for me from snapshots/cvs? Because it's still insecure. - ajax pgpRVEStYxIcP.pgp Description: PGP signature
libdrm stable branch created
Please note that libdrm now has a 1.0 branch. If you make changes to the DRM headers like the recent via_drm.h updates, such that drivers will need them to build, make sure they are applied to the 1.0 branch as well. A rough roadmap for libdrm 1.1: - Build and install the test apps by default - Add xdriinfo to the test app suite - Additional API for unified memory manager (see http://dri.freedesktop.org/wiki/DriMemoryManagerDesign for proposal) - Any changes needed to enable the XvMC drivers to link against libdrm (I don't expect there's much to do here) - Header cleanup (see below) - Unify libdrm code paths between client and server The motivation for that last one is so the remaining copy of libdrm in the server module can be dropped, and libdrm can finally move to being a fully shared object. Regarding header cleanup: Dave has said that the only headers libdrm should be installing are drm.h, drm_sarea.h, and *_drm.h for each device. r300 and via violate this rule and also install headers with register defines. I don't see why they need that, given that the others don't. I'd like to come up with a real policy here. - ajax pgpGYGG5pohCo.pgp Description: PGP signature
Re: libdrm stable branch created
On Friday 11 November 2005 14:51, Felix Kühling wrote: Am Freitag, den 11.11.2005, 13:38 -0500 schrieb Adam Jackson: Please note that libdrm now has a 1.0 branch. If you make changes to the DRM headers like the recent via_drm.h updates, such that drivers will need them to build, make sure they are applied to the 1.0 branch as well. A rough roadmap for libdrm 1.1: - Build and install the test apps by default - Add xdriinfo to the test app suite I don't see what xdriinfo has to do with libdrm. It does not talk to the DRM at all. It only interacts with the Xserver's DRI extension and libGL. libGL loads DRI drivers on xdriinfo's behalf but never initializes them. Consider the idea withdrawn then ;) - ajax pgp7ueEqPMzz1.pgp Description: PGP signature
Re: Questions on libdrm Future
On Friday 11 November 2005 14:22, Matt Sottek wrote:
1) Is libdrm intended to be staticly linked with a libGL, libXvMC etc. Or
are you invisioning a dynamic library available on all systems?
Intended to be dynamic. Any layer that needs to talk to the DRM driver
(server, libGL, libXvMC...) should be doing so through a single copy of
libdrm.
2) Can you please make it c++ safe. (Haven't looked at 1.0 but we needed
modifications) A quick check reveals things like bufs.virt in xf86drm.c and
the need for extern C { around the function prototypes.
Certainly. Patches would definitely be welcome.
3) What about libXF86DRI? To make a DRI client you need libdrm and a
hypothetical libXF86DRI to get the functions such as XF86DRIOpenConnection.
Clearly you'd want to rename the functions to something like
XDRIOpenConnection(), but getting a library that can be linked by other
clients would be nice.
I go back and forth on this. My concern is that the DRI protocol really
shouldn't be user visible at all. In fact I'm largely of the opinion that
the DRI protocol was a mistake. Almost all of it should have been either
inferred from existing GLX protocol (drawable and context ops) or added as
GLX extensions as an implementation detail (driver name and authentication).
4) Any way I can persuade you to NOT put the memory manager in libdrm?
Highly unlikely.
Perhaps another little library, released from the same place but not really
linked together. I have a need for libdrm but I have no use for your memory
manager and it seems like a lot of weight that I don't want to carry.
The bloat argument doesn't so much fly if everything else is already linking
against this one copy.
It also seems a bit misplaced to me. The DRI and DRM protocols are things of
general use that anyone using the DRI would need. The memory manager is a
helper so that code can be shared between drivers (your drivers), but is
not a required component that would be used by other libGL implementations
etc.
I think you misunderstand the memory manager's job. It's explicitly for
managing memory in the presence of more than one process competing for it.
The whole _point_ is that the X server, the GL drivers, the XvMC drivers, and
whatever else all have a consistent view of card memory and the ability to
grab as much of it as they need (instead of the current hack job where most
drivers just split offscreen memory in two and hand half to the DDX and have
to the DRI clients).
If you don't think you need this for your embedded platform, then, uh, why are
you using X.
Also, I expect the memory management layer in libdrm to be a pretty thin
wrapper around the ioctls exported by the kernel. Equivalent in size roughly
to the skip list code (which none of the open drivers use last I checked, and
I doubt yours does either). So if you really don't want that bloat, look to
the kernel to disable it.
The whole purpose of libdrm's existance is to be the one point for wrapping
the interface to the kernel. That includes memory management, so the drmMM
API belongs in libdrm. As a practical matter, if I'm given the choice
between maintaining two libdrm ABIs - where the smaller one exists solely to
make life slightly easier for a closed-source driver - and maintaining only
one ABI, I'm going to choose to maintain only one. People who choose to keep
their drivers closed have chosen to make their lives hard. I'm not going to
break closed drivers without good reason, but I'm also not going to make poor
engineering decisions based on their needs.
Seriously. The API being proposed is all of 11 functions. The libdrm API
averages about 120 bytes per function. Even if the memory management API is
three times that heavy, that's still less than a page. You'd save more by
building your driver with -fvisibility=hidden.
- ajax
pgp90qfxze6KA.pgp
Description: PGP signature
Re: libdrm
On Wednesday 26 October 2005 02:31, Thomas Hellström wrote: Adam Jackson wrote: Sure, if I can assume that the via header isn't going to need more changes before 7.0. Otherwise I'd prefer to wait until via has settled. Nope, there are no more changes pending. http://dri.freedesktop.org/libdrm/libdrm-1.0.5.tar.gz - ajax pgplwhndunnmK.pgp Description: PGP signature
Re: libdrm
On Tuesday 25 October 2005 03:34, Thomas Hellström wrote: Hi! Newly released Mesa 6.4 requires libdrm HEAD due to a cleanup I made to the unichrome dri driver, is there a chance to have a new patchlevel release of libdrm? There are no binary incompatibilities as far as I can see; only changes to via_drm.h. Sure, if I can assume that the via header isn't going to need more changes before 7.0. Otherwise I'd prefer to wait until via has settled. Furthermore will libdrm be included with Xorg 6.9? 7.0? in that case we should really modify the XvMC drivers (i810 and unichrome x 2) to make use of it. 6.9 will build libdrm statically as usual. 7.0 will link against the system's DSO version. - ajax pgpfstHhWl7Y6.pgp Description: PGP signature
Re: radeon 9600 with RV350 AQ chip works
On Sunday 23 October 2005 17:58, Popolon wrote: Popolon wrote: on some xscreensaver-4.16 mode, there are strange mapping of picture a band from picture and some reduced version at different scales. The bug was from xscreensaver as textures works perfectly on RV350_AQ with xscreensaver-4.22 xscreensaver-4.23. Is there a special process for this change to be accepted in tree ? I've checked this in. Thanks! - ajax pgpCEUSkiZhqh.pgp Description: PGP signature
Re: Changes to xf86drm.c (was Re: CVS Update: drm (branch: trunk))
On Thursday 20 October 2005 15:01, Ian Romanick wrote: Adam Jackson wrote: CVSROOT: /cvs/dri Module name: drm Repository: drm/libdrm/ Changes by: [EMAIL PROTECTED] 05/10/20 10:32:32 Log message: Remove bogus Xlib dependency. Modified files: drm/libdrm/: xf86drm.c Revision ChangesPath 1.52 +2 -3 drm/libdrm/xf86drm.c This change results in the following code segment. Is that *really* what you intended? It looks a little nutty to me. I think xf86_ansic.h already wraps malloc and free, so do we even need _DRM_MALLOC and _DRM_FREE at all anymore? # ifdef DRM_USE_MALLOC # define _DRM_MALLOC malloc # define _DRM_FREE free # else # define _DRM_MALLOC malloc # define _DRM_FREE free # endif Obviously, the more preprocessor statements involved, the better it works. This was admittedly a five-second hack to eliminate a useless (and wrong!) dependency on Xlib. But you're right, the libcwrapper does wrap malloc, so that code is totally useless. Feel free to clean it up if I don't get to it first. - ajax pgpbwdYc1CMmm.pgp Description: PGP signature
Re: My experience with the r300 driver
On Thursday 13 October 2005 07:51, Michel Dänzer wrote: There's no question that the override is useful for developers, the question is whether it isn't more harm- than useful for users. I've often thought it'd be nice to have the VideoRAM option in the config file be clamped to the max(user specified, driver probed), with some magic value the driver could specify to say it has no real idea how much vram is available. And, the driver also limits texture memory to only be useable up to 128MB, and I think this is not necessary (as textures are always blitted using the gpu and the memory used by them never touched directly by the cpu) or is it? Indeed, that memory would probably be useful for textures for now, but maybe CPU access to textures in the framebuffer will be necessary in the future? I don't think so. For fixed function cards, the numbers I've been getting while playing with accelerating XGetImage and XPutImage in EXA suggest that even for fairly small updates to offscreen images (about an 8x8 tile update or so), it's faster to download the subimage you're interested in, modify it in host RAM, and re-upload it, than it is to do CPU-driven access directly. XGetImage of XYPixmaps is a good example, where DMAing the pixmap down from the framebuffer and then converting ZPixmap to XYPixmap in host memory is between 3 to 12 times faster than the normal software path. For cards with useful fragment shaders, it'd be really really hot to see the server's fb layer implemented in fragment shaders and do even core X rendering entirely on-card. This is basically the Quartz 2D Extreme model. Again, you need to get this data off the card sometimes for things like glReadPixels or XGetImage, but that should really be done with DMA, or a proper memcpy at minimum. Think of it as manual cache management. Block transfers are fairly quick, and modifying data within a memory domain is really fast, but single-word updates between domains are just painful. So I guess to answer your question, memory outside the BAR is fine to only use for textures, because if the host really wants to modify them it should do so only between DFS and UTS pairs, and presumably the GPU can use its entire address space for DMA sources and targets rather than just only the range visible through the PCI bus aperture. - ajax pgpxozj5uXT8l.pgp Description: PGP signature
Re: Mesa 6.4 release was: ([PATCH] Fix memory corruption in ycbcr texture swap)
On Sunday 09 October 2005 12:45, Sergio Monteiro Basto wrote: Just wondering since libdrm is to be imported into X.org tree, how this will be compiled on X.org monolithic tree ? The same as in 6.8: There will be a copy of libdrm in xc/extras/. - ajax pgpVlrriRmZq9.pgp Description: PGP signature
Re: where is libdrm
On Monday 10 October 2005 02:41, Vladimir Dergachev wrote: Stupid question - what is the official place to get libdrm from ? I read through the webpages (both mesa3d and DRI) and searched on Google, but I dont' seem to find it. http://dri.freedesktop.org/libdrm/ - ajax pgp6JcYlxiebT.pgp Description: PGP signature
Re: Linux OpenGL ABI discussion
On Thursday 29 September 2005 04:35, Dave Airlie wrote: I have to agree with Christoph, the libGL should be a one-size-fits-all and capable of loading drivers from any vendor, I'm not sure what is so hard about this apart from the fact that neither vendor has seemed willing to help out infrastructure on the basis of some belief that they shouldn't have to (maybe because they don't on Windows) or maybe because they don't want to be seen to collaborate on things there is hardly any major secrets in the libGL interface that should stop it... There is exactly one secret: how to go from GL entrypoint to driver dispatch table as fast as possible while still being thread-correct and etc. However this can be read right out of the compiled object with any reasonable disassembler, so it's not much of a secret. As far as I know idr did a lot of work recently on libGL so we can expose GL extensions for vendors like ATI without them having to ship their own driver (I'm not sure if ATI contributed anything more than a list of things needed).. I think he mentioned this was a bit more difficult for glx.. but I'm sure it should be possible... We already had this thread: http://lists.freedesktop.org/archives/dri-egl/2005-July/000565.html In particular, Andy's response about why they're uninterested in a common libGL is basically The Last Word on the subject. It would require that nvidia expend time, effort, and money to get to the same level of functionality they already have. This applies equally to any other IHV, and to ISVs like XiG and SciTech too for that matter. You can have whatever opinion you like about that stance, but it's simply an economic reality. It's also irrelevant. libGL simply needs to provide ABI guarantees. Specifying driver compatibility is outside the scope of the LSB. I would make the case that the sonumber for a libGL that supports OpenGL 2.0 should start with 1. DSO version numbers are for ABI changes, and OpenGL 2.0 is simply not backwards-incompatible with OpenGL 1.5 for the set of entrypoints they share. It's not like 2.0 changes the prototype for glEnd() or anything. So, 1.6. Or 1.10 or whatever, if we really think that people want to do more GL 1.x versions. I would also make the case that the LSB should in no case require an implementation to have features unavailable in open source. In particular, requiring GL 2.0 would be broken. Remember what the L stands for here. The deeper issue here is whether it's actually useful to require some minimum level of functionality even when large swaths of it will be software. If I don't have cube map support in hardware, do I really want to try it in software? Is that a useful experience for developers or for users? Perhaps what I would like is a new set of glGetString tokens that describe what version and extensions the hardware is actually capable of accelerating, rather than what the software supports. Because in some sense, advertising GL 2.0 on a Riva is so inaccurate as to be worse than lying. This is as far as I know how MS's OpenGL ICD system works, there is one frontend and your driver can expose extra things via it... It's not. MS's MCD (mini client driver) system had something like our current system, where you have one GL dispatch layer and the vender provides a driver that gets loaded by the system. In the ICD scheme, opengl32.dll (or whatever it is) is provided per-vendor. - ajax pgp6pMPXttBP8.pgp Description: PGP signature
Re: [DEPRECATION] Fullscreen entrypoints in DRI protocol
On Sunday 11 September 2005 18:29, Keith Whitwell wrote: Yes I believe it is dead and can should be removed. Nuked, despite the lack of commit email (nggh...) I'm debating whether this is worthy of a protocol number bump. The fallback paths in the 3d driver code seem to DTRT when fullscreen support is unavailable, so technically it can be disabled without breaking the API. The fun bit is that the DRI protocol number is defined in xf86dristr.h, which comes from Mesa in the monolith, so actually changing the protocol number requires committing to way more places and I'm tempted to not care. As always, input would be appreciated. - ajax pgpPPG2DaTJnV.pgp Description: PGP signature
Re: problem while installing Mesa
On Wednesday 21 September 2005 06:51, Vitaliy A. Matuschenko wrote: So i've decided to install libdrm manually. I've downloaded libdrm-1.0.3 but it also didn't want to install at any way. If you'd tell me how it failed to install I'd get it fixed. - ajax pgpzwjlJLapOw.pgp Description: PGP signature
Re: Wondering about PC graphics that implements SGI style virtual graphics
On Monday 12 September 2005 22:24, Tim Long wrote: I am wondering if any PC level hardware implements the same features? For the ones that don't what sort of performance impact does it take switch GL threads if the pipeline has to be flushed on a context switch. I am guessing that at least older style PC hardware designed for games would assume that the only openGL context (full screen first person shooter). 3dlabs cards have multiple hardware contexts. My understanding of nVidia cards is that they kinda have multiple hardware contexts. The newer Matrox cards might too. I think for all of these cases you're merely increasing the number of hardware contexts from one to (say) eight, so you'll still have to switch contexts sometimes. You don't necessarily have to flush the pipeline on hardware context switch. You just need to resynchronize the state on the card with the state of the context you're switching to. - ajax pgpbNyLFKzO73.pgp Description: PGP signature
Re: drm ioctl flags cleanup
On Friday 02 September 2005 23:00, Dave Airlie wrote: With the root only/master split the flags looked ugly Any objections to a cleanup along the lines of this patch? None here. +1. - ajax pgprCu1OkanLe.pgp Description: PGP signature
Re: Xorg Mesa update.
On Tuesday 06 September 2005 16:09, Thomas Hellström wrote: Hi! What are the procedures of updating the Mesa code in Xorg for the upcoming 6.9/7.0 release? Current situation is that a change was made to the unichrome DDX which required changes to Mesa, which went into Mesa CVS but apparently not into Xorg, since the Xorg 6.9 unichrome_dri.so is not working? If you must commit to extras/Mesa/ in xc, do so on the MESA branch, and _only_ on that branch. ie: cvs -d...:/cvs/xorg co -r MESA xc cd xc/extras/Mesa # make your changes cvs commit Please make sure that the only changes you apply this way are changes that are already in Mesa, and in particular are in the 6.4 branch of Mesa, since that's what we'll be importing on the next apocalypse day. - ajax pgpAwQJd8D32G.pgp Description: PGP signature
Re: _glthread_TSD problem [was: display lists broken in Mesa maybe due to glapi dispatch changes (?), and an Xthreads problem]
On Tuesday 30 August 2005 11:31, Ian Romanick wrote: Daniel Stone wrote: On Mon, 2005-08-01 at 09:37 -0700, Ian Romanick wrote: The only way this could happen is if *both* PTHREADS and XTHREADS are defined. I suspect the Xthreads.h problem was always there, but it was never hit because XTHREADS was never defined. Some how, somewhere, XTHREADS is getting set. I'll have to look into it, but I think this is a bug in whatever X.org header is defining XTHREADS for us. :( Yes, you're spot on about PTHREADS and XTHREADS both being defined. XlibConf.h now defines XTHREADS if we're using it, the consensus being that if you're using X11/Xlibint.h, you deserve everything you get. Which I consider to be a bug, but apparently I'm the only one. If I wanted XTHREADS support, I'd ask for it. You _have_ to have it defined correctly. The Xlib ABI changes based on whether it was built with XTHREADS support. We didn't have to define XTHREADS in an installed header file in the monolith because everything was built in the same pass and imake would define it for us. This is no longer the case. The s/XTHREADS/USE_/ conversion is correct, to the extent that it lets you choose whether your libGL is threadsafe. Whether we should allow people to do that is perhaps debatable. - ajax pgpY0xnqVTGv4.pgp Description: PGP signature
libdrm [was Re: GRONK???]
On Thursday 18 August 2005 16:38, Alan Grimes wrote: [notice the path names and nearly identical files] So what's the story here? The copy in libdrm is canonical. The versions in xc and in Mesa are clones. They all go away in about five hours when I switch the DRI build to requiring libdrm. - ajax pgpMtJ8euK6We.pgp Description: PGP signature
Re: Xegl on old hardware?
On Sunday 14 August 2005 16:59, Roland Scheidegger wrote: Those are quite stiff requirements though. None of the old chips support all of that fully. Especially ARB_texture_env_combine (or even the EXT variant) could be tricky. I'm not sure what parts of it Xegl really needs, but on something like the plain rage 128 (can't even do normal GL_BLEND in all cases) you could probably easily end up with software fallbacks most of the time. Or, take a look at the voodoo3 driver, which has the most strange tex combine setup ever (confusing as hell, set up very unobvious, it's unclear to me though if the hardware capabilities are really exposed that strange, if the driver is written in an odd way or if glide acts as an obfuscation layer). It has fixed setups for BOTH texture environments combined! Hard to tell if it would support ARB_texture_env_combine somewhat reasonably, the driver at least certainly would need a rewrite in that area at least if it indeed does. And, of course, some otherwise not too bad chips like the g200 can't even do multitexturing :-(. The voodoo really isn't that weird, glide's just a pain. It may not be able to do all of texture_env_combine in hardware, but it does (or, can) alpha blend on normal framebuffer writes (both CPU-driven and blit-driven), so if you separate out the math for the various Render operations you can multipass it. Likewise I'm fairly confident that you can do at least the simple masked blends even on 1TMU hardware if you have render-to-texture functionality. That's easy enough to do in EXA, you just create the surfaces you'll need ahead of time during PrepareComposite. Doing that from GL requires FBOs or similar. Granted this is harder than just multitexturing, which is probably why no one's tried to do it yet. - ajax pgpxp8rwgRi2P.pgp Description: PGP signature
Re: Xegl on old hardware?
On Sunday 14 August 2005 09:59, Philipp Klaus Krause wrote: What are the minimum requirements of Xegl in terms of extensions supported? Not much. See http://freedesktop.org/wiki/Software/Xgl, but the major requirements are: NV_texture_rectangle ARB_texture_border_clamp ARB_multitexture ARB_texture_env_combine Which modifications to a driver are necessary for EGL? Wich parts of the driver (DRM, fb, DRI) have to be modified? The drm/fb layer has to be smart enough to set video modes, and the DRI driver needs some new entrypoints to translate that functionality to the EGL_MESA_screen_surface extension. Will Xegl run fast enough on old hardware like the RagePro 3D or the SiS 305 or Sis 6326? Well no one has tried, so no one knows yet. mach64 will likely have correctness issues due to its craptastic alpha combiner. I would expect acceptable (for some value of acceptable) performance for cards at about the voodoo3 or rage128 level, and anything below that really depends on how clever the driver is and whether the hardware has useful features we can take advantage of. I'm hoping to get back to hacking on EGL stuff once 7.0 lands. - ajax pgpiDuwe3nzL1.pgp Description: PGP signature
Re: Xegl on old hardware?
On Sunday 14 August 2005 14:15, Philipp Klaus Krause wrote: Adam Jackson schrieb: NV_texture_rectangle This shouldn't be really necessary if one is willing to waste some texture memory. In some cases, quite a lot of memory. A 513x513 texture wastes between 1.5 and 3M of memory depending on your color depth. You could offset this some by artificially lowering the maximum texture size. That's probably not a terrible idea for a tunable anyway, since a few older cards have fairly small texture caches and 512^2 textures will basically defeat them. ARB_multitexture OK. Everything except the SiS 6326 should supports it, though I don't know about mach64 (the driver has the extension, but I don't think the hardware has really more than one texture unit). There's a lot of cards that don't support this, just not many that we have drivers for. Pretty sure the virge and savage3d don't really support this, for example. Maybe I'll see if I can get Xgl eunning on the r128 or some other older card. Try the Xglx server first. In the steady state (not moving the Xglx window) your performance should be within a wild-assed guess of about 10-20% of what you might see from Xegl. To be accurate, Xegl relative to Xglx eliminates a few round trips for things like drawable and context creation, clip list updates, and buffer swaps. Those aren't often the bottleneck. Also you wouldn't have your classic DDX chewing up card memory for offscreen pixmaps, which you might be able to work around with suitable use of XAA options. This is not meant to discourage, we really do want to know where the cutoff point is for tolerable performance on older cards. But Xglx will give you a reasonable idea of what's possible. And it's the same driver for both GLX and EGL, so improvements to the one side help the other side too. - ajax pgpBpUamxQQsJ.pgp Description: PGP signature
Re: AAAARRRGH!!!
On Thursday 28 July 2005 01:09, Alan Grimes wrote: I spent all day dl'ing and installing: # This is a pre-release version of the The X.Org Foundation X11. X Window System Version 6.8.99.1 # And my reward for spending $40 on a card that appeared to be supported by Linux? Why you installed a prerelease version of X, to get support for a card (9250, right?) that was definitely supported in the last release, is a bit of a mystery. Why you also chose to install 6.8.99.1 when the snapshots are up to about 6.8.99.15 is more of a mystery. libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering This, however, is no mystery. The 2D driver in Xorg enables color tiling by default, but the bundled DRI driver doesn't understand color tiling yet. This will be fixed in 7.0, in the meantime: Option ColorTiling off - ajax pgpQrfxe2uUh0.pgp Description: PGP signature
Re: Build DRI exactly like X needs
On Tuesday 12 July 2005 10:03, Jon Smirl wrote: Is there a way to build DRI exactly like X needs from the mesa tree or can this only be done instead the X tree? If I made the right set of stubs could I build in the mesa tree? Do I need to define GLX_BUILT_IN_XMESA? Huh? How is 'make linux-dri' insufficient? - ajax pgplANb2W9RP0.pgp Description: PGP signature
Re: Build DRI exactly like X needs
On Tuesday 12 July 2005 11:17, Jon Smirl wrote: On 7/12/05, Adam Jackson [EMAIL PROTECTED] wrote: On Tuesday 12 July 2005 10:03, Jon Smirl wrote: Is there a way to build DRI exactly like X needs from the mesa tree or can this only be done instead the X tree? If I made the right set of stubs could I build in the mesa tree? Do I need to define GLX_BUILT_IN_XMESA? Huh? How is 'make linux-dri' insufficient? If I follow all of the make files it looks like linux-dri is using a glx from the mesa tree instead of the one from xorg. That's what GLX_BUILT_IN_XMESA controls. The imake files turn it on: lib/GL/glx/Imakefile: XMESA_DEFINES = -DGLX_BUILT_IN_XMESA lib/GL/mesa/drivers/x11/Imakefile: XMESA_DEFINES = -DGLX_BUILT_IN_XMESA The glx from the Mesa tree is the GLX client side library. It used to live in xc; now it doesn't. src/glx/x11 is the canonical location for the GLX client library. It is, in other words, exactly what X needs. - ajax pgpelsbNyI3v1.pgp Description: PGP signature
libdrm 1.0
http://people.freedesktop.org/~ajax/libdrm/libdrm-1.0.0.gz I'll soon be switching Mesa to require this to build the DRI drivers and the DRI-capable libGL. This means you need pkg-config. This also means we can get rid of the copy of the drm source in drivers/dri/dri_client, and after installing this you won't need a drm CVS checkout to build the drivers. This will also be where the modular X server gets the drm support headers from. You probably want to install it as a system library, which means ./configure --prefix=/usr --exec-prefix=/ The headers from shared-core are in there too. I'm not sure it's the best place to put them, but having them in a shared versioned module is much better than the skew we have currently. - ajax pgpSQriSMdHVR.pgp Description: PGP signature
Re: Current DRM CVS ?
On Monday 11 July 2005 11:01, Vladimir Dergachev wrote: Hi all, Would anyone know which DRM CVS tree I should submit patches against ? I wanted to give a try at making a patch with R300 DRM driver changes as the source has mostly stabilized. I didn't know there was more than one. /cvs/dri co drm - ajax pgp7m1ZuqApK4.pgp Description: PGP signature
Re: Current DRM CVS ?
On Monday 11 July 2005 13:29, Vladimir Dergachev wrote: On Mon, 11 Jul 2005, Adam Jackson wrote: I didn't know there was more than one. /cvs/dri co drm Thank you ! What about code that Jon is working on ? Is it in ? If his changes aren't in CVS then I don't know where they are. Jon would have to answer that. - ajax pgpFRnHXeBHel.pgp Description: PGP signature
Re: DRI vs DRM
On Sunday 03 July 2005 12:31, Jon Smirl wrote: On 7/3/05, Adam Jackson [EMAIL PROTECTED] wrote: Shouldn't this just be a string you pull right out of a drm ioctl? I know the name currently lives in the server, but as with many things the server does I think that's a mistake. Binding EGL driver load to sysfs is not portable. The code is only in my Linux drivers. In your EGL app you specify something like :0. The generic code is wired to always load dri_egl.so for the :? syntax. dri_egl then figures out which screen corresponds to :0 and looks for the DRM sysfs entry. It then uses that to load the right DRI driver and passes control over. Why aren't the DRI drivers themselves EGL drivers? That's sort of the model I was anticipating: - eglChooseDisplayMESA(display/0) - EGL translates to /dev/dri/card0, opens it - ioctl: what's the DRI driver name for this device? - kernel: i915 - EGL loads i915_dri.so, calls its egl setup - eglCreateContext notices the attached dri driver, does device setup I guess I don't see the point of loading one module to have it load another, particularly if that first module is always getting loaded. On Linux sysfs attributes and ioctls are very similar. It is now preferred on Linux to get simple things like this from a sysfs attribute instead of an ioctl since the sysfs attributes avoid 32/64 and endian issues. It is also easy for a human to see which driver the DRM module needs. The human should never have to care. There's going to need to be an ioctl for this _anyway_ if anyone ever implements this on non-Linux. We should really be avoiding OS-specific code paths in the driver as much as possible. That's why we have the abstract DRM interface to begin with. - ajax pgpTWRV79UQ9l.pgp Description: PGP signature
Re: DRI vs DRM
On Sunday 03 July 2005 18:40, Brian Paul wrote: I said I'd like to keep the src/egl/main/ directory cross-platform. The Linux version of libEGL.so could certainly have additional code in it. But I'm certainly open to ideas. I just don't have much time to spend on this project. I'm still not entirely convinced the EGL API belongs anywhere but libGL. Is there a strong motivator for libEGL? - ajax pgpVyyoLy0wXr.pgp Description: PGP signature
Re: DRI vs DRM
On Sunday 03 July 2005 00:04, Jon Smirl wrote: Is this table right? DRMDRI ffb ffb i810i830 i830i830 i915i915 With the caveat that i830 is old and deprecated. There are three DRI drivers with no DRM. What is up with these? gamma s3v trident The gamma drm was axed for being incurably ugly. The s3v and trident DRMs exist in 2.4-style form in old CVS branches but no one's brought them forward yet. I brought the DRI drivers forward as an exercise, and because the Mesa changes were the hard part, the DRM and DDX should be trivial if anyone wants to expend the effort. I don't have a trident yet, but far too many virges, so I should get to that one eventually. During the EGL driver load process it checks /sys/drm/* looking for card? entries. When it finds one I need a sysfs attribute in /sys/drm/card?/dri to tell me which dri library to load. Shouldn't this just be a string you pull right out of a drm ioctl? I know the name currently lives in the server, but as with many things the server does I think that's a mistake. Binding EGL driver load to sysfs is not portable. - ajax pgp4ljclNLQ8C.pgp Description: PGP signature
Re: [R300] drm driver: merge upstream, security, etc
On Sunday 26 June 2005 21:51, Eric Anholt wrote: Heh. One of the suggestions of BSD style is that when 80 columns becomes too little, you probably need another function. In the diff I'm currently testing for cleaning up map handling (which net removes 200 lines), I've removed that if statement that didn't need to exist (afaict), and split the find-the-map bits into another function. I think it's quite improved. Likewise, from linux/Documentation/CodingStyle: # Now, some people will claim that having 8-character indentations makes # the code move too far to the right, and makes it hard to read on a # 80-character terminal screen. The answer to that is that if you need # more than 3 levels of indentation, you're screwed anyway, and should fix # your program. # # In short, 8-char indents make things easier to read, and have the added # benefit of warning you when you're nesting your functions too deep. # Heed that warning. I've got more horizontal screen space than jesus, and I still can't fit two 120-column terminals side by side on the same monitor. I'm casting my vote for staying with 80 columns. - ajax pgpb8CniCqXbl.pgp Description: PGP signature
Re: Removing the root priv requirement from DRM
On Monday 20 June 2005 00:03, Jon Smirl wrote: On 6/18/05, Adam Jackson [EMAIL PROTECTED] wrote: Obviously determining which sets of registers can be mapped through the drm is a card-by-card problem. Different cards have different register maps, by definition. But the DRI drivers work as a normal user _right_ _now_, and (modulo mach64 and possibly r300) they seem to be secure. There are more security holes than just restricting AddMap. If a normal user has register access to some cards (like the radeon), they can program the DMA controller to write into system RAM. You can use the ability to write into system RAM to gain root priv. I don't think we have good enough docs on any of the cards to says with 100% certainty that it is safe to allow a normal user access to the registers. You still sound really confused here. You say there are more holes than just AddMap, but then go on to describe the hole in AddMap. The DMA controller doesn't just magically show up in a process' address space. It has to have been set up first, either through drmAddMap from a process running as root (and subsequent authorization and drmMap sequence), or from DRM setup (and auth and drmMap). - ajax pgp7pQ1Q9v8ic.pgp Description: PGP signature
Re: Removing the root priv requirement from DRM
On Saturday 18 June 2005 11:20, Jon Smirl wrote: Access to the registers is something that should require root priv right? Once I can get to the registers I can program them to contol the DMA hardware and then muck with the kernel's memory and escalate my priveldge level. EGL avoids this possible hole by not using the registers from user space. Not all register access should require root. In fact you want to do as much as possible directly from userspace because shuffling large amounts of data into the kernel is painful. So what you need to restrict are those registers which can trigger reads and writes from arbitrary system memory bypassing the MMU, which basically means anything that can trigger bus-master writes or DMA. The point to notice here is that these registers generally segmented apart in the card's memory map. If all those trigger regs are within a single 4k range, then that's the only range you need to hide from userspace. EGL really has nothing to do with this, it's entirely a driver issue. My solution would be to leave the permament maps visible and then add a root capability check when someone attempts to drmMap the registers. It would more complex to try and hide the map from GetMap. That's the whole point of the authmagic mechanism. The client gets a magic number from the kernel via drmGetMagic, and passes that up to the server in the XF86DRIAuthConnection call. The server checks that the client is properly authenticated, and tells the DRM to allow that magic number full authenticated (but not root-level) DRM access. The drm API really has three parts: base, authenticated, and master. drmMap is part of the authenticated API, so there's no need to add any additional hiding. Any sensitive register ranges would just be unavailable through drmMap and accessible only from the kernel side, and the safe ranges would only be available after a GetMagic/AuthConnection cycle. I haven't gotten to where I need to AddMap sarea. Can we prebuild a permanent map for it too? You could; I'm not sure you want to. In principle it should get charged to the DRM master process. But it's like two pages, not a huge deal either way. Right now I'm blocked on the AuthMagic call needing root. Of the master-level API, I think only drmAddMap really needs to be restricted to root (to the extent it should exist at all). The rest can be made available to only the first DRM client to start (the server, presumably). I'm not entirely comfortable with that, but I can't completely articulate why yet... - ajax pgpuTXxvkbd7N.pgp Description: PGP signature
Re: radeon DST_LINE
On Saturday 18 June 2005 13:38, Jerome Glisse wrote: On 6/18/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: On Sat, 18 Jun 2005, Jerome Glisse wrote: DST_LINE_START 0x1600 DST_LINE_END 0x1604 (from radeon fb) From the name, I guess that they initiate line drawing in 2d engine. I think it's more than that...but i maybe wrong, depending on value i put in it the lockup on 9800 can take a bit much time to appear...i haven't done statistic on that an thus i could be a feel more than a true a reality... The DDX uses them for the start and end coordinates of Bresenham lines. I have trouble believing they could be anything else. - ajax pgpLLab0LyiHl.pgp Description: PGP signature
