[PATCH 6/9] handle detailed timing operation in xf86Configure.c

[Ma Ling]

handle detailed timing from EDID and CEA extension 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..c5d8f34 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;i4;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/9] handle detailed timing operation in print_edid.c

[Ma Ling]

print all detailed timing blocks of EDID and CEA extension.

---
 hw/xfree86/ddc/print_edid.c |  256 +++---
 1 files changed, 140 insertions(+), 116 deletions(-)

diff --git a/hw/xfree86/ddc/print_edid.c b/hw/xfree86/ddc/print_edid.c
index 7b6e298..2ad199f 100644
--- a/hw/xfree86/ddc/print_edid.c
+++ b/hw/xfree86/ddc/print_edid.c
@@ -333,125 +333,143 @@ print_detailed_timings(int scrnIndex, struct 
detailed_timings *t)
 }
 }
 
+/* This function handle all detailed patchs,
+ * including EDID and EDID-extension
+ */
+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;iDET_TIMINGS;i++) {
-   switch (m[i].type) {
-   case DT:
-   print_detailed_timings(scrnIndex,m[i].section.d_timings);
-   break;
-   case DS_SERIAL:
-   xf86DrvMsg(scrnIndex,X_INFO,Serial No: %s\n,m[i].section.serial);
-   break;
-   case DS_ASCII_STR:
-   xf86DrvMsg(scrnIndex,X_INFO, %s\n,m[i].section.ascii_data);
-   break;
-   case DS_NAME:
-   xf86DrvMsg(scrnIndex,X_INFO,Monitor name: %s\n,m[i].section.name);
-   break;
-   case DS_RANGES:
-   {
-   struct monitor_ranges *r = m[i].section.ranges;
+int j, scrnIndex;
+struct det_print_parameter *p;
+
+p = (struct det_print_parameter *)data;
+scrnIndex = p-m-scrnIndex;
+xf86DetTimingApplyQuirks(det_mon,p-quirks,
+ p-m-features.hsize,
+ p-m-features.vsize);
+
+switch (det_mon-type) {
+case DT:
+print_detailed_timings(scrnIndex,det_mon-section.d_timings);
+break;
+case DS_SERIAL:
+xf86DrvMsg(scrnIndex,X_INFO,Serial No: %s\n,det_mon-section.serial);
+break;
+case DS_ASCII_STR:
+xf86DrvMsg(scrnIndex,X_INFO, %s\n,det_mon-section.ascii_data);
+break;
+case DS_NAME:
+xf86DrvMsg(scrnIndex,X_INFO,Monitor name: 
%s\n,det_mon-section.name);
+break;
+case DS_RANGES:
+{
+struct monitor_ranges *r = det_mon-section.ranges;
+xf86DrvMsg(scrnIndex,X_INFO,
+   Ranges: V min: %i V max: %i Hz, H min: %i H max: %i kHz,,
+   r-min_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; j5; j++)
xf86DrvMsg(scrnIndex,X_INFO,
-  

[PATCH 8/9] handle cea-ext data block in interpret_edid.c

[Ma Ling]

handle CEA extension data block from CEA extension

---
 hw/xfree86/ddc/interpret_edid.c |   57 +++
 1 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index 327f7d1..ef37a60 100644
--- a/hw/xfree86/ddc/interpret_edid.c
+++ b/hw/xfree86/ddc/interpret_edid.c
@@ -159,6 +159,63 @@ void xf86ForEachDetailedBlock(xf86MonPtr mon,
 }
 }
 
+static void handle_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:
+   handle_cea_data_block(ext, data_type, 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 9/9] append modes into mode list from short video descriptor of cea-ext in xf86EdidModes.c

[Ma Ling]

append modes from short video descriptor in CEA extension into mode list.

---
 hw/xfree86/ddc/xf86DDC.h |3 +
 hw/xfree86/modes/xf86EdidModes.c |  102 ++
 2 files changed, 105 insertions(+), 0 deletions(-)

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..12d7780 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 */
+{ MODEPREFIX,54000, 1440, 1472, 1596, 1716, 0,  480,  489,  495,  525, 
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 14:1440x...@60hz */
+{ MODEPREFIX,54000, 1440, 1472, 1596, 1716, 0,  480,  489,  495,  525, 
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 15:1440x...@60hz */
+{ MODEPREFIX,   148500, 1920, 2008, 2052, 2200, 0, 1080, 1084, 1089, 1125, 
0, V_PHSYNC | V_PVSYNC, MODESUFFIX }, /* VIC 16:1920x1...@60hz */
+{ MODEPREFIX,27000,  720,  732,  796,  864, 0,  576,  581,  586,  625, 
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 17:720x...@50hz */
+{ MODEPREFIX,27000,  720,  732,  796,  864, 0,  576,  581,  586,  625, 
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 18:720x...@50hz */
+{ MODEPREFIX,74250, 1280, 1720, 1760, 1980, 0,  720,  725,  730,  750, 
0, V_PHSYNC | V_PVSYNC, MODESUFFIX }, /* VIC 19: 1280x...@50hz */
+{ MODEPREFIX,74250, 1920, 2448, 2492, 2640, 0, 1080, 1084, 1094, 1125, 
0, V_PHSYNC | V_PVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 20:1920x10...@50hz */
+{ MODEPREFIX,27000, 1440, 1464, 1590, 1728, 0,  576,  580,  586,  625, 
0, V_NHSYNC | V_NVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 21:1440x5...@50hz */
+{ MODEPREFIX,27000, 1440, 1464, 1590, 1728, 0,  576,  580,  586,  625, 
0, V_NHSYNC | V_NVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 22:1440x5...@50hz */
+{ MODEPREFIX,27000, 1440, 1464, 1590, 1728, 0,  288,  290,  293,  312, 
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 23:1440x...@50hz */
+{ MODEPREFIX,27000, 1440, 1464, 1590, 1728, 0,  288,  290,  293,  312, 
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 24:1440x...@50hz */
+{ MODEPREFIX,54000, 2880, 2928, 3180, 3456, 0,  576,  580,  586,  625, 
0, V_NHSYNC | V_NVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 25:2880x5...@50hz */
+{ 

Re: wrong colors with Xv extension and image format id: 0x59565955 (UYVY) from an rgb mapping

[Amos Tibaldi]

2009/1/22 Tomas Carnecky t...@dbservice.com

 On 01/22/2009 06:15 AM, Amos Tibaldi wrote:


 Hello,
 I am trying to use the Xv extension in order to display images on
 windows. I have obtained the image formats with
 xvc.fo http://xvc.fo = XvListImageFormats( xvc.display, xvc.port, (int
 *)formats );
 and I have chosen the format
 id: 0x59565955 (UYVY)
 guid: 55595659--0010-8000-00aa00389b71
 bits per pixel: 16
 number of planes: 1
 type: YUV (packed)


 [snip]

  and to display the image with
 void XVWindow::Redraw()
 {
 unsigned short int u, y, v;
 RGBToUYVY(255,255,0,u,y,v);
 unsigned short int thecolor = u  12 | y  8 | v  4 | y;

 for ( int y=0; yImageHeight; y++ )
 for ( int x=0; xImageWidth; x++ )
 ((unsigned short int *)BGimage-data)[ y * ImageWidth + x ] = thecolor;

 counter++;
 XvPutImage( xvc.display, xvc.port, window, gc,
 BGimage, 0, 0, ImageWidth, ImageHeight,
 0, 0, WindowWidth, WindowHeight );
 }


 I think you are confused by 'bits per pixel: 16' in the Xv format list.
 Your code in :Redraw() that composes the pixel is wrong. I know I couldn't
 explain it better, so I'm including a link to a website that explains it
 pretty well:
 http://www.fourcc.org/yuv.php#YUY2
 (Each macropixel is 32 bits, so each of the YUV components is 8 bit and not
 4 like you used in your code)

 tom


 Hello, BGImage-data_size is equal to w x h x 2 bytes (2B per pixel in the
data allocated), and X has calculated it. Moreover I have tried even with
24 |16|8 and the thing is the same. Are you sure of that?

Thanks,


-- 
Amos Tibaldi
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: wrong colors with Xv extension and image format id: 0x59565955 (UYVY) from an rgb mapping

[Tomas Carnecky]

On 01/22/2009 11:26 AM, Amos Tibaldi wrote:


 2009/1/22 Tomas Carnecky t...@dbservice.com mailto:t...@dbservice.com

 On 01/22/2009 06:15 AM, Amos Tibaldi wrote:


 Hello,
 I am trying to use the Xv extension in order to display images on
 windows. I have obtained the image formats with
 xvc.fo http://xvc.fo http://xvc.fo = XvListImageFormats(
 xvc.display, xvc.port, (int

 *)formats );
 and I have chosen the format
 id: 0x59565955 (UYVY)
 guid: 55595659--0010-8000-00aa00389b71
 bits per pixel: 16
 number of planes: 1
 type: YUV (packed)


 [snip]


 and to display the image with
 void XVWindow::Redraw()
 {
 unsigned short int u, y, v;
 RGBToUYVY(255,255,0,u,y,v);
 unsigned short int thecolor = u  12 | y  8 | v  4 | y;

 for ( int y=0; yImageHeight; y++ )
 for ( int x=0; xImageWidth; x++ )
 ((unsigned short int *)BGimage-data)[ y * ImageWidth + x ] =
 thecolor;

 counter++;
 XvPutImage( xvc.display, xvc.port, window, gc,
 BGimage, 0, 0, ImageWidth, ImageHeight,
 0, 0, WindowWidth, WindowHeight );
 }


 I think you are confused by 'bits per pixel: 16' in the Xv format
 list. Your code in :Redraw() that composes the pixel is wrong. I
 know I couldn't explain it better, so I'm including a link to a
 website that explains it pretty well:
 http://www.fourcc.org/yuv.php#YUY2
 (Each macropixel is 32 bits, so each of the YUV components is 8 bit
 and not 4 like you used in your code)

 tom


 Hello, BGImage-data_size is equal to w x h x 2 bytes (2B per pixel in
 the data allocated), and X has calculated it. Moreover I have tried even
 with
 24 |16|8 and the thing is the same. Are you sure of that?


Yes, I'm sure of that.

There's one Y per pixel, U and V are downsampled (one U and one V per 
two pixels). You need to process two pixels at once. Y0 and Y1 is 
separate for each pixel, U0 and V0 is for both pixels.

Your code should be:
for ( int x=0; xImageWidth/2; x+=2 ) {
   // get r,g,b of pixel one, convert that to Y0
   // get r,g,b of pixel two, convert that to Y1
   // average of r,g,b of pixel one+two, convert that to U0 and V0

   // assuming BGimage-data is of type 'unsigned char', eg. 8 bit

   // now we write one 'macropixel' or two 'screen-pixels'
   // that's 32bits, but because it's two screen pixels, the effective
   // 'bits per pixel' is 16.
   BGimage-data[ y * ImageWidth + (x + 0) ] = Y0;
   BGimage-data[ y * ImageWidth + (x + 1) ] = U0;
   BGimage-data[ y * ImageWidth + (x + 2) ] = Y1;
   BGimage-data[ y * ImageWidth + (x + 3) ] = V0;
}



___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: wrong colors with Xv extension and image format id: 0x59565955 (UYVY) from an rgb mapping

[Simon Farnsworth]

Amos Tibaldi wrote:
 unsigned short int thecolor =  u  12 | y  8 | v  4 | y;
 
This is completely wrong. In a UYVY image, you have two different 8-bit
Y components, sharing an 8-bit U component, and an 8-bit V component. In
pseudocode, creating a 32-bit UYVY pixel pair from two RGB pixels:

(y, u, v) RGBtoYUV( r, g, b )
{
y =  0.299 * r +
 0.587 * g +
 0.114 * b;

u = -0.147 * r +
-0.289 * g +
 0.436 * b;

v =  0.615 * r +
-0.515 * g +
-0.100 * b;
}

uyvy RGBtoUYUV( r1, g1, b1, r2, g2, b2 )
{
(y1,u1,v1) = RGBtoYUV( r1, g1, b1 )
(y2,u2,v2) = RGBtoYUV( r2, g2, b2 )

u = (u1 + u2) / 2; // Or other decimation strategy
v = (v1 + v2) / 2; // Or other decimation strategy

uyvy  = 8bits(u)  24;
uyvy |= 8bits(y1)  16;
uyvy |= 8bits(v)  8;
uyvy |= 8bits(y2);
}
-- 
Simon Farnsworth

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: libXrender - documentation?

[Charles Lindsey]

In fe028d69955796489b510ce43dbbe803112cd...@rrsmsx503.amr.corp.intel.com 
Wichmann, Mats D mats.d.wichm...@intel.com writes:

It seems that a library providing an API ought to have docs,
even if the main consumer is another library.  That way the
producer/consumer relationship is codified and there's
actually something to refer to if one or the other changes.

Absolutely so. The main reason people might need it, even if they were not
toolkit developers, is so that they could trace apparent bugs or other
misfeatures that they had encountered in some application.

In my case, I was looking for some unacceptable CPU usage in Opera, which
is built on top of QT. I traced that down to a bug/misfeature in libxft,
which I reported on this list on Nov 26th under the Subject LibXft :
xftglyphcore woes, hoping to catch the eye of the libxft developers
(sadly, noone responded). Essentially, libxft was making a meal out of its
anti-aliasing, and I proposed a patch which at least cured the symptoms.

In a subsequent thread 2D antialiasing? on this list, I was bemoaning
the fact that antialiasing by that method would waste huge amounts of
bandwidth if the client were separated from the Xserver by some slow
network, and someone claimed to me, offlist, that Xrender provided
server-side antialiasing.

So I wanted to verify that claim. Now that this list has pointed me to
Keith Packard's The X Rendering Extension, I have done a quick scan of
that, but can still find no mention of antialiasing. Moreover, that
describes the protocol, rather than the libXrender interface that is more
conveniently used to access it,

Xrender is in LSB, but is not documented.  As a result,
LSB would be willing to help if there's interest in working
up docs.  Or, alternatively, listen to an argument that a
library like Xrender actually shouldn't be in the spec, that
only cairo should be exposed.

Yes, that would be welcome, but this is not really a Linux problem. It is
an Xorg problem.

-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: c...@clerew.man.ac.uk  Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: libXrender - documentation?

[Clemens Eisserer]

Most likely I will write some XRender documentation as part of my
bachelor thesis.

 In a subsequent thread 2D antialiasing? on this list, I was bemoaning
 the fact that antialiasing by that method would waste huge amounts of
 bandwidth if the client were separated from the Xserver by some slow
 network, and someone claimed to me, offlist, that Xrender provided
 server-side antialiasing.

 So I wanted to verify that claim. Now that this list has pointed me to
 Keith Packard's The X Rendering Extension, I have done a quick scan of
 that, but can still find no mention of antialiasing. Moreover, that
 describes the protocol, rather than the libXrender interface that is more
 conveniently used to access it,
Yes, that was me ;)

Antialiasing is usually done by transferring the geometry you intend
to render into a mask-pixmap, this can be done with:
- XPutImage (client-side geometry rasterization)
- XRenderAddTraps

and doing a composite operation with that mask.

or by using an implicit mask with:
- XRenderCompositeTrapezoids

However as far as I know xft already has a XRender aware backend
(using the XRender*Glyphs functions), as well as legacy support for
pre-xrender servers.

- Clemens
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xorg with ATI / RV370 sneakily eats half my CPU with empty screen?

[John Clarke]

Thanks to everybody for helping.

oprofile has a mystifying array of possible options to log, but the -b option 
to top and xrestop have helped shed some light.

The problem still occurs with the vesa driver - it looks like its the 
screensaver or screen locker.

I'll post again when I've got it figured out.

Regards
John

 
 
 


 Message Received: Jan 21 2009, 12:09 PM
 From: Frank de Lange 
 To: John Clarke 
 Cc: xorg@lists.freedesktop.org
 Subject: Re: Xorg with ATI / RV370 sneakily eats half my CPU with empty screen?
 
 
 John Clarke wrote:
  Dear All,
  
  Following an upgrade to Suse 11.1 I find that Xorg is eating my CPU alive.  
  Here's the output from top:
  
  28834 johncc20   0 1437m 615m 298m R 98.2 15.5 794:20.69 isis
   3103 root  20   0  748m 398m 7072 S  1.7 10.1   1080:03 Xorg
  
  I don't know how the massive Xorg usage gets clocked up - I never see more 
  than 1-2% used, but nonetheless next morning there it is and my batch jobs 
  are taking twice as long to run.
  
  There is no display stuff going on at all.  Screensaver is now a simple 
  black screen (although that made no difference) and the batch jobs are 
  compute only, no graphics.  Basically only the clock is changing.
  
  Google didn't turn up anything useful - I don't even know how to increase 
  the logging level to tell me what Xorg is doing.
  
  Please help, I'm going mad.
  Thanks
  John
 
 Can you log in remotely to this machine so that you can observe X while
 it is in the screensaver? It sounds strange that you never observe more
 than 1-2% but it still seems to chew so much time. Maybe that simple
 black screensaver still makes X go bezerk...
 
 Cheers//Frank
 ___
 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: [PATCH 1/9] Includes some new structures and defined MACRO in edid.h

[Alex Deucher]

On Thu, Jan 22, 2009 at 2:46 AM, Ma Ling ling...@intel.com wrote:
 defined corresponding structure and MACRO for detailed timing and CEA data 
 blocks.

 ---
  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..7167f64 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)

I would suggest putting parentheses around x in the above macros, e.g.,
#define VENDOR_LATENCY_PRESENT_I(x)  ( ( (x)  6)  0x01)
to avoid problems with passing things to the macros.

Alex
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Current tinderbox regression (xserver)

[Chris Ball]

http://tinderbox.x.org/builds/2009-01-22-0007/logs/xserver/#build

Keyboard.c: In function 'xnestKeyboardProc':
Keyboard.c:177: warning: passing argument 1 of 'XkbSetRulesDflts' from
incompatible pointer type
Keyboard.c:177: error: too many arguments to function 'XkbSetRulesDflts'
Keyboard.c:178: warning: implicit declaration of function 
'XkbInitKeyboardDeviceStruct'
Keyboard.c:178: warning: nested extern declaration of 
'XkbInitKeyboardDeviceStruct'
Keyboard.c:206: warning: passing argument 1 of 'InitKeyboardDeviceStruct' from 
incompatible pointer type
Keyboard.c:206: warning: passing argument 2 of 'InitKeyboardDeviceStruct' from 
incompatible pointer type5B
Keyboard.c:122: warning: unused variable 'j'
Keyboard.c:117: warning: unused variable 'modifier_keymap'
Keyboard.c: In function 'xnestUpdateModifierState':
Keyboard.c:227: error: 'struct _KeyClassRec' has no member named 'state'
Keyboard.c:235: error: 'struct _KeyClassRec' has no member named 'state'
Keyboard.c:256: error: 'struct _KeyClassRec' has no member named 'state'

-- 
Chris Ball   c...@laptop.org
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: nv driver question

[Roland Scheidegger]

On 22.01.2009 04:04, Sergio Monteiro Basto wrote:
 On Wed, 2009-01-21 at 15:00 -0800, w bugar wrote:
 Hi,
 A quick nv driver question, installed fedora 10. Seem to be stuck at 800x600 
 resolution, does it support higher resolutions?
 Have
  Nvidia Riva 128 ZX card
  Optiquest V95 monitor
 Both advertise up to 1600x1200.
 
 I run nv driver with 1280x1024 on fedora 10 and above.
 Riva 128 looks (to me ) an old card, but I don't know if it is.
 
 Search by Nvidia Riva 128 ZX
 http://developer.nvidia.com/object/RIVA_128_FAQ.html
 5. Why does RIVA 128 only support a 4MB frame buffer? 
 The RIVA 128 was primarily targeted for the consumer mainstream market,
 so balancing cost and performance was key. Since RIVA 128 uniquely has
 the capability to store textures in off-screen memory on both PCI and
 AGP platforms, we did not feel it necessary to burden the graphics card
 with the additional cost of memory. With virtually unlimited system
 texture memory and a target resolution of 800x600 with 16-bit color
 double-buffered, 4MB is the ideal frame buffer size.

That's for 3d though. It should support higher resolutions for 2d. And
IIRC the main difference between the Riva 128 and Riva 128ZX was that
the latter had a 8MB frame buffer, so some deviation from the ideal
frame buffer size :-). Maybe the log offers some insight why it is stuck
at this resolution, I have no idea about this driver though.

Roland
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

build failure in xf86-input-evdev

[Tomas Carnecky]

./autogen.sh didn't complain about missing packages, so maybe a missing 
dependency?

/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I.. -I../include/-march=native -O2 -g -fno-omit-frame-pointer -pipe 
-fvisibility=hidden -I/opt/xorg/include/xorg 
-I/opt/xorg/include/pixman-1 -I/opt/xorg/include-I../src -MT 
evdev.lo -MD -MP -MF .deps/evdev.Tpo -c -o evdev.lo evdev.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include/ 
-march=native -O2 -g -fno-omit-frame-pointer -pipe -fvisibility=hidden 
-I/opt/xorg/include/xorg -I/opt/xorg/include/pixman-1 
-I/opt/xorg/include -I../src -MT evdev.lo -MD -MP -MF .deps/evdev.Tpo -c 
evdev.c  -fPIC -DPIC -o .libs/evdev.o
evdev.c: In function ‘EvdevInitProperty’:
evdev.c:1745: error: ‘AXIS_LABEL_PROP’ undeclared (first use in this 
function)
evdev.c:1745: error: (Each undeclared identifier is reported only once
evdev.c:1745: error: for each function it appears in.)
evdev.c:1751: error: ‘AXIS_LABEL_PROP_REL_X’ undeclared (first use in 
this function)
evdev.c:1756: error: ‘AXIS_LABEL_PROP_ABS_X’ undeclared (first use in 
this function)
evdev.c:1763: error: ‘AXIS_LABEL_PROP_REL_Y’ undeclared (first use in 
this function)
evdev.c:1768: error: ‘AXIS_LABEL_PROP_ABS_Y’ undeclared (first use in 
this function)
evdev.c:1775: error: ‘AXIS_LABEL_PROP_ABS_PRESSURE’ undeclared (first 
use in this function)


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Compile error building xf86-input-keyboard from current git

[Alex Villací­s Lasso]

Alan Coopersmith escribió:
 Alex Villací­s Lasso wrote:
   
 kbd.c:154: error: 'XKB_DFLT_RULES' undeclared here (not in a function)

 This is from a recent git pulled this morning. I am pulling the changes 
 from the last few hours, in the hope this is fixed by compiling an 
 updated proto somewhere.
 

 The xorg-server.h file installed by the Xorg server build should define
 either __XKBDEFRULES__ (Xorg git prior to this week) or XKB_DFLT_RULES
 (current Xorg git).   The kbd driver as of yesterday's git checkout
 should be accepting either one:

 #if !defined(XKB_DFLT_RULES)  defined(__XKBDEFRULES__)
 # define XKB_DFLT_RULES __XKBDEFRULES__
 #endif

   
My build is not defining either. I am building with the 
util/modular/build.sh script included in the git tree.

In the installation dir:

[a...@srv64 xserver]$ grep -r __XKBDEFRULES__ include/
include/xorg/xorg-server.h:/* #undef __XKBDEFRULES__ */
[a...@srv64 xserver]$ grep -r XKB_DFLT_RULES include/
[a...@srv64 xserver]$


My xserver checkout is with current git master.

-- 
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Keyboard events and console switching

[Helge Bahmann]

When a key is in the pressed state while switching console, repeated 
KeyPress/KeyRelease events will be generated while switched away from the 
server. If switching was caused by Alt-Ctrl-Fx, then at least the Fx key is 
pressed and the focused application receives a continuous stream 
of XF86_Switch_VT_x events -- this in itself is sufficiently annoying 
already as various applications like to spew the logs when they encounter 
this event and don't know how to handle it.

Things get even more unfriendly if console switching is initiated by chvt from 
a background service (don't ask). I propose to change the current logic for 
releasing keys on VT switch -- release them before switching away from the 
server, instead of after switching back. Would a patch like the attached one 
be acceptable?

Best regards
-- 
Dipl. Math.
Helge Bahmann
Berater
Geschäftsbereich Hochsicherheit
secunet Security Networks AG
Ammonstraße 74
01067 Dresden, Germany
Fon: +49 201 54 54-3586
Fax: +49 201 54 54-1323
Email: helge.bahm...@secunet.com

Sitz: Kronprinzenstraße 30, 45128 Essen
Amtsgericht Essen HRB 13615
Vorstand: Dr. Rainer Baumgart, Thomas Koelzer, Thomas Pleines
Aufsichtsratsvorsitzender: Dr. Karsten Ottenberg
diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c
index 76c207a..1e2ff11 100644
--- a/hw/xfree86/common/xf86Events.c
+++ b/hw/xfree86/common/xf86Events.c
@@ -82,6 +82,8 @@
 #include mi.h
 #include mipointer.h
 
+#include xkbsrv.h
+
 #ifdef XF86BIGFONT
 #define _XF86BIGFONT_SERVER_
 #include X11/extensions/xf86bigfont.h
@@ -594,17 +596,25 @@ xf86SigHandler(int signo)
 }
 
 static void
+set_key_up(DeviceIntPtr pDev, int key_code)
+{
+pDev-key-postdown[key_code  3] = ~(1  (key_code  7));
+}
+
+static void
 xf86ReleaseKeys(DeviceIntPtr pDev)
 {
 KeyClassPtr keyc = NULL;
 KeySym *map = NULL;
+XkbSrvInfoPtr	xkbi;
 xEvent ke;
-int i = 0, j = 0, nevents = 0;
+int i = 0;
 
 if (!pDev || !pDev-key)
 return;
 
 keyc = pDev-key;
+xkbi = keyc-xkbInfo;
 map = keyc-curKeySyms.map;
 
 /*
@@ -631,25 +641,21 @@ xf86ReleaseKeys(DeviceIntPtr pDev)
 case XK_Kana_Lock:
 break;
 default:
-if (pDev == inputInfo.keyboard) {
-ke.u.keyButtonPointer.time = GetTimeInMillis();
-ke.u.keyButtonPointer.rootX = 0;
-ke.u.keyButtonPointer.rootY = 0;
+ke.u.keyButtonPointer.time = GetTimeInMillis();
+ke.u.keyButtonPointer.rootX = 0;
+ke.u.keyButtonPointer.rootY = 0;
+if (pDev == inputInfo.keyboard)
 ke.u.u.type = KeyRelease;
-ke.u.u.detail = i;
-(*pDev-public.processInputProc) (ke, pDev, 1);
-}
-else {
-		int sigstate = xf86BlockSIGIO ();
-nevents = GetKeyboardEvents(xf86Events, pDev, KeyRelease, i);
-for (j = 0; j  nevents; j++)
-mieqEnqueue(pDev, xf86Events + j);
-		xf86UnblockSIGIO(sigstate);
-}
-break;
+else
+ke.u.u.type = DeviceKeyRelease;
+ke.u.u.detail = i;
+(*pDev-public.processInputProc) (ke, pDev, 1);
+set_key_up(pDev, i);
 }
 }
 }
+
+AccessXCancelRepeatKey(xkbi, xkbi-repeatKey);
 }
 
 /*
@@ -698,10 +704,15 @@ xf86VTSwitch()
  */
 pInfo = xf86InputDevs;
 while (pInfo) {
-  if (pInfo-dev)
-  DisableDevice(pInfo-dev);
+  if (pInfo-dev) {
+xf86ReleaseKeys(pInfo-dev);
+DisableDevice(pInfo-dev);
+  }
   pInfo = pInfo-next;
 }
+/* XXX HACK */
+xf86ReleaseKeys(inputInfo.keyboard);
+
 xf86EnterServerState(SETUP);
 for (i = 0; i  xf86NumScreens; i++)
 	xf86Screens[i]-LeaveVT(i, 0);
@@ -711,6 +722,11 @@ xf86VTSwitch()
 xf86AccessLeave();  /* We need this here, otherwise */
 xf86AccessLeaveState(); /* console won't be restored*/
 
+/* new events may have been enqueued asynchronously in the time window
+between deactivating devices and shutting down the SIGIO handler,
+which will later lead to spurious events after switching back */
+mieqDiscardInputEvents();
+
 if (!xf86VTSwitchAway()) {
   /*
* switch failed
@@ -737,14 +753,10 @@ xf86VTSwitch()
 
   pInfo = xf86InputDevs;
   while (pInfo) {
-if (pInfo-dev) {
-xf86ReleaseKeys(pInfo-dev);
+if (pInfo-dev)
 EnableDevice(pInfo-dev);
-}
 	pInfo = pInfo-next;
   }
-  /* XXX HACK */
-  xf86ReleaseKeys(inputInfo.keyboard);
   for (ih = InputHandlers; ih; ih = ih-next)
 xf86EnableInputHandler(ih);
 
diff --git a/mi/mi.h b/mi/mi.h
index 8d8f488..9e0b886 100644
--- a/mi/mi.h
+++ b/mi/mi.h
@@ -166,6 +166,10 @@ extern void mieqProcessInputEvents(
   

Pointer glide patch for Input/synaptics

[Dylan McCall]

Hello!

I'm just wondering what people think of the little pointer glide thing
I submitted. Here would be a better place for discussion than on
bugzilla, if anyone is interested :)

https://bugs.freedesktop.org/show_bug.cgi?id=19525

The mouse is a successful input technique because the physical device
makes sense. It feels like the mouse pointer on the screen and obeys
the laws of physics if someone throws it (not that anyone would do
that). The important part is that the user controls the pointer directly
and those motions translate accurately on screen. In the real world, the
interaction here would be understandable with any similarly sized object
floating through whatever surface the mouse is being used on.

With a touchpad, everything is an indirect type of motion without any
physical feedback (which is perhaps why it has been, until now, widely
despised). The touchpad doesn't move; it just acts as a window through
which the pointer is nudged. At the moment the pointer is a difficult
object to nudge. A bit like pushing it through syrupy goo. It just
doesn't move unless the user PUSHES it at all times. It doesn't make as
much sense and it doesn't feel like it applies to the real world, no
matter what paper-like texture the manufacturer puts over the touchpad.
(They should really be using a sticky goo texture if they want it to
feel natural).

My idea is to give the pointer a more believable, and at the same time
more comfortable presence when using the touchpad. Since the device
itself doesn't provide any kind of feedback, we have to assume the
pointer is fairly light, with a small amount of friction so it can be
pushed easily. This way the user can interact more naturally. Silly, but
I'm sure this can all be linked to some pseudo-scientific psychology
babble.

This is all achieved through ridiculously primitive physics, of course!
I have the pointer continuing along its path when the finger is
released, slowed down gradually by a set friction and capped with a
maximum speed to avoid anything weird happening. The pointer glide
behaviour only gets in the way if one is expecting it, and defaults to
being turned off.

To test, you will need to build both the patched driver and synclient.
The configuration can be done via xorg.conf, but synclient makes it much
more pleasant. Run synclient PointerGlide=1 to turn the behaviour on,
then you may need to configure it with the other PointerGlide options
available under synclient -l.

I really do think this improves ergonomics in an interesting way. At
least, it has for me!

Bye,
-Dylan McCall


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: Keyboard events and console switching

[Matthias Hopf]

On Jan 22, 09 16:55:08 +0100, Helge Bahmann wrote:
 Things get even more unfriendly if console switching is initiated by chvt 
 from 
 a background service (don't ask). I propose to change the current logic for 
 releasing keys on VT switch -- release them before switching away from the 
 server, instead of after switching back. Would a patch like the attached one 
 be acceptable?

We have several bugs open for openSUSE because of this behavior - so I'm
all for a change. I don't know the inner workings of this area in X, so
I can't claim to understand the patch completely, but I will give it a
try. So if it works, I really suggest taking it.

Thanks a lot

Matthias

-- 
Matthias Hopf mh...@suse.de  ____   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__  m...@mshopf.de
Phone +49-911-74053-715   __)  |_|  __)  |__  R  D   www.mshopf.de
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Wait for hald during initialization when necessary

[Paulo César Pereira de Andrade]

Yan Li wrote:

   Attached the new version without attempting any magic fallback
 (and using 8 spaces instead of tabs)

   Tested and functional by stoping hald, running startx, and starting
 hald from a ssh connection, so that in no more then 8 seconds the
 keyboard and mouse start responding...

 Thanks for this new patch. I'll test it extensively. One thing I'd
 like to change is to set the timer to 150ms, since this is the time
 we've measured with my patch using usleep().  I believe waiting for
 150ms is enough for most situations.

 +#define RECONNECT_TIMEOUT   (8 * 1000)
 +#define RECONNECT_TIMEOUT(150)

  I believe the most common problem is the situation you are
describing: hald not ready by the time the X Server is loading,
usually due to some timing issue, and by like less then one
second.

  Maybe you could use 150ms in config/hal.c:connect_hook(), and
use like 2-4 seconds if it the first timer failed.

  Or maybe Daniel or Peter will implement what they commented
some days ago, that is listen for a dbus message that tells when
hald is ready and accepting connections? (I don't know about
dbus internals, and did not know dbus had that feature...)

 --
 Li, Yan

Paulo

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Compile error building xf86-input-keyboard from current git

[Alex Villací­s Lasso]

Alan Coopersmith escribió:
 Alex Villací­s Lasso wrote:
   
 Alan Coopersmith escribió:
 
 Alex Villací­s Lasso wrote:
   
   
 kbd.c:154: error: 'XKB_DFLT_RULES' undeclared here (not in a function)

 This is from a recent git pulled this morning. I am pulling the changes 
 from the last few hours, in the hope this is fixed by compiling an 
 updated proto somewhere.
 
 
 The xorg-server.h file installed by the Xorg server build should define
 either __XKBDEFRULES__ (Xorg git prior to this week) or XKB_DFLT_RULES
 (current Xorg git).   The kbd driver as of yesterday's git checkout
 should be accepting either one:

 #if !defined(XKB_DFLT_RULES)  defined(__XKBDEFRULES__)
 # define XKB_DFLT_RULES __XKBDEFRULES__
 #endif

   
   
 My build is not defining either. I am building with the 
 util/modular/build.sh script included in the git tree.

 In the installation dir:

 [a...@srv64 xserver]$ grep -r __XKBDEFRULES__ include/
 include/xorg/xorg-server.h:/* #undef __XKBDEFRULES__ */
 [a...@srv64 xserver]$ grep -r XKB_DFLT_RULES include/
 [a...@srv64 xserver]$


 My xserver checkout is with current git master.
 

 I actually hadn't pushed the fix for that until shortly after sending
 that message yesterday (oops!)  but git master now has:

 al...@alf:/export/alanc/X.org/mod/git/xserver [9:02am - 218] grep
 __XKBDEFRULES__ include/*
 al...@alf:/export/alanc/X.org/mod/git/xserver [9:02am - 219] grep 
 XKB_DFLT_RULES
 include/*
 include/xkb-config.h.in:#undef XKB_DFLT_RULES
 include/xorg-server.h.in:#undef XKB_DFLT_RULES

 If you don't see XKB_DFLT_RULES at all, you're several days behind
 git master, or on a different branch than master.

   
I updated xserver to current git. Now I am getting the same compile 
error in xserver itself as reported here:
 http://tinderbox.x.org/builds/2009-01-22-0007/logs/xserver/#build

 Keyboard.c: In function 'xnestKeyboardProc':
 Keyboard.c:177: warning: passing argument 1 of 'XkbSetRulesDflts' from
 incompatible pointer type
 Keyboard.c:177: error: too many arguments to function 'XkbSetRulesDflts'
 Keyboard.c:178: warning: implicit declaration of function 
 'XkbInitKeyboardDeviceStruct'
 Keyboard.c:178: warning: nested extern declaration of 
 'XkbInitKeyboardDeviceStruct'
 Keyboard.c:206: warning: passing argument 1 of 'InitKeyboardDeviceStruct' 
 from incompatible pointer type
 Keyboard.c:206: warning: passing argument 2 of 'InitKeyboardDeviceStruct' 
 from incompatible pointer type5B
 Keyboard.c:122: warning: unused variable 'j'
 Keyboard.c:117: warning: unused variable 'modifier_keymap'
 Keyboard.c: In function 'xnestUpdateModifierState':
 Keyboard.c:227: error: 'struct _KeyClassRec' has no member named 'state'
 Keyboard.c:235: error: 'struct _KeyClassRec' has no member named 'state'
 Keyboard.c:256: error: 'struct _KeyClassRec' has no member named 'state'

 -- Chris Ball c...@laptop.org 
 ___ xorg mailing list 
 xorg@lists.freedesktop.org 
 http://lists.freedesktop.org/mailman/listinfo/xorg


-- 
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: http://wiki.x.org/wiki/Development/git [was: Fedora 10: Trouble installing libdrm (2.4.4) for latest Intel driver (2.6)]

[Jesse Barnes]

On Wednesday, January 21, 2009 7:38 pm Sergio Monteiro Basto wrote:
 Hi,
 Since I also works with Fedora 10, I am also interested in this
 thread :)

 On Wed, 2009-01-21 at 15:03 -0800, Dan Nicholson wrote:
   I've attached my log file.  Am I supposed to have a rules file for
   evdev?
 
  Unfortunately, the script you followed doesn't seem to tell you about
  handling the XKB data. You can either install xkeyboard-config or
  follow the instructions for Making the keyboard work here:
 
  http://wiki.x.org/wiki/Development/git

 ok I found some updates on Development/git, and that a cool page , but I
 have some questions .

 On section: running new stack
 * rmmod i915 # assuming you're using Intel
   * rmmod drm
   * insmod path_to_drm_tree_above/linux-core/drm.ko
   * insmod path_to_drm_tree_above/linux-core/i915.ko

 This isn't more applicable on Intel isn't it ? but as example for others
 that don't use the new drm kernel are fine :)

Right, please correct this on the wiki. :)  For Intel, the Linux drivers are 
maintained in-tree.  The BSD variants are generally ported from there (or the 
mailing list) into their respective trees nowadays.

 Other question is about section: Building DRM.
 On Intel (that is my development case ) make install (without make -C
 linux-core ) , will overwrite drm kernel headers , that is good ?

make install from a kernel tree will overwrite the versions in /lib/modules, 
but it's easier to just copy them by hand from drivers/gpu/ to /lib/modules.

 To be honest I don't know if libdrm could be different of drm kernel and
 they could act independently or if we should check if headers of libdrm
 and headers of drm kernel are equal. Some clues about this question are
 welcome .

Some distros are starting to use the kernel headers rather than the libdrm 
headers now.  I think this makes sense long term; however since the headers 
are slightly out of sync it has caused build problems for some packages.

Jesse
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Compile error building xf86-input-keyboard from current git

[Alan Coopersmith]

Alex Villací­s Lasso wrote:
 I updated xserver to current git. Now I am getting the same compile 
 error in xserver itself as reported here:
 http://tinderbox.x.org/builds/2009-01-22-0007/logs/xserver/#build

A large chunk of XKB code from the XKB-atkins work landed on git master
last night from the folks at linux.conf.au, so things may be a bit off
until they wake up again.

-- 
-Alan Coopersmith-   alan.coopersm...@sun.com
 Sun Microsystems, Inc. - X Window System Engineering

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: build failure in xf86-input-evdev

[Dan Nicholson]

On Thu, Jan 22, 2009 at 7:35 AM, Tomas Carnecky t...@dbservice.com wrote:
 ./autogen.sh didn't complain about missing packages, so maybe a missing
 dependency?

 /bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
 -I.. -I../include/-march=native -O2 -g -fno-omit-frame-pointer -pipe
 -fvisibility=hidden -I/opt/xorg/include/xorg
 -I/opt/xorg/include/pixman-1 -I/opt/xorg/include-I../src -MT
 evdev.lo -MD -MP -MF .deps/evdev.Tpo -c -o evdev.lo evdev.c
 libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include/
 -march=native -O2 -g -fno-omit-frame-pointer -pipe -fvisibility=hidden
 -I/opt/xorg/include/xorg -I/opt/xorg/include/pixman-1
 -I/opt/xorg/include -I../src -MT evdev.lo -MD -MP -MF .deps/evdev.Tpo -c
 evdev.c  -fPIC -DPIC -o .libs/evdev.o
 evdev.c: In function 'EvdevInitProperty':
 evdev.c:1745: error: 'AXIS_LABEL_PROP' undeclared (first use in this
 function)
 evdev.c:1745: error: (Each undeclared identifier is reported only once
 evdev.c:1745: error: for each function it appears in.)
 evdev.c:1751: error: 'AXIS_LABEL_PROP_REL_X' undeclared (first use in
 this function)
 evdev.c:1756: error: 'AXIS_LABEL_PROP_ABS_X' undeclared (first use in
 this function)
 evdev.c:1763: error: 'AXIS_LABEL_PROP_REL_Y' undeclared (first use in
 this function)
 evdev.c:1768: error: 'AXIS_LABEL_PROP_ABS_Y' undeclared (first use in
 this function)
 evdev.c:1775: error: 'AXIS_LABEL_PROP_ABS_PRESSURE' undeclared (first
 use in this function)

I think Peter still has to push this patch to the server:

http://lists.freedesktop.org/archives/xorg/2009-January/042699.html

--
Dan
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Xfbdev: ensure correct yoffset

[Risto Suominen]

If virtual resolution is higher than the screen (as in atyfb), and yoffset
given by the framebuffer driver happens to be non-zero (fbcon changes it on-
the-fly), Xfbdev places its image starting above the displayed part of the
framebuffer. This patch makes sure that the whole picture is visible.

Signed-off-by: Risto Suominen risto.suomi...@gmail.com
---
The testing is done on version 1.1.1 and linux kernel version 2.6.18.

--- a/hw/kdrive/fbdev/fbdev.c.org   2006-07-05 21:31:39.0 +0300
+++ b/hw/kdrive/fbdev/fbdev.c   2009-01-18 15:42:06.0 +0200
@@ -215,6 +215,8 @@ fbdevScreenInitialize (KdScreenInfo *scr

/* Now get the new screeninfo */
ioctl (priv-fd, FBIOGET_VSCREENINFO, priv-var);
+/* We can get anything into yoffset if fbcon is active */
+priv-var.yoffset = 0;
depth = priv-var.bits_per_pixel;
gray = priv-var.grayscale;
If virtual resolution is higher than the screen (as in atyfb), and yoffset
given by the framebuffer driver happens to be non-zero (fbcon changes it on-
the-fly), Xfbdev places its image starting above the displayed part of the
framebuffer. This patch makes sure that the whole picture is visible.

Signed-off-by: Risto Suominen risto.suomi...@gmail.com
---
The testing is done on version 1.1.1 and linux kernel version 2.6.18.

--- a/hw/kdrive/fbdev/fbdev.c.org	2006-07-05 21:31:39.0 +0300
+++ b/hw/kdrive/fbdev/fbdev.c	2009-01-18 15:42:06.0 +0200
@@ -215,6 +215,8 @@ fbdevScreenInitialize (KdScreenInfo *scr
 
 /* Now get the new screeninfo */
 ioctl (priv-fd, FBIOGET_VSCREENINFO, priv-var);
+/* We can get anything into yoffset if fbcon is active */
+priv-var.yoffset = 0;
 depth = priv-var.bits_per_pixel;
 gray = priv-var.grayscale;
 
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: wrong colors with Xv extension and image format id: 0x59565955 (UYVY) from an rgb mapping

[Amos Tibaldi]

2009/1/22 Simon Farnsworth simon.farnswo...@onelan.co.uk

 Amos Tibaldi wrote:
  unsigned short int thecolor =  u  12 | y  8 | v  4 | y;
 
 This is completely wrong. In a UYVY image, you have two different 8-bit
 Y components, sharing an 8-bit U component, and an 8-bit V component. In
 pseudocode, creating a 32-bit UYVY pixel pair from two RGB pixels:

 (y, u, v) RGBtoYUV( r, g, b )
 {
y =  0.299 * r +
 0.587 * g +
 0.114 * b;

u = -0.147 * r +
-0.289 * g +
 0.436 * b;

v =  0.615 * r +
-0.515 * g +
-0.100 * b;
 }

 uyvy RGBtoUYUV( r1, g1, b1, r2, g2, b2 )
 {
(y1,u1,v1) = RGBtoYUV( r1, g1, b1 )
(y2,u2,v2) = RGBtoYUV( r2, g2, b2 )

u = (u1 + u2) / 2; // Or other decimation strategy
v = (v1 + v2) / 2; // Or other decimation strategy

uyvy  = 8bits(u)  24;
uyvy |= 8bits(y1)  16;
uyvy |= 8bits(v)  8;
uyvy |= 8bits(y2);
 }
 --
 Simon Farnsworth


You both are right, but for now I obtain only solid color that doesn't
correspond to the desired one; here is the code:

void RGBToUV(unsigned short int r,
   unsigned short int g,
   unsigned short int b,
   unsigned short int * u,
   unsigned short int * v)
{
*u = -0.147 * r +
   -0.289 * g +
0.436 * b; // min(abs(r * -1214 + g * -2384 + b * 3598 + 4096 +
1048576)  13, 240);
//(unsigned short
int)(-0.147f*(float)r-0.289f*(float)g+0.436f*(float)b);
*v = 0.615 * r +
   -0.515 * g +
   -0.100 * b;
//min(abs(r * 3598 + g * -3013 + b * -585 + 4096 + 1048576)  13, 240);
//(unsigned short int)(0.615f*(float)r-0.515f*(float)g-0.100f*(float)b);
}
void RGBToY(unsigned short int r,
   unsigned short int g,
   unsigned short int b,
   unsigned short int * y
   )
{
   *y = 0.299 * r +
0.587 * g +
0.114 * b; // min(abs(r * 2104 + g * 4130 + b * 802 + 4096 +
131072)  13, 235);
//(unsigned short int)(0.299f*(float)r+0.587f*(float)g+0.114f*(float)b);
}

void XVWindow::Redraw()
{
unsigned short int u, y1, y2, v;
/*RGBToY(255,0,0,y1);
RGBToY(255,0,0,y2);
RGBToUV(255,0,0,u,v);*/
/*RGBToY(0,255,0,y1);
RGBToY(0,255,0,y2);
RGBToUV(0,255,0,u,v); */
RGBToY(0,0,255,y1);
RGBToY(0,0,255,y2);
RGBToUV(0,0,255,u,v);

unsigned char * p = (unsigned char *) BGimage-data;
  for ( int y=0; yImageHeight; y++ , p += BGimage-pitches[0] )
   for ( int x=0; xImageWidth; x++ )
{
  p [ (x  1) + 3 ] = y2;
  p [ (x  1) + 2 ] = v;
  p [ (x  1) + 1 ] = y1;
  p [ (x  1) ] = u;
}

counter++;
XvPutImage( xvc.display, xvc.port, window, gc,
BGimage, 0, 0, ImageWidth, ImageHeight,
   0, 0, WindowWidth, WindowHeight );
}

I cannot understand but it works only if I use (x1). What can I do to
associate the colours correctly?


Thanks,

-- 
Amos Tibaldi
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: wrong colors with Xv extension and image format id: 0x59565955 (UYVY) from an rgb mapping

[Tomas Carnecky]

On 01/22/2009 07:35 PM, Amos Tibaldi wrote:
 You both are right, but for now I obtain only solid color that doesn't
 correspond to the desired one; here is the code:

 void RGBToUV(unsigned short int r,
 unsigned short int g,
 unsigned short int b,
 unsigned short int * u,
 unsigned short int * v)
 {
 *u = -0.147 * r +
 -0.289 * g +
 0.436 * b; // min(abs(r * -1214 + g * -2384 + b * 3598 + 4096 + 1048576)
   13, 240);
 //(unsigned short int)(-0.147f*(float)r-0.289f*(float)g+0.436f*(float)b);
 *v = 0.615 * r +
 -0.515 * g +
 -0.100 * b;
 //min(abs(r * 3598 + g * -3013 + b * -585 + 4096 + 1048576)  13, 240);
 //(unsigned short int)(0.615f*(float)r-0.515f*(float)g-0.100f*(float)b);
 }
 void RGBToY(unsigned short int r,
 unsigned short int g,
 unsigned short int b,
 unsigned short int * y
 )
 {
 *y = 0.299 * r +
 0.587 * g +
 0.114 * b; // min(abs(r * 2104 + g * 4130 + b * 802 + 4096 + 131072) 
 13, 235);
 //(unsigned short int)(0.299f*(float)r+0.587f*(float)g+0.114f*(float)b);
 }

 void XVWindow::Redraw()
 {
 unsigned short int u, y1, y2, v;
 /*RGBToY(255,0,0,y1);
 RGBToY(255,0,0,y2);
 RGBToUV(255,0,0,u,v);*/
 /* RGBToY(0,255,0,y1);
 RGBToY(0,255,0,y2);
 RGBToUV(0,255,0,u,v); */
 RGBToY(0,0,255,y1);
 RGBToY(0,0,255,y2);
 RGBToUV(0,0,255,u,v);

 unsigned char * p = (unsigned char *) BGimage-data;
 for ( int y=0; yImageHeight; y++ , p += BGimage-pitches[0] )
 for ( int x=0; xImageWidth; x++ )
 {
 p [ (x  1) + 3 ] = y2;
 p [ (x  1) + 2 ] = v;
 p [ (x  1) + 1 ] = y1;
 p [ (x  1) ] = u;
 }

 counter++;
 XvPutImage( xvc.display, xvc.port, window, gc,
 BGimage, 0, 0, ImageWidth, ImageHeight,
 0, 0, WindowWidth, WindowHeight );
 }

 I cannot understand but it works only if I use (x1). What can I do to
 associate the colours correctly?

ImageWidth is the width in pixels, but in each iteration you fill in two 
pixels. So you either need 'xImageWidth/2' in the for() loop or use 
'x/2' which is what you did.

Also, keep in mind that you are filling only the first line of the whole 
image. The rest of the image probably has undefined/random colors. That 
you are seeing wrong colors could have several causes. Your formulas 
could be wrong (take a look at ffmpeg, xvid or any other projects that 
have rgb-to-yuv functions and borrow their code), endian issues (try 
YUYV or VYVU) or others.

If in doubt, paste the minimal possible sample of your code that 
compiles and runs so we can test it.

tom

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Fix description of DDC_QUIRK_DETAILED_USE_MAXIMUM_SIZE

[Tormod Volden]

The message ending up in the log was misleading as to what the quirk
actually does: It ignores the sizes in the detailed timings and
replaces them with the display Max Image Size.
---
 hw/xfree86/modes/xf86EdidModes.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/xfree86/modes/xf86EdidModes.c b/hw/xfree86/modes/xf86EdidModes.c
index 5ed61c1..0ea5f03 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -246,7 +246,7 @@ static const ddc_quirk_map_t ddc_quirks[] = {
 },
 {
quirk_detailed_use_maximum_size,   DDC_QUIRK_DETAILED_USE_MAXIMUM_SIZE,
-   Detailed timings give sizes in cm.
+   Use maximum size instead of detailed timing sizes.
 },
 {
quirk_first_detailed_preferred, DDC_QUIRK_FIRST_DETAILED_PREFERRED,
-- 
1.6.0.4

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: build failure in xf86-input-evdev

[Peter Hutterer]

On Thu, Jan 22, 2009 at 10:05:08AM -0800, Dan Nicholson wrote:
 On Thu, Jan 22, 2009 at 7:35 AM, Tomas Carnecky t...@dbservice.com wrote:
  ./autogen.sh didn't complain about missing packages, so maybe a missing
  dependency?
 
  /bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
  -I.. -I../include/-march=native -O2 -g -fno-omit-frame-pointer -pipe
  -fvisibility=hidden -I/opt/xorg/include/xorg
  -I/opt/xorg/include/pixman-1 -I/opt/xorg/include-I../src -MT
  evdev.lo -MD -MP -MF .deps/evdev.Tpo -c -o evdev.lo evdev.c
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include/
  -march=native -O2 -g -fno-omit-frame-pointer -pipe -fvisibility=hidden
  -I/opt/xorg/include/xorg -I/opt/xorg/include/pixman-1
  -I/opt/xorg/include -I../src -MT evdev.lo -MD -MP -MF .deps/evdev.Tpo -c
  evdev.c  -fPIC -DPIC -o .libs/evdev.o
  evdev.c: In function 'EvdevInitProperty':
  evdev.c:1745: error: 'AXIS_LABEL_PROP' undeclared (first use in this
  function)
  evdev.c:1745: error: (Each undeclared identifier is reported only once
  evdev.c:1745: error: for each function it appears in.)
  evdev.c:1751: error: 'AXIS_LABEL_PROP_REL_X' undeclared (first use in
  this function)
  evdev.c:1756: error: 'AXIS_LABEL_PROP_ABS_X' undeclared (first use in
  this function)
  evdev.c:1763: error: 'AXIS_LABEL_PROP_REL_Y' undeclared (first use in
  this function)
  evdev.c:1768: error: 'AXIS_LABEL_PROP_ABS_Y' undeclared (first use in
  this function)
  evdev.c:1775: error: 'AXIS_LABEL_PROP_ABS_PRESSURE' undeclared (first
  use in this function)
 
 I think Peter still has to push this patch to the server:
 
 http://lists.freedesktop.org/archives/xorg/2009-January/042699.html

whoopsi. All pushed now, thanks for reminding me.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

save-under support

[Patrick O'Donnell]

I've been told, recently, that save-under and backing-store under
8-bit [visuals] are no longer supported in recent X.org releases.  We
maintain several old X applications that make significant use of both
save-under and backing-store (and 8-bit PseudoColor visuals), and this
news greatly disturbs us.  However, in several days of searching, I
have been unable to find any definitive pronouncement that that is
truly the case.

So, could someone point me to where I would find more authoritative
information on the status of save-under and backing-store?

I have not done significant X programming in quite some time, and with
my attention diverted to other tasks, I have not been able to keep up
with the latest developments in the X Window System.  So, any pointers
to relevent helpful documents or articles would be greatly
appreciated.

- Patrick O'Donnell
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Current tinderbox regression (xserver)

[Daniel Stone]

On Thu, Jan 22, 2009 at 10:08:04AM -0500, Chris Ball wrote:
 Keyboard.c: In function 'xnestKeyboardProc':
 Keyboard.c:177: warning: passing argument 1 of 'XkbSetRulesDflts' from
 incompatible pointer type
 Keyboard.c:177: error: too many arguments to function 'XkbSetRulesDflts'
 Keyboard.c:178: warning: implicit declaration of function 
 'XkbInitKeyboardDeviceStruct'
 Keyboard.c:178: warning: nested extern declaration of 
 'XkbInitKeyboardDeviceStruct'
 Keyboard.c:206: warning: passing argument 1 of 'InitKeyboardDeviceStruct' 
 from incompatible pointer type
 Keyboard.c:206: warning: passing argument 2 of 'InitKeyboardDeviceStruct' 
 from incompatible pointer type5B
 Keyboard.c:122: warning: unused variable 'j'
 Keyboard.c:117: warning: unused variable 'modifier_keymap'
 Keyboard.c: In function 'xnestUpdateModifierState':
 Keyboard.c:227: error: 'struct _KeyClassRec' has no member named 'state'
 Keyboard.c:235: error: 'struct _KeyClassRec' has no member named 'state'
 Keyboard.c:256: error: 'struct _KeyClassRec' has no member named 'state'

Yeah, Xnest and Xdmx are broken, sorry.  That being said, we've talked a
lot about just deleting Xnest in favour of Xephyr: anyone got any
compelling counter-arguments?

Cheers,
Daniel


signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Keyboard events and console switching

[Daniel Stone]

On Thu, Jan 22, 2009 at 05:36:52PM +0100, Matthias Hopf wrote:
 On Jan 22, 09 16:55:08 +0100, Helge Bahmann wrote:
  Things get even more unfriendly if console switching is initiated by chvt 
  from 
  a background service (don't ask). I propose to change the current logic for 
  releasing keys on VT switch -- release them before switching away from the 
  server, instead of after switching back. Would a patch like the attached 
  one 
  be acceptable?
 
 We have several bugs open for openSUSE because of this behavior - so I'm
 all for a change. I don't know the inner workings of this area in X, so
 I can't claim to understand the patch completely, but I will give it a
 try. So if it works, I really suggest taking it.

It should already work: please file a bug and assign it to me, and I'll
take care of it ASAP.

Cheers,
Daniel


signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: save-under support

[Rui Tiago Cação Matos]

2009/1/22 Patrick O'Donnell p...@ascent.com:
 I've been told, recently, that save-under and backing-store under
 8-bit [visuals] are no longer supported in recent X.org releases.  We
 maintain several old X applications that make significant use of both
 save-under and backing-store (and 8-bit PseudoColor visuals), and this
 news greatly disturbs us.  However, in several days of searching, I
 have been unable to find any definitive pronouncement that that is
 truly the case.

 So, could someone point me to where I would find more authoritative
 information on the status of save-under and backing-store?

 I have not done significant X programming in quite some time, and with
 my attention diverted to other tasks, I have not been able to keep up
 with the latest developments in the X Window System.  So, any pointers
 to relevent helpful documents or articles would be greatly
 appreciated.

http://cgit.freedesktop.org/xorg/xserver/commit/?id=ae7f71a8b3d6756161e55d998d6eec37d2695c98

I'm afraid that's as official as it gets.

Rui
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Fwd: wrong colors with Xv extension and image format id: 0x59565955 (UYVY) from an rgb mapping

[Amos Tibaldi]

2009/1/22 Tomas Carnecky t...@dbservice.com

 On 01/22/2009 07:35 PM, Amos Tibaldi wrote:

  You both are right, but for now I obtain only solid color that doesn't
 correspond to the desired one; here is the code:

 void RGBToUV(unsigned short int r,
 unsigned short int g,
 unsigned short int b,
 unsigned short int * u,
 unsigned short int * v)
 {
 *u = -0.147 * r +
 -0.289 * g +
 0.436 * b; // min(abs(r * -1214 + g * -2384 + b * 3598 + 4096 + 1048576)
   13, 240);
 //(unsigned short int)(-0.147f*(float)r-0.289f*(float)g+0.436f*(float)b);
 *v = 0.615 * r +
 -0.515 * g +
 -0.100 * b;
 //min(abs(r * 3598 + g * -3013 + b * -585 + 4096 + 1048576)  13, 240);
 //(unsigned short int)(0.615f*(float)r-0.515f*(float)g-0.100f*(float)b);
 }
 void RGBToY(unsigned short int r,
 unsigned short int g,
 unsigned short int b,
 unsigned short int * y
 )
 {
 *y = 0.299 * r +
 0.587 * g +
 0.114 * b; // min(abs(r * 2104 + g * 4130 + b * 802 + 4096 + 131072) 
 13, 235);
 //(unsigned short int)(0.299f*(float)r+0.587f*(float)g+0.114f*(float)b);
 }

 void XVWindow::Redraw()
 {
 unsigned short int u, y1, y2, v;
 /*RGBToY(255,0,0,y1);
 RGBToY(255,0,0,y2);
 RGBToUV(255,0,0,u,v);*/
 /* RGBToY(0,255,0,y1);
 RGBToY(0,255,0,y2);
 RGBToUV(0,255,0,u,v); */
 RGBToY(0,0,255,y1);
 RGBToY(0,0,255,y2);
 RGBToUV(0,0,255,u,v);

 unsigned char * p = (unsigned char *) BGimage-data;
 for ( int y=0; yImageHeight; y++ , p += BGimage-pitches[0] )
 for ( int x=0; xImageWidth; x++ )
 {
 p [ (x  1) + 3 ] = y2;
 p [ (x  1) + 2 ] = v;
 p [ (x  1) + 1 ] = y1;
 p [ (x  1) ] = u;
 }

 counter++;
 XvPutImage( xvc.display, xvc.port, window, gc,
 BGimage, 0, 0, ImageWidth, ImageHeight,
 0, 0, WindowWidth, WindowHeight );
 }

 I cannot understand but it works only if I use (x1). What can I do to
 associate the colours correctly?


 ImageWidth is the width in pixels, but in each iteration you fill in two
 pixels. So you either need 'xImageWidth/2' in the for() loop or use 'x/2'
 which is what you did.

 Also, keep in mind that you are filling only the first line of the whole
 image. The rest of the image probably has undefined/random colors. That you
 are seeing wrong colors could have several causes. Your formulas could be
 wrong (take a look at ffmpeg, xvid or any other projects that have
 rgb-to-yuv functions and borrow their code), endian issues (try YUYV or
 VYVU) or others.

 If in doubt, paste the minimal possible sample of your code that compiles
 and runs so we can test it.

 tom

 I have tried t look at ffmpeg and xvid but there is no code for YUV 8b
each. Only for YUV444. Here is the compilable code, if you can help, the
program shows a violet window, while it should not.

tiba...@core2duoe:~/XVideoTest$ cat Makefile
all: testxv2

INCLUDES = -I ./ -I /usr/include/X11/
LINKLIBS = -lpthread -lX11 -lXext -lXv
SOURCES := $(wildcard *.cc)
OBJECTS :=  $(SOURCES:.cc=.o)

XVWindow.o: XVWindow.cc $(wildcard *.h)
g++ -c $ -o $@ $(INCLUDES)

testxv2.o: testxv2.cc $(wildcard *.h)
g++ -c $ -o $@ $(INCLUDES)

testxv2: Makefile $(OBJECTS) $(wildcard *.h)
 g++ -o testxv2  $(OBJECTS) -L/usr/X11R6/lib $(LINKLIBS)

clean:
rm -f *.o testxv2

tiba...@core2duoe:~/XVideoTest$ cat testxv2.cc
// XVideo test program by Jan Wedekind (jan at wedesoft.de).
//
// Based on
// * http://bellet.info/XVideo/testxv.c
// * http://svn.mplayerhq.hu/mplayer/trunk/libvo/vo_xv.c?view=markup
// * http://svn.mplayerhq.hu/mplayer/trunk/libvo/x11_common.c?view=markup
//
// Compile using
// g++ -o testxv2 testxv2.cc -L/usr/X11R6/lib -lX11 -lXext -lXv

#include iostream
#include iomanip
#include X11/Xlib.h
#include X11/Xutil.h
#include X11/extensions/Xv.h
#include X11/extensions/Xvlib.h
#include unistd.h
#include stdint.h
#include XVWindow.h

extern XVWindowsContext xvc;


using namespace std;



int main( int argc, char *argv[] )
{
  int
width = 320,
height = 240;

LaunchXVWindowThread();

while(!xvc.can_start);


XVWindow * window = new XVWindow(width, height, (char*)pippo);
XVWindow * window2 = new XVWindow(width, height, (char*)pluto);



while(!xvc.can_exit);


delete window;
delete window2;

XVWindowsContextUnInitialize();
}

tiba...@core2duoe:~/XVideoTest$ cat XVWindow.h
#ifndef XVWINDOW_H
#define XVWINDOW_H

#include X11/Xlib.h
#include X11/extensions/Xv.h
#include X11/extensions/Xvlib.h
#include X11/Xutil.h
#include pthread.h

#define GUID_YUV12_PLANAR 0x32315659
#define GUID_UYVY_PLANAR 0x59565955

class XVWindow
{
private:
char name[256];
 XGCValues xgcv;
GC gc;
XvImage * BGimage;
unsigned int WindowWidth, WindowHeight, OldWindowWidth, OldWindowHeight;
int ImageWidth, ImageHeight;
float WindowAspectRatio;
bool fullscreen;
public:
Window window;
XVWindow * pme;
XVWindow(int w, int h, char * name);
~XVWindow();
void CreateBGImage(int w, int h);
void SetWindowDimension(int w, int h);
void Redraw();
void ToggleFullScreen();
void FixAspectRatioOfWindow();
};

typedef struct {
Display * display;
XvAdaptorInfo * ai;
XVisualInfo 

Re: http://wiki.x.org/wiki/Development/git [was: Fedora 10: Trouble installing libdrm (2.4.4) for latest Intel driver (2.6)]

[Sergio Monteiro Basto]

On Thu, 2009-01-22 at 10:01 -0800, Jesse Barnes wrote:
 On Wednesday, January 21, 2009 7:38 pm Sergio Monteiro Basto wrote:
  Hi,
  Since I also works with Fedora 10, I am also interested in this
  thread :)
 
  On Wed, 2009-01-21 at 15:03 -0800, Dan Nicholson wrote:
I've attached my log file.  Am I supposed to have a rules file for
evdev?
  
   Unfortunately, the script you followed doesn't seem to tell you about
   handling the XKB data. You can either install xkeyboard-config or
   follow the instructions for Making the keyboard work here:
  
   http://wiki.x.org/wiki/Development/git
 
  ok I found some updates on Development/git, and that a cool page , but I
  have some questions .
 
  On section: running new stack
  * rmmod i915 # assuming you're using Intel
* rmmod drm
* insmod path_to_drm_tree_above/linux-core/drm.ko
* insmod path_to_drm_tree_above/linux-core/i915.ko
 
  This isn't more applicable on Intel isn't it ? but as example for others
  that don't use the new drm kernel are fine :)
 
 Right, please correct this on the wiki. :)  For Intel, the Linux drivers are 
 maintained in-tree.  The BSD variants are generally ported from there (or the 
 mailing list) into their respective trees nowadays.
 
  Other question is about section: Building DRM.
  On Intel (that is my development case ) make install (without make -C
  linux-core ) , will overwrite drm kernel headers , that is good ?
 
 make install from a kernel tree will overwrite the versions in 
 /lib/modules, 
 but it's easier to just copy them by hand from drivers/gpu/ to /lib/modules.
 
  To be honest I don't know if libdrm could be different of drm kernel and
  they could act independently or if we should check if headers of libdrm
  and headers of drm kernel are equal. Some clues about this question are
  welcome .
 
 Some distros are starting to use the kernel headers rather than the libdrm 
 headers now.  I think this makes sense long term; however since the headers 
 are slightly out of sync it has caused build problems for some packages.
 

Somehow (new) libdrm should be build against kernel headers , to ensure
this sync of libdrm and drm kernel. Since that we have some agreement
which is the kernel that provide drm headers. 

So, make install of libdrm should not produce headers if they exists
already in kernel-headers.  

Or as workaround first build libdrm and second build the kernel ... 

 Jesse

Thanks, 
-- 
Sérgio M. B.


smime.p7s
Description: S/MIME cryptographic signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Pointer glide patch for Input/synaptics

[Peter Hutterer]

On Thu, Jan 22, 2009 at 08:28:21AM -0800, Dylan McCall wrote:
 I'm just wondering what people think of the little pointer glide thing
 I submitted. Here would be a better place for discussion than on
 bugzilla, if anyone is interested :)

IMHO, for new features the list is a better place than bugzilla, so I do
encourage you that you send out the patch to the list, ideally as git
formatted patch.

[btw, your bug didn't get ignored, just ETIME and whatnot.]

 With a touchpad, everything is an indirect type of motion without any
 physical feedback (which is perhaps why it has been, until now, widely
 despised). The touchpad doesn't move; it just acts as a window through
 which the pointer is nudged. At the moment the pointer is a difficult
 object to nudge. A bit like pushing it through syrupy goo. It just
 doesn't move unless the user PUSHES it at all times. It doesn't make as
 much sense and it doesn't feel like it applies to the real world, no
 matter what paper-like texture the manufacturer puts over the touchpad.
 (They should really be using a sticky goo texture if they want it to
 feel natural).
 
 My idea is to give the pointer a more believable, and at the same time
 more comfortable presence when using the touchpad. Since the device
 itself doesn't provide any kind of feedback, we have to assume the
 pointer is fairly light, with a small amount of friction so it can be
 pushed easily. This way the user can interact more naturally. Silly, but
 I'm sure this can all be linked to some pseudo-scientific psychology
 babble.

These are a couple of strong statements that you haven't really backed up
other than with your personal opinions. Do you have any references that this
actually improves the behaviour, or that users actually use it?
Synaptics already suffers from feature-bloat, so additional features should
at least have some potential users.
 
 This is all achieved through ridiculously primitive physics, of course!
 I have the pointer continuing along its path when the finger is
 released, slowed down gradually by a set friction and capped with a
 maximum speed to avoid anything weird happening. The pointer glide
 behaviour only gets in the way if one is expecting it, and defaults to
 being turned off.

Can you explain what reasonable defaults one should use for the friction?
The default ones (I just applied the patch here) don't really make sense to
me. If anything, they make the touchpad harder to use as there's a high chance
that the pointer keeps moving after I have released over a button and I miss
the target.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH 1/9] Includes some new structures and defined MACRO in edid.h

[Ma Ling]

Hi Alex,
Thanks for your reply!


On Thu, 2009-01-22 at 22:50 +0800, Alex Deucher wrote:
 On Thu, Jan 22, 2009 at 2:46 AM, Ma Ling ling...@intel.com wrote:
  defined corresponding structure and MACRO for detailed timing and CEA data 
  blocks.
 
  ---
   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..7167f64 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)
 
 I would suggest putting parentheses around x in the above macros, e.g.,
 #define VENDOR_LATENCY_PRESENT_I(x)  ( ( (x)  6)  0x01)
 to avoid problems with passing things to the macros.
OK, I will fix in next version.

Thanks
Ma Ling
 
 Alex

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

restoring XvMC with DRI2 with xf86-video-intel-2.6.0

[Antoine Martin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

As can be seen in the:
[ANNOUNCE] xf86-video-intel 2.6.0

There is a commit named:
  Disable XvMC on DRI2 for now

XvMC is quite important in desktop environments (as it is
very difficult to get decent video playback speed without it)
Are there any plans to re-enable it in 2.6.1?
I could see quite a few problems ahead if distros start shipping DRI2
without XvMC...
(apart from that - UXA/DRI2 rock!)

Thanks
Antoine

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREKAAYFAkl5dkQACgkQGK2zHPGK1ruWGgCeL22KpvwfbYibZ8H/LzJZt2lX
YcsAn26zdSPkdn+zGPsvXZPRCkvJ8lXQ
=fINu
-END PGP SIGNATURE-
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg