Re: [PATCH] input: Fix format string for verify_internal_event

2011-05-16 Thread Mark Kettenis 
On Sat, May 14, 2011 at 04:31:10PM -0700, Jeremy Huddleston wrote:
 
 inpututils.c:577:25: warning: conversion specifies type 'unsigned short' but 
 the argument has type 'unsigned char' [-Wformat,Format String Issue]
 ErrorF(%02hx , *data);
 ^~
 %02hhx
 1 warning generated.

While the fix isn't wrong, it's odd that clang complains about this.
Since ErrorF is a varargs function, *data will be promoted to int, so
while printing it with %02hx is a bit odd, it is perfectly legal C.
Because of the integer promotion, I would actually simply use %02x
here, since I think the h and hh length modifiers are a bit obscure.
Would clang complain about using %02x as well?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] linux: Clean up filenames used in Linux VT init.

2011-05-16 Thread Timothy Meade 
On May 14, 2011 3:39 PM, Cody Maloney cmalo...@theoreticalchaos.com
wrote:

 According to the comment in the Linux kernel source file
 drivers/tty/vt/vt_ioctl.c /dev/tty0 points to /dev/console,
 so we should just go to /dev/console, and virtual terminals
 are always labeled /dev/ttyN where N is 1..MAX_NR_CONSOLES,
 so only check /dev/ttyN.

 Signed-off-by: Cody Maloney cmalo...@theoreticalchaos.com
 ---
  hw/xfree86/os-support/linux/lnx_init.c |   39
++-
  1 files changed, 8 insertions(+), 31 deletions(-)

 diff --git a/hw/xfree86/os-support/linux/lnx_init.c
