[PATCH 0/7] handle detailed timing operation
Hi FengGuan, Thanks for your feedback, based on which I have updated the patchs. [PATCH 1/7] Includes some new structures and defined MACRO in edid.h. [PATCH 2/7] implement detailed timing unified interface in interpret_edid.c [PATCH 3/7] implement detailed timing operation in interpret_edid.c [PATCH 4/7] handle detailed timing operation in xf86EdidModes.c [PATCH 5/7] handle detailed timing operation in xf86Crtc.c [PATCH 6/7] handle detailed timing operation in xf86Configure.c [PATCH 7/7] handle detailed timing operation in print_edid.c Any comments are welcome ! Thanks Ma Ling ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 1/7] Includes some new structures and defined MACRO in edid.h
defined corresponding structure and MACRO for detailed timing operation
---
hw/xfree86/ddc/edid.h | 76 +
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/ddc/edid.h b/hw/xfree86/ddc/edid.h
index 31bc7c1..bb5616f 100644
--- a/hw/xfree86/ddc/edid.h
+++ b/hw/xfree86/ddc/edid.h
@@ -553,4 +553,80 @@ typedef struct {
extern _X_EXPORT xf86MonPtr ConfiguredMonitor;
+#define CEA_EXT 0x02
+#define VTB_EXT 0x10
+#define DI_EXT0x40
+#define LS_EXT0x50
+#define MI_EXT0x60
+
+#define CEA_EXT_MIN_DATA_OFFSET 4
+#define CEA_EXT_MAX_DATA_OFFSET 127
+#define CEA_EXT_DET_TIMING_NUM 6
+
+#define EXT_TAG 0
+#define EXT_REV 1
+
+struct cea_video_blk {
+ Uchar video_code;
+};
+
+struct cea_audio_blk {
+ Uchar descs[3];
+};
+
+struct vendor_hdmi {
+ Uchar support_flags;
+ Uchar max_tmds_clock;
+ Uchar latency_present;
+ Uchar video_latency;
+ Uchar audio_latency;
+ Uchar interlaced_video_latency;
+ Uchar interlaced_audio_latency;
+};
+
+struct cea_vendor_blk {
+ unsigned char ieee_id[3];
+ Uchar portB:4;
+ Uchar portA:4;
+ Uchar portD:4;
+ Uchar portC:4;
+ struct vendor_hdmi hdmi;
+};
+
+struct cea_speaker_blk
+{
+ Uchar FLR:1;
+ Uchar LFE:1;
+ Uchar FC:1;
+ Uchar RLR:1;
+ Uchar RC:1;
+ Uchar FLRC:1;
+ Uchar RLRC:1;
+ Uchar FLRW:1;
+ Uchar FLRH:1;
+ Uchar TC:1;
+ Uchar FCH:1;
+ Uchar Resv:5;
+ Uchar ResvByte;
+};
+
+struct cea_data_blk {
+ Uchar len:5;
+ Uchar tag:3;
+ union{
+struct cea_video_blk video;
+struct cea_audio_blk audio;
+struct cea_vendor_blk vendor;
+struct cea_speaker_blk speaker;
+ }u;
+};
+
+struct cea_ext_body {
+ Uchar tag;
+ Uchar rev;
+ Uchar dt_offset;
+ Uchar flags;
+ struct cea_data_blk data_collection;
+};
+
#endif /* _EDID_H_ */
--
1.5.4.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 2/7]implement detailed timing unified interface in interpret_edid.c
create unified interface for detail timing operation.
---
hw/xfree86/ddc/interpret_edid.c | 64 +++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index 0438449..2002cd5 100644
--- a/hw/xfree86/ddc/interpret_edid.c
+++ b/hw/xfree86/ddc/interpret_edid.c
@@ -95,6 +95,70 @@ handle_edid_quirks(xf86MonPtr m)
}
}
+static int get_cea_detail_timing(Uchar *blk, xf86MonPtr mon,
+ struct detailed_monitor_section *det_mon)
+{
+int dt_num;
+int dt_offset = ((struct cea_ext_body *)blk)->dt_offset;
+
+dt_num = 0;
+
+if (dt_offset < CEA_EXT_MIN_DATA_OFFSET)
+return dt_num;
+
+for (; dt_offset < (CEA_EXT_MAX_DATA_OFFSET - DET_TIMING_INFO_LEN) &&
+ dt_num < CEA_EXT_DET_TIMING_NUM;
+ _NEXT_DT_MD_SECTION(dt_offset)) {
+
+fetch_detailed_block(blk + dt_offset, &mon->ver, det_mon + dt_num);
+dt_num = dt_num + 1 ;
+}
+
+return dt_num;
+}
+
+static void handle_cea_detail_block(Uchar *ext, xf86MonPtr mon,
+handle_detailed_fn fn,
+void *data)
+{
+int i;
+struct detailed_monitor_section det_mon[CEA_EXT_DET_TIMING_NUM];
+int det_mon_num;
+
+det_mon_num = get_cea_detail_timing(ext, mon, det_mon);
+
+for (i = 0; i < det_mon_num; i++)
+fn(det_mon + i, data);
+}
+
+void xf86ForEachDetailedBlock(xf86MonPtr mon,
+ handle_detailed_fn fn,
+ void *data)
+{
+int i;
+Uchar *ext;
+
+if (mon == NULL)
+return;
+
+for (i = 0; i < DET_TIMINGS; i++)
+fn(mon->det_mon + i, data);
+
+for (i = 0; i < mon->no_sections; i++) {
+ext = mon->rawData + EDID1_LEN * (i + 1);
+switch (ext[EXT_TAG]){
+case CEA_EXT:
+handle_cea_detail_block(ext, mon, fn, data);
+break;
+case VTB_EXT:
+case DI_EXT:
+case LS_EXT:
+case MI_EXT:
+ break;
+}
+}
+}
+
struct det_hv_parameter {
int real_hsize;
int real_vsize;
--
1.5.4.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 2/7] implement detailed timing operation in interpret_edid.c
Sorry, please use it to replace "[PATCH 2/7]implement detailed timing unified
interface in interpret_edid.c" sent early.
In this file handle detailed timing operation in interpret_edid.c
---
hw/xfree86/ddc/interpret_edid.c | 242 ++-
1 files changed, 138 insertions(+), 104 deletions(-)
diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index c0e3df9..0438449 100644
--- a/hw/xfree86/ddc/interpret_edid.c
+++ b/hw/xfree86/ddc/interpret_edid.c
@@ -41,8 +41,11 @@ static void get_display_section(Uchar*, struct disp_features
*,
static void get_established_timing_section(Uchar*, struct established_timings
*);
static void get_std_timing_section(Uchar*, struct std_timings *,
struct edid_version *);
+
+static void fetch_detailed_block(Uchar *c, struct edid_version *ver,
+ struct detailed_monitor_section *det_mon);
static void get_dt_md_section(Uchar *, struct edid_version *,
- struct detailed_monitor_section *det_mon);
+ struct detailed_monitor_section *det_mon);
static void copy_string(Uchar *, Uchar *);
static void get_dst_timing_section(Uchar *, struct std_timings *,
struct edid_version *);
@@ -52,11 +55,25 @@ static void get_detailed_timing_section(Uchar*, struct
detailed_timings *);
static Bool validate_version(int scrnIndex, struct edid_version *);
static void
+find_ranges_section(struct detailed_monitor_section *det, void *ranges)
+{
+ if (det->type == DS_RANGES && det->section.ranges.max_clock)
+ *(struct monitor_ranges **)ranges = &det->section.ranges;
+}
+
+static void
+find_max_detailed_clock(struct detailed_monitor_section *det, void *ret)
+{
+if (det->type == DT) {
+*(int *)ret = max(*((int *)ret),
+ det->section.d_timings.clock);
+}
+}
+
+static void
handle_edid_quirks(xf86MonPtr m)
{
-int i, j;
-struct detailed_timings *preferred_timing;
-struct monitor_ranges *ranges;
+struct monitor_ranges *ranges = NULL;
/*
* max_clock is only encoded in EDID in tens of MHz, so occasionally we
@@ -64,28 +81,49 @@ handle_edid_quirks(xf86MonPtr m)
* similar. Strictly we should refuse to round up too far, but let's
* see how well this works.
*/
-for (i = 0; i < 4; i++) {
- if (m->det_mon[i].type == DS_RANGES) {
- ranges = &m->det_mon[i].section.ranges;
- for (j = 0; j < 4; j++) {
- if (m->det_mon[j].type == DT) {
- preferred_timing = &m->det_mon[j].section.d_timings;
- if (!ranges->max_clock) continue; /* zero is legal */
- if (ranges->max_clock * 100 < preferred_timing->clock) {
- xf86Msg(X_WARNING,
- "EDID preferred timing clock %.2fMHz exceeds "
- "claimed max %dMHz, fixing\n",
- preferred_timing->clock / 1.0e6,
- ranges->max_clock);
- ranges->max_clock =
- (preferred_timing->clock+99)/100;
- return;
- }
- }
- }
- }
+
+/* Try to find Monitor Range and max clock, then re-set range value*/
+xf86ForEachDetailedBlock(m, find_ranges_section, &ranges);
+if (ranges && ranges->max_clock) {
+int clock = 0;
+xf86ForEachDetailedBlock(m, find_max_detailed_clock, &clock);
+if (clock && (ranges->max_clock * 1e6 < clock)) {
+xf86Msg(X_WARNING, "EDID timing clock %.2f exceeds claimed max "
+"%dMHz, fixing\n", clock / 1.0e6, ranges->max_clock);
+ranges->max_clock = (clock+99)/1e6;
+}
}
+}
+
+struct det_hv_parameter {
+int real_hsize;
+int real_vsize;
+float target_aspect;
+};
+static void handle_detailed_hvsize(struct detailed_monitor_section *det_mon,
+ void *data)
+{
+struct det_hv_parameter *p = (struct det_hv_perameter *)data;
+float timing_aspect;
+
+if (det_mon->type == DT) {
+struct detailed_timings *timing;
+timing = &det_mon->section.d_timings;
+
+if (!timing->v_size)
+return;
+
+timing_aspect = (float)timing->h_size / timing->v_size;
+if (fabs(1 - (timing_aspect / p->target_aspect)) < 0.05) {
+p->real_hsize = max(p->real_hsize, timing->h_size);
+p->real_vsize = max(p->real_vsize, timing->v_size);
+}
+}
+}
+
+static void encode_aspect_ratio(xf86MonPtr m)
+{
/*
* some monitors encode the aspect ratio instead of the physical size.
* try to find the largest detailed timing that matches that aspect
@@ -95,36 +133,24 @@ handle_edid_quirks(xf86MonPtr m)
(m->features.hsize == 1
[PATCH 3/7]implement detailed timing unified interface in interpret_edid.
create unified interface for detail timing operation.
---
hw/xfree86/ddc/interpret_edid.c | 64 +++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index 0438449..2002cd5 100644
--- a/hw/xfree86/ddc/interpret_edid.c
+++ b/hw/xfree86/ddc/interpret_edid.c
@@ -95,6 +95,70 @@ handle_edid_quirks(xf86MonPtr m)
}
}
+static int get_cea_detail_timing(Uchar *blk, xf86MonPtr mon,
+ struct detailed_monitor_section *det_mon)
+{
+int dt_num;
+int dt_offset = ((struct cea_ext_body *)blk)->dt_offset;
+
+dt_num = 0;
+
+if (dt_offset < CEA_EXT_MIN_DATA_OFFSET)
+return dt_num;
+
+for (; dt_offset < (CEA_EXT_MAX_DATA_OFFSET - DET_TIMING_INFO_LEN) &&
+ dt_num < CEA_EXT_DET_TIMING_NUM;
+ _NEXT_DT_MD_SECTION(dt_offset)) {
+
+fetch_detailed_block(blk + dt_offset, &mon->ver, det_mon + dt_num);
+dt_num = dt_num + 1 ;
+}
+
+return dt_num;
+}
+
+static void handle_cea_detail_block(Uchar *ext, xf86MonPtr mon,
+handle_detailed_fn fn,
+void *data)
+{
+int i;
+struct detailed_monitor_section det_mon[CEA_EXT_DET_TIMING_NUM];
+int det_mon_num;
+
+det_mon_num = get_cea_detail_timing(ext, mon, det_mon);
+
+for (i = 0; i < det_mon_num; i++)
+fn(det_mon + i, data);
+}
+
+void xf86ForEachDetailedBlock(xf86MonPtr mon,
+ handle_detailed_fn fn,
+ void *data)
+{
+int i;
+Uchar *ext;
+
+if (mon == NULL)
+return;
+
+for (i = 0; i < DET_TIMINGS; i++)
+fn(mon->det_mon + i, data);
+
+for (i = 0; i < mon->no_sections; i++) {
+ext = mon->rawData + EDID1_LEN * (i + 1);
+switch (ext[EXT_TAG]){
+case CEA_EXT:
+handle_cea_detail_block(ext, mon, fn, data);
+break;
+case VTB_EXT:
+case DI_EXT:
+case LS_EXT:
+case MI_EXT:
+ break;
+}
+}
+}
+
struct det_hv_parameter {
int real_hsize;
int real_vsize;
--
1.5.4.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 4/7] handle detailed timing operation in xf86EdidModes.c
handled detailed timing operation .e.g extract detailed timing modes from EDID
and cea ext,
then insert mode list.
---
hw/xfree86/ddc/xf86DDC.h | 44 ++
hw/xfree86/modes/xf86EdidModes.c | 278 --
2 files changed, 189 insertions(+), 133 deletions(-)
diff --git a/hw/xfree86/ddc/xf86DDC.h b/hw/xfree86/ddc/xf86DDC.h
index 07411b8..0f4f65f 100644
--- a/hw/xfree86/ddc/xf86DDC.h
+++ b/hw/xfree86/ddc/xf86DDC.h
@@ -62,4 +62,48 @@ extern _X_EXPORT DisplayModePtr xf86DDCGetModes(int
scrnIndex, xf86MonPtr DDC);
extern _X_EXPORT Bool
xf86MonitorIsHDMI(xf86MonPtr mon);
+/*
+ * Quirks to work around broken EDID data from various monitors.
+ */
+typedef enum {
+DDC_QUIRK_NONE = 0,
+/* First detailed mode is bogus, prefer largest mode at 60hz */
+DDC_QUIRK_PREFER_LARGE_60 = 1 << 0,
+/* 135MHz clock is too high, drop a bit */
+DDC_QUIRK_135_CLOCK_TOO_HIGH = 1 << 1,
+/* Prefer the largest mode at 75 Hz */
+DDC_QUIRK_PREFER_LARGE_75 = 1 << 2,
+/* Convert detailed timing's horizontal from units of cm to mm */
+DDC_QUIRK_DETAILED_H_IN_CM = 1 << 3,
+/* Convert detailed timing's vertical from units of cm to mm */
+DDC_QUIRK_DETAILED_V_IN_CM = 1 << 4,
+/* Detailed timing descriptors have bogus size values, so just take the
+ * maximum size and use that.
+ */
+DDC_QUIRK_DETAILED_USE_MAXIMUM_SIZE = 1 << 5,
+/* Monitor forgot to set the first detailed is preferred bit. */
+DDC_QUIRK_FIRST_DETAILED_PREFERRED = 1 << 6,
+/* use +hsync +vsync for detailed mode */
+DDC_QUIRK_DETAILED_SYNC_PP = 1 << 7,
+/* Force single-link DVI bandwidth limit */
+DDC_QUIRK_DVI_SINGLE_LINK = 1 << 8,
+} ddc_quirk_t;
+
+DisplayModePtr xf86DDCGetModes(int scrnIndex, xf86MonPtr DDC);
+
+extern Bool
+xf86MonitorIsHDMI(xf86MonPtr mon);
+
+typedef void (* handle_detailed_fn)(struct detailed_monitor_section *,void *);
+
+void xf86ForEachDetailedBlock(xf86MonPtr mon,
+ handle_detailed_fn,
+ void *data);
+
+ddc_quirk_t
+xf86DDCDetectQuirks(int scrnIndex, xf86MonPtr DDC, Bool verbose);
+
+void xf86DetTimingApplyQuirks(struct detailed_monitor_section *det_mon,
+ ddc_quirk_t quirks, int hsize, int vsize);
+
#endif
diff --git a/hw/xfree86/modes/xf86EdidModes.c b/hw/xfree86/modes/xf86EdidModes.c
index 1413e87..da304a0 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -45,20 +45,23 @@
#include
#include
+static void handle_detailed_rblank(struct detailed_monitor_section *det_mon,
+ void *data)
+{
+if (det_mon->type == DS_RANGES)
+if (det_mon->section.ranges.supported_blanking & CVT_REDUCED)
+*(Bool*)data = TRUE;
+}
+
static Bool
xf86MonitorSupportsReducedBlanking(xf86MonPtr DDC)
{
/* EDID 1.4 explicitly defines RB support */
if (DDC->ver.revision >= 4) {
- int i;
- for (i = 0; i < DET_TIMINGS; i++) {
- struct detailed_monitor_section *det_mon = &DDC->det_mon[i];
- if (det_mon->type == DS_RANGES)
- if (det_mon->section.ranges.supported_blanking & CVT_REDUCED)
- return TRUE;
- }
-
- return FALSE;
+Bool ret = FALSE;
+
+xf86ForEachDetailedBlock(DDC, handle_detailed_rblank, &ret);
+return ret;
}
/* For anything older, assume digital means RB support. Boo. */
@@ -68,34 +71,6 @@ xf86MonitorSupportsReducedBlanking(xf86MonPtr DDC)
return FALSE;
}
-/*
- * Quirks to work around broken EDID data from various monitors.
- */
-
-typedef enum {
-DDC_QUIRK_NONE = 0,
-/* First detailed mode is bogus, prefer largest mode at 60hz */
-DDC_QUIRK_PREFER_LARGE_60 = 1 << 0,
-/* 135MHz clock is too high, drop a bit */
-DDC_QUIRK_135_CLOCK_TOO_HIGH = 1 << 1,
-/* Prefer the largest mode at 75 Hz */
-DDC_QUIRK_PREFER_LARGE_75 = 1 << 2,
-/* Convert detailed timing's horizontal from units of cm to mm */
-DDC_QUIRK_DETAILED_H_IN_CM = 1 << 3,
-/* Convert detailed timing's vertical from units of cm to mm */
-DDC_QUIRK_DETAILED_V_IN_CM = 1 << 4,
-/* Detailed timing descriptors have bogus size values, so just take the
- * maximum size and use that.
- */
-DDC_QUIRK_DETAILED_USE_MAXIMUM_SIZE = 1 << 5,
-/* Monitor forgot to set the first detailed is preferred bit. */
-DDC_QUIRK_FIRST_DETAILED_PREFERRED = 1 << 6,
-/* use +hsync +vsync for detailed mode */
-DDC_QUIRK_DETAILED_SYNC_PP = 1 << 7,
-/* Force single-link DVI bandwidth limit */
-DDC_QUIRK_DVI_SINGLE_LINK = 1 << 8,
-} ddc_quirk_t;
-
static Bool quirk_prefer_large_60 (int scrnIndex, xf86MonPtr DDC)
{
/* Belinea 10 15 55 */
@@ -667,7 +642,7 @@ DDCGuessRangesFromModes(int scrnIndex, MonPtr Monitor,
DisplayModePtr Modes)
}
}
-static ddc_quirk_t
+ddc_quirk_t
xf86DDCDetectQuirks(int scrnIndex,
[PATCH 5/7] handle detailed timing operation in xf86Crtc.c
handle detailed timing operation,e.g. set up Monitor from detailed timing
block
from EDID and cea ext
---
hw/xfree86/modes/xf86Crtc.c | 128 ---
1 files changed, 83 insertions(+), 45 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index cb13deb..72f8f15 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -1530,6 +1530,40 @@ GuessRangeFromModes(MonPtr mon, DisplayModePtr mode)
mon->vrefresh[0].lo = 58.0;
}
+struct det_monrec_parameter {
+MonRec *mon_rec;
+int *max_clock;
+enum { sync_config, sync_edid, sync_default } *sync_source;
+};
+
+static void handle_detailed_monrec(struct detailed_monitor_section *det_mon,
+ void *data)
+{
+enum { sync_config, sync_edid, sync_default };
+struct det_monrec_parameter *p;
+p = (struct det_monrec_parameter *)data;
+
+if (det_mon->type == DS_RANGES) {
+struct monitor_ranges *ranges = &det_mon->section.ranges;
+if (p->mon_rec->nHsync == 0 && ranges->max_h) {
+p->mon_rec->hsync[p->mon_rec->nHsync].lo = ranges->min_h;
+p->mon_rec->hsync[p->mon_rec->nHsync].hi = ranges->max_h;
+p->mon_rec->nHsync++;
+if (*p->sync_source == sync_default)
+*p->sync_source = sync_edid;
+}
+if (p->mon_rec->nVrefresh == 0 && ranges->max_v) {
+p->mon_rec->vrefresh[p->mon_rec->nVrefresh].lo = ranges->min_v;
+p->mon_rec->vrefresh[p->mon_rec->nVrefresh].hi = ranges->max_v;
+p->mon_rec->nVrefresh++;
+if (*p->sync_source == sync_default)
+*p->sync_source = sync_edid;
+}
+if (ranges->max_clock * 1000 > *p->max_clock)
+*p->max_clock = ranges->max_clock * 1000;
+}
+}
+
void
xf86ProbeOutputModes (ScrnInfoPtr scrn, int maxX, int maxY)
{
@@ -1608,42 +1642,22 @@ xf86ProbeOutputModes (ScrnInfoPtr scrn, int maxX, int
maxY)
edid_monitor = output->MonInfo;
- if (edid_monitor)
- {
- int i;
- Boolset_hsync = mon_rec.nHsync == 0;
- Boolset_vrefresh = mon_rec.nVrefresh == 0;
- struct disp_features*features = &edid_monitor->features;
+if (edid_monitor)
+{
+struct det_monrec_parameter p;
+struct disp_features*features = &edid_monitor->features;
/* if display is not continuous-frequency, don't add default modes
*/
if (!GTF_SUPPORTED(features->msc))
add_default_modes = FALSE;
-
- for (i = 0; i < sizeof (edid_monitor->det_mon) / sizeof
(edid_monitor->det_mon[0]); i++)
- {
- if (edid_monitor->det_mon[i].type == DS_RANGES)
- {
- struct monitor_ranges *ranges =
&edid_monitor->det_mon[i].section.ranges;
- if (set_hsync && ranges->max_h)
- {
- mon_rec.hsync[mon_rec.nHsync].lo = ranges->min_h;
- mon_rec.hsync[mon_rec.nHsync].hi = ranges->max_h;
- mon_rec.nHsync++;
- if (sync_source == sync_default)
- sync_source = sync_edid;
- }
- if (set_vrefresh && ranges->max_v)
- {
- mon_rec.vrefresh[mon_rec.nVrefresh].lo = ranges->min_v;
- mon_rec.vrefresh[mon_rec.nVrefresh].hi = ranges->max_v;
- mon_rec.nVrefresh++;
- if (sync_source == sync_default)
- sync_source = sync_edid;
- }
- if (ranges->max_clock * 1000 > max_clock)
- max_clock = ranges->max_clock * 1000;
- }
- }
+
+p.mon_rec = &mon_rec;
+p.max_clock = &max_clock;
+p.sync_source = &sync_source;
+
+xf86ForEachDetailedBlock(edid_monitor,
+handle_detailed_monrec,
+&p);
}
if (xf86GetOptValFreq (output->options, OPTION_MIN_CLOCK,
@@ -2887,6 +2901,35 @@ xf86OutputSetEDIDProperty (xf86OutputPtr output, void
*data, int data_len)
#endif
+/* Pull out a phyiscal size from a detailed timing if available. */
+struct det_phySize_parameter {
+xf86OutputPtr output;
+ddc_quirk_t quirks;
+Bool ret;
+};
+
+static void handle_detailed_physical_size(struct detailed_monitor_section
+ *det_mon, void *data)
+{
+struct det_phySize_parameter *p;
+p = (struct det_phySize_parameter *)data;
+
+if (p->ret == TRUE )
+return ;
+
+xf86DetTimingApplyQuirks(det_mon, p->quirks,
+ p->output->M
PATCH 6/7] handle detailed timing operation in xf86Configure.c
handle detailed timing in xf86Configure.c
---
hw/xfree86/common/xf86Configure.c | 57
1 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/hw/xfree86/common/xf86Configure.c
b/hw/xfree86/common/xf86Configure.c
index b803b49..822b020 100644
--- a/hw/xfree86/common/xf86Configure.c
+++ b/hw/xfree86/common/xf86Configure.c
@@ -531,6 +531,36 @@ configureMonitorSection (int screennum)
return ptr;
}
+/* Initialize Configure Monitor from Detailed Timing Block */
+static void handle_detailed_input(struct detailed_monitor_section *det_mon,
+ void *data)
+{
+XF86ConfMonitorPtr ptr = (XF86ConfMonitorPtr) data;
+
+switch (det_mon->type) {
+case DS_NAME:
+ptr->mon_modelname = xf86confrealloc(ptr->mon_modelname,
+
strlen((char*)(det_mon->section.name)) +
+ 1);
+strcpy(ptr->mon_modelname,
+ (char*)(det_mon->section.name));
+break;
+case DS_RANGES:
+ptr->mon_hsync[ptr->mon_n_hsync].lo =
+det_mon->section.ranges.min_h;
+ptr->mon_hsync[ptr->mon_n_hsync].hi =
+det_mon->section.ranges.max_h;
+ptr->mon_n_vrefresh = 1;
+ptr->mon_vrefresh[ptr->mon_n_hsync].lo =
+det_mon->section.ranges.min_v;
+ptr->mon_vrefresh[ptr->mon_n_hsync].hi =
+det_mon->section.ranges.max_v;
+ptr->mon_n_hsync++;
+default:
+break;
+}
+}
+
static XF86ConfMonitorPtr
configureDDCMonitorSection (int screennum)
{
@@ -578,31 +608,8 @@ configureDDCMonitorSection (int screennum)
}
#endif /* def CONFIGURE_DISPLAYSIZE */
-for (i=0;i<4;i++) {
- switch (ConfiguredMonitor->det_mon[i].type) {
- case DS_NAME:
- ptr->mon_modelname = xf86confrealloc(ptr->mon_modelname,
- strlen((char*)(ConfiguredMonitor->det_mon[i].section.name))
- + 1);
- strcpy(ptr->mon_modelname,
- (char*)(ConfiguredMonitor->det_mon[i].section.name));
- break;
- case DS_RANGES:
- ptr->mon_hsync[ptr->mon_n_hsync].lo =
- ConfiguredMonitor->det_mon[i].section.ranges.min_h;
- ptr->mon_hsync[ptr->mon_n_hsync].hi =
- ConfiguredMonitor->det_mon[i].section.ranges.max_h;
- ptr->mon_n_vrefresh = 1;
- ptr->mon_vrefresh[ptr->mon_n_hsync].lo =
- ConfiguredMonitor->det_mon[i].section.ranges.min_v;
- ptr->mon_vrefresh[ptr->mon_n_hsync].hi =
- ConfiguredMonitor->det_mon[i].section.ranges.max_v;
- ptr->mon_n_hsync++;
- default:
- break;
- }
-}
-
+xf86ForEachDetailedBlock(ConfiguredMonitor, handle_detailed_input,
+ ptr);
if (ConfiguredMonitor->features.dpms) {
ptr->mon_option_lst = xf86addNewOption(ptr->mon_option_lst,
xstrdup("DPMS"), NULL);
}
--
1.5.4.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 7/7] handle detailed timing operation in print_edid.c
Here we print all detailed timing of EDID and CEA or other extension.
---
hw/xfree86/ddc/print_edid.c | 252 +++
1 files changed, 136 insertions(+), 116 deletions(-)
diff --git a/hw/xfree86/ddc/print_edid.c b/hw/xfree86/ddc/print_edid.c
index 7b6e298..3dff1ab 100644
--- a/hw/xfree86/ddc/print_edid.c
+++ b/hw/xfree86/ddc/print_edid.c
@@ -333,123 +333,137 @@ print_detailed_timings(int scrnIndex, struct
detailed_timings *t)
}
}
+struct det_print_parameter{
+ xf86MonPtr m;
+ int index;
+ ddc_quirk_t quirks;
+};
+
static void
-print_detailed_monitor_section(int scrnIndex,
- struct detailed_monitor_section *m)
+handle_detailed_print(struct detailed_monitor_section *det_mon,
+ void *data)
{
-int i,j;
-
-for (i=0;imin_v, r->max_v, r->min_h, r->max_h);
- if (r->max_clock_khz != 0) {
- xf86ErrorF(" PixClock max %i kHz\n", r->max_clock_khz);
- if (r->maxwidth)
- xf86DrvMsg(scrnIndex, X_INFO, "Maximum pixel width: %d\n",
- r->maxwidth);
- xf86DrvMsg(scrnIndex, X_INFO, "Supported aspect ratios:");
- if (r->supported_aspect & SUPPORTED_ASPECT_4_3)
- xf86ErrorF(" 4:3%s",
- r->preferred_aspect == PREFERRED_ASPECT_4_3?"*":"");
- if (r->supported_aspect & SUPPORTED_ASPECT_16_9)
- xf86ErrorF(" 16:9%s",
- r->preferred_aspect == PREFERRED_ASPECT_16_9?"*":"");
- if (r->supported_aspect & SUPPORTED_ASPECT_16_10)
- xf86ErrorF(" 16:10%s",
- r->preferred_aspect == PREFERRED_ASPECT_16_10?"*":"");
- if (r->supported_aspect & SUPPORTED_ASPECT_5_4)
- xf86ErrorF(" 5:4%s",
- r->preferred_aspect == PREFERRED_ASPECT_5_4?"*":"");
- if (r->supported_aspect & SUPPORTED_ASPECT_15_9)
- xf86ErrorF(" 15:9%s",
- r->preferred_aspect == PREFERRED_ASPECT_15_9?"*":"");
- xf86ErrorF("\n");
- xf86DrvMsg(scrnIndex, X_INFO, "Supported blankings:");
- if (r->supported_blanking & CVT_STANDARD)
- xf86ErrorF(" standard");
- if (r->supported_blanking & CVT_REDUCED)
- xf86ErrorF(" reduced");
- xf86ErrorF("\n");
- xf86DrvMsg(scrnIndex, X_INFO, "Supported scalings:");
- if (r->supported_scaling & SCALING_HSHRINK)
- xf86ErrorF(" hshrink");
- if (r->supported_scaling & SCALING_HSTRETCH)
- xf86ErrorF(" hstretch");
- if (r->supported_scaling & SCALING_VSHRINK)
- xf86ErrorF(" vshrink");
- if (r->supported_scaling & SCALING_VSTRETCH)
- xf86ErrorF(" vstretch");
- xf86ErrorF("\n");
- xf86DrvMsg(scrnIndex, X_INFO, "Preferred refresh rate: %d\n",
- r->preferred_refresh);
- } else if (r->max_clock != 0) {
- xf86ErrorF(" PixClock max %i MHz\n", r->max_clock);
- } else {
- xf86ErrorF("\n");
- }
- if (r->gtf_2nd_f > 0)
- xf86DrvMsg(scrnIndex,X_INFO," 2nd GTF parameters: f: %i kHz "
- "c: %i m: %i k %i j %i\n", r->gtf_2nd_f,
- r->gtf_2nd_c, r->gtf_2nd_m, r->gtf_2nd_k,
- r->gtf_2nd_j);
- break;
- }
- case DS_STD_TIMINGS:
- for (j = 0; j<5; j++)
- xf86DrvMsg(scrnIndex,X_INFO,"#%i: hsize: %i vsize %i refresh:
%i "
- "vid: %i\n",i,m[i].section.std_t[i].hsize,
-
m[i].section.std_t[j].vsize,m[i].section.std_t[j].refresh,
- m[i].section.std_t[j].id);
- break;
- case DS_WHITE_P:
- for (j = 0; j<2; j++)
- if (m[i].section.wp[j].index != 0)
- xf86DrvMsg(scrnIndex,X_INFO,
- "White point %i: whiteX: %f, whiteY: %f; gamma:
%f\n",
-
m[i].section.wp[j].index,m[i].section.wp[j].white_x,
- m[i].section.wp[j].white_y,
- m[i].section.wp[j].white_gamma);
- break;
- case DS_CMD:
- xf86DrvMsg(scrnIndex, X_INFO,
- "Color management data: (not decoded)\n");
- break;
- case DS_CVT:
- xf86DrvMsg(scrnIndex, X_INFO,
- "CVT 3-byte-code modes:\n");
- print_cvt_timings(scrnIndex, m[i].section.cvt);
- break;
- case DS_EST_III:
- xf86DrvMsg(scrnIndex, X_INFO,
- "Established timings III: (not decoded)\n");
- break;
- case D
Re: Intel + GEM + suspend -> fail
I have the same issue. Vanilla 2.6.28 kernel, Xorg stack from gentoo x11 overlay, gma950. Sometimes it occurs even without suspend - few switches X->console->X are enought. Regards Vasily On 23 December 2008 06:56:07 Peter Clifton wrote: > If it's a known issue, fine, well and good.. otherwise let me know and > I'll dig you out some more info as to the exact config, and see if I can > be useful about getting this fixed. > > 2.6.28 kernel + patch + patch "drm/i915: Don't return busy for buffers > left on the flushing list." > > Intel driver: d8e89b26ef5ef2c15e5d34162b14d279a7f0bb1c (I think!) > Mesa: d9b92b112fb64005c71edf1158f7dffabc4659bb > > > [ 3027.819992] [ cut here ] > [ 3027.819996] WARNING: > at > ../../../../home/pcjc2/source/ubuntu-kernel/ubuntu-jaunty/drivers/gpu/drm/i >915/i915_gem.c:2470 i915_gem_idle+0x3a8/0x3d0 [i915]() [ 3027.82] > Modules linked in: isofs udf crc_itu_t i915 drm > binfmt_misc af_packet bridge stp bnep sco rfcomm l2cap bluetooth ipv6 > acpi_cpufreq cpufreq_powersave cpufreq_conservative cpufreq_ondemand > cpufreq_stats cpufreq_userspace freq_table wmi pci_slot sbs sbshc > iptable_filter ip_tables x_tables pciehp lp joydev pcmcia arc4 ecb > iwl3945 rfkill parport_pc parport mac80211 led_class snd_hda_intel > cfg80211 container tpm_infineon tpm tpm_bios video output snd_pcm > snd_seq iTCO_wdt sdhci_pci sdhci tifm_7xx1 snd_timer iTCO_vendor_support > snd_seq_device tifm_core intel_agp psmouse serio_raw mmc_core ac snd > yenta_socket rsrc_nonstatic pcmcia_core evdev pcspkr agpgart battery > button shpchp pci_hotplug soundcore snd_page_alloc ext3 jbd mbcache > sd_mod crc_t10dif sr_mod cdrom sg usbhid hid ata_generic ahci ata_piix > pata_acpi tg3 libata scsi_mod ehci_hcd uhci_hcd usbcore thermal > processor fan fbcon tileblit font bitblit softcursor fuse > [ 3027.820090] Pid: 8446, comm: Xorg Tainted: G A > 2.6.28-3-generic #4-Ubuntu > [ 3027.820093] Call Trace: > [ 3027.820099] [] ? printk+0x18/0x1b > [ 3027.820103] [] warn_on_slowpath+0x54/0x80 > [ 3027.820114] [] ? __next_cpu+0x15/0x30 > [ 3027.820121] [] ? i915_gem_retire_requests+0xf9/0x150 > [i915] > [ 3027.820127] [] ? i915_gem_retire_requests+0xf9/0x150 > [i915] > [ 3027.820133] [] i915_gem_idle+0x3a8/0x3d0 [i915] > [ 3027.820139] [] i915_gem_leavevt_ioctl+0x14/0x30 [i915] > [ 3027.820150] [] drm_ioctl+0xe0/0x2e0 [drm] > [ 3027.820155] [] ? __rcu_process_callbacks+0xcc/0x250 > [ 3027.820161] [] ? i915_gem_leavevt_ioctl+0x0/0x30 [i915] > [ 3027.820176] [] vfs_ioctl+0x79/0x90 > [ 3027.820179] [] do_vfs_ioctl+0x5e/0x200 > [ 3027.820182] [] sys_ioctl+0x63/0x70 > [ 3027.820186] [] sysenter_do_call+0x12/0x2f > [ 3027.820188] ---[ end trace e1870677dd3009ef ]--- > [ 3027.905871] mtrr: no MTRR for d000,1000 found > [ 3083.058359] [ cut here ] signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver 1.6 branch and mouse position zapping
'Twas brillig, and Peter Hutterer at 26/12/08 00:25 did gyre and gimble: > On Wed, Dec 24, 2008 at 11:41:10AM +, Colin Guthrie wrote: >>> Just built the 1.6 branch + recent mesa snapshot and other such stuff. >>> >>> It seems to be stable enough just now, but one thing that's been >>> affected is how the mouse positions itself to top-left after a certain >>> operations. >>> >>> So far I've found odd behaviour when doing: >>> * Compiz cube dragging (ctrl+alt+click and drag) >>> * Compiz window moving (alt+click and drag) >>> * Compiz window moving (click and drag on title bar) >>> >>> When this happens the mouse just jumps to the top left, but not always >>> immediately. > > >>> While this could easily be a compiz issue (I certainly cannot reproduce >>> in metacity), I'm guessing it's related to the xserver change. I have >>> also updated to the latest input-proto and other such stuff too. >>> >>> Is there an obvious starting point to look further into this? Or perhaps >>> it's a known issue? > > can you reproduce this with any other client too? It's most likely an X server > issue, but a good reproduceable behaviour in a client other than compiz makes > it easier for me to find the bug. > My first guess is that event replay after synchronous grabs have the wrong > coordinates. > You say it doesn't always happen immediately: try to move particularly fast or > slow to see if that can trigger it. It's really hard to describe! Speed of movement doesn't seem to make much odds but I have narrowed down the behaviour to the "Snapping Windows" compiz plugin. Disabling this makes things a lot more stable but there are still some issues. Every time I move the cube face, either with a window drag to the edge, or with a keystroke, the mouse pointer zaps to the top left. I can't duplicate the behaviour in metacity, but I've not tried in Kwin4 yet. I'm not 100% certain it's a xserver issue here and perhaps compiz is hooking into something it shouldn't be, but it's certainly a regression of sorts. Not really sure how to give you better info to help diagnose :( I'll try asking on compiz IRC to see if anyone else is experiencing the same issues. >> I'm thinking that there is *something* up with mouse moves generally. >> Simple things like hovering the mouse over a link in firefox is also a >> bit odd. Hard to describe really but it seems that the "hover" event (in >> web/js event terminology) only happens when the mouse is actually >> *moving* not when it's just settled over the link. > > A NotifyInferior event sent when moving the mouse from the menu bars into the > main window has the wrong subwindow information. This causes some internal > state in firefox to go nuts. Attributed to the wrong enter/leave model, see > also > > http://lists.freedesktop.org/archives/xorg/2008-December/041696.html > http://bugs.freedesktop.org/show_bug.cgi?id=19086 Thanks Peter. The patck on #19086 appears to be working nicely for me. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Profiling redraws with Xorg 1.5.99.3
Hi guys, I've been profiling some speed differences rendering pixel aligned (should be fast-path) cairo drawing, and happened across the fact that for my redraw test (which is running flat out), 13% of my total system time is spent in dixLookupPrivate. Is there anything which can be done to avoid the overhead of dixLookupPrivate? The overhead is spread over a number of callers, the top few being: exaPixmapIsOffscreen (Total 3.43%) exaDoMoveInPixmap(Total 1.82%) exaDoMigration (Total 1.17%) Now whether this is simply because my cairo rendering is slow, and causing lots of migration I don't know.. but I thought it would be of interest here. This is made with the Intel driver at the tip of the 1.6 branch, using EXA acceleration. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Profiling redraws with Xorg 1.5.99.3
2008/12/26 Peter Clifton : > Hi guys, > > I've been profiling some speed differences rendering pixel aligned > (should be fast-path) cairo drawing, and happened across the fact that > for my redraw test (which is running flat out), 13% of my total system > time is spent in dixLookupPrivate. > > Is there anything which can be done to avoid the overhead of > dixLookupPrivate? > > The overhead is spread over a number of callers, the top few being: > > exaPixmapIsOffscreen (Total 3.43%) > exaDoMoveInPixmap(Total 1.82%) > exaDoMigration (Total 1.17%) > > Now whether this is simply because my cairo rendering is slow, and > causing lots of migration I don't know.. but I thought it would be of > interest here. > > This is made with the Intel driver at the tip of the 1.6 branch, using > EXA acceleration. > > Best wishes, > Perhaps you're struck by this bug: http://bugs.freedesktop.org/show_bug.cgi?id=16647 Regards, Erik > -- > Peter Clifton > > Electrical Engineering Division, > Engineering Department, > University of Cambridge, > 9, JJ Thomson Avenue, > Cambridge > CB3 0FA > > Tel: +44 (0)7729 980173 - (No signal in the lab!) > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: about continuous frequency
On Thu, Dec 25, 2008 at 2:33 AM, Ma, Ling wrote: > hi Alex, > Because the flag exist in EDID, but some laptop can't provide EDID, how can > we know whether it support continuous frequency or not ? > Hi, Most laptop panels have a fixed resolution so generally the driver will always run the panel at it's native resolution regardless of the requested mode. If a non-native mode is selected, the driver will either reject the mode or use the scaler the up/down-scale the requested mode to the panel's native resolution and timing. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Profiling redraws with Xorg 1.5.99.3
On Fri, 2008-12-26 at 16:53 +0100, Erik Andrén wrote: > 2008/12/26 Peter Clifton : > > Hi guys, > > > > I've been profiling some speed differences rendering pixel aligned > > (should be fast-path) cairo drawing, and happened across the fact that > > for my redraw test (which is running flat out), 13% of my total system > > time is spent in dixLookupPrivate. > > > > Is there anything which can be done to avoid the overhead of > > dixLookupPrivate? > > > > The overhead is spread over a number of callers, the top few being: > > > > exaPixmapIsOffscreen (Total 3.43%) > > exaDoMoveInPixmap(Total 1.82%) > > exaDoMigration (Total 1.17%) > > > > Now whether this is simply because my cairo rendering is slow, and > > causing lots of migration I don't know.. but I thought it would be of > > interest here. > > > > This is made with the Intel driver at the tip of the 1.6 branch, using > > EXA acceleration. > > > > Best wishes, > > > > Perhaps you're struck by this bug: > http://bugs.freedesktop.org/show_bug.cgi?id=16647 Could be. Shame the new optimised implementation of the private lookup had to be reverted on the 1.5 branch. I'm running 1.5.99, and it would appear that the patch is applied. It is a shame dixLookupPrivate is consuming so many cycles still. The patch for the performance issue is not applied on the server I'm using, so I'll try applying that and rebuilding. Thanks for the pointer! -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: memcpy to AGP vs memcpy to framebuffer - which is faster?
On Wed, Dec 24, 2008 at 1:28 PM, Alex Villacís Lasso wrote: > This is probably a very basic question, but it is important for me to know: > > If I do an ordinary (non-accelerated) memcpy of a frame from system > memory to a buffer in AGP memory (allocated via DRI), is it any faster > than a (non-accelerated) memcpy of the exact same frame to a buffer area > in offscreen memory in the framebuffer? Does the fact of whether the > chipset is integrated into the mainboard (and using memory stolen from > main RAM as video memory) affect this, as opposed to a plug-in card in > the AGP port? It's going to be faster to copy to gart buffers rather than to access framebuffer memory directly since you don't have to go across the PCI/AGP bus. For IGP chips you could probably copy stuff directly to the stolen memory pool (if you know where it is), but in that case it doesn't go through the GPU's host data path which handles tiling and things like that. > > I want to know because I am evaluating whether it is worthwhile to > implement allocation of AGP buffers via DRI in the XVideo code path of > xf86-video-savage. The "mastered image transfer" (used to transform from > planar YV12 to packed YUV) present in the chipset can choose between > framebuffer memory and AGP memory as a source for the conversion. > Currently it uses an upload from system memory to an area in offscreen > memory, followed by the conversion. However, the upload to the > framebuffer is the main source of delay, and measurements with mplayer > and a 640x480 movie show that software conversion (BCIForXV=off) is > *faster* (90 seconds) than BCI-mediated conversion (110 seconds). You'd have to benchmark it to be sure. The advantage of using gart buffers is that the GPU will do the fetch across the bus freeing the CPU to do other stuff. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Profiling redraws with Xorg 1.5.99.3
> Could be. Shame the new optimised implementation of the private lookup > had to be reverted on the 1.5 branch. Its not shame, its just that ABI changes don't fit in minor releases. > I'm running 1.5.99, and it would appear that the patch is applied. It is > a shame dixLookupPrivate is consuming so many cycles still. I doubt the new implementation could consume 13% of total cycles. Its _very_ quick and should consume only a few cycles. > The patch for the performance issue is not applied on the server I'm > using, so I'll try applying that and rebuilding. Thanks for the pointer! Could be. When have you pulled your version? I thought the patch was applied to 1.6 quite a while ago. - Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Profiling redraws with Xorg 1.5.99.3
On Fri, 2008-12-26 at 17:48 +0100, Clemens Eisserer wrote: > > Could be. Shame the new optimised implementation of the private lookup > > had to be reverted on the 1.5 branch. > Its not shame, its just that ABI changes don't fit in minor releases. > > > I'm running 1.5.99, and it would appear that the patch is applied. It is > > a shame dixLookupPrivate is consuming so many cycles still. > I doubt the new implementation could consume 13% of total cycles. > Its _very_ quick and should consume only a few cycles. > > > The patch for the performance issue is not applied on the server I'm > > using, so I'll try applying that and rebuilding. Thanks for the pointer! > Could be. When have you pulled your version? > I thought the patch was applied to 1.6 quite a while ago. The other patch which is in that bug (marked as FIXED) is not applied to either 1.6, or the git master. Only the patch for dixLookupPrivate is. Even with both patches applied, dixLookupPrivate takes 10% of system time in my rendering test with cairo. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Profiling redraws with Xorg 1.5.99.3
On Fri, 2008-12-26 at 17:48 +0100, Clemens Eisserer wrote: > > Could be. Shame the new optimised implementation of the private lookup > > had to be reverted on the 1.5 branch. > Its not shame, its just that ABI changes don't fit in minor releases. > > > I'm running 1.5.99, and it would appear that the patch is applied. It is > > a shame dixLookupPrivate is consuming so many cycles still. > I doubt the new implementation could consume 13% of total cycles. > Its _very_ quick and should consume only a few cycles. Ok - so I found my own bug.. I was dividing by 256, rather than 255 when computing colours, and getting a non 1.0 alpha in cairo - hence was drawing translucent lines rather than solid ones, hence a huge cost in pixmap migration for each line I drew. (Almost every other column, and almost every other row on the screen). With that fixed, the dixLookupPrivate only consumes 4.5% of the total system time. I say "only", but that is still about 4% or so too many ;). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Bad performance on 2.6.28rc vs. 2.6.27 for intel 2.5.1 + xserver 1.5.3
'Twas brillig, and Colin Guthrie at 15/12/08 00:19 did gyre and gimble: > Just trying a new kernel 2.6.28rc and without changing anything else my > DRI/GLX performance seems to have suffered badly. I'm running compiz on > a i945GM. > > Is there anything specific that needs to be changed (e.g. in libdrm or > mesa) to keep up to date with changes in the kernel itself? > > If I need to provide logs etc. for debugging it can be arranged ;) Just wanted to follow up on this. I'm now using server-1.6-branch, libdrm 2.4.3 and a mesa snapshot from a few days ago. Booting into kernel 2.6.28rc8 causes a massive slowdown in compiz. Could this be something simple like a timing issue on the compiz side affecting it's animations or something more sinister? I'll ask upstream on compiz IRC but I'm just canvassing opinion from the clever folks here to see if there is anything obvious that I need to take into account :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
How to get working OpenGL on Intel G45?
Hi. I've built X from git several times since this summer but never managed to get "OpenGL renderer string" to anything but "Software Rasterizer" on my Intel G45 board. This time it's with 2.6.28 but it doesn't seem to help. What should I look for? It works with standard ubuntu 8.10 but I need more a recent X for hdmi audio to work. Thankful for any help, /Magnus H xorg.conf: Section "Device" Identifier "g45-fus" Driver "intel" Option "AccelMethod" "UXA" Option "monitor-HDMI-1" "fus-hdmi" EndSection Section "Monitor" Identifier "fus-hdmi" Modeline "1920x1200_50.00" 158.08 1920 2032 2240 2560 1200 1201 1204 1235 -HSync +Vsync EndSection Section "Screen" Identifier "g45-fus" Device "g45-fus" Monitor"fus-hdmi" SubSection "Display" Modes "1440x900" EndSubSection EndSection glxinfo: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 7.3-devel OpenGL shading language version string: 1.10 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_half_float_pixel, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_depth_bounds_test, GL_EXT_draw_range_elements, GL_EXT_framebuffer_object, GL_EXT_framebuffer_blit, GL_EXT_fog_coord, GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_vertex_array, GL_3DFX_texture_compression_FXT1, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_ATI_fragment_shader, GL_ATI_separate_stencil, GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_program_debug, GL_MESA_resize_buffers, GL_MESA_texture_array, GL_MESA_ycbcr_texture, GL_MESA_window_pos, G
xorg-server from git master: ctrl+alt+backspace doesn't work anymore
Hi, I recently upgraded to latest X11 stack from gentoo x11 overlay (just want to test gem+dri2 :)), and it seems that ctrl+alt+backspace doesn't kill X anymore. Is it bug or planned behavior? Regards Vasily signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to get working OpenGL on Intel G45?
On Fri, 2008-12-26 at 22:29 +0100, Magnus Hörlin wrote: > glxinfo: > name of display: :0.0 > display: :0 screen: 0 > direct rendering: Yes > server glx vendor string: SGI > server glx version string: 1.2 > server glx extensions: > GLX_ARB_multisample, GLX_EXT_import_context, > GLX_EXT_texture_from_pixmap, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, > GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, > GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group > client glx vendor string: SGI > client glx version string: 1.4 > client glx extensions: > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, > GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, > GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, > GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, > GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, > GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap > GLX version: 1.2 > GLX extensions: > GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, > GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group > OpenGL vendor string: Mesa Project > OpenGL renderer string: Software Rasterizer > OpenGL version string: 2.1 Mesa 7.3-devel > OpenGL shading language version string: 1.10 > OpenGL extensions: > GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, > GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, > GL_ARB_half_float_pixel, GL_ARB_imaging, GL_ARB_multisample, > GL_ARB_multitexture, GL_ARB_occlusion_query, > GL_ARB_pixel_buffer_object, > GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects, > GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_shadow_ambient, > GL_ARB_texture_border_clamp, GL_ARB_texture_compression, > GL_ARB_texture_cube_map, GL_ARB_texture_env_add, > GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, > GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, > GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, > GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, > GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, > GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, > GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, > GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, > GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, > GL_EXT_convolution, > GL_EXT_copy_texture, GL_EXT_depth_bounds_test, > GL_EXT_draw_range_elements, > GL_EXT_framebuffer_object, GL_EXT_framebuffer_blit, GL_EXT_fog_coord, > GL_EXT_gpu_program_parameters, GL_EXT_histogram, > GL_EXT_multi_draw_arrays, > GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, > GL_EXT_paletted_texture, GL_EXT_pixel_buffer_object, > GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, > GL_EXT_secondary_color, GL_EXT_separate_specular_color, > GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, > GL_EXT_stencil_wrap, > GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, > GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, > GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, > GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, > GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, > GL_EXT_vertex_array, GL_3DFX_texture_compression_FXT1, > GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, > GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, > GL_ATI_texture_mirror_once, GL_ATI_fragment_shader, > GL_ATI_separate_stencil, GL_IBM_multimode_draw_arrays, > GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, > GL_INGR_blend_func_separate, GL_MESA_pack_invert, > GL_MESA_program_debug, > GL_MESA_resize_buffers, GL_MESA_texture_array, GL_MESA_ycbcr_texture, > GL_MESA_window_pos, GL_NV_blend_square, GL_NV_fragment_program, > GL_NV_light_max_exponent, GL_NV_point_sprite, GL_NV_texture_rectangle, > GL_NV_texgen_reflection, GL_NV_vertex_program, GL_NV_vertex_program1_1, > GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, > GL_SGI_texture_color_table, GL_SGIS_generate_mipmap, > GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, > GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, > GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays > What is the output of 'LIBGL_DEBUG=verbose glxinfo' ? Adam -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-server from git master: ctrl+alt+backspace doesn't work anymore
>Option "DontZap" "boolean" > This disallows the use of the Ctrl+Alt+Backspace sequence. That > sequence is normally used to terminate the Xorg server. When > this option is enabled (as per default), that key sequence has > no special meaning. Default: on. you should setup your xorg.conf in the above parameter to use zap. commit 8c560422b44e012053612754430d2b87dc44ed59 changed the default behavior. On Sat, 27 Dec 2008 00:27:21 +0200 Vasily Khoruzhick wrote: > Hi, > > I recently upgraded to latest X11 stack from gentoo x11 overlay (just want to > test gem+dri2 :)), and it seems that ctrl+alt+backspace doesn't kill X > anymore. Is it bug or planned behavior? > > Regards > Vasily > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-server from git master: ctrl+alt+backspace doesn't work anymore
On Sat, 27 Dec 2008 07:47:19 +0900 Shunichi Fuji wrote: > commit 8c560422b44e012053612754430d2b87dc44ed59 changed the default behavior. oops, that is man pages change. around 9d135ac10a7374c7ccda705f1eeb02cc53076c34 is it. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-server from git master: ctrl+alt+backspace doesn't work anymore
On 27 December 2008 00:47:19 Shunichi Fuji wrote: > >Option "DontZap" "boolean" > > This disallows the use of the Ctrl+Alt+Backspace sequence. > > That sequence is normally used to terminate the Xorg server. When this > > option is enabled (as per default), that key sequence has no special > > meaning. Default: on. > > you should setup your xorg.conf in the above parameter to use zap. > commit 8c560422b44e012053612754430d2b87dc44ed59 changed the default > behavior. Thank you :) signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fw: Re: [ANNOUNCE] xf86-video-ati 6.9.0.91 - release candidate
On Tue, Dec 23, 2008 at 11:57 PM, Shunichi Fuji wrote: > > > Begin forwarded message: > > Date: Tue, 23 Dec 2008 22:29:38 -0500 > From: Gene Heskett > To: Shunichi Fuji > Subject: Re: [ANNOUNCE] xf86-video-ati 6.9.0.91 - release candidate > > > On Tuesday 23 December 2008, Shunichi Fuji wrote: >>On Tue, 23 Dec 2008 19:13:58 -0500 >> >>Gene Heskett wrote: >>> gcc -DHAVE_CONFIG_H -I. -I.. -I./AtomBios/includes -Wall >>> -I/usr/include/xorg -I/usr/include/drm -I/usr/include/X11/dri >>> -DDISABLE_EASF -DENABLE_ALL_SERVICE_FUNCTIONS -DATOM_BIOS >>> -DATOM_BIOS_PARSER -DDRIVER_PARSER -g -O2 -MT radeon_accel.lo -MD -MP -MF >>> .deps/radeon_accel.Tpo -c >>> radeon_accel.c -fPIC -DPIC -o .libs/radeon_accel.o >>> radeon_accel.c: In function 'RADEONEngineInit': >>> radeon_accel.c:383: error: 'RADEON_PARAM_NUM_GB_PIPES' undeclared (first >>> use in this function) >>> radeon_accel.c:383: error: (Each undeclared identifier is reported only >>> once radeon_accel.c:383: error: for each function it appears in.) >>> make[2]: *** [radeon_accel.lo] Error 1 >>> make[2]: Leaving directory `/usr/src/xf86-video-ati-6.9.0.91/src' >>> make[1]: *** [all-recursive] Error 1 >>> make[1]: Leaving directory `/usr/src/xf86-video-ati-6.9.0.91' >>> make: *** [all] Error 2 >>> >>> What header am I missing? >> >>RADEON_PARAM_NUM_GB_PIPES defined in radon_drm.h, and git repository has it >> one. but tar package seems don't have it. >> >>i guess that radeon_drm.h will ship with libdrm > > Not installed on this FU8 system, and not available to yumex. > >>and it install to >> include/drm. there are 3 copy at least kernel,drm and xf86-video-ati... > > I found the one in xf86-video-radeonhd-1.2.4, and copied it to the src tree > beside the other .h files, and it built, and I've installed it and running > it, although not much is changed. glxgears is still moping along at about > 875 fps, and glxinfo says no drm?dri. > > But now this exposes a new problem I don't recall in these exact words, when I > do a startx, it cannot load the kernel radeon module > (this from the Xorg.0.log) > > (WW) RADEON(0): Direct rendering for RN50/RS600/R600 forced on -- This is NOT > officially supported at the hardware level and may cause instability or > lockups > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is -1, (No such device) > drmOpenDevice: open result is -1, (No such device) > drmOpenDevice: Open failed > [drm] failed to load kernel module "radeon" > (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM > [dri] Disabling DRI. > > So, just for giggles: > > [r...@coyote ~]# modprobe radeon > WARNING: Error inserting drm > (/lib/modules/2.6.28-rc9/kernel/drivers/gpu/drm/drm.ko): Invalid argument > FATAL: Error inserting radeon > (/lib/modules/2.6.28-rc9/kernel/drivers/gpu/drm/radeon/radeon.ko): Invalid > argument > > I can also recall not too far back in the 2.6.28-rc cycle, seeing dmesg > reporting that the firmware for the card had been loaded from > the /lib/firmware/radeon directory, but that appears to be on the missing > list too for an rcN or 2. The firmware is there from previous kernel builds, > but is no longer being installed by this line of my "./makeit" script: > > make firmware_install && \ > > Which tells me something has changed in the Makefiles or .config's. > > How important is this firmware for the health & well being of an HD2400-Pro > (rv610) card? There is no working drm support yet for r6xx/r7xx cards yet. It will be released soon. > > From the .config that built this kernel: > > [r...@coyote linux-2.6.28-rc9]# grep FIRMWARE .config > # CONFIG_PREVENT_FIRMWARE_BUILD is not set > # CONFIG_FIRMWARE_IN_KERNEL is not set > CONFIG_EXTRA_FIRMWARE="radeon/R100_cp.bin.ihex radeon/R200_cp.bin.ihex > radeon/R300_cp.bin.ihex radeon/R420_cp.bin.ihex radeon/R520_cp.bin.ihex > radeon/RS600_cp.bin.ihex radeon/RS690_cp.bin.ihex" > CONFIG_EXTRA_FIRMWARE_DIR="firmware" > # CONFIG_DVB_AV7110_FIRMWARE is not set > # CONFIG_FIRMWARE_EDID is not set > CONFIG_FIRMWARE_MEMMAP=y Looks like you are using some distro-specific patch that separates the firmware from the radeon drm. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fw: Re: [ANNOUNCE] xf86-video-ati 6.9.0.91 - release candidate
On Friday 26 December 2008, Alex Deucher wrote: >On Tue, Dec 23, 2008 at 11:57 PM, Shunichi Fuji wrote: >> Begin forwarded message: >> >> Date: Tue, 23 Dec 2008 22:29:38 -0500 >> From: Gene Heskett >> To: Shunichi Fuji >> Subject: Re: [ANNOUNCE] xf86-video-ati 6.9.0.91 - release candidate >> >> On Tuesday 23 December 2008, Shunichi Fuji wrote: >>>On Tue, 23 Dec 2008 19:13:58 -0500 >>> >>>Gene Heskett wrote: gcc -DHAVE_CONFIG_H -I. -I.. -I./AtomBios/includes -Wall -I/usr/include/xorg -I/usr/include/drm -I/usr/include/X11/dri -DDISABLE_EASF -DENABLE_ALL_SERVICE_FUNCTIONS -DATOM_BIOS -DATOM_BIOS_PARSER -DDRIVER_PARSER -g -O2 -MT radeon_accel.lo -MD -MP -MF .deps/radeon_accel.Tpo -c radeon_accel.c -fPIC -DPIC -o .libs/radeon_accel.o radeon_accel.c: In function 'RADEONEngineInit': radeon_accel.c:383: error: 'RADEON_PARAM_NUM_GB_PIPES' undeclared (first use in this function) radeon_accel.c:383: error: (Each undeclared identifier is reported only once radeon_accel.c:383: error: for each function it appears in.) make[2]: *** [radeon_accel.lo] Error 1 make[2]: Leaving directory `/usr/src/xf86-video-ati-6.9.0.91/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/xf86-video-ati-6.9.0.91' make: *** [all] Error 2 What header am I missing? >>> >>>RADEON_PARAM_NUM_GB_PIPES defined in radon_drm.h, and git repository has >>> it one. but tar package seems don't have it. >>> >>>i guess that radeon_drm.h will ship with libdrm >> >> Not installed on this FU8 system, and not available to yumex. >> >>>and it install to >>> include/drm. there are 3 copy at least kernel,drm and xf86-video-ati... >> >> I found the one in xf86-video-radeonhd-1.2.4, and copied it to the src >> tree beside the other .h files, and it built, and I've installed it and >> running it, although not much is changed. glxgears is still moping along >> at about 875 fps, and glxinfo says no drm?dri. >> >> But now this exposes a new problem I don't recall in these exact words, >> when I do a startx, it cannot load the kernel radeon module >> (this from the Xorg.0.log) >> >> (WW) RADEON(0): Direct rendering for RN50/RS600/R600 forced on -- This is >> NOT officially supported at the hardware level and may cause instability >> or lockups >> drmOpenDevice: node name is /dev/dri/card0 >> drmOpenDevice: open result is -1, (No such device) >> drmOpenDevice: open result is -1, (No such device) >> drmOpenDevice: Open failed >> [drm] failed to load kernel module "radeon" >> (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM >> [dri] Disabling DRI. >> >> So, just for giggles: >> >> [r...@coyote ~]# modprobe radeon >> WARNING: Error inserting drm >> (/lib/modules/2.6.28-rc9/kernel/drivers/gpu/drm/drm.ko): Invalid argument >> FATAL: Error inserting radeon >> (/lib/modules/2.6.28-rc9/kernel/drivers/gpu/drm/radeon/radeon.ko): Invalid >> argument >> >> I can also recall not too far back in the 2.6.28-rc cycle, seeing dmesg >> reporting that the firmware for the card had been loaded from >> the /lib/firmware/radeon directory, but that appears to be on the missing >> list too for an rcN or 2. The firmware is there from previous kernel >> builds, but is no longer being installed by this line of my "./makeit" >> script: >> >> make firmware_install && \ >> >> Which tells me something has changed in the Makefiles or .config's. >> >> How important is this firmware for the health & well being of an >> HD2400-Pro (rv610) card? > >There is no working drm support yet for r6xx/r7xx cards yet. It will >be released soon. > >> From the .config that built this kernel: >> >> [r...@coyote linux-2.6.28-rc9]# grep FIRMWARE .config >> # CONFIG_PREVENT_FIRMWARE_BUILD is not set >> # CONFIG_FIRMWARE_IN_KERNEL is not set >> CONFIG_EXTRA_FIRMWARE="radeon/R100_cp.bin.ihex radeon/R200_cp.bin.ihex >> radeon/R300_cp.bin.ihex radeon/R420_cp.bin.ihex radeon/R520_cp.bin.ihex >> radeon/RS600_cp.bin.ihex radeon/RS690_cp.bin.ihex" >> CONFIG_EXTRA_FIRMWARE_DIR="firmware" >> # CONFIG_DVB_AV7110_FIRMWARE is not set >> # CONFIG_FIRMWARE_EDID is not set >> CONFIG_FIRMWARE_MEMMAP=y > >Looks like you are using some distro-specific patch that separates the >firmware from the radeon drm. > I can nuke the stuff in /lib/firmware/radeon, and nuke that from the .config too I guess. The 2.6.28 final kernel does not install those anymore. And I no longer see messages in the boot log indicating it is being loaded either. I guess the answer to "Should I?" is yes? Time frame for the release? >Alex >___ >xorg mailing list >xorg@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/xorg -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Huh? ___ xorg mailing list xorg@lists.fr
