[PATCH 0/9] handle detailed timing and short video descriptor of CEA extension
Hi All, I re-updated the patches which are intended to handle detailed timing blocks in EDID and E-EDID. In order not to pollute xf86MonPtr interface, based on Ajax's suggestion I used unified interface. And in patch 8, we select appropriate modes from video blocks of CEA extension, then insert them into mode list. Any comments are welcome! [PATCH 1/9] Includes new structures and defined MACRO [PATCH 2/9] construct detailed timing unified interface [PATCH 3/9] handle detailed timing operation in interpret_edid.c [PATCH 4/9] handle detailed timing operation in xf86EdidModes.c [PATCH 5/9] handle detailed timing operation in xf86Crtc.c [PATCH 6/9] handle detailed timing operation in xf86Configure.c [PATCH 7/9] handle detailed timing operation in print_edid.c [PATCH 8/9] handle cea-ext data block and insert mode into mode list. Thanks Ma Ling ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 1/9] Includes new structures and defined MACRO
declare new structures and MACRO related with CEA extension.
---
hw/xfree86/ddc/edid.h | 90 +
1 files changed, 90 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/ddc/edid.h b/hw/xfree86/ddc/edid.h
index b556003..0af9e59 100644
--- a/hw/xfree86/ddc/edid.h
+++ b/hw/xfree86/ddc/edid.h
@@ -555,4 +555,94 @@ typedef struct {
extern _X_EXPORT xf86MonPtr ConfiguredMonitor;
+#define EXT_TAG 0
+#define EXT_REV 1
+#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 IEEE_ID_HDMI0x000C03
+#define CEA_AUDIO_BLK 1
+#define CEA_VIDEO_BLK 2
+#define CEA_VENDOR_BLK 3
+#define CEA_SPEAKER_ALLOC_BLK 4
+#define CEA_VESA_DTC_BLK 5
+#define VENDOR_SUPPORT_AI(x) ((x) 7)
+#define VENDOR_SUPPORT_DC_48bit(x) ( ( (x) 6) 0x01)
+#define VENDOR_SUPPORT_DC_36bit(x) ( ( (x) 5) 0x01)
+#define VENDOR_SUPPORT_DC_30bit(x) ( ( (x) 4) 0x01)
+#define VENDOR_SUPPORT_DC_Y444(x) ( ( (x) 3) 0x01)
+#define VENDOR_LATENCY_PRESENT(x) ( (x) 7)
+#define VENDOR_LATENCY_PRESENT_I(x) ( ( (x) 6) 0x01)
+#define HDMI_MAX_TMDS_UNIT (5000)
+
+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/9] construct detailed timing unified interface
construct unified interface, anytime when program need detailed timing block,
it always dynamically parse and handle it through the interface.
---
hw/xfree86/ddc/interpret_edid.c | 182 +++
hw/xfree86/ddc/xf86DDC.h|5 +
2 files changed, 132 insertions(+), 55 deletions(-)
diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index c0e3df9..f04c6bc 100644
--- a/hw/xfree86/ddc/interpret_edid.c
+++ b/hw/xfree86/ddc/interpret_edid.c
@@ -41,6 +41,8 @@ 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);
static void copy_string(Uchar *, Uchar *);
@@ -163,6 +165,70 @@ xf86InterpretEDID(int scrnIndex, Uchar *block)
return NULL;
}
+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;
+}
+}
+}
+
xf86MonPtr
xf86InterpretEEDID(int scrnIndex, Uchar *block)
{
@@ -285,65 +351,71 @@ get_std_timing_section(Uchar *c, struct std_timings *r,
}
static void
-get_dt_md_section(Uchar *c, struct edid_version *ver,
- struct detailed_monitor_section *det_mon)
+fetch_detailed_block(Uchar *c, struct edid_version *ver,
+ struct detailed_monitor_section *det_mon)
{
- int i;
-
- for (i=0;iDET_TIMINGS;i++) {
if (ver-version == 1 ver-revision = 1 IS_MONITOR_DESC) {
+switch (MONITOR_DESC_TYPE) {
+case SERIAL_NUMBER:
+det_mon-type = DS_SERIAL;
+copy_string(c,det_mon-section.serial);
+break;
+case ASCII_STR:
+det_mon-type = DS_ASCII_STR;
+copy_string(c,det_mon-section.ascii_data);
+break;
+case MONITOR_RANGES:
+det_mon-type = DS_RANGES;
+get_monitor_ranges(c,det_mon-section.ranges);
+break;
+case MONITOR_NAME:
+det_mon-type = DS_NAME;
+copy_string(c,det_mon-section.name);
+break;
+case ADD_COLOR_POINT:
+det_mon-type = DS_WHITE_P;
+get_whitepoint_section(c,det_mon-section.wp);
+break;
+case ADD_STD_TIMINGS:
+det_mon-type = DS_STD_TIMINGS;
+get_dst_timing_section(c,det_mon-section.std_t, ver);
+break;
+case COLOR_MANAGEMENT_DATA:
+det_mon-type = DS_CMD;
+break;
+case CVT_3BYTE_DATA:
+det_mon-type = DS_CVT;
+get_cvt_timing_section(c, det_mon-section.cvt);
+break;
+case ADD_EST_TIMINGS:
+det_mon-type = DS_EST_III;
+break;
+case ADD_DUMMY:
+det_mon-type = DS_DUMMY;
+break;
+default:
+det_mon-type = DS_UNKOWN;
+break;
+}
+if (c[3] = 0x0F) {
+det_mon-type = DS_VENDOR + c[3];
+}
+} else {
+det_mon-type = DT;
+
[PATCH 4/9] handle detailed timing operation in xf86EdidModes.c
handle detailed timing quirks and insert detailed timing modes into mode list
---
hw/xfree86/ddc/xf86DDC.h | 39 +
hw/xfree86/modes/xf86EdidModes.c | 284 --
2 files changed, 190 insertions(+), 133 deletions(-)
diff --git a/hw/xfree86/ddc/xf86DDC.h b/hw/xfree86/ddc/xf86DDC.h
index b865e1a..0f4f65f 100644
--- a/hw/xfree86/ddc/xf86DDC.h
+++ b/hw/xfree86/ddc/xf86DDC.h
@@ -62,9 +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..97c40bf 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -45,20 +45,23 @@
#include string.h
#include math.h
+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, xf86MonPtr DDC, Bool verbose)
{
ddc_quirk_tquirks;
@@
[PATCH 5/9] handle detailed timing operation in xf86Crtc.c
through unified interface handle monitor record and physical size of detailed
timing block
---
hw/xfree86/modes/xf86Crtc.c | 132 ---
1 files changed, 87 insertions(+), 45 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index cb13deb..85805bb 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -1530,6 +1530,42 @@ GuessRangeFromModes(MonPtr mon, DisplayModePtr mode)
mon-vrefresh[0].lo = 58.0;
}
+struct det_monrec_parameter {
+MonRec *mon_rec;
+int *max_clock;
+Bool set_hsync;
+Bool set_vrefresh;
+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-set_hsync 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-set_vrefresh 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 +1644,24 @@ 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.set_hsync = mon_rec.nHsync == 0;
+ p.set_vrefresh = mon_rec.nVrefresh == 0;
+ p.sync_source = sync_source;
+
+ xf86ForEachDetailedBlock(edid_monitor,
+handle_detailed_monrec,
+p);
}
if (xf86GetOptValFreq (output-options, OPTION_MIN_CLOCK,
@@ -2887,6 +2905,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,
+
[PATCH 8/9] handle cea-ext data block and insert mode into mode list.
select appropriate mode form video data blocks of CEA extension, then insert
them into mode list.
---
hw/xfree86/ddc/interpret_edid.c | 56 +
hw/xfree86/ddc/xf86DDC.h |3 +
hw/xfree86/modes/xf86EdidModes.c | 102 ++
3 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index d2a9fb4..194d182 100644
--- a/hw/xfree86/ddc/interpret_edid.c
+++ b/hw/xfree86/ddc/interpret_edid.c
@@ -253,6 +253,62 @@ void xf86ForEachDetailedBlock(xf86MonPtr mon,
}
}
+static void extract_cea_data_block(Uchar *ext, int data_type, void *data)
+{
+struct cea_ext_body *cea;
+struct cea_data_blk *data_collection;
+struct cea_data_blk *data_end;
+
+cea = (struct cea_ext_body *)ext;
+
+if (cea-dt_offset = CEA_EXT_MIN_DATA_OFFSET)
+return;
+
+data_collection = cea-data_collection;
+data_end = (struct cea_data_blk *)(cea-dt_offset + ext);
+
+for ( ;data_collection data_end;) {
+
+ if (data_type == data_collection-tag) {
+ *((struct cea_data_blk **)data) = data_collection;
+ return;
+ }
+ data_collection = (unsigned char *)data_collection +
+ data_collection-len + 1 ;
+}
+}
+
+void xf86FetchDataBlock(xf86MonPtr mon,
+int ext_type, int data_type,
+void *data)
+{
+int i;
+Uchar *ext;
+
+if (mon == NULL)
+ return;
+
+for (i = 0; i mon-no_sections; i++) {
+ ext = mon-rawData + EDID1_LEN * (i + 1);
+ if (ext[EXT_TAG] == ext_type)
+ break;
+}
+/* return if don't find corresponding extension type */
+if (i == mon-no_sections)
+ return;
+
+switch (ext[EXT_TAG]){
+case CEA_EXT:
+ extract_cea_data_block(ext, data_type, data);
+ break;
+case VTB_EXT:
+case DI_EXT:
+case LS_EXT:
+case MI_EXT:
+ break;
+}
+}
+
xf86MonPtr
xf86InterpretEEDID(int scrnIndex, Uchar *block)
{
diff --git a/hw/xfree86/ddc/xf86DDC.h b/hw/xfree86/ddc/xf86DDC.h
index 0f4f65f..81ead53 100644
--- a/hw/xfree86/ddc/xf86DDC.h
+++ b/hw/xfree86/ddc/xf86DDC.h
@@ -106,4 +106,7 @@ xf86DDCDetectQuirks(int scrnIndex, xf86MonPtr DDC, Bool
verbose);
void xf86DetTimingApplyQuirks(struct detailed_monitor_section *det_mon,
ddc_quirk_t quirks, int hsize, int vsize);
+void xf86FetchDataBlock(xf86MonPtr mon,
+int ext_type, int data_type,
+void *data);
#endif
diff --git a/hw/xfree86/modes/xf86EdidModes.c b/hw/xfree86/modes/xf86EdidModes.c
index 97c40bf..4760316 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -741,6 +741,104 @@ xf86DDCSetPreferredRefresh(int scrnIndex, DisplayModePtr
modes,
best-type |= M_T_PREFERRED;
}
+#define CEA_VIDEO_MODES_NUM 64
+static const DisplayModeRec CEAVideoModes[CEA_VIDEO_MODES_NUM] = {
+{ MODEPREFIX,25175, 640, 656, 752, 800, 0, 480, 490, 492, 525,
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 1:640x...@60hz */
+{ MODEPREFIX,27000, 720, 736, 798, 858, 0, 480, 489, 495, 525,
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 2:720x...@60hz */
+{ MODEPREFIX,27000, 720, 736, 798, 858, 0, 480, 489, 495, 525,
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 3:720x...@60hz */
+{ MODEPREFIX,74250, 1280, 1390, 1430, 1650, 0, 720, 725, 730, 750,
0, V_PHSYNC | V_PVSYNC, MODESUFFIX }, /* VIC 4: 1280x...@60hz */
+{ MODEPREFIX,74250, 1920, 2008, 2052, 2200, 0, 1080, 1084, 1094, 1125,
0, V_PHSYNC | V_PVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 5:1920x10...@60hz */
+{ MODEPREFIX,27000, 1440, 1478, 1602, 1716, 0, 480, 488, 494, 525,
0, V_NHSYNC | V_NVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 6:1440x4...@60hz */
+{ MODEPREFIX,27000, 1440, 1478, 1602, 1716, 0, 480, 488, 494, 525,
0, V_NHSYNC | V_NVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 7:1440x4...@60hz */
+{ MODEPREFIX,27000, 1440, 1478, 1602, 1716, 0, 240, 244, 247, 262,
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 8:1440x...@60hz */
+{ MODEPREFIX,27000, 1440, 1478, 1602, 1716, 0, 240, 244, 247, 262,
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 9:1440x...@60hz */
+{ MODEPREFIX,54000, 2880, 2956, 3204, 3432, 0, 480, 488, 494, 525,
0, V_NHSYNC | V_NVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 10:2880x4...@60hz */
+{ MODEPREFIX,54000, 2880, 2956, 3204, 3432, 0, 480, 488, 494, 525,
0, V_NHSYNC | V_NVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 11:2880x4...@60hz */
+{ MODEPREFIX,54000, 2880, 2956, 3204, 3432, 0, 240, 244, 247, 262,
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 12:2880x...@60hz */
+{ MODEPREFIX,54000, 2880, 2956, 3204, 3432, 0, 240, 244, 247, 262,
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 13:2880x...@60hz */
+{
XKB - xkbcomp can't find keycode includes (Bug?)
Hi All,
xkbcomp fail with message:
The XKEYBOARD keymap compiler (xkbcomp) reports:
Error:Can't find file xfree86 for keycodes include
Exiting
Abandoning keycodes file default
Errors from xkbcomp are not fatal to the X server
(EE) Error compiling keymap (server-0)
(EE) XKB: Couldn't compile keymap
The question is, does it look for those includes in directory specified with
--with-xkb-path?
I've got xkeyboard-config (ver. 1.5) build with --with-xkb-base set to
/etc/X11/xkb and --with-xkb-path (Xorg-server 1.5.99.902) also set to same
directory. I was trying to use setxkbmap (build with
--with-xkb-config-root=/etc/X11/xkb) but this didn't work. Finally I've managed
to fix (or workaround) that issue by creating symlink /usr/share/X11/xkb -
/etc/X11/xkb - {datadir}/X11/xkb is mentioned as default for --with-xkb-patch
xorg-server configure option. So does this option work? Maybe it's responsible
for sth different or this is a bug.
-Jacek
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] glx: Replace broken GLX visual setup with a fixed all mode.
On Sun, 2009-02-08 at 13:00 +0100, Eric Anholt wrote: With trying to match depths so that you didn't end up with a depth 24 fbconfig for the 32-bit composite visual, I broke the alpha bits on the depth 24 X visual, which angered other applications. But in fixing that, the pickFBconfigs code for minimal also could end up breaking GLX visuals if the same FBconfig was chosen for more than one X visual. We have no reason to not expose as many visuals as possible, but the old all mode didn't match any existing X visuals to GLX visuals, so normal GL apps didn't work at all. Instead, replace it with a simple combination of the two modes: Create GLX visuals by picking unique FBconfigs with as many features as possible for each X visual in order. Then, for all remaining FBconfigs that are appropriate for display, add a corresponding X and GLX visual. This gets all applications (even ones that aren't smart enough to do FBconfigs) get all the options to get the visual configuration they want. The only potential downside is that the composite ARGB visual is unique and gets a nearly full-featured GLX visual (except that the root visual might have taken the tastiest FBconfig), which means that a dumb compositing manager could waste resources. Write compositing managers using FBconfigs instead, please. I've just rebuilt my xorg with this applied, and seem to have lost some parts of the window decoration in compiz. Specifically, the window minimise / maximise close buttons, and the application icon. Could well be a compiz bug. Other than that, seems to be working so far. -- 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: [PATCH 8/9] fb: move some code to mi
commit 734b23e5982e171031077a2d5d6b5dc2a12e1a70 should fix the problem. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
How To Disable input driver
Hi I am using Xorg version - 1.5.2 I am developing kernel driver which create /dev/eventX - file. when i insert the kernel driver X11 thinks it's a mouse. how can i configure the X11 to ignore the driver (/dev/eventX) thanks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How To Disable input driver
On Wed, Feb 11, 2009 at 04:38:41PM +0200, linux multitouch wrote: Hi I am using Xorg version - 1.5.2 I am developing kernel driver which create /dev/eventX - file. when i insert the kernel driver X11 thinks it's a mouse. how can i configure the X11 to ignore the driver (/dev/eventX) thanks Why do you want to do this? -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] XI2 draft protocol specification (v 0.1)
Peter Hutterer wrote:
Thanks for the comments. All your suggestions have been added, but I'll
refrain from commenting on them much (the spec has to work on it's own
eventually).
No prob. Some details follow though.
FP1616
-Fixed point decimal in 16.16 format as 32 bit integer. The client is
-required to convert to 16.16 decimal format.
+Fixed point decimal in 16.16 format as 32 bit integer in the form of
+(value * 10e15). The client is required to convert to 16.16 decimal
+format.
TBH, that one puzzles me even more. In particular, what is decimal as
opposed to binary? Can you point me to code that does what you describe?
Or maybe you meant (value * 116)?
-HIERARCHYCHANGETYPE { CreateMaster, RemoveMaster, ChangeAttachment }
+HIERARCHYCHANGETYPE { CreateMaster, RemoveMaster, SlaveAttached,
+ SlaveDetached }
CHANGEMODE { Float, Attach }
I think that one has to go then, too.
Ah, and: CM, RM are imperative, SA/SD are passive and past. Pasto?
+client. RawDevice events are only generated for slave devices and provide
+both the raw data as supplied by the driver and transformed data as used
+in the server. Transformations include, but are not limited to, axis
+clipping and acceleration.
+Transformed valuator data may be equivalent to raw data. In this case,
+both raw and transformed valuator data is provided.
Much better.
Cheers,
Simon
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
USB Touchscreen
Hi, I'm using Xfbdev with TSlib and the Linux input event interface. The command line I'm using to launch X is: Xfbdev :0 -br -pn -mouse tslib,,device=/dev/input/event2 -noreset -screen 800x600x16 This is my problem, when I disconnect the touch some library (TSlib or X itself) lost the input device, this is the message: usb 1-1: USB disconnect, address 9 selected device is not a Linux input event device And the only way to restore the touch is relaunching X. What can I do to solve this behavior? I'm using it on an embedded device, when it enters in (kind of) sleep mode it shut down the USB power. Ideas? Comments? Regards, Diego A. Fons. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fedora 10, Belkin KVM, USB Mouse/Keyboard, NVIDIA Card, OpenOffice
Thanks -- I did just that (after a few trial and errors) and was able to get
it to crash:
Received signal SIGSEGV, Segmentation fault.
XkbStringText (str=0x21 Address 0x21 out of bounds, format=2) at
xkbtext.c:526
526for (ok= True,len=0,in=str;*in!='\0';in++,len++) {
(gdb)
Continuing.
Program received signal SIGABRT, Aborted.
0x0033dac32f05 in raise (sig=value optimized out) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Missing separate debuginfos, use: debuginfo-install libgcc-4.3.2-7.x86_64
(gdb) bt
#0 0x0033dac32f05 in raise (sig=value optimized out) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0033dac34a73 in abort () at abort.c:88
#2 0x004613f9 in ddxGiveUp () at xf86Init.c:1483
#3 0x004f208d in AbortServer () at log.c:407
#4 0x004f2755 in FatalError (f=0x56f4f0 Caught signal %d. Server
aborting\n) at log.c:553
#5 0x0047a689 in xf86SigHandler (signo=11) at xf86Events.c:593
#6 signal handler called
#7 XkbStringText (str=0x21 Address 0x21 out of bounds, format=2) at
xkbtext.c:526
#8 0x0055879a in XkbWriteXKBGeometry (file=0x7fd5f046c8c0,
xkb=0x1580e90, topLevel=0,
showImplicit=0, addOn=0x557fe0 _AddIncl, priv=0x7fd5f0d90820) at
xkbout.c:831
#9 0x00557d1b in XkbWriteXKBKeymapForNames (file=0x7fd5f046c8c0,
names=0x7fa6cde0,
xkb=0x1580e90, want=value optimized out, need=63) at xkbfmisc.c:346
#10 0x00561cba in XkbDDXCompileKeymapByNames () at ddxLoad.c:259
#11 XkbDDXLoadKeymapByNames (keybd=value optimized out,
names=0x7fa6cde0, want=127, need=63,
xkbRtrn=0x7fa6cee8, nameRtrn=0x7fa6cf00 , nameRtrnLen=4096) at
ddxLoad.c:357
#12 0x0053fb2b in ProcXkbGetKbdByName (client=0x7fd5f0f2d190) at
xkb.c:5642
#13 0x004468d4 in Dispatch () at dispatch.c:454
#14 0x0042cd1d in main (argc=9, argv=0x7fa6e0d8, envp=value
optimized out) at main.c:441
On Tue, Feb 10, 2009 at 6:53 PM, Dan Nicholson dbn.li...@gmail.com wrote:
On Tue, Feb 10, 2009 at 10:04 AM, Kevin Johnson kpj...@gmail.com wrote:
Hello,
Here is the setup. I am running two different desktop computers, each
with
their own monitor, but with only one keyboard / mouse. I am using a
Belkin
KVM switch to control the keyboard / mouse function between the two. The
switch has USB inputs and USB outputs.
I am running Fedora10 (F1)0) on each desktop computer. Each has a
different
NVIDIA Quadro card installed, and I am running NVIDIA drivers (different
version of each because the one card is not supported anymore).
Everything works fine, until I launch OpenOffice on either computer. At
that
point, when I use the KVM to switch mouse / keyboard to the other desktop
X
will crash. I have not been able to reproduce this with anything other
than
the OpenOffice suite of applications.
It has something to do with the evdev module here is the backtrace in
the Xorg.0.log
(EE) Belkin Corporation Flip CC: Read error: No such device
(II) config/hal: removing device Belkin Corporation Flip CC
(II) Belkin Corporation Flip CC: Close
(II) UnloadModule: evdev
(EE) Dell Dell USB Keyboard: Read error: No such device
(II) config/hal: removing device Dell Dell USB Keyboard
(II) Dell Dell USB Keyboard: Close
(II) UnloadModule: evdev
(II) config/hal: Adding input device Belkin Corporation Flip KVM
(**) Belkin Corporation Flip KVM: always reports core events
(**) Belkin Corporation Flip KVM: Device: /dev/input/event3
(II) Belkin Corporation Flip KVM: Found 5 mouse buttons
(II) Belkin Corporation Flip KVM: Found x and y relative axes
(II) Belkin Corporation Flip KVM: Configuring as mouse
(**) Belkin Corporation Flip KVM: YAxisMapping: buttons 4 and 5
(**) Belkin Corporation Flip KVM: EmulateWheelButton: 4,
EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device Belkin Corporation Flip KVM
(type: MOUSE)
(II) config/hal: Adding input device Belkin Corporation Flip KVM
(**) Belkin Corporation Flip KVM: always reports core events
(**) Belkin Corporation Flip KVM: Device: /dev/input/event7
(II) Belkin Corporation Flip KVM: Found keys
(II) Belkin Corporation Flip KVM: Configuring as keyboard
(II) XINPUT: Adding extended input device Belkin Corporation Flip KVM
(type: KEYBOARD)
(**) Option xkb_rules evdev
(**) Belkin Corporation Flip KVM: xkb_rules: evdev
(**) Option xkb_model pc105+inet
(**) Belkin Corporation Flip KVM: xkb_model: pc105+inet
(**) Option xkb_layout us
(**) Belkin Corporation Flip KVM: xkb_layout: us
Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4e7a26]
1: /usr/bin/Xorg(xf86SigHandler+0x39) [0x47a679]
2: /lib64/libc.so.6 [0x33dac32f90]
3: /usr/bin/Xorg(XkbStringText+0x1c) [0x56711c]
4: /usr/bin/Xorg(XkbWriteXKBGeometry+0x191) [0x5587d1]
5: /usr/bin/Xorg(XkbWriteXKBKeymapForNames+0x5bb) [0x557d1b]
6:
Current tinderbox regression (mesa)
http://tinderbox.x.org/builds/2009-02-10-0034/logs/libGL/#build In file included from nv04_surface_2d.c:5: ../../../../src/gallium/drivers/nouveau/nouveau_winsys.h:8:32: error: nouveau/nouveau_bo.h: No such file or directory ../../../../src/gallium/drivers/nouveau/nouveau_winsys.h:9:37: error: nouveau/nouveau_channel.h: No such file or directory ../../../../src/gallium/drivers/nouveau/nouveau_winsys.h:10:35: error: nouveau/nouveau_class.h: No such file or directory ../../../../src/gallium/drivers/nouveau/nouveau_winsys.h:11:36: error: nouveau/nouveau_device.h: No such file or directory ../../../../src/gallium/drivers/nouveau/nouveau_winsys.h:12:35: error: nouveau/nouveau_grobj.h: No such file or directory ../../../../src/gallium/drivers/nouveau/nouveau_winsys.h:13:38: error: nouveau/nouveau_notifier.h: No such file or directory ../../../../src/gallium/drivers/nouveau/nouveau_winsys.h:14:38: error: nouveau/nouveau_resource.h: No such file or directory -- Chris Ball c...@laptop.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 8/9] handle cea-ext data block and insert mode into mode list.
On Wed, 2009-02-11 at 17:17 +0800, Ma Ling wrote:
+void xf86FetchDataBlock(xf86MonPtr mon,
+int ext_type, int data_type,
+void *data)
+{
+int i;
+Uchar *ext;
+
+if (mon == NULL)
+ return;
+
+for (i = 0; i mon-no_sections; i++) {
+ ext = mon-rawData + EDID1_LEN * (i + 1);
+ if (ext[EXT_TAG] == ext_type)
+ break;
+}
+/* return if don't find corresponding extension type */
+if (i == mon-no_sections)
+ return;
+
+switch (ext[EXT_TAG]){
+case CEA_EXT:
+ extract_cea_data_block(ext, data_type, data);
+ break;
+case VTB_EXT:
+case DI_EXT:
+case LS_EXT:
+case MI_EXT:
+ break;
+}
+}
This doesn't seem like the right interface. VTB, for example, lets you
have multiple detailed timing blocks, but this interface would only let
you ask for one. Strictly speaking it's legal in CEA too, but I don't
think anyone's been stupid enough to encode their CEA block that way.
Also, returns void, but has a single void * outparameter? Ew.
Either make this an iterator like ForEachDetailedBlock, or lose the
ext_type and data_type and just grab the CEA video descriptor directly
(and return it, rather than outparam'ing it).
diff --git a/hw/xfree86/modes/xf86EdidModes.c
b/hw/xfree86/modes/xf86EdidModes.c
index 97c40bf..4760316 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -741,6 +741,104 @@ xf86DDCSetPreferredRefresh(int scrnIndex,
DisplayModePtr modes,
best-type |= M_T_PREFERRED;
}
+#define CEA_VIDEO_MODES_NUM 64
+static const DisplayModeRec CEAVideoModes[CEA_VIDEO_MODES_NUM] = {
This timing list actually brings up an unpleasant topic. How are
interlaced modes supposed to be represented inside the server? Detailed
blocks seem to mostly be written such that 1080i is described as 1920
wide, 540 high, with the interlace bit set; ie, that height is field
height. The mode list you've got here, and the standard mode list
already in the server, give height as frame height.
The language in the EDID spec describes detailed timing numbers as being
about the addressable image size of the mode, ie, frame height. So
probably we just need to correct detailed timings on the way in.
+static DisplayModePtr
+DDCModesFromCeaExtension(int scrnIndex, xf86MonPtr MonPtr)
CEA should be all-capitals for consistency.
- ajax
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: [PATCH 4/9] handle detailed timing operation in xf86EdidModes.c
On Wed, 2009-02-11 at 17:15 +0800, Ma Ling wrote:
+struct det_modes_parameter {
+xf86MonPtr DDC;
+ddc_quirk_t quirks;
+DisplayModePtr * Modes;
+Bool rb;
+Bool preferred;
+int timing_level;
+};
Why the double pointer on Modes? (Admittedly, X's love of pointer
typedefs is lame.)
- ajax
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 Disable input driver
On Wednesday 11 February 2009, linux multitouch wrote: Hi I am using Xorg version - 1.5.2 I am developing kernel driver which create /dev/eventX - file. when i insert the kernel driver X11 thinks it's a mouse. how can i configure the X11 to ignore the driver (/dev/eventX) thanks Assuming your Xorg server is configured via hal, you can place a file in /etc/hal/fdi/policy/ that removes the driver key. I use the following file to suppress a joystick from being recognized as an X11 input device: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input !-- Match on anything you like from lshal -- match key=input.product contains=SomeProduct Identifier remove key=info.capabilities/ remove key=input.x11_driver/ /match /match /device /deviceinfo Similarly you could use an fdi file to instruct Xorg to use your own input driver. Have a look at the fdi files provided for e.g. synaptics touchpads. HTH Magnus Kessler ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 8/9] fb: move some code to mi
On Wednesday 11 February 2009, Maarten Maathuis wrote: commit 734b23e5982e171031077a2d5d6b5dc2a12e1a70 should fix the problem. Thanks, Maarten. In the meantime Eric Anholt committed 5009127de7d9527ae329d1c2fbc7283648bde2e6 (http://cgit.freedesktop.org/xorg/driver/xf86-video- intel/commit/?id=5009127de7d9527ae329d1c2fbc7283648bde2e6) that fixes the issue on the intel driver side. Magnus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How To Disable input driver
On Wed, Feb 11, 2009 at 08:37:44PM +, Magnus Kessler wrote: On Wednesday 11 February 2009, linux multitouch wrote: Hi I am using Xorg version - 1.5.2 I am developing kernel driver which create /dev/eventX - file. when i insert the kernel driver X11 thinks it's a mouse. how can i configure the X11 to ignore the driver (/dev/eventX) thanks Assuming your Xorg server is configured via hal, you can place a file in /etc/hal/fdi/policy/ that removes the driver key. I use the following file to suppress a joystick from being recognized as an X11 input device: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input !-- Match on anything you like from lshal -- match key=input.product contains=SomeProduct Identifier remove key=info.capabilities/ remove key=input.x11_driver/ /match /match /device /deviceinfo Similarly you could use an fdi file to instruct Xorg to use your own input driver. Have a look at the fdi files provided for e.g. synaptics touchpads. Actually, just removing input.x11_driver alone is enough, it's the only thing we really care about in the server. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xmodmap: different keys have different keycode semantics?
Hello, I noticed a very strange thing about xmodmap. Apparently, the semantics of the keycode nr = keysyms command depend on the keycode. For example, when I assign the keysyms like this: keycode 25 = 0 1 2 3 4 5 6 7 8 9 keycode 38 = a b c d e f g h i j I get the following results (generated keysyms). Keycode 25 38 | 25 38 | 25 38 | 25 38 Key 0 a | 2 c | 8 g | 0 i Key + Shift 1 b | 3 d | 9 h | 1 j Key + ISO_Level3_Shift4 a | 6 e | 8 g | 4 i Key + Shift + ISO_Level3_Shift5 b | 7 f | 9 h | 5 j (successive columns are generated by pressing ISO_Next_Group once in between) So while the key with keycode 25 cycles between 3 groups, 2 of which allow the use of the level shift modifier, the key with keycode 38 apparently cycles between 4 groups, and none of them allows me use the modifier. Is there a reason for this behavior? And how can I change it? I would very much like to configure all my keys with modifier-aware 3 groups... Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] app/xinit: make startx's $? a useful value
When startx fails to start X, it's most likely xinit that failed. xinit returns a proper return code (1), but that gets clobbed in the startx script by clean-up commands. This patch saves $? from xinit and forces startx to exit with that value. This way, if startx actually fails to start X, $? reflects that. Signed-off-by: Andres Salomon dilin...@debian.org --- startx.cpp |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/startx.cpp b/startx.cpp index f911499..05d28e3 100644 --- a/startx.cpp +++ b/startx.cpp @@ -320,6 +320,7 @@ XINIT $client $clientargs -- $server $display $serverargs #endif #endif +retval=$? if [ x$enable_xauth = x1 ] ; then if [ x$removelist != x ]; then @@ -347,3 +348,6 @@ screenrestore #if defined(sun) kbd_mode -a #endif + +exit $retval + -- 1.5.6.5 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[Xlib] Saving state before an unmap
Hi all, Basically I want to unmap a window, fiddle with it a bit (like removing the border, removing the maximize button, etc...) and then remap it. The problem I'm running into is that unmapping the window results in unintended side-effects. Take the _NET_WM_STATE property for example, it gets blown away if you unmap the window. This results in things like a window being kept-below before I fiddle with it, but then after I remap it, the window will no longer be kept-below anymore. Is there a general Xlib idiom for saving all of a window's state before an unmap operation, and then restoring it after a subsequent re- map operation? The solution I came up with (no doubt sub-optimal) is this: 1. Get the current _NET_WM_STATE property. 2. unmap the window and fiddle with it. 3. re-map the window. 4. use XChangeProperty() to change _NET_WM_STATE back to what it was before, Atom by Atom (see next step as to why I do it Atom by Atom). 5. Send out an ClientMessage XEvent for every Atom we just changed in _NET_WM_STATE (I think this is necessary because the union we get for a ClientMessage isn't big enough for us to send notification of all changed Atoms if there are many multiple Atoms set for the _NET_WM_STATE property). There has to be a better way, right? Alternatively, if there is a way to remove the close/minimize/maximize buttons or window-decorations from a window w/o unmapping it (or w/o losing the window's current _NET_WM_STATE property) that'd be awesome. It has to work on an already mapped window, as that is my intended use case. Essentially, I'm writing a window-manager-lite on top of a real window manager so that I can manipulate all the windows of all the disparate applications of the software suite I'm developing in various ways. It's a little complicated, but probably not as complicated as I'm making it sound. Essentially the use case is that the user may at any point command the window of another application to remove (or un- remove) its border/close-button/etc, and I need to respect as much of the current window state of the target window as possible (ie: _NET_WM_STATE and possibly other Extended Window Manager Hints properties that I haven't even thought of yet.) Any ideas? -- Andrew Troschinetz Applied Research Laboratories ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] glx: Replace broken GLX visual setup with a fixed all mode.
On Wed, 2009-02-11 at 12:07 +, Peter Clifton wrote: On Sun, 2009-02-08 at 13:00 +0100, Eric Anholt wrote: With trying to match depths so that you didn't end up with a depth 24 fbconfig for the 32-bit composite visual, I broke the alpha bits on the depth 24 X visual, which angered other applications. But in fixing that, the pickFBconfigs code for minimal also could end up breaking GLX visuals if the same FBconfig was chosen for more than one X visual. We have no reason to not expose as many visuals as possible, but the old all mode didn't match any existing X visuals to GLX visuals, so normal GL apps didn't work at all. Instead, replace it with a simple combination of the two modes: Create GLX visuals by picking unique FBconfigs with as many features as possible for each X visual in order. Then, for all remaining FBconfigs that are appropriate for display, add a corresponding X and GLX visual. This gets all applications (even ones that aren't smart enough to do FBconfigs) get all the options to get the visual configuration they want. The only potential downside is that the composite ARGB visual is unique and gets a nearly full-featured GLX visual (except that the root visual might have taken the tastiest FBconfig), which means that a dumb compositing manager could waste resources. Write compositing managers using FBconfigs instead, please. I've just rebuilt my xorg with this applied, and seem to have lost some parts of the window decoration in compiz. Specifically, the window minimise / maximise close buttons, and the application icon. Could well be a compiz bug. Other than that, seems to be working so far. Ok, seems to be related to another upgrade: https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/327793 So it is not related to the above patch. Sorry for the noise. -- 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: Fedora 10, Belkin KVM, USB Mouse/Keyboard, NVIDIA Card, OpenOffice
On Wed, Feb 11, 2009 at 10:51:25AM -0500, Kevin Johnson wrote:
Thanks -- I did just that (after a few trial and errors) and was able to get
it to crash:
Received signal SIGSEGV, Segmentation fault.
XkbStringText (str=0x21 Address 0x21 out of bounds, format=2) at
xkbtext.c:526
526for (ok= True,len=0,in=str;*in!='\0';in++,len++) {
(gdb)
Continuing.
Program received signal SIGABRT, Aborted.
0x0033dac32f05 in raise (sig=value optimized out) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
[...]
#6 signal handler called
#7 XkbStringText (str=0x21 Address 0x21 out of bounds, format=2) at
xkbtext.c:526
#8 0x0055879a in XkbWriteXKBGeometry (file=0x7fd5f046c8c0,
xkb=0x1580e90, topLevel=0,
showImplicit=0, addOn=0x557fe0 _AddIncl, priv=0x7fd5f0d90820) at
xkbout.c:831
[...]
Oops, the geom colour name copying code is very, very broken: it needs
to do a deep copy instead of just taking the address (!) of the source.
Please file a bug and assign it to me.
Cheers,
Daniel
signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
What is the role of drawable parameter in XCreatePixmap()
Hi, We pass a drawable parameter as input while calling XCreatePixmap().Now this drawable can be either a X window Id(which we got from a previous call to XCreateWindow) Or, this drawable could be a X pixmap id(which we got from a previous XCreatePixmap() call). I checked the xlib manual and it mentions that this drawable parameter is used to just determine the screen number, where the new pixmap will be created. I want to know is there any other significance of this drawable? Is there any difference between the behavior of when we pass X window id as drawable to XCreatePixmap and when we pass a X pixmap id as drawable to another XCreatePixmap call. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 1/9] Includes new structures and defined MACRO
Hi ajax
based on your suggestion, I will fix them you mentioned in next
version.
Thanks a lot!
Ma Ling
On Thu, 2009-02-12 at 03:19 +0800, Adam Jackson wrote:
On Wed, 2009-02-11 at 17:12 +0800, Ma Ling wrote:
+struct cea_audio_blk {
+ Uchar descs[3];
+};
I think you have this wrong. The block is up to 31 bytes long, based on
the length field. Each descriptor is three bytes, so there can be up to
10.
Yes, this is a bug, I will fix!
+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;
+};
I don't see the port bits mentioned in the base CEA spec, at all. Where
are you getting this from?
Oh, I saw it in 8.3.2 HDMI Vendor-Specific Data Block (HDMI VSDB) of
HDMISpecification13a.pdf
- ajax
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 4/9] handle detailed timing operation in xf86EdidModes.c
On Thu, 2009-02-12 at 03:30 +0800, Adam Jackson wrote:
On Wed, 2009-02-11 at 17:15 +0800, Ma Ling wrote:
+struct det_modes_parameter {
+xf86MonPtr DDC;
+ddc_quirk_t quirks;
+DisplayModePtr * Modes;
+Bool rb;
+Bool preferred;
+int timing_level;
+};
Why the double pointer on Modes? (Admittedly, X's love of pointer
typedefs is lame.)
Ok, I will use single pointer to replace it!
- ajax
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 8/9] handle cea-ext data block and insert mode into mode list.
On Thu, 2009-02-12 at 03:11 +0800, Adam Jackson wrote:
On Wed, 2009-02-11 at 17:17 +0800, Ma Ling wrote:
+void xf86FetchDataBlock(xf86MonPtr mon,
+int ext_type, int data_type,
+void *data)
+{
+int i;
+Uchar *ext;
+
+if (mon == NULL)
+ return;
+
+for (i = 0; i mon-no_sections; i++) {
+ ext = mon-rawData + EDID1_LEN * (i + 1);
+ if (ext[EXT_TAG] == ext_type)
+ break;
+}
+/* return if don't find corresponding extension type */
+if (i == mon-no_sections)
+ return;
+
+switch (ext[EXT_TAG]){
+case CEA_EXT:
+ extract_cea_data_block(ext, data_type, data);
+ break;
+case VTB_EXT:
+case DI_EXT:
+case LS_EXT:
+case MI_EXT:
+ break;
+}
+}
This doesn't seem like the right interface. VTB, for example, lets you
have multiple detailed timing blocks, but this interface would only let
you ask for one. Strictly speaking it's legal in CEA too, but I don't
think anyone's been stupid enough to encode their CEA block that way.
Also, returns void, but has a single void * outparameter? Ew.
Either make this an iterator like ForEachDetailedBlock, or lose the
ext_type and data_type and just grab the CEA video descriptor directly
(and return it, rather than outparam'ing it).
ok, I will chose the similar approach like xf86ForEachDetailedBlock.
diff --git a/hw/xfree86/modes/xf86EdidModes.c
b/hw/xfree86/modes/xf86EdidModes.c
index 97c40bf..4760316 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -741,6 +741,104 @@ xf86DDCSetPreferredRefresh(int scrnIndex,
DisplayModePtr modes,
best-type |= M_T_PREFERRED;
}
+#define CEA_VIDEO_MODES_NUM 64
+static const DisplayModeRec CEAVideoModes[CEA_VIDEO_MODES_NUM] = {
This timing list actually brings up an unpleasant topic. How are
interlaced modes supposed to be represented inside the server? Detailed
blocks seem to mostly be written such that 1080i is described as 1920
wide, 540 high, with the interlace bit set; ie, that height is field
height.
I notice whether xf86GetDefaultModes function will search
xf86DefaultModes table containing interlaced mode, but whether duplicate
mode line or not depends on interalceAllowed flag set by driver, So can
we implement the similar function like that to handle CEA short video
descriptor, and Mode structure always use 1080 as VDisplay?
The mode list you've got here, and the standard mode list
already in the server, give height as frame height.
The language in the EDID spec describes detailed timing numbers as being
about the addressable image size of the mode, ie, frame height. So
probably we just need to correct detailed timings on the way in.
+static DisplayModePtr
+DDCModesFromCeaExtension(int scrnIndex, xf86MonPtr MonPtr)
CEA should be all-capitals for consistency.
OK I will fix it!
- ajax
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xvesa black magic
Apparently xinit was eating a lot of potentially useful output. Anybody able to extract anything meaningful from this session? # Xvesa -mode 0x117 -kb -mouse mouse,/dev/input/mice Int 10h (0x4F10) failed: 0x014F (function call failed) No DPMS Support -1 FreeFontPath: FPE build-ins refcount is 2, should be 1; fixing. # Xvesa -mode 0x117 -mouse mouse,/dev/input/mice Mouse device is serial port, protocol exps/2 is not serial protocol Int 10h (0x4F10) failed: 0x014F (function call failed) No DPMS Support -1 FreeFontPath: FPE built-ins refcount is 2, should be 1; fixing. # Xvesa -mode 0x117 Int 10h (0x4F10) failed: 0x014F (function call failed) No DPMS Support -1 FreeFontPath FPE built-ins refcount is 2, should be 1; fixing. For those who came in late, this is under Qemu. I had to retype the output (Qemu doesn't seem to support copy-paste from a console session, hehe) so I hope there's no typos in there. Once Xvesa is launched, I can't make it respond to ctrl-alt-backspace signals from Qemu; to get at the output above, I had to launch sleep 30; pkill X in another terminal before each time I launched X. I have other people's builds of Xvesa running happily under the same emulator, so I can't see that the problem is with the emulator. I don't know off the top of my head where I can look up kernel calls (and Google isn't helping right now) so I don't know what 0x4F10 does. (I'm going to guess that it involves video mode setting--if I leave off the -mode flag, the server goes into a loop making failing 0x4F10 calls, which I assume is a symptom of a failed autodetect routine.) Also, the Mouse device is a serial port message is interesting. I can't seem to find any other magic combination of flags that triggers that message; it makes me wonder if the mouse device I'm pointing Xvesa at is not what I think it is. If anyone can point me in the right direction to continue debugging this, I would be very grateful. -- William Tracy afishion...@gmail.com -- wtr...@calpoly.edu Vice President, Cal Poly Linux Users' Group http://www.cplug.org I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall, frequently mis-attributed to Voltaire ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 8/9] handle cea-ext data block and insert mode into mode list.
Sorry, please use this one to replace last email.
Thanks
Ma Ling
On Thu, 2009-02-12 at 03:11 +0800, Adam Jackson wrote:
On Wed, 2009-02-11 at 17:17 +0800, Ma Ling wrote:
+void xf86FetchDataBlock(xf86MonPtr mon,
+int ext_type, int data_type,
+void *data)
+{
+int i;
+Uchar *ext;
+
+if (mon == NULL)
+ return;
+
+for (i = 0; i mon-no_sections; i++) {
+ ext = mon-rawData + EDID1_LEN * (i + 1);
+ if (ext[EXT_TAG] == ext_type)
+ break;
+}
+/* return if don't find corresponding extension type */
+if (i == mon-no_sections)
+ return;
+
+switch (ext[EXT_TAG]){
+case CEA_EXT:
+ extract_cea_data_block(ext, data_type, data);
+ break;
+case VTB_EXT:
+case DI_EXT:
+case LS_EXT:
+case MI_EXT:
+ break;
+}
+}
This doesn't seem like the right interface. VTB, for example, lets you
have multiple detailed timing blocks, but this interface would only let
you ask for one. Strictly speaking it's legal in CEA too, but I don't
think anyone's been stupid enough to encode their CEA block that way.
Also, returns void, but has a single void * outparameter? Ew.
Either make this an iterator like ForEachDetailedBlock, or lose the
ext_type and data_type and just grab the CEA video descriptor directly
(and return it, rather than outparam'ing it).
ok, I will chose the similar approach like xf86ForEachDetailedBlock.
diff --git a/hw/xfree86/modes/xf86EdidModes.c
b/hw/xfree86/modes/xf86EdidModes.c
index 97c40bf..4760316 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -741,6 +741,104 @@ xf86DDCSetPreferredRefresh(int scrnIndex,
DisplayModePtr modes,
best-type |= M_T_PREFERRED;
}
+#define CEA_VIDEO_MODES_NUM 64
+static const DisplayModeRec CEAVideoModes[CEA_VIDEO_MODES_NUM] = {
This timing list actually brings up an unpleasant topic. How are
interlaced modes supposed to be represented inside the server? Detailed
blocks seem to mostly be written such that 1080i is described as 1920
wide, 540 high, with the interlace bit set; ie, that height is field
height. The mode list you've got here, and the standard mode list
already in the server, give height as frame height.
I notice xf86GetDefaultModes function will search
xf86DefaultModes table which also contain interlaced mode, but whether
duplicate interlaced mode line or not depends on interalceAllowed flag
set by driver, So can we implement the similar function like that to
handle CEA short video descriptor, and Mode structure always use 1080
as VDisplay?
The language in the EDID spec describes detailed timing numbers as being
about the addressable image size of the mode, ie, frame height. So
probably we just need to correct detailed timings on the way in.
+static DisplayModePtr
+DDCModesFromCeaExtension(int scrnIndex, xf86MonPtr MonPtr)
CEA should be all-capitals for consistency.
OK I will fix it!
- ajax
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xvesa black magic
Also, for completeness, not that I expect it to be helpful: # Xvesa -mode 0x117 -kb -mouse mouse,/dev/input/mice -keybd keyboard Int 10h (0x4F10) failed: 0x014F (function call failed) No DPMS Support -1 FreeFontPath: FPE build-ins refcount is 2, should be 1; fixing. -- William Tracy afishion...@gmail.com -- wtr...@calpoly.edu Vice President, Cal Poly Linux Users' Group http://www.cplug.org I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall, frequently mis-attributed to Voltaire ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How To Disable input driver
Hi thanks for the fast reply. i want this option because i am developing the kernel driver. when the X11 see a new input device connected. it recognize it like a mouse, and X11 behave wired. I didn't develop any X11 driver. The X11 detect the the device as (type: MOUSE), and if remove evdev_drv.so I will not have mouse in the system, so i can not remove the driver, but i would like X11 to ignore this /dev/input/files/. so i will try to configure the HAL Magnus Kessler suggested. On Wed, Feb 11, 2009 at 5:27 PM, Matthew Garrett mj...@srcf.ucam.orgwrote: On Wed, Feb 11, 2009 at 04:38:41PM +0200, linux multitouch wrote: Hi I am using Xorg version - 1.5.2 I am developing kernel driver which create /dev/eventX - file. when i insert the kernel driver X11 thinks it's a mouse. how can i configure the X11 to ignore the driver (/dev/eventX) thanks Why do you want to do this? -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xmodmap: different keys have different keycode semantics?
On Wed, Feb 11, 2009 at 04:19:57PM -0500, Nikolaus Rath wrote: I noticed a very strange thing about xmodmap. Apparently, the semantics of the keycode nr = keysyms command depend on the keycode. Yes. You may find reading about XKB enlightening: http://pascal.tsu.ru/en/xkb/ or http://www.charvolant.org/~doug/xkb/ Specifically, the type assigned to a keycode determines how the various shift keys select a level. Marius Gedminas -- Since this protocol deals with Firewalls there are no real security considerations. -- RFC 3093 signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