b/hw/xfree86/os-support/linux/lnx_init.c
 index 77dfb2f..04518f3 100644
 --- a/hw/xfree86/os-support/linux/lnx_init.c
 +++ b/hw/xfree86/os-support/linux/lnx_init.c
 @@ -76,17 +76,17 @@ switch_to(int vt, const char *from)
  void
  xf86OpenConsole(void)
  {
 -int i, fd = -1, ret;
 +int fd = -1, ret;
 struct vt_mode VT;
 struct vt_stat vts;
 MessageType from = X_PROBED;
 -char *tty0[] = { /dev/tty0, /dev/vc/0, NULL };
 -char *vcs[] = { /dev/vc/%d, /dev/tty%d, NULL };
 +const char *console_fname = /dev/console;
 +char *vcs = /dev/tty%d;

 if (serverGeneration == 1) {

/* when KeepTty check if we're run with euid==0 */
 -   if (KeepTty  geteuid() != 0)
 +   if (KeepTty  geteuid() != 0)
FatalError(xf86OpenConsole:
Server must be suid root for option
\KeepTTY\\n);

 @@ -96,17 +96,11 @@ xf86OpenConsole(void)
if (xf86Info.vtno != -1) {
from = X_CMDLINE;
} else {
 +   fd = open(console_fname, O_WRONLY, 0);

 -   i=0;
 -   while (tty0[i] != NULL) {
 -   if ((fd = open(tty0[i],O_WRONLY,0)) = 0)
 - break;
 -   i++;
 -   }
 -
if (fd  0)
FatalError(
 -   xf86OpenConsole: Cannot open /dev/tty0 (%s)\n,
 +   xf86OpenConsole: Cannot open /dev/console to use VT
ioctls (%s)\n,
strerror(errno));

 if (ShareVTs)
 @@ -149,13 +143,8 @@ xf86OpenConsole(void)
strerror(errno));
}

 -i=0;
 -while (vcs[i] != NULL) {
 -sprintf(vtname, vcs[i], xf86Info.vtno); /* /dev/tty1-64 */
 -   if ((xf86Info.consoleFd = open(vtname, O_RDWR|O_NDELAY, 0)) =
0)
 -   break;
 -i++;
 -}
 +sprintf(vtname, vcs, xf86Info.vtno); /* /dev/tty1-64 */
 +xf86Info.consoleFd = open(vtname, O_RDWR|O_NDELAY, 0);

if (xf86Info.consoleFd  0)
FatalError(xf86OpenConsole: Cannot open virtual console
 @@ -172,18 +161,6 @@ xf86OpenConsole(void)
else
activeVT = vts.v_active;

 -#if 0
 -   if (!KeepTty) {
 -   /*
 -* Detach from the controlling tty to avoid char loss
 -*/
 -   if ((i = open(/dev/tty,O_RDWR)) = 0) {
 -   SYSCALL(ioctl(i, TIOCNOTTY, 0));
 -   close(i);
 -   }
 -   }
 -#endif
 -
 if (!ShareVTs)
 {
 struct termios nTty;
 --
 1.7.5.1

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel

This may be different when operating under mdev, devfs, android init,
devtmpfs (devfs replacement, not sure that's what it's called), especially
/dev/vc/*

Timothy Meade (tmzt)
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: xclock/oclock endian mismatch in Xfbdev [SOLVED]

2011-05-16 Thread Soeren Sandmann 
Dushara Jayasinghe dushara.jayasin...@hydrix.com writes:

 I'm Working on an iMX.25 (ARM) based embedded platform with
 xserver_xorg-server-1.7.5.

 I had to make the following mods to servermd.h to reflect the hardware.

 #define FBNOPIXADDR
 #define IMAGE_BYTE_ORDER MSBFirst
 #define BITMAP_BIT_ORDER MSBFirst

 This setup works with xlogo and oclock (The image looks correct). However
 when running xclock and a 3rd party gtk based app, the BIT/BYTE_ORDER is
 incorrect.

 Are there instances where these defines are ignored? Any ideas on where I
 should start looking?

 Ok figured it out. It stems from the fact that the CPU endianness (arm
 being LITTLE endian) doesn't match the endianness of the LCD
 peripheral (big). So even though I configured the FB, pixman was
 setting the endianness via the configure script. Which brings me to my
 next question, shouldn't pixman, xserver (and anything else that I may
 not have encountered yet) have this setting configured in a single
 place?

Generally, pixman should be compiled with the endianness of the CPU, not
of the framebuffer. There could easily be code in pixman that depends on
the endian-ness of the CPU for other things than swapping color
channels. If compiled with the wrong endianness, such code will break.

The right way to deal with framebuffers with the opposite endian of the
CPU is to add new swapped formats, not to compile pixman with the wrong
endianness. For example, the b8g8r8a8 format was added to deal with the
a8r8g8b8 format on a framebuffer that was endian-swapped reletive to the
host it was attached to.


Soren
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] input: Fix format string for verify_internal_event

2011-05-16 Thread Jeremy Huddleston 

On May 16, 2011, at 01:13, Mark Kettenis wrote:

 On Sat, May 14, 2011 at 04:31:10PM -0700, Jeremy Huddleston wrote:
 
 inpututils.c:577:25: warning: conversion specifies type 'unsigned short' but 
 the argument has type 'unsigned char' [-Wformat,Format String Issue]
ErrorF(%02hx , *data);
^~
%02hhx
 1 warning generated.
 
 While the fix isn't wrong, it's odd that clang complains about this.
 Since ErrorF is a varargs function, *data will be promoted to int, so
 while printing it with %02hx is a bit odd, it is perfectly legal C.
 Because of the integer promotion, I would actually simply use %02x
 here, since I think the h and hh length modifiers are a bit obscure.
 Would clang complain about using %02x as well?

Yes, and I believe gcc will complain about it as well if you specify a strict 
enough -Wformat.  The warning is there to ensure that you know what you are 
doing.  Yes, functionally they probably result in the bits output, but 
eliminating warnings helps the important ones stand out more.

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH twm 2/3] Add sanity checking to avoid a possible NULL dereference

2011-05-16 Thread walter harms 


Am 12.05.2011 07:43, schrieb Jeremy Huddleston:
 
 menus.c:934:26: warning: Access to field 'fore' results in a dereference of a 
 null pointer (loaded from variable 'cur')
 cur-hi_back = cur-fore = f3.pixel;
~~~  ^
 
 Found-by: clang static analyzer
 Signed-off-by: Jeremy Huddleston jerem...@apple.com
 ---
  src/menus.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/src/menus.c b/src/menus.c
 index 34a3c8e..395426f 100644
 --- a/src/menus.c
 +++ b/src/menus.c
 @@ -920,7 +920,7 @@ MakeMenu(MenuRoot *mr)
   b3.flags = DoRed | DoGreen | DoBlue;
  
   num -= 1;
 - for (i = 0, cur = start-next; i  num; i++, cur = cur-next)
 + for (i = 0, cur = start-next; i  num  cur; i++, cur = cur-next)
   {
   f3.red += fred;
   f3.green += fgreen;

you are mixing two for loops, it would improve readability if you could
entangle that.

re,
 wh
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] fb: Fix memcpy abuse

2011-05-16 Thread Cyril Brulebois 
Adam Jackson a...@redhat.com (02/05/2011):
 I like the idea of having more in pixman and less in fb. […]

I'm also happy with that, but I'd really love to get correctness in
the server in the meanwhile. I've applied Soeren's and Walter's
suggestions and the offending memcpy() calls are apparently gone
(thanks to the glibc wrapper Aurélien Jarno implemented to report
memcpy calls with overlapping areas through syslog[1]), tested by
playing the resize-my-terminal-like-crazy game.

 1. http://packages.qa.debian.org/e/eglibc/news/20110511T224840Z.html

I'm about to send a follow-up to your initial patch, I tried to
preserve authorship information, but not exactly sure how to handle
the v2-with-a-different-author thing. Feel free to point any issue.

Mraw,
KiBi.


signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH v2] Try and get overlapping cases fixed.

2011-05-16 Thread Cyril Brulebois 
From: Adam Jackson a...@redhat.com

The memcpy fast path implicitly assumes that the copy walks
left-to-right.  That's not something memcpy guarantees, and newer glibc
on some processors will indeed break that assumption.  Since we walk a
line at a time, check the source and destination against the width of
the blit to determine whether we can be sloppy enough to allow memcpy.
(Having done this, we can remove the check for !reverse as well.)

On an Intel Core i7-2630QM with an NVIDIA GeForce GTX 460M running in
NoAccel, the broken code and various fixes for -copywinwin{10,100,500}
gives (edited to fit in 80 columns):

1: Disable the fastpath entirely
2: Replace memcpy with memmove
3: This fix
4: The code before this fix

  12 3 4   Operation
--   ---   ---   ---   
258000   269000 (  1.04)   544000 (  2.11)   552000 (  2.14)   Copy 10x10
 2130023000 (  1.08)43700 (  2.05)47100 (  2.21)   Copy 100x100
   960  962 (  1.00) 1990 (  2.09) 1990 (  2.07)   Copy 500x500

So it's a modest performance hit, but correctness demands it, and it's
probably worth keeping the 2x speedup from having the fast path in the
first place.

Signed-off-by: Adam Jackson a...@redhat.com

v2: Fix limit cases thanks to Soeren Sandmann, and apply a tiny
optimization by Walter Harms.

Signed-off-by: Cyril Brulebois k...@debian.org
---
 fb/fbblt.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)


Tested on amd64 on top of xorg-server's server-1.10-branch.


diff --git a/fb/fbblt.c b/fb/fbblt.c
index 38271c0..b6e7785 100644
--- a/fb/fbblt.c
+++ b/fb/fbblt.c
@@ -65,6 +65,7 @@ fbBlt (FbBits   *srcLine,
 intn, nmiddle;
 BooldestInvarient;
 intstartbyte, endbyte;
+int careful;
 FbDeclareMergeRop ();
 
 #ifdef FB_24BIT
@@ -76,7 +77,9 @@ fbBlt (FbBits   *srcLine,
 }
 #endif
 
-if (alu == GXcopy  pm == FB_ALLONES  !reverse 
+careful = (width * (bpp / 8)  abs(srcLine-dstLine)) || (bpp % 8);
+
+if (alu == GXcopy  pm == FB_ALLONES  !careful 
 !(srcX  7)  !(dstX  7)  !(width  7)) {
 int i;
 CARD8 *src = (CARD8 *) srcLine;
-- 
1.7.5.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v2] Try and get overlapping cases fixed.

2011-05-16 Thread Jeremy Huddleston 
Is the one div needed for:

bpp / 8
bpp % 8

really universally faster than the two bitwise ops needed for

bpp  3
bpp  0x7

?  I'm sure most modern compilers will know how to optimize that based on the 
target CPU, but I've always tried to avoid doing mults and divs in fast paths 
where possible.

--Jeremy

On May 16, 2011, at 09:08, Cyril Brulebois wrote:

 From: Adam Jackson a...@redhat.com
 
 The memcpy fast path implicitly assumes that the copy walks
 left-to-right.  That's not something memcpy guarantees, and newer glibc
 on some processors will indeed break that assumption.  Since we walk a
 line at a time, check the source and destination against the width of
 the blit to determine whether we can be sloppy enough to allow memcpy.
 (Having done this, we can remove the check for !reverse as well.)
 
 On an Intel Core i7-2630QM with an NVIDIA GeForce GTX 460M running in
 NoAccel, the broken code and various fixes for -copywinwin{10,100,500}
 gives (edited to fit in 80 columns):
 
 1: Disable the fastpath entirely
 2: Replace memcpy with memmove
 3: This fix
 4: The code before this fix
 
  12 3 4   Operation
 --   ---   ---   ---   
 258000   269000 (  1.04)   544000 (  2.11)   552000 (  2.14)   Copy 10x10
 2130023000 (  1.08)43700 (  2.05)47100 (  2.21)   Copy 100x100
   960  962 (  1.00) 1990 (  2.09) 1990 (  2.07)   Copy 500x500
 
 So it's a modest performance hit, but correctness demands it, and it's
 probably worth keeping the 2x speedup from having the fast path in the
 first place.
 
 Signed-off-by: Adam Jackson a...@redhat.com
 
 v2: Fix limit cases thanks to Soeren Sandmann, and apply a tiny
optimization by Walter Harms.
 
 Signed-off-by: Cyril Brulebois k...@debian.org
 ---
 fb/fbblt.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
 
 
 Tested on amd64 on top of xorg-server's server-1.10-branch.
 
 
 diff --git a/fb/fbblt.c b/fb/fbblt.c
 index 38271c0..b6e7785 100644
 --- a/fb/fbblt.c
 +++ b/fb/fbblt.c
 @@ -65,6 +65,7 @@ fbBlt (FbBits   *srcLine,
 int   n, nmiddle;
 BooldestInvarient;
 int   startbyte, endbyte;
 +int careful;
 FbDeclareMergeRop ();
 
 #ifdef FB_24BIT
 @@ -76,7 +77,9 @@ fbBlt (FbBits   *srcLine,
 }
 #endif
 
 -if (alu == GXcopy  pm == FB_ALLONES  !reverse 
 +careful = (width * (bpp / 8)  abs(srcLine-dstLine)) || (bpp % 8);
 +
 +if (alu == GXcopy  pm == FB_ALLONES  !careful 
 !(srcX  7)  !(dstX  7)  !(width  7)) {
 int i;
 CARD8 *src = (CARD8 *) srcLine;
 -- 
 1.7.5.1
 
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel
 

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] bsd: Add support for -novtswitch.

2011-05-16 Thread Cyril Brulebois 
Hi,

Alan Coopersmith alan.coopersm...@oracle.com (13/05/2011):
 Our gdm maintainer has been poking me about -novtswitch as well, so
 maybe we should consider moving it up to the xfree86 ddx common
 layer, instead of replicating for each OS.

are there any prospective patches in that direction? Or should I
address the points Julien raised to get it merged for FreeBSD before
it moves to the ddx common layer?

Mraw,
KiBi.


signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] xfree86: add nouveau as the first automatic driver for NVIDIA hardware

2011-05-16 Thread Cyril Brulebois 
Daniel Stone dan...@fooishbar.org (20/04/2011):
 On Wed, Apr 20, 2011 at 02:34:52PM +0300, Anssi Hannula wrote:
  Heh, I thought of that but decided not to do it as it would be so
  different from the rest of the entries. In any case, attached is the
  patch using that style.
 
 Though I prefer the original one by virtue of fitting in better, take my
 R-b for either form:
 Reviewed-by: Daniel Stone dan...@fooishbar.org

For either form as well:
Reviewed-by: Cyril Brulebois k...@debian.org

Mraw,
KiBi.


signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v2] Try and get overlapping cases fixed.

2011-05-16 Thread Adam Jackson 

On 5/16/11 12:26 PM, Jeremy Huddleston wrote:

Is the one div needed for:

bpp / 8

 bpp % 8


really universally faster than the two bitwise ops needed for

bpp  3

 bpp  0x7


?  I'm sure most modern compilers will know how to optimize that
based on the target CPU, but I've always tried to avoid doing mults
and divs in fast paths where possible.


Even if it's ten cycles slower, I'm going to wager it pales next to the 
hundreds-to-millions of cycles of memcpy.


- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xfree86] Signed-off-by: Oleh Nykyforchyn oleh....@gmail.com

2011-05-16 Thread Oleh R. Nykyforchyn 
xfree86: allow negative conditions in Match* statements

Match statement syntax is extended to allow strings like:
aaa,!a,bbb,!b,ccc,!c
Match succeedes if an attribute matches aaa, bbb, or ccc, or
does not match neither a, b, or c.

Signed-off-by: Oleh Nykyforchyn oleh@gmail.com
---
 hw/xfree86/common/xf86Xinput.c |   28 ++--
 1 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index e7e1ce1..9462bad 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -495,13 +495,29 @@ MatchAttrToken(const char *attr, struct list *patterns,
 char * const *cur;
 Bool match = FALSE;
 
-for (cur = group-values; *cur; cur++)
-if ((*compare)(attr, *cur) == 0) {
-match = TRUE;
-break;
+for (cur = group-values; *cur; cur++) {
+if (**cur == '!') {
+/*
+ * A condition starting with '!' is NEGATIVE
+ * If it is matched, the match is rejected
+ */
+if ((*compare)(attr, *cur+1) == 0)
+return FALSE;
+else
+match = TRUE;
+}
+else {
+if ((*compare)(attr, *cur) == 0) {
+match = TRUE;
+break;
+}
+}
 }
-if (!match)
-return FALSE;
+/*
+ * Either a positive condition or all
+ * negative conditions succeeded
+ */
+if (!match) return FALSE;
 }
 
 /* All the entries in the list matched the attribute */
-- 
1.7.4.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xfree86] Signed-off-by: Oleh Nykyforchyn oleh....@gmail.com

2011-05-16 Thread Oleh R. Nykyforchyn 
xfree86: Allow MatchLayout string in config files

Usage example (tested on a dual-seat PC):
Section InputClass
Identifier keyboard-all
MatchIsKeyboard on
MatchDevicePath /dev/input/event*
MatchLayout !GeForce|!Matrox
Driver evdev
Option XkbLayout us
Option XkbOptions terminate:ctrl_alt_bksp
EndSection

It disables auto keyboard configuration for layouts GeForce and Matrox.

Signed-off-by: Oleh Nykyforchyn oleh@gmail.com
---
 hw/xfree86/common/xf86Xinput.c |7 +++
 hw/xfree86/parser/InputClass.c |   21 +
 hw/xfree86/parser/xf86Parser.h |1 +
 hw/xfree86/parser/xf86tokens.h |1 +
 4 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index 9462bad..0906c1c 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -580,6 +580,13 @@ InputClassMatches(const XF86ConfInputClassPtr iclass, 
const InputInfoPtr idev,
 return FALSE;
 }
 
+/* MatchLayout string */
+if (!list_is_empty(iclass-match_layout)) {
+if (!MatchAttrToken((xf86ConfigLayout.id ? xf86ConfigLayout.id : ),
+iclass-match_layout, strcmp))
+return FALSE;
+}
+
 /* MatchIs* booleans */
 if (iclass-is_keyboard.set 
 iclass-is_keyboard.val != !!(attrs-flags  ATTR_KEYBOARD))
diff --git a/hw/xfree86/parser/InputClass.c b/hw/xfree86/parser/InputClass.c
index 9f88e7e..3f80170 100644
--- a/hw/xfree86/parser/InputClass.c
+++ b/hw/xfree86/parser/InputClass.c
@@ -52,6 +52,7 @@ xf86ConfigSymTabRec InputClassTab[] =
 {MATCH_USBID, matchusbid},
 {MATCH_DRIVER, matchdriver},
 {MATCH_TAG, matchtag},
+{MATCH_LAYOUT, matchlayout},
 {MATCH_IS_KEYBOARD, matchiskeyboard},
 {MATCH_IS_POINTER, matchispointer},
 {MATCH_IS_JOYSTICK, matchisjoystick},
@@ -94,6 +95,7 @@ xf86parseInputClassSection(void)
 list_init(ptr-match_usbid);
 list_init(ptr-match_driver);
 list_init(ptr-match_tag);
+list_init(ptr-match_layout);
 
 while ((token = xf86getToken(InputClassTab)) != ENDSECTION) {
 switch (token) {
@@ -169,6 +171,12 @@ xf86parseInputClassSection(void)
 add_group_entry(ptr-match_tag,
 xstrtokenize(val.str, TOKEN_SEP));
 break;
+case MATCH_LAYOUT:
+if (xf86getSubToken((ptr-comment)) != STRING)
+Error(QUOTE_MSG, MatchLayout);
+add_group_entry(ptr-match_layout,
+xstrtokenize(val.str, TOKEN_SEP));
+break;
 case MATCH_IS_KEYBOARD:
 if (xf86getSubToken((ptr-comment)) != STRING)
 Error(QUOTE_MSG, MatchIsKeyboard);
@@ -307,6 +315,13 @@ xf86printInputClassSection (FILE * cf, 
XF86ConfInputClassPtr ptr)
 *cur);
 fprintf(cf, \\n);
 }
+list_for_each_entry(group, ptr-match_layout, entry) {
+fprintf(cf, \tMatchLayout \);
+for (cur = group-values; *cur; cur++)
+fprintf(cf, %s%s, cur == group-values ?  : TOKEN_SEP,
+*cur);
+fprintf(cf, \\n);
+}
 
 if (ptr-is_keyboard.set)
 fprintf(cf, \tIsKeyboard  \%s\\n,
@@ -392,6 +407,12 @@ xf86freeInputClassList (XF86ConfInputClassPtr ptr)
 free(*list);
 free(group);
 }
+list_for_each_entry_safe(group, next, ptr-match_layout, entry) {
+list_del(group-entry);
+for (list = group-values; *list; list++)
+free(*list);
+free(group);
+}
 
 TestFree(ptr-comment);
 xf86optionListFree(ptr-option_lst);
diff --git a/hw/xfree86/parser/xf86Parser.h b/hw/xfree86/parser/xf86Parser.h
index 4f279f1..a8785c5 100644
--- a/hw/xfree86/parser/xf86Parser.h
+++ b/hw/xfree86/parser/xf86Parser.h
@@ -358,6 +358,7 @@ typedef struct
struct list match_usbid;
struct list match_driver;
struct list match_tag;
+   struct list match_layout;
xf86TriState is_keyboard;
xf86TriState is_pointer;
xf86TriState is_joystick;
diff --git a/hw/xfree86/parser/xf86tokens.h b/hw/xfree86/parser/xf86tokens.h
index 468a2ff..abcafcf 100644
--- a/hw/xfree86/parser/xf86tokens.h
+++ b/hw/xfree86/parser/xf86tokens.h
@@ -282,6 +282,7 @@ typedef enum {
 MATCH_USBID,
 MATCH_DRIVER,
 MATCH_TAG,
+MATCH_LAYOUT,
 MATCH_IS_KEYBOARD,
 MATCH_IS_POINTER,
 MATCH_IS_JOYSTICK,
-- 
1.7.4.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] Fix XWin compilation after updates for input API changes

2011-05-16 Thread Jon TURNEY 
From: Colin Harrison colin.harri...@virgin.net

Fix XWin compilation after updates for input API changes in commits
e7150db5 8670c46b and 20fb07f4

Also remove a no longer needed InternalEvent* variable

Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
 hw/xwin/winkeybd.c |6 ++
 hw/xwin/winmouse.c |4 ++--
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/hw/xwin/winkeybd.c b/hw/xwin/winkeybd.c
index 2fa6b3f..a3112ff 100644
--- a/hw/xwin/winkeybd.c
+++ b/hw/xwin/winkeybd.c
@@ -472,8 +472,6 @@ winKeybdReleaseKeys (void)
 void
 winSendKeyEvent (DWORD dwKey, Bool fDown)
 {
-  InternalEvent* events;
-
   /*
* When alt-tabing between screens we can get phantom key up messages
* Here we only pass them through it we think we should!
@@ -485,8 +483,8 @@ winSendKeyEvent (DWORD dwKey, Bool fDown)
 
   QueueKeyboardEvents(g_pwinKeyboard, fDown ? KeyPress : KeyRelease, dwKey + 
MIN_KEYCODE, NULL);
 
-  winDebug(winSendKeyEvent: dwKey: %d, fDown: %d, nEvents %d\n,
-   dwKey, fDown, nevents);
+  winDebug(winSendKeyEvent: dwKey: %d, fDown: %d\n,
+   dwKey, fDown);
 }
 
 BOOL winCheckKeyPressed(WPARAM wParam, LPARAM lParam)
diff --git a/hw/xwin/winmouse.c b/hw/xwin/winmouse.c
index b1b0657..752334a 100644
--- a/hw/xwin/winmouse.c
+++ b/hw/xwin/winmouse.c
@@ -244,8 +244,8 @@ winMouseButtonsSendEvent (int iEventType, int iButton)
 POINTER_RELATIVE, mask);
 
 #if CYGDEBUG
-  ErrorF(winMouseButtonsSendEvent: iEventType: %d, iButton: %d, nEvents %d\n,
-  iEventType, iButton, nevents);
+  ErrorF(winMouseButtonsSendEvent: iEventType: %d, iButton: %d\n,
+  iEventType, iButton);
 #endif
 }
 
-- 
1.7.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] linux: Clean up filenames used in Linux VT init.

2011-05-16 Thread Cody Maloney 
On Mon, May 16, 2011 at 5:27 AM, Timothy Meade zt.t...@gmail.com wrote:

 On May 14, 2011 3:39 PM, Cody Maloney cmalo...@theoreticalchaos.com
 wrote:

 According to the comment in the Linux kernel source file
 drivers/tty/vt/vt_ioctl.c /dev/tty0 points to /dev/console,
 so we should just go to /dev/console, and virtual terminals
 are always labeled /dev/ttyN where N is 1..MAX_NR_CONSOLES,
 so only check /dev/ttyN.

 Signed-off-by: Cody Maloney cmalo...@theoreticalchaos.com
 ---
  hw/xfree86/os-support/linux/lnx_init.c |   39
 ++-
  1 files changed, 8 insertions(+), 31 deletions(-)

 diff --git a/hw/xfree86/os-support/linux/lnx_init.c
 b/hw/xfree86/os-support/linux/lnx_init.c
 index 77dfb2f..04518f3 100644
 --- a/hw/xfree86/os-support/linux/lnx_init.c
 +++ b/hw/xfree86/os-support/linux/lnx_init.c
 @@ -76,17 +76,17 @@ switch_to(int vt, const char *from)
  void
  xf86OpenConsole(void)
  {
 -    int i, fd = -1, ret;
 +    int fd = -1, ret;
     struct vt_mode VT;
     struct vt_stat vts;
     MessageType from = X_PROBED;
 -    char *tty0[] = { /dev/tty0, /dev/vc/0, NULL };
 -    char *vcs[] = { /dev/vc/%d, /dev/tty%d, NULL };
 +    const char *console_fname = /dev/console;
 +    char *vcs = /dev/tty%d;

     if (serverGeneration == 1) {

        /* when KeepTty check if we're run with euid==0 */
 -       if (KeepTty  geteuid() != 0)
 +       if (KeepTty  geteuid() != 0)
            FatalError(xf86OpenConsole:
                        Server must be suid root for option
 \KeepTTY\\n);

 @@ -96,17 +96,11 @@ xf86OpenConsole(void)
        if (xf86Info.vtno != -1) {
            from = X_CMDLINE;
        } else {
 +           fd = open(console_fname, O_WRONLY, 0);

 -           i=0;
 -           while (tty0[i] != NULL) {
 -               if ((fd = open(tty0[i],O_WRONLY,0)) = 0)
 -                 break;
 -               i++;
 -           }
 -
            if (fd  0)
                FatalError(
 -                   xf86OpenConsole: Cannot open /dev/tty0 (%s)\n,
 +                   xf86OpenConsole: Cannot open /dev/console to use VT
 ioctls (%s)\n,
                    strerror(errno));

             if (ShareVTs)
 @@ -149,13 +143,8 @@ xf86OpenConsole(void)
                        strerror(errno));
        }

 -        i=0;
 -        while (vcs[i] != NULL) {
 -            sprintf(vtname, vcs[i], xf86Info.vtno); /* /dev/tty1-64 */
 -           if ((xf86Info.consoleFd = open(vtname, O_RDWR|O_NDELAY, 0)) =
 0)
 -               break;
 -            i++;
 -        }
 +        sprintf(vtname, vcs, xf86Info.vtno); /* /dev/tty1-64 */
 +        xf86Info.consoleFd = open(vtname, O_RDWR|O_NDELAY, 0);

        if (xf86Info.consoleFd  0)
            FatalError(xf86OpenConsole: Cannot open virtual console
 @@ -172,18 +161,6 @@ xf86OpenConsole(void)
        else
            activeVT = vts.v_active;

 -#if 0
 -       if (!KeepTty) {
 -           /*
 -            * Detach from the controlling tty to avoid char loss
 -            */
 -           if ((i = open(/dev/tty,O_RDWR)) = 0) {
 -               SYSCALL(ioctl(i, TIOCNOTTY, 0));
 -               close(i);
 -           }
 -       }
 -#endif
 -
         if (!ShareVTs)
         {
             struct termios nTty;
 --
 1.7.5.1

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel

 This may be different when operating under mdev, devfs, android init,
 devtmpfs (devfs replacement, not sure that's what it's called), especially
 /dev/vc/*

 Timothy Meade (tmzt)

I just checked and in android, there is no /dev/tty0, /dev/vc/*, but
there is /dev/tty and /dev/console, so the old code would have missed
completely anyways. devtmpfs doesn't add any devices directly, relying
on what the kernel creates (I'll come back to what the kernel creates
later). devfs was killed off a while ago (replaced with udev), it
maintains /dev/tty[0-9]+, as well as /dev/vc/[0-9]+. All major distros
have switched off of it in new versions (versions which contain new
Xorg). Devtmpfs serves as a container for a minimal /dev for embedded
devices such as android, and only has devices documented in
doc/devices.txt added to it. For mdev, the directory name in /sys that
mdev finds the 'dev' file is located is taken to be the filename used
for the device name, this means it could never add subdirectories, so
/dev/vc/0 could never exist.

Grepping through the kernel source, the only place where
/dev/vc/[0-9]+ is mentioned is one line:
linux-2.6.38.6/drivers/tty/vt/vt.c: 
register_chrdev_region(MKDEV(TTY_MAJOR, 0), 1, /dev/vc/0)  0)

Looking at the source code, this may or may not be created depending
on whether or not the if exits early. /dev/tty0 is always created. If
you look at the updated patch I sent
(http://lists.freedesktop.org/archives/xorg-devel/2011-May/05.html),
I use /dev/tty0 instead of /dev/console because, as Julien pointed
out,

Re: [PATCH] Fix XWin compilation after updates for input API changes

2011-05-16 Thread Peter Hutterer 
On Mon, May 16, 2011 at 07:31:57PM +0100, Jon TURNEY wrote:
 From: Colin Harrison colin.harri...@virgin.net
 
 Fix XWin compilation after updates for input API changes in commits
 e7150db5 8670c46b and 20fb07f4
 
 Also remove a no longer needed InternalEvent* variable
 
 Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
 ---

merged, thanks. and sorry, fwiw.

Cheers,
  Peter

  hw/xwin/winkeybd.c |6 ++
  hw/xwin/winmouse.c |4 ++--
  2 files changed, 4 insertions(+), 6 deletions(-)
 
 diff --git a/hw/xwin/winkeybd.c b/hw/xwin/winkeybd.c
 index 2fa6b3f..a3112ff 100644
 --- a/hw/xwin/winkeybd.c
 +++ b/hw/xwin/winkeybd.c
 @@ -472,8 +472,6 @@ winKeybdReleaseKeys (void)
  void
  winSendKeyEvent (DWORD dwKey, Bool fDown)
  {
 -  InternalEvent* events;
 -
/*
 * When alt-tabing between screens we can get phantom key up messages
 * Here we only pass them through it we think we should!
 @@ -485,8 +483,8 @@ winSendKeyEvent (DWORD dwKey, Bool fDown)
  
QueueKeyboardEvents(g_pwinKeyboard, fDown ? KeyPress : KeyRelease, dwKey + 
 MIN_KEYCODE, NULL);
  
 -  winDebug(winSendKeyEvent: dwKey: %d, fDown: %d, nEvents %d\n,
 -   dwKey, fDown, nevents);
 +  winDebug(winSendKeyEvent: dwKey: %d, fDown: %d\n,
 +   dwKey, fDown);
  }
  
  BOOL winCheckKeyPressed(WPARAM wParam, LPARAM lParam)
 diff --git a/hw/xwin/winmouse.c b/hw/xwin/winmouse.c
 index b1b0657..752334a 100644
 --- a/hw/xwin/winmouse.c
 +++ b/hw/xwin/winmouse.c
 @@ -244,8 +244,8 @@ winMouseButtonsSendEvent (int iEventType, int iButton)
POINTER_RELATIVE, mask);
  
  #if CYGDEBUG
 -  ErrorF(winMouseButtonsSendEvent: iEventType: %d, iButton: %d, nEvents 
 %d\n,
 -  iEventType, iButton, nevents);
 +  ErrorF(winMouseButtonsSendEvent: iEventType: %d, iButton: %d\n,
 +  iEventType, iButton);
  #endif
  }
  
 -- 
 1.7.4
 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: xclock/oclock endian mismatch in Xfbdev [SOLVED]

2011-05-16 Thread Dushara Jayasinghe 

On 17/05/2011 12:08 AM, Soeren Sandmann wrote:

Dushara Jayasinghedushara.jayasin...@hydrix.com  writes:


I'm Working on an iMX.25 (ARM) based embedded platform with
xserver_xorg-server-1.7.5.

I had to make the following mods to servermd.h to reflect the hardware.

#define FBNOPIXADDR
#define IMAGE_BYTE_ORDERMSBFirst
#define BITMAP_BIT_ORDERMSBFirst

This setup works with xlogo and oclock (The image looks correct). However
when running xclock and a 3rd party gtk based app, the BIT/BYTE_ORDER is
incorrect.

Are there instances where these defines are ignored? Any ideas on where I
should start looking?


Ok figured it out. It stems from the fact that the CPU endianness (arm
being LITTLE endian) doesn't match the endianness of the LCD
peripheral (big). So even though I configured the FB, pixman was
setting the endianness via the configure script. Which brings me to my
next question, shouldn't pixman, xserver (and anything else that I may
not have encountered yet) have this setting configured in a single
place?


Generally, pixman should be compiled with the endianness of the CPU, not
of the framebuffer. There could easily be code in pixman that depends on
the endian-ness of the CPU for other things than swapping color
channels. If compiled with the wrong endianness, such code will break.

The right way to deal with framebuffers with the opposite endian of the
CPU is to add new swapped formats, not to compile pixman with the wrong
endianness. For example, the b8g8r8a8 format was added to deal with the
a8r8g8b8 format on a framebuffer that was endian-swapped reletive to the
host it was attached to.


Hi Thanks for the reply Soren,

I'll have a look at it again to see how I can fix it. Thanks again.

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: xclock/oclock endian mismatch in Xfbdev [SOLVED]

2011-05-16 Thread Dushara Jayasinghe 

On 17/05/2011 12:08 AM, Soeren Sandmann wrote:

Dushara Jayasinghedushara.jayasin...@hydrix.com  writes:


I'm Working on an iMX.25 (ARM) based embedded platform with
xserver_xorg-server-1.7.5.

I had to make the following mods to servermd.h to reflect the hardware.

#define FBNOPIXADDR
#define IMAGE_BYTE_ORDERMSBFirst
#define BITMAP_BIT_ORDERMSBFirst

This setup works with xlogo and oclock (The image looks correct). However
when running xclock and a 3rd party gtk based app, the BIT/BYTE_ORDER is
incorrect.

Are there instances where these defines are ignored? Any ideas on where I
should start looking?


Ok figured it out. It stems from the fact that the CPU endianness (arm
being LITTLE endian) doesn't match the endianness of the LCD
peripheral (big). So even though I configured the FB, pixman was
setting the endianness via the configure script. Which brings me to my
next question, shouldn't pixman, xserver (and anything else that I may
not have encountered yet) have this setting configured in a single
place?


Generally, pixman should be compiled with the endianness of the CPU, not
of the framebuffer. There could easily be code in pixman that depends on
the endian-ness of the CPU for other things than swapping color
channels. If compiled with the wrong endianness, such code will break.

The right way to deal with framebuffers with the opposite endian of the
CPU is to add new swapped formats, not to compile pixman with the wrong
endianness. For example, the b8g8r8a8 format was added to deal with the
a8r8g8b8 format on a framebuffer that was endian-swapped reletive to the
host it was attached to.


I had a look at the pixman code but what's required to add the format 
that suits the hardware is not immediately obvious to me. The CPU 
peripheral is configured as 1bpp (packed). The MSbit is the left most pixel.


I'm guessing that I have to invent a new pixman type (maybe 
PIXMAN_TYPE_AREV) and add a format to the list in pixman_format_code_t 
pixman.h. And finally implement the handlers (yet to figure that out) 
that use the formats. Please tell me if I'm on the wrong track.


Thank you
D
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH:xdm 1/2] Add Solaris 11 libsocket to list of libraries to search for getifaddrs()

2011-05-16 Thread Alan Coopersmith 
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
 configure.ac |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 089329f..0c7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -59,8 +59,9 @@ AM_CONDITIONAL(HAVE_MKTEMP_COMMAND, test x$MKTEMP_COMMAND != 
x)
 # pre-pends the found library to $LIBS.
 #
 #--
-# Function getifaddrs() comes from the C library or the -lnsl name service 
library
-AC_SEARCH_LIBS([getifaddrs], [nsl])
+# Function getifaddrs() comes from the C library, Solaris 11 -lsocket, or
+# the -lnsl name service library
+AC_SEARCH_LIBS([getifaddrs], [socket nsl])
 
 # Function getspnam() comes from the C library, System V -lsec, UnixWare 7 
-lgen
 # or Old Linux versions -lshadow
-- 
1.7.3.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH:xdm 2/2] freeifaddrs() when done with it in DefineSelf()

2011-05-16 Thread Alan Coopersmith 
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
 xdm/auth.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xdm/auth.c b/xdm/auth.c
index 8b6e1ec..bbca167 100644
--- a/xdm/auth.c
+++ b/xdm/auth.c
@@ -851,6 +851,7 @@ DefineSelf(int fd, FILE *file, Xauth *auth)
 # endif
writeAddr(family, len, addr, file, auth);
 }
+freeifaddrs(ifap);
 Debug(DefineSelf done\n);
 }
 #else  /* GETIFADDRS */
-- 
1.7.3.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH:macros] Add AC_LANG_DEFINES_PROVIDED to XORG_RAW_CPP to silence autoconf warnings

2011-05-16 Thread Alan Coopersmith 
Since we're intentionally doing a special case to just check cpp output,
and not a full program compilation, add the magic macro to silence:

configure.ac:46: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in 
body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
aclocal.m4:1077: XORG_PROG_RAWCPP is expanded from...
configure.ac:46: the top level

Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
 xorg-macros.m4.in |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in
index f89efb6..a21cf7e 100644
--- a/xorg-macros.m4.in
+++ b/xorg-macros.m4.in
@@ -64,7 +64,8 @@ AC_PATH_PROGS(RAWCPP, [cpp], [${CPP}],
 # which is not the best choice for supporting other OS'es, but covers most
 # of the ones we need for now.
 AC_MSG_CHECKING([if $RAWCPP requires -undef])
-AC_LANG_CONFTEST([Does cpp redefine unix ?])
+AC_LANG_CONFTEST([Does cpp redefine unix ?
+ AC_LANG_DEFINES_PROVIDED])
 if test `${RAWCPP}  conftest.$ac_ext | grep -c 'unix'` -eq 1 ; then
AC_MSG_RESULT([no])
 else
@@ -82,7 +83,8 @@ fi
 rm -f conftest.$ac_ext
 
 AC_MSG_CHECKING([if $RAWCPP requires -traditional])
-AC_LANG_CONFTEST([Does cpp preserve   whitespace?])
+AC_LANG_CONFTEST([Does cpp preserve   whitespace?
+ AC_LANG_DEFINES_PROVIDED])
 if test `${RAWCPP}  conftest.$ac_ext | grep -c 'preserve   \'` -eq 1 ; then
AC_MSG_RESULT([no])
 else
-- 
1.7.3.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH:libXfont] Fix memory leak in allocation failure path of BitmapOpenScalable()

2011-05-16 Thread Alan Coopersmith 
Go ahead and fill in the font-info pointers so that bitmapUnloadScalable()
will free the bits that were allocated, even if some were not.

Error: Memory leak (CWE 401)
   Memory leak of pointer unknown allocated with ComputeScaledProperties(...)
at line 1629 of 
/export/alanc/X.Org/git/lib/libXfont/src/bitmap/bitscale.c in function 
'BitmapOpenScalable'.
  pointer allocated at line 1616 with ComputeScaledProperties(...).
  unknown leaks when props != 0 at line 1623.

[ This bug was found by the Parfait 0.3.7 bug checking tool.
  For more information see http://labs.oracle.com/projects/parfait/ ]

Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
 src/bitmap/bitscale.c |   11 ---
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/src/bitmap/bitscale.c b/src/bitmap/bitscale.c
index cf16bff..50818c6 100644
--- a/src/bitmap/bitscale.c
+++ b/src/bitmap/bitscale.c
@@ -1620,19 +1620,16 @@ BitmapOpenScalable (FontPathElementPtr fpe,
 if (!sourceFont-refcnt)
FontFileCloseFont((FontPathElementPtr) 0, sourceFont);
 
+font-info.props = props;
+font-info.nprops = propCount;
+font-info.isStringProp = isStringProp;
+
 if (propCount  (!props || !isStringProp))
 {
-   font-info.nprops = 0;
-   font-info.props = (FontPropPtr)0;
-   font-info.isStringProp = (char *)0;
bitmapUnloadScalable(font);
return AllocError;
 }
 
-font-info.props = props;
-font-info.nprops = propCount;
-font-info.isStringProp = isStringProp;
-
 *pFont = font;
 return Successful;
 }
-- 
1.7.3.2

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PULL] XQuartz crash fixes

2011-05-16 Thread Jeremy Huddleston 
The following changes since commit 0e7f61d72c4a929319e57c9b5b777e9413c23051:

  doc: use devbook.am for developers documentation (2011-05-14 11:22:29 -0700)

are available in the git repository at:
  git://people.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (3):
  XQuartz: Fix an array-index-out-of-bounds crasher
  XQuartz: Don't call mieqEnqueue during server shutdown
  XQuartz: RandR: Avoid over-releasing if we are unable to determine the 
current display mode.

 dix/main.c|   25 -
 hw/xquartz/console_redirect.c |2 +-
 hw/xquartz/pbproxy/app-main.m |6 +++---
 hw/xquartz/pbproxy/main.m |   16 
 hw/xquartz/quartzRandR.c  |   19 +++
 mi/mieq.c |   16 
 6 files changed, 47 insertions(+), 37 deletions(-)

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:xdm 1/2] Add Solaris 11 libsocket to list of libraries to search for getifaddrs()

2011-05-16 Thread Gaetan Nadon 
On Mon, 2011-05-16 at 17:52 -0700, Alan Coopersmith wrote:

 Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
 ---
  configure.ac |5 +++--
  1 files changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index 089329f..0c7 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -59,8 +59,9 @@ AM_CONDITIONAL(HAVE_MKTEMP_COMMAND, test x$MKTEMP_COMMAND 
 != x)
  # pre-pends the found library to $LIBS.
  #
  
 #--
 -# Function getifaddrs() comes from the C library or the -lnsl name service 
 library
 -AC_SEARCH_LIBS([getifaddrs], [nsl])
 +# Function getifaddrs() comes from the C library, Solaris 11 -lsocket, or
 +# the -lnsl name service library
 +AC_SEARCH_LIBS([getifaddrs], [socket nsl])
  
  # Function getspnam() comes from the C library, System V -lsec, UnixWare 7 
 -lgen
  # or Old Linux versions -lshadow


Acked-by: Gaetan Nadon mems...@videotron.ca


signature.asc
Description: This is a digitally signed message part
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel