"empty" model/layout for xkb

[Jeremy Huddleston]

I'm trying to modify xkeyboard-config to create an "empty" xbk rules set.  This 
way, we can set "empty" as the default in XQuartz and have a clean slate.

I'm having a bit of trouble getting this to work.  Firstly, I can't seem to 
figure out how to NOT set the +aliases(qwerty) variant on the keycodes.  
Secondly, it doesn't seem to recognize my empty symbols file.

Can someone fill me in on what I'm missing?

Thanks,
Jeremy


diff --git a/keycodes/Makefile.am b/keycodes/Makefile.am
index c289e14..68c9a54 100644
--- a/keycodes/Makefile.am
+++ b/keycodes/Makefile.am
@@ -6,6 +6,7 @@ dist_keycodes_DATA = \
 aliases \
 amiga \
 ataritt \
+empty \
 evdev \
 fujitsu \
 hp \
diff --git a/keycodes/empty b/keycodes/empty
new file mode 100644
index 000..eedc943
--- /dev/null
+++ b/keycodes/empty
@@ -0,0 +1,4 @@
+default xkb_keycodes "empty" {
+minimum= 8;
+maximum= 255;
+};
diff --git a/rules/base.m_k.part b/rules/base.m_k.part
index dd0c391..6d5eda0 100644
--- a/rules/base.m_k.part
+++ b/rules/base.m_k.part
@@ -1,5 +1,6 @@
   amiga=   amiga(de)
   ataritt  =   ataritt(de)
+  empty =   empty
   sun4 =   sun(type4_euro)
   sun5 =   sun(type5_euro)
   sun6 =   sun(type6_usb)
diff --git a/rules/base.ml_s.part b/rules/base.ml_s.part
index 1c16b6b..31e5d33 100644
--- a/rules/base.ml_s.part
+++ b/rules/base.ml_s.part
@@ -3,6 +3,8 @@
   amiga$nonlatin   =   
xfree68_vndr/amiga(usa1)+%l%(v):2
   amiga*   =   
xfree68_vndr/amiga(usa1)+%l%(v)
   classmateus  =   pc+%l(classmate)
+  empty *   =   empty
+  * empty   =   empty
   sun4 $nonlatin   =   
latin+sun_vndr/us(type4)+%l%(v):2
   sun4 *   =   latin+sun_vndr/us(type4)+%l%(v)
   sun5 $nonlatin   =   
latin+sun_vndr/us(type5)+%l%(v):2
diff --git a/symbols/Makefile.am b/symbols/Makefile.am
index d22d6c3..7724984 100644
--- a/symbols/Makefile.am
+++ b/symbols/Makefile.am
@@ -30,7 +30,7 @@ terminate \
 tj tm tr \
 ua us uz vn \
 za \
-altwin capslock compose ctrl eurosign group inet \
+altwin capslock compose ctrl empty eurosign group inet \
 keypad kpdl level3 level5 nbsp olpc shift srvr_ctrl typo
 
 dir_data = $(dist_symbols_DATA)
diff --git a/symbols/empty b/symbols/empty
new file mode 100644
index 000..72eb127
--- /dev/null
+++ b/symbols/empty
@@ -0,0 +1,6 @@
+// $XKeyboardConfig$
+
+default
+xkb_symbols "basic" {
+name[Group1]= "Empty";
+};


In my DDX, I'm doing this to set the rules:

+XkbRMLVOSet rmlvo = { .rules = "base", .model = "empty", .layout = "empty",
+  .variant = NULL, .options = NULL };
+/* We need to really have rules... or something... */
+XkbSetRulesDflts(&rmlvo);

These changes result in:

xkb_keymap {
xkb_keycodes "empty+aliases(qwerty)" {
minimum = 8;
maximum = 255;
virtual indicator 1 = "Caps Lock";
virtual indicator 2 = "Num Lock";
virtual indicator 3 = "Shift Lock";
virtual indicator 4 = "Group 2";
virtual indicator 5 = "Mouse Keys";
virtual indicator 6 = "Scroll Lock";
};

xkb_types "complete" {
...
};

xkb_compatibility "complete" {
...
}

xkb_symbols "unknown" {

key <> {
symbols[Group1]= [   a,   A ],
symbols[Group2]= [   aring,   Aring ]
};
modifier_map Mod2 { <> };
modifier_map Shift { <> };
modifier_map Lock { <> };
modifier_map Mod1 { <> };
modifier_map Control { <> };
modifier_map Shift { <> };
modifier_map Mod1 { <> };
modifier_map Control { <> };
modifier_map Mod2 { <> };
};

};



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

[PULL] XQuartz fix for stuck mouse pointer bug

[Jeremy Huddleston]

The following changes since commit 4d575b0559817258f7a0ce6c4d2d0f9e7e5bba63:
  Robert Morell (1):
RENDER: Fix gradient and solid fill pictures with Xinerama, and misc 
cleanup

are available in the git repository at:

  git://anongit.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (3):
  XQuartz: Add some .gitignore magic
  XQuartz: Dead code removal
  XQuartz: Attatch a stub display when CoreGraphics reports no displays.

 hw/xquartz/bundle/.gitignore  |1 +
 hw/xquartz/darwin.c   |   41 +
 hw/xquartz/darwin.h   |2 --
 hw/xquartz/pbproxy/.gitignore |1 +
 hw/xquartz/xpr/xprScreen.c|   13 +
 5 files changed, 16 insertions(+), 42 deletions(-)
 create mode 100644 hw/xquartz/bundle/.gitignore
 create mode 100644 hw/xquartz/pbproxy/.gitignore



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

Re: [PATCH util-macros 0/4] Add doc macros for groff fop, ps2pdf

[Jeremy Huddleston]

Series Reviewed-by: Jeremy Huddleston 

On Feb 1, 2010, at 08:23, Gaetan Nadon wrote:

> Second version.
> 
> This is the last installment of document generation control macros.
> The code is identical to the first 3 released, which were well reviewed.
> 
> In addition, the XORG_ENABLE_DOCS provides a --enable-docs option intended to 
> replace the
> various ad hoc options like:
> enable-devel-docs
> enable-specs
> enable-builddocs
> enable-docs   (this one has been retained)
> 
> The default value is "yes" but can be changed in the configuration file:
> XORG_ENABLE_DOCS(no)
> 
> Assumption:
> The concept of "doc" does not apply to "man pages". They will continue to be 
> build without
> condition. The exception are those built with xmlto. If the tool is not there,
> they will be skipped.
> 
> For additional info, see 
> http://www.x.org/wiki/Development/Documentation/WritingDocumentation
> 
> 
> Gaetan Nadon (4):
>  Additional doc macros for GROFF, FOP and PS2PDF
>  Add XORG_ENABLE_DOCS to control the building of documentation
>  XORG_WITH_GROFF: add tests for -ms and -mm macro packages
>  Version bump: 1.6.0
> 
> configure.ac  |2 +-
> xorg-macros.m4.in |  219 +
> 2 files changed, 220 insertions(+), 1 deletions(-)
> 
> ___
> xorg-devel mailing list
> xorg-devel@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel



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

Re: "empty" model/layout for xkb

[Jeremy Huddleston]

On Feb 2, 2010, at 03:18, Peter Hutterer wrote:

> On Tue, Jan 26, 2010 at 12:36:55PM -0800, Jeremy Huddleston wrote:
>> I'm trying to modify xkeyboard-config to create an "empty" xbk rules set.
>> This way, we can set "empty" as the default in XQuartz and have a clean
>> slate.
>> 
>> I'm having a bit of trouble getting this to work.  Firstly, I can't seem
>> to figure out how to NOT set the +aliases(qwerty) variant on the keycodes.
>> Secondly, it doesn't seem to recognize my empty symbols file.
>> 
>> Can someone fill me in on what I'm missing?
> 
> the evdev rules file is combined from the base* as well (look at the
> Makefile.am). So for the +aliases to disappear you need to add it to
> base.l_k.part.

What would I add there?  I've had both of these before the '* = 
+aliases(qwerty)" line with no success:

empty = 
or
empty = empty

> that's the only thing I can spot immediately. I take it the rules file is
> composed correctly and the resulting files in /usr/share/X11/xkb (or
> whatever prefix) look alright?

They look alright to me.  I'm still puzzled why the symbols get defined like 
this:

xkb_symbols "unknown" {

   key <> {
   symbols[Group1]= [   a,   A ],
   symbols[Group2]= [   aring,   Aring ]
   };
   modifier_map Mod2 { <> };
   modifier_map Shift { <> };
   modifier_map Lock { <> };
   modifier_map Mod1 { <> };
   modifier_map Control { <> };
   modifier_map Shift { <> };
   modifier_map Mod1 { <> };
   modifier_map Control { <> };
   modifier_map Mod2 { <> };
};

given that the empty symbols file is just:

+++ b/symbols/empty
@@ -0,0 +1,6 @@
+// $XKeyboardConfig$
+
+default
+xkb_symbols "basic" {
+name[Group1]= "Empty";
+};


___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

-fno-strict-aliasing in CWARNFLAGS?

[Jeremy Huddleston]

What's the rationale behind having -fno-strict-aliasing in CWARNFLAGS?

Do we actually have code somewhere that needs -fno-strict-aliasing?  If so, we 
should restrict -fno-strict-aliasing to that project (and try to address the 
reason for the need) rather than putting it in util-macros.


___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11 3/4] man: Fix value of XkbAllComponentsMask in XkbGetKeyboard

[Jeremy Huddleston]

I'd prefer to see this written as:

(1L<<7) - 1L

On Feb 2, 2010, at 12:24, Dirk Wallenstein wrote:

> XkbAllComponentsMask is the combination of all component masks not just
> a single bit.
> 
> Signed-off-by: Dirk Wallenstein 
> ---
> man/xkb/XkbGetKeyboard.man |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/man/xkb/XkbGetKeyboard.man b/man/xkb/XkbGetKeyboard.man
> index ab6b8d7..0ae0715 100644
> --- a/man/xkb/XkbGetKeyboard.man
> +++ b/man/xkb/XkbGetKeyboard.man
> @@ -73,7 +73,7 @@ XkbIndicatorMapMask indicators  (1L<<3)
> XkbNamesMask  names   (1L<<4)
> XkbCompatMapMask  compat  (1L<<5)
> XkbGeometryMask   geom(1L<<6)
> -XkbAllComponentsMask All Fields  (1L<<7)
> +XkbAllComponentsMask All Fields  (0x7f)
> .TE
> 
> .I XkbGetKeyboard 
> -- 
> 1.6.5.3
> 
> ___
> xorg-devel mailing list
> xorg-devel@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: -fno-strict-aliasing in CWARNFLAGS?

[Jeremy Huddleston]

On Feb 2, 2010, at 13:18, Gaetan Nadon wrote:

> I have not seen any compelling reasons to turn off this optimization.
> Maybe 10 years ago when it was first introduced. I have seen reports of
> large number of warnings, but from older gcc versions. As it is today,
> we are losing some optimization that could be beneficial.
> 
> This option has been there for so long (most likely copied along), I
> doubt you will will get a clear answer for each of the 240 xorg modules.
> It would take a few modules to try it out first.

I see it in libX11 has historically used -fno-strict-aliasing:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=db7c6fdeeaef9475458498e4cf09d6b1329e9aa3

but adding XORG_CWARNFLAGS to XORG_DEFAULT_OPTIONS has caused this to change 
for other modules.

Looking at historic versions of modules, I see it present in:

libICE
libSM
libX11
libXau
libXfont
libXft
libXpm
libXres
xorg-server

of course most of these seem to have just copied the entire GCC_WARNINGS block 
and probably didn't actually need -fno-strict-aliasing
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH util-macros 2/2] Add -Wformat=2 to the default CWARNFLAGS

[Jeremy Huddleston]

This will include -Wformat-security to catch possible security problems in 
formatting in printf, scanf, etc.

Signed-off-by: Jeremy Huddleston 
---
 xorg-macros.m4.in |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in
index 40f5939..6d6f044 100644
--- a/xorg-macros.m4.in
+++ b/xorg-macros.m4.in
@@ -589,7 +589,7 @@ AC_REQUIRE([AC_PROG_CC])
 if  test "x$GCC" = xyes ; then
 CWARNFLAGS="-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes 
\
 -Wmissing-declarations -Wnested-externs -Wstrict-aliasing=2 \
--Wbad-function-cast"
+-Wbad-function-cast -Wformat=2"
 case `$CC -dumpversion` in
 3.4.* | 4.*)
CWARNFLAGS="$CWARNFLAGS -Wold-style-definition 
-Wdeclaration-after-statement"
-- 
1.6.2


___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH util-macros 1/2] Don't disable strict aliasing (-fno-strict-aliasing) globally

[Jeremy Huddleston]

Instead, we warn where this optimization might cause a problem!

This was included for historic reasons and has persisted to the point of now
infecting all X.org modules.  Historically, it was just present in these
modules before adding XORG_CWARNFLAGS to XORG_DEFAULT_OPTIONS:

libICE
libSM
libX11
libXau
libXfont
libXft
libXpm
libXres
xorg-server

Most of these modules probably don't even need to disable this optimization,
but if it is decided that this optimization should be disabled, it should be
restricted to the required module rather than a global option.

Signed-off-by: Jeremy Huddleston 
---
 xorg-macros.m4.in |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in
index caf61c2..40f5939 100644
--- a/xorg-macros.m4.in
+++ b/xorg-macros.m4.in
@@ -588,7 +588,7 @@ AC_DEFUN([XORG_CWARNFLAGS], [
 AC_REQUIRE([AC_PROG_CC])
 if  test "x$GCC" = xyes ; then
 CWARNFLAGS="-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes 
\
--Wmissing-declarations -Wnested-externs -fno-strict-aliasing \
+-Wmissing-declarations -Wnested-externs -Wstrict-aliasing=2 \
 -Wbad-function-cast"
 case `$CC -dumpversion` in
 3.4.* | 4.*)
-- 
1.6.2


___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto

[Jeremy Huddleston]

Signed-off-by: Jeremy Huddleston 
---
 configure.ac  |6 +++---
 src/Font.c|2 +-
 src/OpenDis.c |2 +-
 src/XlibInt.c |2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 0eea575..00ab51c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -60,13 +60,13 @@ AM_CONDITIONAL(XCB, test x$ac_cv_use_xcb != xno)
 # Checks for pkg-config packages
 
 # Always required
-X11_REQUIRES='xproto >= 7.0.13 xextproto xtrans'
+X11_REQUIRES='[xproto >= 7.0.13] xextproto xtrans'
 
 PKG_PROG_PKG_CONFIG()
 
 case "$ac_cv_use_xcb" in
 no)
-   X11_REQUIRES="${X11_REQUIRES} xau xcmiscproto bigreqsproto"
+   X11_REQUIRES="${X11_REQUIRES} xau [xcmiscproto >= 1.2.0] [bigreqsproto 
>= 1.1.0]"
X11_EXTRA_DEPS="xau"
PKG_CHECK_MODULES(XDMCP, xdmcp,
AC_CHECK_LIB(Xdmcp, XdmcpWrap,
@@ -330,7 +330,7 @@ AC_ARG_ENABLE(xf86bigfont,
[Disable XF86BigFont extension support]),
  [XF86BIGFONT=$enableval],[XF86BIGFONT="yes"])
 if test "x$XF86BIGFONT" = "xyes"; then
-PKG_CHECK_MODULES(BIGFONT, xf86bigfontproto,
+PKG_CHECK_MODULES(BIGFONT, [xf86bigfontproto >= 1.2.0],
  AC_DEFINE(XF86BIGFONT,1,[Enable XF86BIGFONT 
extension]),XF86BIGFONT="no")
 AC_SUBST(BIGFONT_CFLAGS)
 AC_SUBST(BIGFONT_LIBS)
diff --git a/src/Font.c b/src/Font.c
index b664b8d..5479c83 100644
--- a/src/Font.c
+++ b/src/Font.c
@@ -45,7 +45,7 @@ authorization from the X Consortium and the XFree86 Project.
 
 #include 
 #include 
-#include 
+#include 
 #endif
 
 #include "Xlcint.h"
diff --git a/src/OpenDis.c b/src/OpenDis.c
index 46e1026..78cf74b 100644
--- a/src/OpenDis.c
+++ b/src/OpenDis.c
@@ -34,7 +34,7 @@ in this Software without prior written authorization from The 
Open Group.
 #include "Xxcbint.h"
 #else /* !USE_XCB */
 #include 
-#include 
+#include 
 #endif /* USE_XCB */
 #include 
 #include 
diff --git a/src/XlibInt.c b/src/XlibInt.c
index fb6e715..0f30f74 100644
--- a/src/XlibInt.c
+++ b/src/XlibInt.c
@@ -44,7 +44,7 @@ from The Open Group.
 #include 
 #if !USE_XCB
 #include 
-#include 
+#include 
 #endif /* !USE_XCB */
 #include 
 #include 
-- 
1.6.2


___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libX11 2/2] Fix various build warnings

[Jeremy Huddleston]

imLcIm.c: In function '_XimCachedFileName':
imLcIm.c:361: warning: format '%03x' expects type 'unsigned int', but argument 
8 has type 'long unsigned int'
imLcIm.c:364: warning: format '%03x' expects type 'unsigned int', but argument 
8 has type 'long unsigned int'

imRm.c: In function '_XimDefaultArea':
imRm.c:597: warning: cast from pointer to integer of different size
imRm.c: In function '_XimDefaultColormap':
imRm.c:626: warning: cast from pointer to integer of different size

lcFile.c:224: warning: no previous prototype for 'xlocaledir'

lcUTF8.c: In function 'iconv_cstombs':
lcUTF8.c:1841: warning: assignment discards qualifiers from pointer target type
lcUTF8.c:1869: warning: pointer targets in passing argument 1 of 'wctomb' 
differ in signedness
lcUTF8.c:1873: warning: pointer targets in passing argument 1 of 'wctomb' 
differ in signedness
lcUTF8.c: In function 'iconv_mbstocs':
lcUTF8.c:1935: warning: pointer targets in passing argument 2 of 'mbtowc' 
differ in signedness
lcUTF8.c: In function 'iconv_mbtocs':
lcUTF8.c:2031: warning: pointer targets in passing argument 2 of 'mbtowc' 
differ in signedness
lcUTF8.c: In function 'iconv_mbstostr':
lcUTF8.c:2121: warning: pointer targets in passing argument 2 of 'mbtowc' 
differ in signedness
lcUTF8.c: In function 'iconv_strtombs':
lcUTF8.c:2180: warning: pointer targets in passing argument 1 of 'wctomb' 
differ in signedness
lcUTF8.c: In function '_XlcAddGB18030LocaleConverters':
lcUTF8.c:2367: warning: passing argument 5 of '_XlcSetConverter' from 
incompatible pointer type
lcUTF8.c:2368: warning: passing argument 5 of '_XlcSetConverter' from 
incompatible pointer type
lcUTF8.c:2373: warning: passing argument 5 of '_XlcSetConverter' from 
incompatible pointer type
lcUTF8.c:2374: warning: passing argument 5 of '_XlcSetConverter' from 
incompatible pointer type
lcUTF8.c:2375: warning: passing argument 5 of '_XlcSetConverter' from 
incompatible pointer type
lcUTF8.c:2376: warning: passing argument 5 of '_XlcSetConverter' from 
incompatible pointer type
lcUTF8.c:2377: warning: passing argument 5 of '_XlcSetConverter' from 
incompatible pointer type

XlibInt.c: In function '_XGetHostname':
XlibInt.c:3441: warning: implicit declaration of function 'gethostname'
XlibInt.c:3441: warning: nested extern declaration of 'gethostname'

ConnDis.c: In function '_XDisconnectDisplay':
ConnDis.c:540: warning: old-style function definition
ConnDis.c: In function '_XSendClientPrefix':
ConnDis.c:554: warning: old-style function definition
ConnDis.c: In function 'XSetAuthorization':
ConnDis.c:677: warning: old-style function definition

Signed-off-by: Jeremy Huddleston 
---
 include/X11/Xlibint.h  |7 +++
 modules/im/ximcp/imLcIm.c  |4 ++--
 modules/im/ximcp/imLcPrs.c |5 -
 modules/im/ximcp/imRm.c|4 ++--
 src/ConnDis.c  |   21 +
 src/XlibInt.c  |4 
 src/xlibi18n/lcUTF8.c  |   28 ++--
 7 files changed, 38 insertions(+), 35 deletions(-)

diff --git a/include/X11/Xlibint.h b/include/X11/Xlibint.h
index 767b083..0e97fd9 100644
--- a/include/X11/Xlibint.h
+++ b/include/X11/Xlibint.h
@@ -1391,6 +1391,13 @@ extern Bool _XCopyEventCookie(
 XGenericEventCookie *in,
 XGenericEventCookie *out);
 
+/* lcFile.c */
+
+extern void xlocaledir(
+char *buf,
+int buf_len
+);
+
 _XFUNCPROTOEND
 
 #endif /* _XLIBINT_H_ */
diff --git a/modules/im/ximcp/imLcIm.c b/modules/im/ximcp/imLcIm.c
index eb41603..83f216a 100644
--- a/modules/im/ximcp/imLcIm.c
+++ b/modules/im/ximcp/imLcIm.c
@@ -359,10 +359,10 @@ Private int _XimCachedFileName (
 
 if (len == 0 || dir [len-1] != '/')
sprintf (*res, "%s/%c%d_%03x_%08x_%08x", dir, _XimGetMyEndian(),
-   XIM_CACHE_VERSION, sizeof (DefTree), hash, hash2);
+   XIM_CACHE_VERSION, (unsigned int)sizeof (DefTree), hash, hash2);
 else
sprintf (*res, "%s%c%d_%03x_%08x_%08x", dir, _XimGetMyEndian(),
-   XIM_CACHE_VERSION, sizeof (DefTree), hash, hash2);
+   XIM_CACHE_VERSION, (unsigned int)sizeof (DefTree), hash, hash2);
 
 /* fprintf (stderr, "-> %s\n", *res); */
 if ( (fd = _XOpenFile (*res, O_RDONLY)) == -1)
diff --git a/modules/im/ximcp/imLcPrs.c b/modules/im/ximcp/imLcPrs.c
index c080172..75449ef 100644
--- a/modules/im/ximcp/imLcPrs.c
+++ b/modules/im/ximcp/imLcPrs.c
@@ -44,11 +44,6 @@ OR PERFORMANCE OF THIS SOFTWARE.
 
 #define XLC_BUFSIZE 256
 
-extern void xlocaledir(
-char *buf,
-int buf_len
-);
-
 extern int _Xmbstowcs(
 wchar_t*wstr,
 char 

Re: -fno-strict-aliasing in CWARNFLAGS?

[Jeremy Huddleston]

On Feb 2, 2010, at 17:11, Gaetan Nadon wrote:

> On Tue, 2010-02-02 at 14:00 -0800, Jeremy Huddleston wrote:
> 
>> On Feb 2, 2010, at 13:18, Gaetan Nadon wrote:
>> 
>>> I have not seen any compelling reasons to turn off this optimization.
>>> Maybe 10 years ago when it was first introduced. I have seen reports of
>>> large number of warnings, but from older gcc versions. As it is today,
>>> we are losing some optimization that could be beneficial.
>>> 
>>> This option has been there for so long (most likely copied along), I
>>> doubt you will will get a clear answer for each of the 240 xorg modules.
>>> It would take a few modules to try it out first.
>> 
>> I see it in libX11 has historically used -fno-strict-aliasing:
>> http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=db7c6fdeeaef9475458498e4cf09d6b1329e9aa3
>> 
>> but adding XORG_CWARNFLAGS to XORG_DEFAULT_OPTIONS has caused this to change 
>> for other modules.
>> 
>> Looking at historic versions of modules, I see it present in:
>> 
>> libICE
>> libSM
>> libX11
>> libXau
>> libXfont
>> libXft
>> libXpm
>> libXres
>> xorg-server
>> 
>> of course most of these seem to have just copied the entire GCC_WARNINGS 
>> block and probably didn't actually need -fno-strict-aliasing
> 
> Of course. Whatever the reasons were, if anyone remembers, may not apply
> anymore. Devising a plan for it's removal will not be an easy task. I
> see 3 options:
> 
> 1) take it out of macros, 1 patch

I sent that patch already.

> 2) transfer it to all makefiles and then removing it gradually, that's
> 2*240 +1 patches

I don't think that's wise.  If anything, you should just put it in the ones 
where it was prior to XORG_CWARNFLAGS (the 9 mentioned above).

That being said, I also enabled the warning which should mention when it 
discovers code sensitive to the -fstrict-aliasing optimization, and none of the 
libs in the list above spewed such a warning.

> 3) override in 'n' makefiles until proven safe. Then take it out macros.
> That's 2*n +1 patches.

We could do that for the 9 modules above.  I'm fairly confident that the libs 
don't need it, but I haven't rebuilt all of the server to be confident it 
doesn't spew any warnings about strict-aliasing.



___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto

[Jeremy Huddleston]

On Feb 2, 2010, at 19:49, Dan Nicholson wrote:

>> -   X11_REQUIRES="${X11_REQUIRES} xau xcmiscproto bigreqsproto"
>> +   X11_REQUIRES="${X11_REQUIRES} xau [xcmiscproto >= 1.2.0] 
>> [bigreqsproto >= 1.1.0]"
> 
> Do these actually change anything? autoconf is just going to remove
> the [] after processing through m4, and having >= within quotes in
> shell is fine. There's a lot of this excessive quoting/unquoting in
> the x configure.ac's, and all that's really needed is to make sure
> that the arguments to the autoconf m4 macros are quoted...

I did it more for stylistic reasons.

>> -PKG_CHECK_MODULES(BIGFONT, xf86bigfontproto,
>> +PKG_CHECK_MODULES(BIGFONT, [xf86bigfontproto >= 1.2.0],
> 
> like this. Can you show the warning that was being printed?

I'm not sure what you mean... I thought it was fairly obvious from the commit 
message.

$ echo "#include " | gcc -E - -o /dev/null 
In file included from :1:
./xf86bigfstr.h:1:2: warning: #warning "xf86bigfstr.h is obsolete and may be 
removed in the future."
./xf86bigfstr.h:2:2: warning: #warning "include 
 for the protocol defines."


___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto

[Jeremy Huddleston]

I think it makes sense because:

1) If people are updating their libX11, they can easily update their protos.
2) We're reporting that they're deprecated, so if we expect 3rd party clients 
of the headers to migrate, we should be willing to do it for our own code.
3) The server has already done it.
4) Fewer warnings make me happier, and I like being happy.

On Feb 3, 2010, at 09:14, Julien Cristau wrote:

> 
> Would it make sense to keep compatibility with the old header locations
> instead of requiring the newer protos?
> 
> I don't have a particular opinion either way, just thought I'd ask.
> 
> Cheers,
> Julien

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11 3/4] man: Fix value of XkbAllComponentsMask in XkbGetKeyboard

[Jeremy Huddleston]

On Feb 3, 2010, at 10:12, Dirk Wallenstein wrote:


On Tue, 02 Feb 2010 13:44:48 -0800 Jeremy Huddleston wrote:

I'd prefer to see this written as:

(1L<<7) - 1L


If it's a value I'd like to have it in sync with the code for easy
comparison. I can change both if you like. Alternatively I could use  
the

OR-ed other masks.



I think (next - 1) is less prone to human error when adding bits in  
the future.  That's my main concern.


I think OR-ing all the others does not scale well and also suffers  
from the same human-error aspect.


Consistency is great.  Add the change to the header as well, I think  
that's a good idea.


Reviewed-by: Jeremy Huddleston 



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

Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto

[Jeremy Huddleston]

On Feb 3, 2010, at 09:31, Julien Cristau wrote:


On Wed, Feb  3, 2010 at 09:17:35 -0800, Jeremy Huddleston wrote:

2) We're reporting that they're deprecated, so if we expect 3rd party
clients of the headers to migrate, we should be willing to do it for
our own code.


We can migrate while still staying compatible with the old stuff  
with a

couple configure checks.


How about this then:


From 5c271b18b45b8e138b793e0a882fd894a488610b Mon Sep 17 00:00:00 2001
From: Jeremy Huddleston 
Date: Tue, 2 Feb 2010 15:48:42 -0800
Subject: [PATCH] Fix warnings for recent bigreqsproto, xcmiscproto,  
and xf86bigfontproto


Signed-off-by: Jeremy Huddleston 
Acked-by: Dan Nicholson 
---
 configure.ac  |   10 +++---
 src/Font.c|4 
 src/OpenDis.c |4 
 src/XlibInt.c |4 
 4 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 0eea575..93d9959 100644
--- a/configure.ac
+++ b/configure.ac
@@ -60,13 +60,13 @@ AM_CONDITIONAL(XCB, test x$ac_cv_use_xcb != xno)
 # Checks for pkg-config packages

 # Always required
-X11_REQUIRES='xproto >= 7.0.13 xextproto xtrans'
+X11_REQUIRES='[xproto >= 7.0.13] xextproto xtrans'

 PKG_PROG_PKG_CONFIG()

 case "$ac_cv_use_xcb" in
 no)
-   X11_REQUIRES="${X11_REQUIRES} xau xcmiscproto bigreqsproto"
+	X11_REQUIRES="${X11_REQUIRES} xau [xcmiscproto >= 1.2.0]  
[bigreqsproto >= 1.1.0]"

X11_EXTRA_DEPS="xau"
PKG_CHECK_MODULES(XDMCP, xdmcp,
AC_CHECK_LIB(Xdmcp, XdmcpWrap,
@@ -186,6 +186,10 @@ AC_MSG_RESULT($XLIB_LOADABLE_XCURSOR)
 AC_HEADER_STDC
 AC_CHECK_HEADERS([sys/select.h])

+# Backwards compatability with older proto packages.  This will be  
removed eventually.

+# When removing, make sure to update Font.c OpenDis.c XlibInt.c
+AC_CHECK_HEADERS([X11/extensions/xcmiscproto.h X11/extensions/ 
bigreqsproto.h X11/extensions/xf86bigfproto.h], [], [], [#include Xproto.h>])

+
 # Checks for typedefs, structures, and compiler characteristics.

 # Checks for library functions.
@@ -330,7 +334,7 @@ AC_ARG_ENABLE(xf86bigfont,
[Disable XF86BigFont extension support]),
  [XF86BIGFONT=$enableval],[XF86BIGFONT="yes"])
 if test "x$XF86BIGFONT" = "xyes"; then
-PKG_CHECK_MODULES(BIGFONT, xf86bigfontproto,
+PKG_CHECK_MODULES(BIGFONT, [xf86bigfontproto >= 1.2.0],
  AC_DEFINE(XF86BIGFONT,1,[Enable XF86BIGFONT  
extension]),XF86BIGFONT="no")

 AC_SUBST(BIGFONT_CFLAGS)
 AC_SUBST(BIGFONT_LIBS)
diff --git a/src/Font.c b/src/Font.c
index b664b8d..2b82ade 100644
--- a/src/Font.c
+++ b/src/Font.c
@@ -45,8 +45,12 @@ authorization from the X Consortium and the XFree86  
Project.


 #include 
 #include 
+#ifdef HAVE_X11_EXTENSIONS_XF86BIGFPROTO_H
+#include 
+#else
 #include 
 #endif
+#endif

 #include "Xlcint.h"
 #include "XlcPubI.h"
diff --git a/src/OpenDis.c b/src/OpenDis.c
index 46e1026..e4656a2 100644
--- a/src/OpenDis.c
+++ b/src/OpenDis.c
@@ -34,7 +34,11 @@ in this Software without prior written  
authorization from The Open Group.

 #include "Xxcbint.h"
 #else /* !USE_XCB */
 #include 
+#ifdef HAVE_X11_EXTENSIONS_BIGREQSPROTO_H
+#include 
+#else
 #include 
+#endif
 #endif /* USE_XCB */
 #include 
 #include 
diff --git a/src/XlibInt.c b/src/XlibInt.c
index fb6e715..8e06273 100644
--- a/src/XlibInt.c
+++ b/src/XlibInt.c
@@ -44,7 +44,11 @@ from The Open Group.
 #include 
 #if !USE_XCB
 #include 
+#ifdef HAVE_X11_EXTENSIONS_XCMISCPROTO_H
+#include 
+#else
 #include 
+#endif
 #endif /* !USE_XCB */
 #include 
 #include 
--
1.6.3.1




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

Re: -fno-strict-aliasing in CWARNFLAGS?

[Jeremy Huddleston]

Ok.

In light of the discussion here, I think it would be best to take  
Gaetan's "option 3" here:


1) We should turn -fno-strict-aliasing on in the 9 (note that this  
number does not include xf86 drivers) modules that traditionally had it:


libICE
libSM
libX11
libXau
libXfont
libXft
libXpm
libXres
xorg-server
xf86-* (somene else should check which ones traditionally had this  
CFLAG)


2) We should remove it from the CWARNFLAGS in util-macros (and turn on  
the warning)


3) We should "audit" the modules where we added it in #1 and slowly  
remove it where safe.


--Jeremy

On Feb 3, 2010, at 10:55, Soeren Sandmann wrote:


Dan Nicholson  writes:


Here's one link:

http://lkml.org/lkml/2003/2/26/158

Traditionally, -fno-strict-aliasing was definitely necessary for  
the X

server and/or some drivers to work correctly.


I know in mesa it's been required. Here are two bugs fixed/worked
around by -fno-strict-aliasing.

https://bugs.freedesktop.org/show_bug.cgi?id=6046
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311


I recently turned it on in pixman because completely reasonable code
like this:

   void
   pixman_contract (uint32_t *  dst,
const uint64_t *src,
int width)
   {
   int i;

   /* Start at the beginning so that we can do the contraction in
* place when src == dst
*/
   for (i = 0; i < width; i++)
   {
   const uint8_t a = src[i] >> 56,
 r = src[i] >> 40,
 g = src[i] >> 24,
 b = src[i] >> 8;

   dst[i] = a << 24 | r << 16 | g << 8 | b;
   }
   }

is actually illegal under the C aliasing rules, and GCC can and will
break it unless you use -fno-strict-aliasing. I don't think any other
compiler makes use of type based aliasing, perhaps because they
rightly - consider the standard broken.


Soren
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel




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

Re: [PATCH app-sessreg] Add AC_GNU_SOURCE which provides needed WTMPX_FILE define

[Jeremy Huddleston]

No adverse effects on darwin (non-GNU)

Tested-by (on darwin): Jeremy Huddleston 

On Feb 3, 2010, at 11:28, Gaetan Nadon wrote:


The WTMPX_FILE is only defined under __USE_GNU conditional
compilation. Autoconf provides AC_GNU_SOURCE which is a subset of
AC_USE_SYSTEM_EXTENSIONS.

It must be expanded before any other macros that uses the compiler.
To reduce the risk of being misplaced, the statements have been
grouped (mostly) as per the GNU standard layout.This macro
requires Autoconf level 2.60 or later.

The compilation failed under a GNU-Linux OS.

Signed-off-by: Gaetan Nadon 
---
configure.ac |   32 +++-
1 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/configure.ac b/configure.ac
index be1b4b4..6287a6b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,25 +20,34 @@ dnl  PERFORMANCE OF THIS SOFTWARE.
dnl
dnl Process this file with autoconf to create configure.

-AC_PREREQ([2.57])
+# Initialize Autoconf
+AC_PREREQ([2.60])
AC_INIT(sessreg, [1.0.5],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],
sessreg)
+AC_CONFIG_SRCDIR([Makefile.am])
+AC_CONFIG_HEADERS([config.h])
+AC_CANONICAL_HOST
+AC_GNU_SOURCE
+AC_SYS_LARGEFILE
+
+# Initialize Automake
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE

-AM_CONFIG_HEADER(config.h)
-
-# Require xorg-macros 1.3 or later: XORG_DEFAULT_OPTIONS
+# Require xorg-macros: XORG_DEFAULT_OPTIONS
m4_ifndef([XORG_MACROS_VERSION],
-	  [m4_fatal([must install xorg-macros 1.3 or later before running  
autoconf/autogen])])

-XORG_MACROS_VERSION(1.3)
+	  [m4_fatal([must install xorg-macros 1.4 or later before running  
autoconf/autogen])])

+XORG_MACROS_VERSION(1.4)
+XORG_DEFAULT_OPTIONS
+XORG_WITH_LINT

+# Checks for programs.
AC_PROG_CC
+AC_PROG_CC_C99
AC_PROG_INSTALL

-XORG_DEFAULT_OPTIONS
-
+# Checks for header files.
AC_CHECK_HEADERS([lastlog.h utmp.h utmpx.h sys/param.h])
AC_CHECK_MEMBER([struct utmpx.ut_syslen],
HAVE_SYSLEN=1,
@@ -46,15 +55,12 @@ AC_CHECK_MEMBER([struct utmpx.ut_syslen],
[#include ])
AC_DEFINE_UNQUOTED(HAVE_UTMPX_UT_SYSLEN,$HAVE_SYSLEN,
   [utmpx structure includes ut_syslen field])
-AC_CHECK_FUNCS([updwtmpx utmpxname])

-AC_SYS_LARGEFILE
+# Checks for typedefs, structures, and compiler characteristics.
+AC_CHECK_FUNCS([updwtmpx utmpxname])

# Checks for pkg-config packages
PKG_CHECK_MODULES(SESSREG, xproto)
AC_SUBST(SESSREG_CFLAGS)

-# Allow checking code with lint, sparse, etc.
-XORG_WITH_LINT
-
AC_OUTPUT([Makefile])
--
1.6.0.4

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel




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

Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto

[Jeremy Huddleston]

Of course, since you've enforced newer xcmiscproto and friends in the
pkg-config checks, you'll always have these headers.


bah.  yes.  I'll back those out.


Another thing to think about is that libX11 is currently in 1.3 RC
phase, so it's reasonable to enforce newer proto versions in addition
to the version of xproto needed for generic events. We can branch from
before the generic events patches (75fe48e7a) and cherry pick patches
for a 1.2.x for people on more stable systems. In fact, there aleady
is libX11-1.2-branch.


Yeah, I considered that as well, and I'd be fine either way.  I'd  
prefer the original patch (forcing new protos), but I do believe the  
1.2 branch is "good enough" for anyone stuck on old protos.





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

Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto

[Jeremy Huddleston]

On Feb 3, 2010, at 12:40, Dan Nicholson wrote:


On Wed, Feb 3, 2010 at 12:28 PM, Alan Coopersmith
 wrote:

Dan Nicholson wrote:

Another thing to think about is that libX11 is currently in 1.3 RC
phase, so it's reasonable to enforce newer proto versions in  
addition
to the version of xproto needed for generic events. We can branch  
from
before the generic events patches (75fe48e7a) and cherry pick  
patches

for a 1.2.x for people on more stable systems. In fact, there aleady
is libX11-1.2-branch.


1.3 is already out & stable.  I don't think we've had a reason yet to
split off a libX11-1.3-branch, since there's no changes proposed that
would warrant a 1.4 bump.


Oh, man, I was in an extremely stale checkout. Pushing newer proto
versions doesn't seem like a nice thing to do in the middle of a
stable branch.


Ok, then how about we go with the 2nd patch (with the corrected/ 
unversioned requirements to the PKG_ macros) for the life of 1.3.x and  
plan on gutting that support whenever 1.4.x emerges?

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

Re: [PATCH util-macros] doc: add XORG_ENABLE_DEVEL_DOCS and XORG_ENABLE_SPECS

[Jeremy Huddleston]

Reviewed-by: Jeremy Huddleston 

On Feb 3, 2010, at 18:02, Gaetan Nadon wrote:

> Identical to XORG_ENABLE_DOCS, this macros allows modules
> to classify docs per type and selectively control their building.
> 
> Signed-off-by: Gaetan Nadon 
> ---
> xorg-macros.m4.in |   70 +
> 1 files changed, 70 insertions(+), 0 deletions(-)
> 
> diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in
> index 8ad049b..b2bfc2f 100644
> --- a/xorg-macros.m4.in
> +++ b/xorg-macros.m4.in
> @@ -676,6 +676,76 @@ AC_MSG_CHECKING([whether to build documentation])
> AC_MSG_RESULT([$build_docs])
> ]) # XORG_ENABLE_DOCS
> 
> +# XORG_ENABLE_DEVEL_DOCS (enable_devel_docs=yes)
> +# 
> +# Minimum version: 1.6.0
> +#
> +# This macro enables a builder to skip all developer documentation.
> +# Combined with the specific tool checking macros XORG_WITH_*, it provides
> +# maximum flexibilty in controlling documentation building.
> +# Refer to:
> +# XORG_WITH_XMLTO --with-xmlto
> +# XORG_WITH_ASCIIDOC  --with-asciidoc
> +# XORG_WITH_DOXYGEN   --with-doxygen
> +# XORG_WITH_FOP   --with-fop
> +# XORG_WITH_GROFF --with-groff
> +# XORG_WITH_PS2PDF--with-ps2pdf
> +#
> +# Interface to module:
> +# ENABLE_DEVEL_DOCS: used in makefiles to conditionally generate developer 
> docs
> +# --enable-devel-docs:   'yes' user instructs the module to generate 
> developer docs
> +#'no' user instructs the module not to generate 
> developer docs
> +# parm1: specify the default value, yes or no.
> +#
> +AC_DEFUN([XORG_ENABLE_DEVEL_DOCS],[
> +devel_default=$1
> +if test "x$devel_default" = x ; then
> +  devel_default="yes"
> +fi
> +AC_ARG_ENABLE(devel-docs,
> + AS_HELP_STRING([--enable-devel-docs],
> +[Enable building the developer documentation (default: yes)]),
> +[build_devel_docs=$enableval], [build_devel_docs=$devel_default])
> +AM_CONDITIONAL(ENABLE_DEVEL_DOCS, [test x$build_devel_docs = xyes])
> +AC_MSG_CHECKING([whether to build developer documentation])
> +AC_MSG_RESULT([$build_devel_docs])
> +]) # XORG_ENABLE_DEVEL_DOCS
> +
> +# XORG_ENABLE_SPECS (enable_specs=yes)
> +# 
> +# Minimum version: 1.6.0
> +#
> +# This macro enables a builder to skip all functional specification targets.
> +# Combined with the specific tool checking macros XORG_WITH_*, it provides
> +# maximum flexibilty in controlling documentation building.
> +# Refer to:
> +# XORG_WITH_XMLTO --with-xmlto
> +# XORG_WITH_ASCIIDOC  --with-asciidoc
> +# XORG_WITH_DOXYGEN   --with-doxygen
> +# XORG_WITH_FOP   --with-fop
> +# XORG_WITH_GROFF --with-groff
> +# XORG_WITH_PS2PDF--with-ps2pdf
> +#
> +# Interface to module:
> +# ENABLE_SPECS:  used in makefiles to conditionally generate 
> specs
> +# --enable-specs:'yes' user instructs the module to generate specs
> +#'no' user instructs the module not to generate specs
> +# parm1: specify the default value, yes or no.
> +#
> +AC_DEFUN([XORG_ENABLE_SPECS],[
> +spec_default=$1
> +if test "x$spec_default" = x ; then
> +  spec_default="yes"
> +fi
> +AC_ARG_ENABLE(specs,
> + AS_HELP_STRING([--enable-specs],
> +[Enable building the specs (default: yes)]),
> +[build_specs=$enableval], [build_specs=$spec_default])
> +AM_CONDITIONAL(ENABLE_SPECS, [test x$build_specs = xyes])
> +AC_MSG_CHECKING([whether to build functional specifications])
> +AC_MSG_RESULT([$build_specs])
> +]) # XORG_ENABLE_SPECS
> +
> # XORG_CHECK_MALLOC_ZERO
> # --
> # Minimum version: 1.0.0
> -- 
> 1.6.0.4
> 
> As discussed, these 2 additional macros will allow modules to qualify their 
> documents
> as they see fit. 
> 
> Any preference?
> libXaw now used enable-docs but directory is called 'spec'
> How about xserver dmx and xfree86?
> http://wiki.x.org/wiki/Development/Documentation/WritingDocumentation
> 
> 
> 
> 
> 
> 
> ___
> xorg-devel mailing list
> xorg-devel@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: -fno-strict-aliasing in CWARNFLAGS?

[Jeremy Huddleston]

On Feb 2, 2010, at 17:34, Jeremy Huddleston wrote:

> That being said, I also enabled the warning which should mention when it 
> discovers code sensitive to the -fstrict-aliasing optimization, and none of 
> the libs in the list above spewed such a warning.

I'd like to correct my statement here.  It turns out that Apple's gcc does not 
enable -fstrict-aliasing with -O2, so I did not actually do this test properly. 
 I will be rebuilding the modules with -fstrict-aliasing -Wstrict-aliasing=2 
explicitly this weekend and will send patches to re-add -fno-strict-aliasing 
explicitly to the modules' configure.ac

On a side note, util-macros should not do the -fno-strict-aliasing -> 
-Wstrict-aliasing=2 change until all affected modules have had a release with 
the explicit -fno-strict-aliasing in-module.  I'll just hold on to that patch 
locally and anyone interested in testing can certainly make the change locally.

--Jeremy

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xinput] man: document XI2 options

[Jeremy Huddleston]

On Feb 3, 2010, at 21:06, Peter Hutterer wrote:

> +.B --reattach \fIdevice\fP \fImaster\fP
> +Reattach the given device to the given master device.

Formatting throughout this file seems inconsistent with respect to hilighting 
arguments in the descriptions.  Shouldn't this be more like:

.B --reattach \fIdevice\fP \fImaster\fP
Reattach \fIdevice\fP to the \fImaster\fP device.

which better matches what's already in the man page:
.B --get-feedbacks \fIdevice\fP
Display the feedbacks of \fIdevice\fP.

I just picked this one line as an example, but there are inconsistencies like 
this throughout.  As example, this is currently in the man page:


___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11 3/4] man: Fix value of XkbAllComponentsMask in XkbGetKeyboard

[Jeremy Huddleston]

On Feb 5, 2010, at 01:57, Dirk Wallenstein wrote:

> I've done this for all of kbproto. Just a little procedural question.
> 
> I have now patches that are related, but in different components. Should
> I put them into one thread of patches, optionally with a cover letter
> without component?

That seems to be historically the trend.  That's what I plan to do when I get 
around to the strict-aliasing issue.

> If I have a patch that requires a previous one that is not yet in the
> archives, do I just vaguely refer to that patch, or wait.

It doesn't seem like the changes you are referring to actually lend themselves 
to strict requirements... just man pages and stylistic cleanups.  I'm not sure 
how that can result in a requirement.

If you simply want to refer to commit , then I'd say just leave that 
text out of the comment for now and insert the text after you actually push the 
first commit (so you have the correct hash to write in the second)

--Jeremy

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11] specs: install html images in $docdir with html files

[Jeremy Huddleston]

This review applies to all 6 that you sent this morning (pacific) for app-xfs, 
libXfont, libSM, and libX11

Reviewed-by: Jeremy Huddleston 

On Feb 5, 2010, at 09:43, Gaetan Nadon wrote:

> The images required by the html files have been omitted.
> 
> Signed-off-by: Gaetan Nadon 
> ---
> specs/XIM/Makefile.am|2 --
> specs/i18n/Makefile.am   |4 +---
> specs/libX11/Makefile.am |3 ---
> specs/troffrules.in  |   27 +--
> 4 files changed, 26 insertions(+), 10 deletions(-)
> 
> diff --git a/specs/XIM/Makefile.am b/specs/XIM/Makefile.am
> index 89806bd..c0368b9 100644
> --- a/specs/XIM/Makefile.am
> +++ b/specs/XIM/Makefile.am
> @@ -26,5 +26,3 @@
> doc_sources = xim.ms
> 
> include $(top_srcdir)/specs/troffrules.in
> -
> -
> diff --git a/specs/i18n/Makefile.am b/specs/i18n/Makefile.am
> index 812ad01..7d3ac80 100644
> --- a/specs/i18n/Makefile.am
> +++ b/specs/i18n/Makefile.am
> @@ -23,8 +23,6 @@
> 
> # Based on xc/doc/specs/i18n/Makefile from X11R6.9
> 
> -doc_sources = Framework.ms LocaleDB.ms Trans.ms 
> +doc_sources = Framework.ms LocaleDB.ms Trans.ms
> 
> include $(top_srcdir)/specs/troffrules.in
> -
> -
> diff --git a/specs/libX11/Makefile.am b/specs/libX11/Makefile.am
> index a9b813a..7cf269f 100644
> --- a/specs/libX11/Makefile.am
> +++ b/specs/libX11/Makefile.am
> @@ -54,6 +54,3 @@ doc_includes = \
> include $(top_srcdir)/specs/troffrules.in
> 
> EXTRA_DIST += $(doc_includes)
> -
> -
> -
> diff --git a/specs/troffrules.in b/specs/troffrules.in
> index d4e44a0..af89120 100644
> --- a/specs/troffrules.in
> +++ b/specs/troffrules.in
> @@ -33,13 +33,36 @@ endif
> 
> if ENABLE_SPECS
> if HAVE_GROFF_MS
> -doc_DATA =   $(doc_sources:.ms=.txt) \
> +spec_DATA =  $(doc_sources:.ms=.txt) \
>   $(doc_sources:.ms=$(printable_format)) \
>   $(doc_sources:.ms=.html)
> +specdir = $(docdir)/$(subdir)
> +imagesdir = $(specdir)/images
> 
> -CLEANFILES = $(doc_DATA)
> +CLEANFILES = $(spec_DATA)
> MOSTLYCLEANFILES = index.*
> 
> +# Install html generated images for specs
> +install-data-local:
> + test -z "$(imagesdir)" || $(MKDIR_P) "$(DESTDIR)$(imagesdir)"
> + @d="$(srcdir)/images/"; \
> + list=`ls $$d`; \
> + for p in $$list; do \
> +   echo " $(docDATA_INSTALL) '$$d$$p' '$(DESTDIR)$(imagesdir)/$$p'"; \
> +   $(specDATA_INSTALL) "$$d$$p" "$(DESTDIR)$(imagesdir)/$$p"; \
> + done;
> +
> +uninstall-local:
> + @if test -n $(DESTDIR)$(imagesdir); then \
> +   if test -d $(DESTDIR)$(imagesdir); then \
> + list=`ls $(DESTDIR)$(imagesdir)`; \
> + for p in $$list; do \
> +   echo " rm -f '$(DESTDIR)$(imagesdir)/$$p'"; \
> +   rm -f "$(DESTDIR)$(imagesdir)/$$p"; \
> + done \
> +   fi; \
> + fi;
> +
> mostlyclean-local:
>   @rm -fr images
> 
> -- 
> 1.6.0.4
> 
> ___
> xorg-devel mailing list
> xorg-devel@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v2 3/3] xfree86: dri2: conditionalize libdrm

[Jeremy Huddleston]

Would it be better to do:
+#ifdef WITH_LIBDRM
#include 
+#else
+typedef uint32_t drm_magic_t
+#endif

rather than changing all the drm_magic_t to uint32_t?

On Feb 6, 2010, at 04:24, Tiago Vignatti wrote:

> wrap drm bits with macros and change drm_magic type
> 
> Signed-off-by: Tiago Vignatti 
> ---
> hw/xfree86/dri2/dri2.c|   12 +++-
> hw/xfree86/dri2/dri2.h|2 +-
> hw/xfree86/dri2/dri2ext.c |2 ++
> 3 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
> index cc09789..f07112d 100644
> --- a/hw/xfree86/dri2/dri2.c
> +++ b/hw/xfree86/dri2/dri2.c
> @@ -35,7 +35,9 @@
> #endif
> 
> #include 
> +#ifdef WITH_LIBDRM
> #include 
> +#endif
> #include "xf86Module.h"
> #include "scrnintstr.h"
> #include "windowstr.h"
> @@ -798,7 +800,7 @@ DRI2Connect(ScreenPtr pScreen, unsigned int driverType, 
> int *fd,
> }
> 
> Bool
> -DRI2Authenticate(ScreenPtr pScreen, drm_magic_t magic)
> +DRI2Authenticate(ScreenPtr pScreen, uint32_t magic)
> {
> DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
> 
> @@ -845,8 +847,16 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
>   ds->AuthMagic = info->AuthMagic;
> }
> 
> +/*
> + * if the driver doesn't provide an AuthMagic function or the info struct
> + * version is too low, it relies on the old method (using libdrm) or fail
> + */
> if (!ds->AuthMagic)
> +#ifdef WITH_LIBDRM
>   ds->AuthMagic = drmAuthMagic;
> +#else
> + return FALSE;
> +#endif
> 
> if (info->version == 3 || info->numDrivers == 0) {
>   /* Driver too old: use the old-style driverName field */
> diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
> index f770760..1510fca 100644
> --- a/hw/xfree86/dri2/dri2.h
> +++ b/hw/xfree86/dri2/dri2.h
> @@ -194,7 +194,7 @@ extern _X_EXPORT Bool DRI2Connect(ScreenPtr pScreen,
>const char **driverName,
>const char **deviceName);
> 
> -extern _X_EXPORT Bool DRI2Authenticate(ScreenPtr pScreen, drm_magic_t magic);
> +extern _X_EXPORT Bool DRI2Authenticate(ScreenPtr pScreen, uint32_t magic);
> 
> extern _X_EXPORT int DRI2CreateDrawable(DrawablePtr pDraw);
> 
> diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
> index 3e6b03e..e97ed97 100644
> --- a/hw/xfree86/dri2/dri2ext.c
> +++ b/hw/xfree86/dri2/dri2ext.c
> @@ -42,7 +42,9 @@
> #include "scrnintstr.h"
> #include "pixmapstr.h"
> #include "extnsionst.h"
> +#ifdef WITH_LIBDRM
> #include "xf86drm.h"
> +#endif
> #include "xfixes.h"
> #include "dri2.h"
> #include "protocol-versions.h"
> -- 
> 1.6.0.4
> 
> ___
> xorg-devel mailing list
> xorg-devel@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 0/5] using util-macros to manage docs targets

[Jeremy Huddleston]

Series Reviewed-by: Jeremy Huddleston 

The only reservation I have is wrt the txt->text renaming.  The issue that I 
can see is when the generated file is present and the user tries to checkout a 
version with the file in git.  Is this renaming really the best way to handle 
this situation?  I'm sure this problem has come up before for other 
repositories.

On Feb 6, 2010, at 06:37, Gaetan Nadon wrote:

> Summary of visible external functional changes:
> 
> * --enable-builddocs replaced with generic util-macros --enable-devel-docs
> * documentation now built by default
> * dmx/doc git files dmx.txt and scaled.txt have renamed extension to .text
> * message alerting builder when tarball cannot be created due to missing 
> doxygen tool
> 
> See individual patches for details and rationales.
> 
> * all the rules under which a tarball may or may not be created have not 
> changed.
> * the content of the tarball has not changed. (save for .text extension)
> * the documents retain their classifcation as "development" documents
> 
> Gaetan Nadon (5):
>  config: use new XORG_ENABLE_DEVEL_DOCS util-macro
>  doc: update .gitignore for dmx and xfree86 docs
>  dmx/doc: resolve conflict between generated files also in git
>  config: enable building documentation by default
>  dmx/doc: alert builder when a tarball cannot be created
> 
> configure.ac|   14 +-
> hw/dmx/Makefile.am  |6 +-
> hw/dmx/doc/.gitignore   |8 +
> hw/dmx/doc/Makefile.am  |   28 +-
> hw/dmx/doc/dmx.text | 2989 +++
> hw/dmx/doc/dmx.txt  | 2989 ---
> hw/dmx/doc/scaled.text  |  579 
> hw/dmx/doc/scaled.txt   |  579 
> hw/xfree86/doc/Makefile.am  |4 -
> hw/xfree86/doc/sgml/.gitignore  |5 +
> hw/xfree86/doc/sgml/Makefile.am |8 +-
> 11 files changed, 3616 insertions(+), 3593 deletions(-)
> create mode 100644 hw/dmx/doc/dmx.text
> delete mode 100644 hw/dmx/doc/dmx.txt
> create mode 100644 hw/dmx/doc/scaled.text
> delete mode 100644 hw/dmx/doc/scaled.txt
> create mode 100644 hw/xfree86/doc/sgml/.gitignore
> 
> ___
> xorg-devel mailing list
> xorg-devel@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 0/5] using util-macros to manage docs targets

[Jeremy Huddleston]

Ok, fair enough.  It's not ideal, but as long as you're working towards the 
ideal, I'm happy =)


On Feb 6, 2010, at 14:01, Gaetan Nadon wrote:

> On Sat, 2010-02-06 at 10:38 -0800, Jeremy Huddleston wrote:
> 
>> Series Reviewed-by: Jeremy Huddleston 
>> 
>> The only reservation I have is wrt the txt->text renaming.  The issue that I 
>> can see is when the generated file is present and the user tries to checkout 
>> a version with the file in git.  Is this renaming really the best way to 
>> handle this situation?  I'm sure this problem has come up before for other 
>> repositories.
> 
> The reason why the dmx.txt is both generated and in git is for
> convenience. The original source is .sgml. If the linuxdoc tool is not
> available, one can read the dmx.txt file. In a recent review this was
> deemed to be important.
> 
> Currently, the code is extracted from git, and when built with linuxdoc,
> a new dmx.txt is created and overwrites the one from git. Running 'make
> clean' removes the dmx.txt and now git thinks the file is deleted. If
> you try to pull and rebase, git refuses as your directory is not clean.
> It also introduces duplication of files which will eventually be out of
> sync.
> 
> Renaming dmx.txt to dmx.text avoid all these issues, except duplication.
> As far as git is concerned, these are 2 different files.  The real
> solution is to rework the doc generation with tools that are available
> on all platforms and stop putting generated files in the tarball. Having
> all the documentation properly built on a web site would alleviate the
> need for such construct.
> 
> This issue is not really hurting anyone because the documents are not
> generated by default. I wanted to fix these issues (knowing it is still
> not the best way) so now we can turn on the generation by default, like
> all the other xorg modules.
> 
> Thanks
> 
>> 
>> On Feb 6, 2010, at 06:37, Gaetan Nadon wrote:
>> 
>>> Summary of visible external functional changes:
>>> 
>>> * --enable-builddocs replaced with generic util-macros --enable-devel-docs
>>> * documentation now built by default
>>> * dmx/doc git files dmx.txt and scaled.txt have renamed extension to .text
>>> * message alerting builder when tarball cannot be created due to missing 
>>> doxygen tool
>>> 
>>> See individual patches for details and rationales.
>>> 
>>> * all the rules under which a tarball may or may not be created have not 
>>> changed.
>>> * the content of the tarball has not changed. (save for .text extension)
>>> * the documents retain their classifcation as "development" documents
>>> 
>>> Gaetan Nadon (5):
>>> config: use new XORG_ENABLE_DEVEL_DOCS util-macro
>>> doc: update .gitignore for dmx and xfree86 docs
>>> dmx/doc: resolve conflict between generated files also in git
>>> config: enable building documentation by default
>>> dmx/doc: alert builder when a tarball cannot be created
>>> 
>>> configure.ac|   14 +-
>>> hw/dmx/Makefile.am  |6 +-
>>> hw/dmx/doc/.gitignore   |8 +
>>> hw/dmx/doc/Makefile.am  |   28 +-
>>> hw/dmx/doc/dmx.text | 2989 
>>> +++
>>> hw/dmx/doc/dmx.txt  | 2989 
>>> ---
>>> hw/dmx/doc/scaled.text  |  579 
>>> hw/dmx/doc/scaled.txt   |  579 
>>> hw/xfree86/doc/Makefile.am  |4 -
>>> hw/xfree86/doc/sgml/.gitignore  |5 +
>>> hw/xfree86/doc/sgml/Makefile.am |8 +-
>>> 11 files changed, 3616 insertions(+), 3593 deletions(-)
>>> create mode 100644 hw/dmx/doc/dmx.text
>>> delete mode 100644 hw/dmx/doc/dmx.txt
>>> create mode 100644 hw/dmx/doc/scaled.text
>>> delete mode 100644 hw/dmx/doc/scaled.txt
>>> create mode 100644 hw/xfree86/doc/sgml/.gitignore
>>> 
>>> ___
>>> xorg-devel mailing list
>>> xorg-devel@lists.x.org
>>> http://lists.x.org/mailman/listinfo/xorg-devel
>> 



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

[PULL] 2 XQuartz patches

[Jeremy Huddleston]

The following changes since commit 001ce71dc11287dc94cc2fbc5d35677c046e6c04:
  Julien Cristau (1):
dix: restore lastDeviceEventTime update in dixSaveScreens

are available in the git repository at:

  git://anongit.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (2):
  XQuartz: Fix a possible crash in quartzAudio fade
  XQuartz: clang static analysis fixes

 hw/xquartz/GL/indirect.c  |2 +-
 hw/xquartz/GL/visualConfigs.c |3 +--
 hw/xquartz/X11Application.m   |   18 ++
 hw/xquartz/mach-startup/bundle-main.c |   30 +++---
 hw/xquartz/mach-startup/stub.c|7 ---
 hw/xquartz/pbproxy/x-selection.h  |9 -
 hw/xquartz/quartzAudio.c  |3 ++-
 hw/xquartz/quartzKeyboard.c   |2 +-
 8 files changed, 38 insertions(+), 36 deletions(-)

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libAppleWM] man: make manpage macro substitutions

[Jeremy Huddleston]

-e 's|__xservername__|Xorg|g' \

should probably be

-e 's|__xservername__|XQuartz|g' \

 ... but I don't think that's even used in the man page

On Feb 13, 2010, at 08:31, Gaetan Nadon wrote:

> The man page displays to the user the variables to be substituted
> such as __vendorversion__.
> 
> The filename in git should be .man.
> The process to substitute the variables is the same used by
> all other modules.
> 
> Signed-off-by: Gaetan Nadon 
> ---
> configure.ac|1 +
> man/.gitignore  |3 -
> man/AppleWM.3   |  340 ---
> man/AppleWM.man |  340 +++
> man/Makefile.am |   32 +-
> 5 files changed, 370 insertions(+), 346 deletions(-)
> delete mode 100644 man/.gitignore
> delete mode 100644 man/AppleWM.3
> create mode 100644 man/AppleWM.man
> 
> diff --git a/configure.ac b/configure.ac
> index 0ea3c35..08f3cd1 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -37,6 +37,7 @@ AM_CONFIG_HEADER(config.h)
> # Check for progs
> AC_PROG_CC
> AC_PROG_LIBTOOL
> +AC_PROG_SED
> 
> # Check for dependencies
> PKG_CHECK_MODULES(APPLEWM, x11 xext xextproto [applewmproto >= 1.4])
> diff --git a/man/.gitignore b/man/.gitignore
> deleted file mode 100644
> index 58d42ad..000
> --- a/man/.gitignore
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -#Add & Override for this directory and it's subdirectories
> -# Override default pattern *.[0-9] from toplevel .gitignore
> -!AppleWM.3
> diff --git a/man/AppleWM.3 b/man/AppleWM.3
> deleted file mode 100644
> index bb81470..000
> --- a/man/AppleWM.3
> +++ /dev/null
> @@ -1,340 +0,0 @@
> -.\"
> -.\" $XFree86: xc/lib/apple/AppleWM.man,v 1.1 2003/08/12 23:47:10 torrey Exp $
> -.\"
> -.\" Copyright (c) 2002 Apple Computer, Inc. All Rights Reserved.
> -.\" Copyright (c) 2003 Torrey T. Lyons. All Rights Reserved.
> -.\" 
> -.\" Permission is hereby granted, free of charge, to any person obtaining a
> -.\" copy of this software and associated documentation files (the
> -.\" "Software"), to deal in the Software without restriction, including
> -.\" without limitation the rights to use, copy, modify, merge, publish,
> -.\" distribute, sub license, and/or sell copies of the Software, and to
> -.\" permit persons to whom the Software is furnished to do so, subject to
> -.\" the following conditions:
> -.\" 
> -.\" The above copyright notice and this permission notice (including the
> -.\" next paragraph) shall be included in all copies or substantial portions
> -.\" of the Software.
> -.\" 
> -.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> -.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> -.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> -.\" IN NO EVENT SHALL PRECISION INSIGHT AND/OR ITS SUPPLIERS BE LIABLE FOR
> -.\" ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> -.\" TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> -.\" SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> -.\"
> -.de TQ
> -.br
> -.ns
> -.TP \\$1
> -..
> -.TH APPLEWM __libmansuffix__ __vendorversion__
> -
> -.SH NAME
> - AppleWM \- Apple rootless window management extension.
> -.SH SYNTAX
> -\&#include 
> -.nf
> -.sp
> -Bool XAppleWMQueryExtension \^(\^Display *\fIdpy\fP, 
> -int *\fIevent_basep\fP, int *\fIerror_basep\fP\^);
> -.sp
> -Status XAppleWMQueryVersion \^(\^Display *\fIdpy\fP,
> -int *\fImajor_versionp\fP, int *\fIminor_versionp\fP\^);
> -.sp
> -Bool XAppleWMDisableUpdate \^(\^Display *\fIdpy\fP, int \fIscreen\fP\^);
> -.sp
> -Bool XAppleWMReenableUpdate \^(\^Display *\fIdpy\fP, int \fIscreen\fP\^);
> -.sp
> -Bool XAppleWMSelectInput \^(\^Display *\fIdpy\fP, unsigned long 
> \fImask\fP\^);
> -.sp
> -Bool XAppleWMSetWindowMenu \^(\^Display *\fIdpy\fP, int \fInitems\fP,
> -const char **\fIitems\fP\^);
> -.sp
> -Bool XAppleWMSetWindowMenuWithShortcuts \^(\^Display *\fIdpy\fP,
> -int \fInitems\fP, const char **\fIitems\fP,
> -const char *\fIshortcuts\fP\^);
> -.sp
> -Bool XAppleWMSetWindowMenuCheck \^(\^Display *\fIdpy\fP, int \fIindex\fP\^);
> -.sp
> -Bool XAppleWMSetFrontProcess \^(\^Display *\fIdpy\fP\^);
> -.sp
> -Bool XAppleWMSetWindowLevel \^(\^Display *\fIdpy\fP, Window \fIwindow\fP,
> -int \fIlevel\fP\^);
> -.sp
> -Bool XAppleWMSetCanQuit \^(\^Display *\fIdpy\fP, Bool \fIstate\fP\^);
> -.sp
> -Bool XAppleWMFrameGetRect \^(\^Display *\fIdpy\fP,
> -unsigned int \fIframe_class\fP,
> -unsigned int \fIframe_rect\fP,
> -short \fIinner_x\fP, short \fIinner_y\fP,
> -short \fIinner_w\fP, short \fIinner_h\fP,
> -short \fIouter_x\fP, short \fIouter_y\fP,
> -short \fIouter_w\fP, short \fIouter_h\fP,
> -short *\fIret_x\fP, short *\fIret_y\fP,
> -short *\fIret_w\fP, short *\fIret_h\fP\^);
> -.sp
> -unsigned int XAppleWMFrameHitTest \^(\^Display *\fIdpy\fP,
> -

Re: [PATCH libAppleWM] man: make manpage macro substitutions

[Jeremy Huddleston]

Reviewed-by: Jeremy Huddleston 

On Feb 14, 2010, at 17:37, Gaetan Nadon wrote:

> The man page displays to the user the variables to be substituted
> such as __vendorversion__.
> 
> The filename in git should be .man.
> The process to substitute the variables is the same used by
> all other modules.
> 
> Signed-off-by: Gaetan Nadon 
> ---
> configure.ac|1 +
> man/.gitignore  |3 -
> man/AppleWM.3   |  340 ---
> man/AppleWM.man |  340 +++
> man/Makefile.am |   32 +-
> 5 files changed, 370 insertions(+), 346 deletions(-)
> delete mode 100644 man/.gitignore
> delete mode 100644 man/AppleWM.3
> create mode 100644 man/AppleWM.man
> 
> diff --git a/configure.ac b/configure.ac
> index 0ea3c35..08f3cd1 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -37,6 +37,7 @@ AM_CONFIG_HEADER(config.h)
> # Check for progs
> AC_PROG_CC
> AC_PROG_LIBTOOL
> +AC_PROG_SED
> 
> # Check for dependencies
> PKG_CHECK_MODULES(APPLEWM, x11 xext xextproto [applewmproto >= 1.4])
> diff --git a/man/.gitignore b/man/.gitignore
> deleted file mode 100644
> index 58d42ad..000
> --- a/man/.gitignore
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -#Add & Override for this directory and it's subdirectories
> -# Override default pattern *.[0-9] from toplevel .gitignore
> -!AppleWM.3
> diff --git a/man/AppleWM.3 b/man/AppleWM.3
> deleted file mode 100644
> index bb81470..000
> --- a/man/AppleWM.3
> +++ /dev/null
> @@ -1,340 +0,0 @@
> -.\"
> -.\" $XFree86: xc/lib/apple/AppleWM.man,v 1.1 2003/08/12 23:47:10 torrey Exp $
> -.\"
> -.\" Copyright (c) 2002 Apple Computer, Inc. All Rights Reserved.
> -.\" Copyright (c) 2003 Torrey T. Lyons. All Rights Reserved.
> -.\" 
> -.\" Permission is hereby granted, free of charge, to any person obtaining a
> -.\" copy of this software and associated documentation files (the
> -.\" "Software"), to deal in the Software without restriction, including
> -.\" without limitation the rights to use, copy, modify, merge, publish,
> -.\" distribute, sub license, and/or sell copies of the Software, and to
> -.\" permit persons to whom the Software is furnished to do so, subject to
> -.\" the following conditions:
> -.\" 
> -.\" The above copyright notice and this permission notice (including the
> -.\" next paragraph) shall be included in all copies or substantial portions
> -.\" of the Software.
> -.\" 
> -.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> -.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> -.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
> -.\" IN NO EVENT SHALL PRECISION INSIGHT AND/OR ITS SUPPLIERS BE LIABLE FOR
> -.\" ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
> -.\" TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
> -.\" SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> -.\"
> -.de TQ
> -.br
> -.ns
> -.TP \\$1
> -..
> -.TH APPLEWM __libmansuffix__ __vendorversion__
> -
> -.SH NAME
> - AppleWM \- Apple rootless window management extension.
> -.SH SYNTAX
> -\&#include 
> -.nf
> -.sp
> -Bool XAppleWMQueryExtension \^(\^Display *\fIdpy\fP, 
> -int *\fIevent_basep\fP, int *\fIerror_basep\fP\^);
> -.sp
> -Status XAppleWMQueryVersion \^(\^Display *\fIdpy\fP,
> -int *\fImajor_versionp\fP, int *\fIminor_versionp\fP\^);
> -.sp
> -Bool XAppleWMDisableUpdate \^(\^Display *\fIdpy\fP, int \fIscreen\fP\^);
> -.sp
> -Bool XAppleWMReenableUpdate \^(\^Display *\fIdpy\fP, int \fIscreen\fP\^);
> -.sp
> -Bool XAppleWMSelectInput \^(\^Display *\fIdpy\fP, unsigned long 
> \fImask\fP\^);
> -.sp
> -Bool XAppleWMSetWindowMenu \^(\^Display *\fIdpy\fP, int \fInitems\fP,
> -const char **\fIitems\fP\^);
> -.sp
> -Bool XAppleWMSetWindowMenuWithShortcuts \^(\^Display *\fIdpy\fP,
> -int \fInitems\fP, const char **\fIitems\fP,
> -const char *\fIshortcuts\fP\^);
> -.sp
> -Bool XAppleWMSetWindowMenuCheck \^(\^Display *\fIdpy\fP, int \fIindex\fP\^);
> -.sp
> -Bool XAppleWMSetFrontProcess \^(\^Display *\fIdpy\fP\^);
> -.sp
> -Bool XAppleWMSetWindowLevel \^(\^Display *\fIdpy\fP, Window \fIwindow\fP,
> -int \fIlevel\fP\^);
> -.sp
> -Bool XAppleWMSetCanQuit \^(\^Display *\fIdpy\fP, Bool \fIstate\fP\^);
> -.sp
> -Bool XAppleWMFrameGetRect \^(\^Display *\fIdpy\fP,
> -unsigned int \fIframe_class\fP,
> -unsigned int

Fwd: [PULL] 2 XQuartz patches

[Jeremy Huddleston]

Resending, thanks.

Begin forwarded message:

> From: Jeremy Huddleston 
> Date: February 12, 2010 20:08:04 PST
> To: Keith Packard 
> Cc: xorg-devel 
> Subject: [PULL] 2 XQuartz patches
> 
> The following changes since commit 001ce71dc11287dc94cc2fbc5d35677c046e6c04:
>  Julien Cristau (1):
>dix: restore lastDeviceEventTime update in dixSaveScreens
> 
> are available in the git repository at:
> 
>  git://anongit.freedesktop.org/~jeremyhu/xserver master
> 
> Jeremy Huddleston (2):
>  XQuartz: Fix a possible crash in quartzAudio fade
>  XQuartz: clang static analysis fixes
> 
> hw/xquartz/GL/indirect.c  |2 +-
> hw/xquartz/GL/visualConfigs.c |3 +--
> hw/xquartz/X11Application.m   |   18 ++
> hw/xquartz/mach-startup/bundle-main.c |   30 +++---
> hw/xquartz/mach-startup/stub.c|7 ---
> hw/xquartz/pbproxy/x-selection.h  |9 -
> hw/xquartz/quartzAudio.c  |3 ++-
> hw/xquartz/quartzKeyboard.c   |2 +-
> 8 files changed, 38 insertions(+), 36 deletions(-)
> 
> ___
> xorg-devel mailing list
> xorg-devel@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] xquartz: add missing CloseInput.

[Jeremy Huddleston]

No worries.  This is why it's great to be living on master.

I've got this change already in my pull-request (just sent), so Keith, you can 
just pull my branch and we should be good.

Thanks,
Jeremy

On Feb 15, 2010, at 16:24, Peter Hutterer wrote:

> Missing from d33adcdf03c69407d151e732fa0cf9947151eb19.
> 
> Signed-off-by: Peter Hutterer 
> ---
> Sorry, Jeremy.
> 
> hw/xquartz/darwin.c |4 
> 1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/hw/xquartz/darwin.c b/hw/xquartz/darwin.c
> index 3feacdc..572de54 100644
> --- a/hw/xquartz/darwin.c
> +++ b/hw/xquartz/darwin.c
> @@ -502,6 +502,10 @@ void InitInput( int argc, char **argv )
> QuartzInitInput(argc, argv);
> }
> 
> +void CloseInput(void)
> +{
> +}
> +
> 
> /*
>  * DarwinAdjustScreenOrigins
> -- 
> 1.6.6.1
> ___
> xorg-devel mailing list
> xorg-devel@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

[PULL] XQuartz fixes (replaces previous request)

[Jeremy Huddleston]

The following changes since commit 84905007702da2c05a4f7446b3fc5ff52be49655:
  Thomas Jaeger (1):
udev: Don't filter subsystem "input"

are available in the git repository at:

  git://anongit.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (3):
  XQuartz: Fix linking (CloseInput())
  XQuartz: clang static analysis fixes
  XQuartz: Fix a possible buffer overrun in quartzAudio

 hw/xquartz/GL/indirect.c  |2 +-
 hw/xquartz/GL/visualConfigs.c |3 +-
 hw/xquartz/X11Application.m   |   18 +---
 hw/xquartz/darwinXinput.c |6 +
 hw/xquartz/mach-startup/bundle-main.c |   30 +--
 hw/xquartz/mach-startup/stub.c|7 --
 hw/xquartz/pbproxy/x-selection.h  |9 
 hw/xquartz/quartzAudio.c  |   35 +
 hw/xquartz/quartzKeyboard.c   |2 +-
 9 files changed, 60 insertions(+), 52 deletions(-)

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH video-intel] config: add -fno-strict-aliasing now that it is out of $CWARNFLAGS

[Jeremy Huddleston]

Thanks Gaetan.  This review goes similarly to the other affected  
modules you've mentioned as long as they all match this same pattern.


I also reviewed the xserver changes.  It would be nice to move those  
to Makefile.am as well, but that's a bit more trouble than it may be  
worth.


Reviewed-by: Jeremy Huddleston 

On Feb 22, 2010, at 14:03, Gaetan Nadon wrote:


This patch will ensure the modules continues to suppress the
optimization, based on strict aliasing rules, after the option
is removed from $CWARNFLAGS. There is no change in the object
code produced.

There is no attempt to determine if the module should or should not
have such an optimization. A new warning (-Wstrict-aliasing=2)
has been added to the XORG_CWARNFLAGS macro to help  find code
that may interfere with optimization.
---
configure.ac |7 +++
src/Makefile.am  |   11 +--
src/xvmc/Makefile.am |   12 ++--
uxa/Makefile.am  |6 +-
4 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 87cbe55..687dcf7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -40,6 +40,13 @@ m4_ifndef([XORG_MACROS_VERSION],
XORG_MACROS_VERSION(1.3)
XORG_DEFAULT_OPTIONS

+# Suppress optimization based on strict aliasing rules
+ALIASING_CFLAGS=
+if test "x$GCC" = xyes; then
+ALIASING_CFLAGS=-fno-strict-aliasing
+fi
+AC_SUBST([ALIASING_CFLAGS])
+
# Checks for programs.
AC_DISABLE_STATIC
AC_PROG_LIBTOOL
diff --git a/src/Makefile.am b/src/Makefile.am
index b4bafbd..b84feff 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -26,8 +26,15 @@ SUBDIRS = xvmc render_program
# _ladir passes a dummy rpath to libtool so the thing will actually  
link
# TODO: -nostdlib/-Bstatic/-lgcc platform magic, not installing  
the .a, etc.


-AM_CFLAGS = @CWARNFLAGS@ @XORG_CFLAGS@ @DRM_CFLAGS@ @DRI_CFLAGS@ \
-	@PCIACCESS_CFLAGS@ -I$(top_srcdir)/uxa -I$(top_srcdir)/src/ 
render_program

+AM_CFLAGS = \
+   $(CWARNFLAGS) \
+   $(ALIASING_CFLAGS) \
+   $(XORG_CFLAGS) \
+   $(DRM_CFLAGS) \
+   $(DRI_CFLAGS) \
+   $(PCIACCESS_CFLAGS) \
+   -I$(top_srcdir)/uxa \
+   -I$(top_srcdir)/src/render_program

intel_drv_la_LTLIBRARIES = intel_drv.la
intel_drv_la_LDFLAGS = -module -avoid-version
diff --git a/src/xvmc/Makefile.am b/src/xvmc/Makefile.am
index be8824b..815eda8 100644
--- a/src/xvmc/Makefile.am
+++ b/src/xvmc/Makefile.am
@@ -7,8 +7,16 @@ SUBDIRS = shader
libI810XvMC_la_SOURCES = I810XvMC.c \
 I810XvMC.h

-libI810XvMC_la_CFLAGS = @CWARNFLAGS@ @XORG_CFLAGS@ @DRM_CFLAGS@  
@DRI_CFLAGS@ \

-   -I$(top_srcdir)/src -DTRUE=1 -DFALSE=0
+libI810XvMC_la_CFLAGS = \
+   $(CWARNFLAGS) \
+   $(ALIASING_CFLAGS) \
+   $(XORG_CFLAGS) \
+   $(DRM_CFLAGS) \
+   $(DRI_CFLAGS) \
+   -I$(top_srcdir)/src \
+   -DTRUE=1 \
+   -DFALSE=0
+
libI810XvMC_la_LDFLAGS = -version-number 1:0:0
libI810XvMC_la_LIBADD = @DRI_LIBS@ @DRM_LIBS@ @XVMCLIB_LIBS@

diff --git a/uxa/Makefile.am b/uxa/Makefile.am
index 0dfad48..3658b9a 100644
--- a/uxa/Makefile.am
+++ b/uxa/Makefile.am
@@ -7,7 +7,11 @@ SOLARIS_ASM_CFLAGS=""
INCLUDES = \
$(XORG_INCS)

-AM_CFLAGS = $(CWARNFLAGS) $(XORG_CFLAGS) $(DIX_CFLAGS)
+AM_CFLAGS = \
+   $(CWARNFLAGS) \
+   $(ALIASING_CFLAGS) \
+   $(XORG_CFLAGS) \
+   $(DIX_CFLAGS)

libuxa_la_SOURCES = \
uxa.c \
--
1.6.0.4

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel




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

Re: [PATCH xserver 3/3] XQuartz: remove undefined XSERSER_CFLAGS variable

[Jeremy Huddleston]

Reviewed-by: Jeremy Huddleston 

On Feb 23, 2010, at 06:13, Gaetan Nadon wrote:

> This is a variable local to configure.ac which is not AC_SUBST()
> It is undefined in any generated Makefile.
> 
> Signed-off-by: Gaetan Nadon 
> ---
> hw/xquartz/GL/Makefile.am   |6 +-
> hw/xquartz/Makefile.am  |4 ++--
> hw/xquartz/mach-startup/Makefile.am |4 +++-
> hw/xquartz/xpr/Makefile.am  |5 -
> 4 files changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/xquartz/GL/Makefile.am b/hw/xquartz/GL/Makefile.am
> index 0ac9d5f..66f19ad 100644
> --- a/hw/xquartz/GL/Makefile.am
> +++ b/hw/xquartz/GL/Makefile.am
> @@ -1,5 +1,9 @@
> noinst_LTLIBRARIES = libCGLCore.la
> -AM_CFLAGS = $(XSERVER_CFLAGS) $(DIX_CFLAGS) $(ALIASING_CFLAGS)
> +
> +AM_CFLAGS = \
> + $(DIX_CFLAGS) \
> + $(ALIASING_CFLAGS)
> +
> AM_CPPFLAGS = \
>   -I$(top_srcdir) \
>   -I$(top_srcdir)/glx \
> diff --git a/hw/xquartz/Makefile.am b/hw/xquartz/Makefile.am
> index 0a0ff95..9efe489 100644
> --- a/hw/xquartz/Makefile.am
> +++ b/hw/xquartz/Makefile.am
> @@ -1,6 +1,6 @@
> noinst_LTLIBRARIES = libXquartz.la
> -AM_CFLAGS = $(XSERVER_CFLAGS) $(DIX_CFLAGS) $(ALIASING_CFLAGS)
> -AM_OBJCFLAGS = $(XSERVER_CFLAGS) $(DIX_CFLAGS) $(ALIASING_CFLAGS)
> +AM_CFLAGS = $(DIX_CFLAGS) $(ALIASING_CFLAGS)
> +AM_OBJCFLAGS = $(DIX_CFLAGS) $(ALIASING_CFLAGS)
> AM_CPPFLAGS = \
>   -DBUILD_DATE=\"$(BUILD_DATE)\" \
>   -DXSERVER_VERSION=\"$(VERSION)\" \
> diff --git a/hw/xquartz/mach-startup/Makefile.am 
> b/hw/xquartz/mach-startup/Makefile.am
> index 77d17eb..9e4173e 100644
> --- a/hw/xquartz/mach-startup/Makefile.am
> +++ b/hw/xquartz/mach-startup/Makefile.am
> @@ -3,7 +3,9 @@ AM_CPPFLAGS = \
>   -DXSERVER_VERSION=\"$(VERSION)\" \
>   -DX11BINDIR=\"$(bindir)\"
> 
> -AM_CFLAGS = $(XSERVER_CFLAGS) $(DIX_CFLAGS) $(ALIASING_CFLAGS)
> +AM_CFLAGS = \
> + $(DIX_CFLAGS) \
> + $(ALIASING_CFLAGS)
> 
> x11appdir = 
> $(APPLE_APPLICATIONS_DIR)/$(APPLE_APPLICATION_NAME).app/Contents/MacOS
> x11app_PROGRAMS = X11.bin
> diff --git a/hw/xquartz/xpr/Makefile.am b/hw/xquartz/xpr/Makefile.am
> index e9a092f..965da36 100644
> --- a/hw/xquartz/xpr/Makefile.am
> +++ b/hw/xquartz/xpr/Makefile.am
> @@ -1,6 +1,9 @@
> noinst_LTLIBRARIES = libXquartzXpr.la
> 
> -AM_CFLAGS =  $(XSERVER_CFLAGS) $(DIX_CFLAGS) $(ALIASING_CFLAGS)
> +AM_CFLAGS =  \
> + $(DIX_CFLAGS) \
> + $(ALIASING_CFLAGS)
> +
> AM_CPPFLAGS = \
>   -I$(srcdir) -I$(srcdir)/.. \
>   -I$(top_srcdir)/miext \
> -- 
> 1.6.0.4
> 
> ___
> xorg-devel mailing list
> xorg-devel@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 1/3] config: add -fno-strict-aliasing now that it is out of $CWARNFLAGS

[Jeremy Huddleston]

With your 2/3, you don't need this any more:

> +CWARNFLAGS="$CWARNFLAGS $ALIASING_CFLAGS"

Also, can you remove XQuartz from the changes in 2/3.  I'm 99% certain XQuartz 
is strict-aliasing safe, and if not, I want to see the fallout, so I can fix it.

Thanks,
Jeremy

On Feb 23, 2010, at 06:13, Gaetan Nadon wrote:

> This patch will ensure the xserver continues to suppress the
> optimization, based on strict aliasing rules, after the option
> is removed from $CWARNFLAGS. There is no change in the object
> code produced.
> 
> There is no attempt to determine if xserver should or should not
> have such an optimization. A new warning (-Wstrict-aliasing=2)
> has been added to the XORG_CWARNFLAGS macro to help  find code
> that may interfere with optimization.
> 
> Reviewed-by: Jeremy Huddleston 
> Signed-off-by: Gaetan Nadon 
> ---
> configure.ac |8 
> 1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index b9c7574..2360cde 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -79,6 +79,14 @@ AC_SYS_LARGEFILE
> XORG_PROG_RAWCPP
> AC_PATH_PROG(SED,sed)
> 
> +# Suppress strict aliasing optimization
> +ALIASING_CFLAGS=
> +if test "x$GCC" = xyes; then
> +ALIASING_CFLAGS=-fno-strict-aliasing
> +fi
> +AC_SUBST([ALIASING_CFLAGS])
> +CWARNFLAGS="$CWARNFLAGS $ALIASING_CFLAGS"
> +
> # Quoted so that make will expand $(CWARNFLAGS) in makefiles to allow
> # easier overrides at build time.
> XSERVER_CFLAGS='$(CWARNFLAGS)'
> -- 
> 1.6.0.4
> 
> Reposting single patch as the first of a serie due to dependencies
> 
> 
> 
> 
> ___
> xorg-devel mailing list
> xorg-devel@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 1/3] config: add -fno-strict-aliasing now that it is out of $CWARNFLAGS

[Jeremy Huddleston]

You're still have this which is not necessary due to your #2 patch:

+CWARNFLAGS="$CWARNFLAGS $ALIASING_CFLAGS"

--Jeremy

On Feb 23, 2010, at 10:37, Gaetan Nadon wrote:


This patch will ensure the xserver continues to suppress the
optimization, based on strict aliasing rules, after the option
is removed from $CWARNFLAGS. There is no change in the object
code produced.

There is no attempt to determine if xserver should or should not
have such an optimization. A new warning (-Wstrict-aliasing=2)
has been added to the XORG_CWARNFLAGS macro to help  find code
that may interfere with optimization.

Reviewed-by: Jeremy Huddleston 
Signed-off-by: Gaetan Nadon 
---
configure.ac |8 
1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index b9c7574..2360cde 100644
--- a/configure.ac
+++ b/configure.ac
@@ -79,6 +79,14 @@ AC_SYS_LARGEFILE
XORG_PROG_RAWCPP
AC_PATH_PROG(SED,sed)

+# Suppress strict aliasing optimization
+ALIASING_CFLAGS=
+if test "x$GCC" = xyes; then
+ALIASING_CFLAGS=-fno-strict-aliasing
+fi
+AC_SUBST([ALIASING_CFLAGS])
+CWARNFLAGS="$CWARNFLAGS $ALIASING_CFLAGS"
+
# Quoted so that make will expand $(CWARNFLAGS) in makefiles to allow
# easier overrides at build time.
XSERVER_CFLAGS='$(CWARNFLAGS)'
--
1.6.0.4

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel




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

Re: [PATCH xserver 1/3] config: add -fno-strict-aliasing now that it is out of $CWARNFLAGS

[Jeremy Huddleston]

Well if they're not merged, we need another patch to remove it from  
configure... I think it's easier to just merge them.


On Feb 23, 2010, at 10:54, Alan Coopersmith wrote:

But if it's not in patch 1, then bisecting will fail when it lands  
between

patch 1 & 2.   Removing it only makes sense if 1 & 2 get merged.

-alan-

Jeremy Huddleston wrote:

You're still have this which is not necessary due to your #2 patch:

+CWARNFLAGS="$CWARNFLAGS $ALIASING_CFLAGS"

--Jeremy

On Feb 23, 2010, at 10:37, Gaetan Nadon wrote:


This patch will ensure the xserver continues to suppress the
optimization, based on strict aliasing rules, after the option
is removed from $CWARNFLAGS. There is no change in the object
code produced.

There is no attempt to determine if xserver should or should not
have such an optimization. A new warning (-Wstrict-aliasing=2)
has been added to the XORG_CWARNFLAGS macro to help  find code
that may interfere with optimization.

Reviewed-by: Jeremy Huddleston 
Signed-off-by: Gaetan Nadon 
---
configure.ac |8 
1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index b9c7574..2360cde 100644
--- a/configure.ac
+++ b/configure.ac
@@ -79,6 +79,14 @@ AC_SYS_LARGEFILE
XORG_PROG_RAWCPP
AC_PATH_PROG(SED,sed)

+# Suppress strict aliasing optimization
+ALIASING_CFLAGS=
+if test "x$GCC" = xyes; then
+ALIASING_CFLAGS=-fno-strict-aliasing
+fi
+AC_SUBST([ALIASING_CFLAGS])
+CWARNFLAGS="$CWARNFLAGS $ALIASING_CFLAGS"
+
# Quoted so that make will expand $(CWARNFLAGS) in makefiles to  
allow

# easier overrides at build time.
XSERVER_CFLAGS='$(CWARNFLAGS)'
--
1.6.0.4

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel





___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel


--
-Alan Coopersmith-   alan.coopersm...@sun.com
 Oracle Solaris Platform Engineering: X Window System

___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel




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

Re: [PATCH xserver 1/3] config: add -fno-strict-aliasing now that it is out of $CWARNFLAGS

[Jeremy Huddleston]

On Feb 23, 2010, at 11:07, Keith Packard wrote:

On Tue, 23 Feb 2010 13:37:18 -0500, Gaetan Nadon  
 wrote:



This patch will ensure the xserver continues to suppress the
optimization, based on strict aliasing rules, after the option
is removed from $CWARNFLAGS. There is no change in the object
code produced.


I don't think we need to allow any of the code in the X server to be
'optimized' in this fashion, so I don't see a need to allow for
per-directory selection.


It would be helpful if I had the option to remove this flag from  
XQuartz.






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

Re: [PATCH xserver 1/3] config: add -fno-strict-aliasing now that it is out of $CWARNFLAGS

[Jeremy Huddleston]

On Feb 24, 2010, at 05:45, Gaetan Nadon wrote:

> On Wed, 2010-02-24 at 09:34 +0100, Michel Dänzer wrote:
> 
>> On Tue, 2010-02-23 at 11:11 -0800, Jeremy Huddleston wrote: 
>>> On Feb 23, 2010, at 11:07, Keith Packard wrote:
>>> 
>>>> On Tue, 23 Feb 2010 13:37:18 -0500, Gaetan Nadon  
>>>>  wrote:
>>>> 
>>>>> This patch will ensure the xserver continues to suppress the
>>>>> optimization, based on strict aliasing rules, after the option
>>>>> is removed from $CWARNFLAGS. There is no change in the object
>>>>> code produced.
>>>> 
>>>> I don't think we need to allow any of the code in the X server to be
>>>> 'optimized' in this fashion, so I don't see a need to allow for
>>>> per-directory selection.
>>> 
>>> It would be helpful if I had the option to remove this flag from  
>>> XQuartz.
>> 
>> Out of curiosity, what significant benefit have you measured from using
>> -fstrict-aliasing?
>> 
>> 
> 
> Excellent question which I carefully want to avoid :-) 
> 
> The problem I want to solve is the following: someone added
> -fnostrict-aliasing a long time ago and I don't know why. Then it got
> copied to a number of libraries, then got included in a macro
> (XORG_CWARNFLAGS), which then got included by over a hundred modules,
> still not knowing why.
> 
> There are over 50 modules that are compiling with no warning flags at
> all. I don't want to contribute to the spread of this option. The patch
> is about *transferring* the option out of the macro back to the modules
> (where the skills are) and let them decide if they want that option or
> not.

Additionally, before being copied into XORG_CWARNFLAGS fairly recently, this 
was only in a handful of modules:

libICE
libSM
libX11
libXau
libXfont
libXft
libXpm
libXres
xorg-server
(I didn't check xf86-drivers)

So adding it across the board is rather far-reaching, IMO.  I believe it should 
only be added back to the modules listed above.



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

Re: [PATCH xserver 1/3] config: add -fno-strict-aliasing now that it is out of $CWARNFLAGS

[Jeremy Huddleston]

> I'll submit a patch for the new macro definitions. Comments are welcome
> at anytime.

I definitely agree that '-fno-strict-aliasing' is something that should be 
hardcoded into util-macros.  That makes the job of packagers much easier.  I 
was thinking it would be fine to just hard code it into the ~10 packages that 
had it >1yr ago, but if we want to be more conservative than that, util-macros 
is the right place.

That will give me the ability to remove it easily in one location rather than 
patching every single configure.ac while at the same time making it easy for me 
to set it on xserver, pixman, cairo, mesa, and libX11 (and possibly a few 
others from the list of ~10) by just setting CFLAGS at configure time.

Thanks for your efforts here and on cleaning up the build system in general, 
Gaetan.

--Jeremy

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

Re: [PATCH] dix: Use DeliverGrabbedEvent for implicit passive grabs (#25400)

[Jeremy Huddleston]

On Mar 8, 2010, at 15:56, Keith Packard wrote:

On Tue, 9 Mar 2010 09:44:44 +1000, Peter Hutterer > wrote:


thanks. I've reverted it on the nominations branch until we've  
narrowed down

what the cause of it is.


It seems not unlikely that fluxbox is depending on the old  
("incorrect")

behaviour, leaving us with the choice of shipping code that doesn't
conform to the spec or breaking applications.


If fluxbox fixes itself, how bad will the behavior be on older  
("incorrect") servers?  I'm certainly one for conforming to standards  
in a tie breaker like this.




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

Re: [PATCH util-macros 0/4] Specify minimum version to doc tools

[Jeremy Huddleston]

Series Reviewed-by: Jeremy Huddleston 

On Mar 9, 2010, at 08:14, Gaetan Nadon wrote:


This will avoid build breaks when tool installed tool is too old.
The package will then be versioned at 1.6.1 and released

Final version for:
Dan Nicholson (2):
 doc: Specify minimum asciidoc version to XORG_WITH_ASCIIDOC
 doc: Specify minimum xmlto version to XORG_WITH_XMLTO

Added same code to doxygen:
Gaetan Nadon (2):
 doc: Specify minimum xmlto version to XORG_WITH_DOXYGEN
 doc: fix typo in AC_MSG_CHECKING for XORG_CHECK_LINUXDOC

xorg-macros.m4.in |   68 + 
+--

1 files changed, 55 insertions(+), 13 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




smime.p7s
Description: S/MIME cryptographic 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

[PULL] XQuartz regression fixes and keymapping change

[Jeremy Huddleston]

The following changes since commit f2eacb4646beb25d055de22868f93e6b24f229b6:
  Peter Hutterer (1):
Revert "dix: Use DeliverGrabbedEvent for implicit passive grabs 
(#25400)"

are available in the git repository at:

  git://anongit.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (3):
  XQuartz: GLX: Fix prototype for swapBuffers
  XQuartz: Include os.h for OsAbort()
  XQuartz: Use an empty xkb keymap by default

 hw/xquartz/GL/capabilities.c |4 
 hw/xquartz/GL/indirect.c |2 +-
 hw/xquartz/darwin.c  |6 ++
 hw/xquartz/quartzKeyboard.c  |   16 +---
 4 files changed, 16 insertions(+), 12 deletions(-)



smime.p7s
Description: S/MIME cryptographic 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

[PULL] XQuartz regression fixes and keymapping change

[Jeremy Huddleston]

resending

Begin forwarded message:

> From: Jeremy Huddleston 
> Date: March 11, 2010 00:08:35 PST
> To: Keith Packard 
> Cc: xorg-devel 
> Subject: [PULL] XQuartz regression fixes and keymapping change
> 
> The following changes since commit f2eacb4646beb25d055de22868f93e6b24f229b6:
>  Peter Hutterer (1):
>Revert "dix: Use DeliverGrabbedEvent for implicit passive grabs 
> (#25400)"
> 
> are available in the git repository at:
> 
>  git://anongit.freedesktop.org/~jeremyhu/xserver master
> 
> Jeremy Huddleston (3):
>  XQuartz: GLX: Fix prototype for swapBuffers
>  XQuartz: Include os.h for OsAbort()
>  XQuartz: Use an empty xkb keymap by default
> 
> hw/xquartz/GL/capabilities.c |4 
> hw/xquartz/GL/indirect.c |2 +-
> hw/xquartz/darwin.c  |6 ++
> hw/xquartz/quartzKeyboard.c  |   16 +---
> 4 files changed, 16 insertions(+), 12 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



smime.p7s
Description: S/MIME cryptographic 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: [RFC] Multitouch support, step one

[Jeremy Huddleston]

On Mar 15, 2010, at 09:01, Simon Thum wrote:

> Henrik,
> 
> if I'm anywhere near understanding this, then probably your're missing
> an important point. This is _step one_. Getting information to where you
> need it and giving it a basic structure, roughly.
> 
> The things you're talking about are more suited as a step two: Making
> sense of the information. Along those lines, you're probably right,
> though I'd go even further. But ATM concensus is needed how to transport
> MT information in a suitable and forward-compatible manner.
> 
> The sooner this is nailed down, the sooner more abstract concepts can be
> tackled.
> 
> Cheers,
> 
> Simon


I agree that application developers want something higher level.  The structure 
that Henrik describes will be more beneficial to application developers.  The 
point now is to determine who actually provides that data.  Do we want tracking 
and grouping to be handled by the Xserver and sent to the client as such, or do 
we want to send the raw data to the client and have a library interpret these 
data and provide the client with these pretty structures?

It seems like the latter can make use of the already-existing XI2 protocol.  If 
we try to do this all in the server and package it up for the user, will we be 
looking at yet another bump of XI?  Can we do it in a way that will be 
compatible with XI2?

I actually like the idea of using the valuators to send the data over the wire. 
 Why not use the valuators to also send data like:

valuator 0  = core X
valuator 1  = core Y
valuator 2  = multi-touch 0 tracking id
valuator 3  = multi-touch 0 group id
valuator 4  = multi-touch 0 x
valuator 5  = multi-touch 0 y
valuator 6  = multi-touch 0 pressure
valuator 7  = multi-touch 1 tracking id
valuator 8  = multi-touch 1 group id
valuator 9  = multi-touch 1 x
valuator 10 = multi-touch 1 y
valuator 11 = multi-touch 1 pressure

More complex data management could then be handled by a client-side library.

This still does not solve the valuator limit of 32.  How difficult will it be 
to eliminate that maximum and have no limit?

--Jeremy



smime.p7s
Description: S/MIME cryptographic 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

[PULL] revert an XQuartz patch that doesn't seem to be needed any more

[Jeremy Huddleston]

I'm not quite sure any more why this was needed, but DDXRingBell() is called 
from CoreKeyboardBell(), and I don't want to ring the bell three times.  This 
results in our DDXRingBell() getting called just once per XBell().

The following changes since commit 67a8c659f25218904bae64aac6e98e326c90330b:
  Roland Scheidegger (1):
hw/xfree86: move reference counting out of the UseHWCursor[ARGB] 
functions

are available in the git repository at:

  git://anongit.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (1):
  Revert "XQuartz: Explicitly pass a bellProc to make XBell() work again."

 hw/xquartz/quartzKeyboard.c |8 +---
 1 files changed, 1 insertions(+), 7 deletions(-)



smime.p7s
Description: S/MIME cryptographic 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

keyboard bell woes (ignores xset)

[Jeremy Huddleston]

I turn off the bell using 'xset -b' :
~ $ xset -q | grep bell
  bell percent:  0bell pitch:  400bell duration:  100

but when I do XBell(dpy, 100), the bell still rings at volume 100.

#0  DDXRingBell (volume=100, pitch=400, duration=100) at quartzAudio.c:223
#1  0x000100138ba2 in CoreKeyboardBell (volume=100, pDev=0x115b708e0, 
arg=0x115b71100, something=0) at devices.c:498
#2  0x000100105114 in XkbHandleBell (force=0 '\0', eventOnly=0 '\0', 
kbd=0x115b708e0, percent=100 'd', pCtrl=0x115b71100, class=0 '\0', name=0, 
pWin=0x0, pClient=0x115e11c00) at xkbEvents.c:514

Shouldn't the bell percent set by 'xset' be multiplied by the volume passed to 
XBell?  From XBell(3):

"""
   The XBell function rings the bell on the keyboard on the specified 
display, if possible.  The specified
   volume is relative to the base volume for the keyboard.  If the value 
for the percent argument is not in
   the range -100 to 100 inclusive, a BadValue error results.  The volume 
at which the bell rings when the
   percent argument is nonnegative is:

  base - [(base * percent) / 100] + percent

   The volume at which the bell rings when the percent argument is negative 
is:

  base + [(base * percent) / 100]
"""

--Jeremy



smime.p7s
Description: S/MIME cryptographic 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: keyboard bell woes (ignores xset)

[Jeremy Huddleston]

Actually, as I read this again, I noticed that it is behaving as per the spec:

XBell(dpy, 100) with base = 0:
base - [(base * percent) / 100] + percent = 0 - 0 + 100 = 100

XBell(dpy, 100) with base = 100:
base - [(base * percent) / 100] + percent = 100 - 100 + 100 = 100

So... this just seems a bit deceptive... if 'xset -b' is supposed to mute the 
keyboard bell, why was XBell() designed to work around this?


On Mar 16, 2010, at 11:47, Jeremy Huddleston wrote:

> I turn off the bell using 'xset -b' :
> ~ $ xset -q | grep bell
>  bell percent:  0bell pitch:  400bell duration:  100
> 
> but when I do XBell(dpy, 100), the bell still rings at volume 100.
> 
> #0  DDXRingBell (volume=100, pitch=400, duration=100) at quartzAudio.c:223
> #1  0x000100138ba2 in CoreKeyboardBell (volume=100, pDev=0x115b708e0, 
> arg=0x115b71100, something=0) at devices.c:498
> #2  0x000100105114 in XkbHandleBell (force=0 '\0', eventOnly=0 '\0', 
> kbd=0x115b708e0, percent=100 'd', pCtrl=0x115b71100, class=0 '\0', name=0, 
> pWin=0x0, pClient=0x115e11c00) at xkbEvents.c:514
> 
> Shouldn't the bell percent set by 'xset' be multiplied by the volume passed 
> to XBell?  From XBell(3):
> 
> """
>   The XBell function rings the bell on the keyboard on the specified 
> display, if possible.  The specified
>   volume is relative to the base volume for the keyboard.  If the value 
> for the percent argument is not in
>   the range -100 to 100 inclusive, a BadValue error results.  The volume 
> at which the bell rings when the
>   percent argument is nonnegative is:
> 
>  base - [(base * percent) / 100] + percent
> 
>   The volume at which the bell rings when the percent argument is 
> negative is:
> 
>  base + [(base * percent) / 100]
> """
> 
> --Jeremy
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic 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: keyboard bell woes (ignores xset)

[Jeremy Huddleston]

I started looking into this because a user reported that XQuartz was still 
beeping in his xterm even though he uses 'xset -b' ... it turns out that xterm 
is using XkbBell() rather than XBell().  Even with 'xset -b', the audible bell 
is still calling DDXRingBell() with volume = 50...

I made a reduced test case that does:

XBell(dpy, 0);// No beep with 'xset -b'
XkbBell(dpy, 0, 0, None); // Beep with vol=50 with 'xset -b'

shouldn't these be the same?


On Mar 16, 2010, at 15:30, Peter Hutterer wrote:

> On Tue, Mar 16, 2010 at 01:12:54PM -0700, Jeremy Huddleston wrote:
>> Actually, as I read this again, I noticed that it is behaving as per the 
>> spec:
>> 
>> XBell(dpy, 100) with base = 0:
>> base - [(base * percent) / 100] + percent = 0 - 0 + 100 = 100
>> 
>> XBell(dpy, 100) with base = 100:
>> base - [(base * percent) / 100] + percent = 100 - 100 + 100 = 100
>> 
>> So... this just seems a bit deceptive... if 'xset -b' is supposed to mute
>> the keyboard bell, why was XBell() designed to work around this?
> 
> I think you need to ask the question the other way round - why does 
> xset -b provide a functionality that XBell() can route around. I'm pretty
> sure XBell() was there first :)
> 
> Looks like to really disable the bell for core requests you need to call
> XkbSetControls() with the XkbAudibleBellMask. That way it can only be
> overridden by a forced XkbBell() request, not by any core requests.
> xset at this point doesn't do xkb but I don't se why it couldn't.
> 
> Cheers,
>  Peter
> 
> 
>> On Mar 16, 2010, at 11:47, Jeremy Huddleston wrote:
>> 
>>> I turn off the bell using 'xset -b' :
>>> ~ $ xset -q | grep bell
>>> bell percent:  0bell pitch:  400bell duration:  100
>>> 
>>> but when I do XBell(dpy, 100), the bell still rings at volume 100.
>>> 
>>> #0  DDXRingBell (volume=100, pitch=400, duration=100) at quartzAudio.c:223
>>> #1  0x000100138ba2 in CoreKeyboardBell (volume=100, pDev=0x115b708e0, 
>>> arg=0x115b71100, something=0) at devices.c:498
>>> #2  0x000100105114 in XkbHandleBell (force=0 '\0', eventOnly=0 '\0', 
>>> kbd=0x115b708e0, percent=100 'd', pCtrl=0x115b71100, class=0 '\0', name=0, 
>>> pWin=0x0, pClient=0x115e11c00) at xkbEvents.c:514
>>> 
>>> Shouldn't the bell percent set by 'xset' be multiplied by the volume passed 
>>> to XBell?  From XBell(3):
>>> 
>>> """
>>>  The XBell function rings the bell on the keyboard on the specified 
>>> display, if possible.  The specified
>>>  volume is relative to the base volume for the keyboard.  If the value 
>>> for the percent argument is not in
>>>  the range -100 to 100 inclusive, a BadValue error results.  The volume 
>>> at which the bell rings when the
>>>  percent argument is nonnegative is:
>>> 
>>> base - [(base * percent) / 100] + percent
>>> 
>>>  The volume at which the bell rings when the percent argument is 
>>> negative is:
>>> 
>>> base + [(base * percent) / 100]
>>> """
>>> 
>>> --Jeremy
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic 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: keyboard bell woes (ignores xset)

[Jeremy Huddleston]

Alright, well I opened https://bugs.freedesktop.org/show_bug.cgi?id=27118 for 
whoever wants to fix it...

Thanks, Peter.

On Mar 16, 2010, at 16:52, Peter Hutterer wrote:

> On Tue, Mar 16, 2010 at 04:37:31PM -0700, Jeremy Huddleston wrote:
>> I started looking into this because a user reported that XQuartz was still
>> beeping in his xterm even though he uses 'xset -b' ... it turns out that
>> xterm is using XkbBell() rather than XBell().  Even with 'xset -b', the
>> audible bell is still calling DDXRingBell() with volume = 50...
>> 
>> I made a reduced test case that does:
>> 
>> XBell(dpy, 0);// No beep with 'xset -b'
>> XkbBell(dpy, 0, 0, None); // Beep with vol=50 with 'xset -b'
>> 
>> shouldn't these be the same?
> 
> I think so. This may be some wierd interaction between core and XKB with the
> bell feedback classes though, where XKB slips through the cracks because on
> some device the base is still on the default. No idea on the details though.
> 
> Cheers,
>  Peter
> 
>> On Mar 16, 2010, at 15:30, Peter Hutterer wrote:
>> 
>>> On Tue, Mar 16, 2010 at 01:12:54PM -0700, Jeremy Huddleston wrote:
>>>> Actually, as I read this again, I noticed that it is behaving as per the 
>>>> spec:
>>>> 
>>>> XBell(dpy, 100) with base = 0:
>>>> base - [(base * percent) / 100] + percent = 0 - 0 + 100 = 100
>>>> 
>>>> XBell(dpy, 100) with base = 100:
>>>> base - [(base * percent) / 100] + percent = 100 - 100 + 100 = 100
>>>> 
>>>> So... this just seems a bit deceptive... if 'xset -b' is supposed to mute
>>>> the keyboard bell, why was XBell() designed to work around this?
>>> 
>>> I think you need to ask the question the other way round - why does 
>>> xset -b provide a functionality that XBell() can route around. I'm pretty
>>> sure XBell() was there first :)
>>> 
>>> Looks like to really disable the bell for core requests you need to call
>>> XkbSetControls() with the XkbAudibleBellMask. That way it can only be
>>> overridden by a forced XkbBell() request, not by any core requests.
>>> xset at this point doesn't do xkb but I don't se why it couldn't.
>>> 
>>> Cheers,
>>> Peter
>>> 
>>> 
>>>> On Mar 16, 2010, at 11:47, Jeremy Huddleston wrote:
>>>> 
>>>>> I turn off the bell using 'xset -b' :
>>>>> ~ $ xset -q | grep bell
>>>>> bell percent:  0bell pitch:  400bell duration:  100
>>>>> 
>>>>> but when I do XBell(dpy, 100), the bell still rings at volume 100.
>>>>> 
>>>>> #0  DDXRingBell (volume=100, pitch=400, duration=100) at quartzAudio.c:223
>>>>> #1  0x000100138ba2 in CoreKeyboardBell (volume=100, pDev=0x115b708e0, 
>>>>> arg=0x115b71100, something=0) at devices.c:498
>>>>> #2  0x000100105114 in XkbHandleBell (force=0 '\0', eventOnly=0 '\0', 
>>>>> kbd=0x115b708e0, percent=100 'd', pCtrl=0x115b71100, class=0 '\0', 
>>>>> name=0, pWin=0x0, pClient=0x115e11c00) at xkbEvents.c:514
>>>>> 
>>>>> Shouldn't the bell percent set by 'xset' be multiplied by the volume 
>>>>> passed to XBell?  From XBell(3):
>>>>> 
>>>>> """
>>>>> The XBell function rings the bell on the keyboard on the specified 
>>>>> display, if possible.  The specified
>>>>> volume is relative to the base volume for the keyboard.  If the value 
>>>>> for the percent argument is not in
>>>>> the range -100 to 100 inclusive, a BadValue error results.  The 
>>>>> volume at which the bell rings when the
>>>>> percent argument is nonnegative is:
>>>>> 
>>>>>base - [(base * percent) / 100] + percent
>>>>> 
>>>>> The volume at which the bell rings when the percent argument is 
>>>>> negative is:
>>>>> 
>>>>>base + [(base * percent) / 100]
>>>>> """
>>>>> 
>>>>> --Jeremy
>>> 
>>> ___
>>> 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



smime.p7s
Description: S/MIME cryptographic 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

People-friendly opcodes

[Jeremy Huddleston]

How does one ensure that X Errors report human readable text versions of major 
/ minor opcodes?

ie, how do I make sure that something like this is reported:

Major opcode of failed request:  145 (MY-EXTENSION)
Minor opcode of failed request:  8 (MyExtDoSomething   )

rather than:

Major opcode of failed request:  145
Minor opcode of failed request:  8




smime.p7s
Description: S/MIME cryptographic 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 RFC] XQuartz: Constrain the pointer to the updated display bounds on display reconfigure.

[Jeremy Huddleston]

Currently on 1.7 and 1.8, when OSX's display configuration changes, the server 
is left in a state where input pointer events get clipped to the old display 
region.  This can be worked around by running 'xinput test pointer' after the 
reconfig.

I'm trying to figure out how to best solve this problem.  There are two places 
where this clipping is occuring.  First is based on the VCP's miPointer's 
limits.  The second is based on the VCP's sprite limits.

The following patch "fixes" the problem, but I'm sure there is a better way to 
handle this.  Please comment.

Thanks,
Jeremy



http://xquartz.macosforge.org/trac/ticket/346

Signed-off-by: Jeremy Huddleston 
---
 hw/xquartz/quartz.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/hw/xquartz/quartz.c b/hw/xquartz/quartz.c
index 3c04205..b29e60f 100644
--- a/hw/xquartz/quartz.c
+++ b/hw/xquartz/quartz.c
@@ -277,8 +277,16 @@ void QuartzUpdateScreens(void) {
 //pScreen->PaintWindowBackground (pRoot, &pRoot->borderClip,  
PW_BACKGROUND);
 miPaintWindow(pRoot, &pRoot->borderClip,  PW_BACKGROUND);
 
-//  TODO: This is a noop in 1.6 and nuked in master... we may need to do 
something else now to handle it
-//DefineInitialRootWindow(pRoot);
+/*  pointer events are clipped to old display 
region after display reconfiguration
+ * http://xquartz.macosforge.org/trac/ticket/346
+ */
+bounds.x1 = 0;
+bounds.x2 = width;
+bounds.y1 = 0;
+bounds.y2 = height;
+pScreen->ConstrainCursor(inputInfo.pointer, pScreen, &bounds);
+inputInfo.pointer->spriteInfo->sprite->physLimits = bounds;
+inputInfo.pointer->spriteInfo->sprite->hotLimits = bounds;
 
 DEBUG_LOG("Root Window: %dx%d @ (%d, %d) darwinMainScreen (%d, %d) xy (%d, 
%d) dixScreenOrigins (%d, %d)\n", width, height, x - sx, y - sy, 
darwinMainScreenX, darwinMainScreenY, x, y, dixScreenOrigins[pScreen->myNum].x, 
dixScreenOrigins[pScreen->myNum].y);
 
-- 
1.6.2



smime.p7s
Description: S/MIME cryptographic 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: [PULL] revert an XQuartz patch that doesn't seem to be needed any more

[Jeremy Huddleston]

On Mar 21, 2010, at 15:25, Keith Packard wrote:

> On Tue, 16 Mar 2010 11:44:49 -0700, Jeremy Huddleston 
>  wrote:
> 
>>  git://anongit.freedesktop.org/~jeremyhu/xserver master
> 
> There are a bunch of additional patches on that branch; were you
> planning on getting those merged to master before 1.8?

Yes.  I didn't realize you hadn't processed the earlier request yet.  Here's 
the current / updated pull request:


The following changes since commit 235fa5030428084368e5be57fca695647b7b79c4:
  Keith Packard (1):
Merge commit 'fa5103a02bd509e4a102afdad2ab26cb22210367'

are available in the git repository at:

  git://anongit.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (6):
  Revert "XQuartz: Explicitly pass a bellProc to make XBell() work again."
  XQuartz: GLX: Fix Availability for Tiger ppc workaround
  XQuartz: Minor cleanup
  XQuartz: xpbproxy: Cleanup xpbproxy threading
  XQuartz: pbproxy: Make standalone xpbproxy respect the launchd prefix
  XQuartz: Constrain the pointer to the updated display bounds on display 
reconfigure.

 hw/xquartz/GL/indirect.c   |2 +-
 hw/xquartz/X11Application.m|   25 +-
 hw/xquartz/pbproxy/Makefile.am |6 ++-
 hw/xquartz/pbproxy/app-main.m  |   12 +
 hw/xquartz/pbproxy/main.m  |   43 +
 hw/xquartz/pbproxy/pbproxy.h   |3 +-
 hw/xquartz/pbproxy/x-input.m   |  100 +---
 hw/xquartz/quartz.c|   27 +++
 hw/xquartz/quartzKeyboard.c|8 +---
 9 files changed, 106 insertions(+), 120 deletions(-)



smime.p7s
Description: S/MIME cryptographic 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

clang static analysis of xorg-server

[Jeremy Huddleston]

I ran the static analyzer on a build of the current git master of xorg-server.  
Here are the results:

http://people.freedesktop.org/~jeremyhu/clang/2010-03-22-1/

There are quite a number of hidden issues.  Would people find it useful to have 
this data part of tinderbox.x.org?  If so, I'll look into seeing how easily it 
would be to integrate clang into jhbuild.

--Jeremy



smime.p7s
Description: S/MIME cryptographic 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] GLX: Fix initialization of some glXDispSwap requests

[Jeremy Huddleston]

Found by the clang static analyzer

__glXDispSwap_DestroyPbuffer
__glXDispSwap_DestroyGLXPbufferSGIX
__glXDispSwap_ChangeDrawableAttributes
__glXDispSwap_ChangeDrawableAttributesSGIX

Signed-off-by: Jeremy Huddleston 
---
 glx/glxcmdsswap.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/glx/glxcmdsswap.c b/glx/glxcmdsswap.c
index f1c0ce6..c414dc8 100644
--- a/glx/glxcmdsswap.c
+++ b/glx/glxcmdsswap.c
@@ -354,7 +354,7 @@ int __glXDispSwap_CreateGLXPbufferSGIX(__GLXclientState 
*cl, GLbyte *pc)
 
 int __glXDispSwap_DestroyPbuffer(__GLXclientState *cl, GLbyte *pc)
 {
-xGLXDestroyPbufferReq *req = (xGLXDestroyPbufferReq *) req;
+xGLXDestroyPbufferReq *req = (xGLXDestroyPbufferReq *) pc;
 __GLX_DECLARE_SWAP_VARIABLES;
 
 __GLX_SWAP_INT(&req->pbuffer);
@@ -364,7 +364,7 @@ int __glXDispSwap_DestroyPbuffer(__GLXclientState *cl, 
GLbyte *pc)
 
 int __glXDispSwap_DestroyGLXPbufferSGIX(__GLXclientState *cl, GLbyte *pc)
 {
-xGLXDestroyGLXPbufferSGIXReq *req = (xGLXDestroyGLXPbufferSGIXReq *) req;
+xGLXDestroyGLXPbufferSGIXReq *req = (xGLXDestroyGLXPbufferSGIXReq *) pc;
 __GLX_DECLARE_SWAP_VARIABLES;
 
 __GLX_SWAP_INT(&req->pbuffer);
@@ -375,7 +375,7 @@ int __glXDispSwap_DestroyGLXPbufferSGIX(__GLXclientState 
*cl, GLbyte *pc)
 int __glXDispSwap_ChangeDrawableAttributes(__GLXclientState *cl, GLbyte *pc)
 {
 xGLXChangeDrawableAttributesReq *req =
-   (xGLXChangeDrawableAttributesReq *) req;
+   (xGLXChangeDrawableAttributesReq *) pc;
 __GLX_DECLARE_SWAP_VARIABLES;
 __GLX_DECLARE_SWAP_ARRAY_VARIABLES;
 CARD32 *attribs;
@@ -392,7 +392,7 @@ int 
__glXDispSwap_ChangeDrawableAttributesSGIX(__GLXclientState *cl,
   GLbyte *pc)
 {
 xGLXChangeDrawableAttributesSGIXReq *req =
-   (xGLXChangeDrawableAttributesSGIXReq *) req;
+   (xGLXChangeDrawableAttributesSGIXReq *) pc;
 __GLX_DECLARE_SWAP_VARIABLES;
 __GLX_DECLARE_SWAP_ARRAY_VARIABLES;
 CARD32 *attribs;
-- 
1.6.2




smime.p7s
Description: S/MIME cryptographic 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: clang static analysis of xorg-server

[Jeremy Huddleston]

I aree ... some of the "dead store" issues are more stylistic or future 
proofing.

The real ones we should consider are the logic errors... garbage assignment and 
null dereference.

Some of the errors seem outright bogus 
(http://people.freedesktop.org/~jeremyhu/clang/2010-03-22-1/report-K6CxIC.html#EndPath),
 so if you see any others like that, let me know.  I'm building the latest 
version of clang right now, and if those oddities are still present, I'll 
report them to the developers.





On Mar 22, 2010, at 10:25, Matthias Hopf wrote:

> On Mar 22, 10 09:58:59 -0700, Jeremy Huddleston wrote:
>> I ran the static analyzer on a build of the current git master of 
>> xorg-server.  Here are the results:
>> http://people.freedesktop.org/~jeremyhu/clang/2010-03-22-1/
>> There are quite a number of hidden issues.  Would people find it useful to 
>> have this data part of tinderbox.x.org?  If so, I'll look into seeing how 
>> easily it would be to integrate clang into jhbuild.
> 
> While 'rand is a poor random generator' and 'Dead assignment' are
> questionable, at least some of the NULL pointer accesses seem real.
> 
> It might be interesting to have this on tinderbox, however, there should
> be a possibility to mark false positives (like the use of rand() in not
> security critical code). Any ideas?
> 
> Thanks for the test
> 
> Matthias
> 
> -- 
> Matthias Hopf   ____   __
> Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__  m...@mshopf.de
> Phone +49-911-74053-715   __)  |_|  __)  |__  R & D   www.mshopf.de



smime.p7s
Description: S/MIME cryptographic 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] GLX: Fix initialization of some glXDispSwap requests

[Jeremy Huddleston]

On Mar 22, 2010, at 11:24, Ian Romanick wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Jeremy Huddleston wrote:
>> Found by the clang static analyzer
>> 
>> __glXDispSwap_DestroyPbuffer
>> __glXDispSwap_DestroyGLXPbufferSGIX
>> __glXDispSwap_ChangeDrawableAttributes
>> __glXDispSwap_ChangeDrawableAttributesSGIX
> 
> I finally got around to acking the same patch sent to the list back in
> December by Tomas Carnecky.  This *should* be in 1.8.

It's not.  It'll be in my next [PULL] request with your review.  I'll c-p it 
into 1.7-nom as well once that's done.

Thanks,
Jeremy




smime.p7s
Description: S/MIME cryptographic 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] Use arc4random instead of rand where available

[Jeremy Huddleston]

Mainly to shut up clang.  These are not security-sensitive uses of rand()

Signed-off-by: Jeremy Huddleston 
---
 configure.ac|2 +-
 dix/window.c|   18 ++
 exa/exa_glyphs.c|8 
 include/dix-config.h.in |3 +++
 4 files changed, 30 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index d379b3a..361f380 100644
--- a/configure.ac
+++ b/configure.ac
@@ -206,7 +206,7 @@ dnl Checks for library functions.
 AC_FUNC_VPRINTF
 AC_CHECK_FUNCS([geteuid getuid link memmove memset mkstemp strchr strrchr \
strtol getopt getopt_long vsnprintf walkcontext backtrace \
-   getisax getzoneid shmctl64 strcasestr ffs])
+   getisax getzoneid shmctl64 strcasestr ffs arc4random])
 AC_FUNC_ALLOCA
 dnl Old HAS_* names used in os/*.c.
 AC_CHECK_FUNC([getdtablesize],
diff --git a/dix/window.c b/dix/window.c
index c7201df..303cf4d 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -3189,10 +3189,17 @@ dixSaveScreens(ClientPtr client, int on, int mode)
if (logoScreenSaver)
(*pWin->drawable.pScreen->ClearToBackground)(pWin, 0, 0, 0, 
0, FALSE);
 #endif
+#ifdef HAVE_ARC4RANDOM
+   (*pWin->drawable.pScreen->MoveWindow)(pWin,
+  (short)(-(arc4random() % RANDOM_WIDTH)),
+  (short)(-(arc4random() % RANDOM_WIDTH)),
+  pWin->nextSib, VTMove);
+#else
(*pWin->drawable.pScreen->MoveWindow)(pWin,
   (short)(-(rand() % RANDOM_WIDTH)),
   (short)(-(rand() % RANDOM_WIDTH)),
   pWin->nextSib, VTMove);
+#endif
 #ifndef NOLOGOHACK
if (logoScreenSaver)
DrawLogo(pWin);
@@ -3732,7 +3739,11 @@ DrawLogo(WindowPtr pWin)
 if (!pGC)
return;
 
+#ifdef HAVE_ARC4RANDOM 
+if ((arc4random() % 100) <= 17) /* make the probability for white fairly 
low */
+#else
 if ((rand() % 100) <= 17) /* make the probability for white fairly low */
+#endif
fore[0].val = pScreen->whitePixel;
 else
fore[0].val = pScreen->blackPixel;
@@ -3776,10 +3787,17 @@ DrawLogo(WindowPtr pWin)
 size = width;
 if (height < width)
 size = height;
+#ifdef HAVE_ARC4RANDOM
+size = RANDOM_WIDTH + arc4random() % (size - RANDOM_WIDTH);
+size &= ~1;
+x += arc4random() % (width - size);
+y += arc4random() % (height - size);
+#else
 size = RANDOM_WIDTH + rand() % (size - RANDOM_WIDTH);
 size &= ~1;
 x += rand() % (width - size);
 y += rand() % (height - size);
+#endif
 
 /*
  * Draw what will be the thin strokes.
diff --git a/exa/exa_glyphs.c b/exa/exa_glyphs.c
index fd14e9b..8c9e591 100644
--- a/exa/exa_glyphs.c
+++ b/exa/exa_glyphs.c
@@ -223,7 +223,11 @@ exaRealizeGlyphCaches(ScreenPtrpScreen,
for (j = 0; j < cache->hashSize; j++)
cache->hashEntries[j] = -1;

+#ifdef HAVE_ARC4RANDOM 
+   cache->evictionPosition = arc4random() % cache->size;
+#else
cache->evictionPosition = rand() % cache->size;
+#endif
 }
 
 /* Each cache references the picture individually */
@@ -504,7 +508,11 @@ exaGlyphCacheBufferGlyph(ScreenPtr pScreen,
exaGlyphCacheHashInsert(cache, pGlyph, pos);
 
/* And pick a new eviction position */
+#ifdef HAVE_ARC4RANDOM 
+   cache->evictionPosition = arc4random() % cache->size;
+#else
cache->evictionPosition = rand() % cache->size;
+#endif
}
 
exaGlyphCacheUploadGlyph(pScreen, cache, x, y, pGlyph);
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index 058c8fd..2ded353 100644
--- a/include/dix-config.h.in
+++ b/include/dix-config.h.in
@@ -54,6 +54,9 @@
 /* Support XDM-AUTH*-1 */
 #undef HASXDMAUTH
 
+/* Define to 1 if you have the `arc4random' function. */
+#undef HAVE_ARC4RANDOM
+
 /* Define to 1 if you have the `getdtablesize' function. */
 #undef HAS_GETDTABLESIZE
 
-- 
1.6.2




smime.p7s
Description: S/MIME cryptographic 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] Use arc4random instead of rand where available

[Jeremy Huddleston]

I was thinking smaller would be more "acceptable" ... but I too would  
prefer something like OsRandom() in os/utils.c ... is that something  
that should be exported to drivers or just internal to the server?


On Mar 22, 2010, at 13:51, Tiago Vignatti wrote:


Jeremy Huddleston wrote:
Mainly to shut up clang.  These are not security-sensitive uses of  
rand()

Signed-off-by: Jeremy Huddleston 
---
configure.ac|2 +-
dix/window.c|   18 ++
exa/exa_glyphs.c|8 
include/dix-config.h.in |3 +++
4 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index d379b3a..361f380 100644
--- a/configure.ac
+++ b/configure.ac
@@ -206,7 +206,7 @@ dnl Checks for library functions.
AC_FUNC_VPRINTF
AC_CHECK_FUNCS([geteuid getuid link memmove memset mkstemp strchr  
strrchr \

strtol getopt getopt_long vsnprintf walkcontext backtrace \
-   getisax getzoneid shmctl64 strcasestr ffs])
+   getisax getzoneid shmctl64 strcasestr ffs arc4random])
AC_FUNC_ALLOCA
dnl Old HAS_* names used in os/*.c.
AC_CHECK_FUNC([getdtablesize],
diff --git a/dix/window.c b/dix/window.c
index c7201df..303cf4d 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -3189,10 +3189,17 @@ dixSaveScreens(ClientPtr client, int on,  
int mode)

if (logoScreenSaver)
		(*pWin->drawable.pScreen->ClearToBackground)(pWin, 0, 0, 0,  
0, FALSE);

#endif
+#ifdef HAVE_ARC4RANDOM
+   (*pWin->drawable.pScreen->MoveWindow)(pWin,
+  (short)(-(arc4random() % RANDOM_WIDTH)),
+  (short)(-(arc4random() % RANDOM_WIDTH)),
+  pWin->nextSib, VTMove);
+#else
(*pWin->drawable.pScreen->MoveWindow)(pWin,
   (short)(-(rand() % RANDOM_WIDTH)),
   (short)(-(rand() % RANDOM_WIDTH)),
   pWin->nextSib, VTMove);
+#endif
#ifndef NOLOGOHACK
if (logoScreenSaver)
DrawLogo(pWin);
@@ -3732,7 +3739,11 @@ DrawLogo(WindowPtr pWin)
if (!pGC)
return;
+#ifdef HAVE_ARC4RANDOM +if ((arc4random() % 100) <= 17) /*  
make the probability for white fairly low */

+#else
if ((rand() % 100) <= 17) /* make the probability for white  
fairly low */

+#endif
fore[0].val = pScreen->whitePixel;
else
fore[0].val = pScreen->blackPixel;
@@ -3776,10 +3787,17 @@ DrawLogo(WindowPtr pWin)
size = width;
if (height < width)
 size = height;
+#ifdef HAVE_ARC4RANDOM
+size = RANDOM_WIDTH + arc4random() % (size - RANDOM_WIDTH);
+size &= ~1;
+x += arc4random() % (width - size);
+y += arc4random() % (height - size);
+#else
size = RANDOM_WIDTH + rand() % (size - RANDOM_WIDTH);
size &= ~1;
x += rand() % (width - size);
y += rand() % (height - size);
+#endif
 /*
 * Draw what will be the thin strokes.
diff --git a/exa/exa_glyphs.c b/exa/exa_glyphs.c
index fd14e9b..8c9e591 100644
--- a/exa/exa_glyphs.c
+++ b/exa/exa_glyphs.c
@@ -223,7 +223,11 @@ exaRealizeGlyphCaches(ScreenPtrpScreen,
for (j = 0; j < cache->hashSize; j++)
cache->hashEntries[j] = -1;

+#ifdef HAVE_ARC4RANDOM +	cache->evictionPosition = arc4random() %  
cache->size;

+#else
cache->evictionPosition = rand() % cache->size;
+#endif
}
 /* Each cache references the picture individually */
@@ -504,7 +508,11 @@ exaGlyphCacheBufferGlyph(ScreenPtr  
pScreen,

exaGlyphCacheHashInsert(cache, pGlyph, pos);
/* And pick a new eviction position */
+#ifdef HAVE_ARC4RANDOM +	cache->evictionPosition =  
arc4random() % cache->size;

+#else
cache->evictionPosition = rand() % cache->size;
+#endif
}
exaGlyphCacheUploadGlyph(pScreen, cache, x, y, pGlyph);
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index 058c8fd..2ded353 100644
--- a/include/dix-config.h.in
+++ b/include/dix-config.h.in
@@ -54,6 +54,9 @@
/* Support XDM-AUTH*-1 */
#undef HASXDMAUTH
+/* Define to 1 if you have the `arc4random' function. */
+#undef HAVE_ARC4RANDOM
+
/* Define to 1 if you have the `getdtablesize' function. */
#undef HAS_GETDTABLESIZE



a macro on some internal header file would be much nicer, isn't  
Jeremy?


 Tiago




smime.p7s
Description: S/MIME cryptographic 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: clang static analysis of xorg-server

[Jeremy Huddleston]

Actually, it was a valid error.  The assignment was doing |= rather  
than =, and the current value was garbage.




On Mar 22, 2010, at 14:08, Alan Coopersmith wrote:


Jeremy Huddleston wrote:
I aree ... some of the "dead store" issues are more stylistic or  
future proofing.


The real ones we should consider are the logic errors... garbage  
assignment and null dereference.


Some of the errors seem outright bogus (http://people.freedesktop.org/~jeremyhu/clang/2010-03-22-1/report-K6CxIC.html#EndPath 
), so if you see any others like that, let me know.  I'm building  
the latest version of clang right now, and if those oddities are  
still present, I'll report them to the developers.


That might be pointing out that the definition of  
XkbControlsEnabledMask is
technically undefined on a 32-bit system, since it should be (1UL <<  
31) not

(1L << 31) - we've gotten that error in various tools before.

--
-Alan Coopersmith-   alan.coopersm...@sun.com
 Oracle Solaris Platform Engineering: X Window System





smime.p7s
Description: S/MIME cryptographic 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] Use arc4random instead of rand where available

[Jeremy Huddleston]

On Mar 23, 2010, at 06:48, Mark Kettenis wrote:

> Guys, if you ask me, introducing all this additional complecity just
> to placate a static analysis tool is starting to get a bit silly.
> 
> How about just putting a comment in the code that the usage of rand()
> is not security related at all and therefore perfectly fine?

Yeah, I agree... if someone at some point in time drops rand(), we may need to 
do this, but for now it really is "close enough"

--Jeremy



smime.p7s
Description: S/MIME cryptographic 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] XKB: Fix garbage initialization

[Jeremy Huddleston]

XkbEnableDisableControls set extra garbage bits on the xkbControlsNotify
changedControls mask because it was uninitialized on the stack.

Found by clang

Signed-off-by: Jeremy Huddleston 
---
 xkb/xkbUtils.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index 5b317c9..e287997 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -753,7 +753,7 @@ XkbSrvLedInfoPtrsli;
 if (cause!=NULL) {
xkbControlsNotify cn;
cn.numGroups= ctrls->num_groups;
-   cn.changedControls|= XkbControlsEnabledMask;
+   cn.changedControls= XkbControlsEnabledMask;
cn.enabledControls= ctrls->enabled_ctrls;
cn.enabledControlChanges= (ctrls->enabled_ctrls^old);
cn.keycode= cause->kc;
-- 
1.6.2



smime.p7s
Description: S/MIME cryptographic 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: [xdm PATCH 1/3] Don't remove the pid file from xdm child processes

[Jeremy Huddleston]

Reviewed-by: Jeremy Huddleston 

On Mar 23, 2010, at 11:40, Julien Cristau wrote:


The parent xdm process registers RemovePid with atexit(), which means
that any child exit would trigger the (wrong) removal of the pidfile.
So in RemovePid, don't do anything if we're not the parent xdm  
process.


Signed-off-by: Julien Cristau 
---
dm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/dm.c b/dm.c
index 55fb24e..da18800 100644
--- a/dm.c
+++ b/dm.c
@@ -969,6 +969,9 @@ StorePid (void)
static void
RemovePid (void)
{
+if (parent_pid != getpid())
+   return;
+
Debug ("unlinking process ID file %s\n", pidFile);
if (unlink (pidFile))
if (errno != ENOENT)
--
1.7.0

___
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




smime.p7s
Description: S/MIME cryptographic 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: [xdm PATCH 3/3] xdmcp: use getnameinfo() to get a name from a struct sockaddr

[Jeremy Huddleston]

Reviewed-by: Jeremy Huddleston 

On Mar 23, 2010, at 11:40, Julien Cristau wrote:


xdm uses gethostbyaddr and inet_ntop to get the display name.  This
fails for e.g. link-local ipv6 addresses.  Use getnameinfo instead,
which gives us what we want.

Signed-off-by: Julien Cristau 
---
I'm not sure this is correct, I don't quite understand where the
connectionType/connectionAddress are coming from, and why/if they  
should
be used instead of the originalAddress.  But I tested that I could  
get a

login window with 'X -query fe80::dead:beff:feef:0123%eth0', which
didn't work before because the interface was lost when going from
address to display name.

xdmcp.c |   43 +++
1 files changed, 15 insertions(+), 28 deletions(-)

diff --git a/xdmcp.c b/xdmcp.c
index 66a5e0f..640d845 100644
--- a/xdmcp.c
+++ b/xdmcp.c
@@ -516,6 +516,7 @@ NetworkAddressToName(
CARD16  connectionType,
ARRAY8Ptr   connectionAddress,
struct sockaddr   *originalAddress,
+int addrlen,
CARD16  displayNumber)
{
switch (connectionType)
@@ -526,39 +527,34 @@ NetworkAddressToName(
{
CARD8   *data;
struct hostent  *hostent;
-   char*hostname = NULL;
+   charhostname[NI_MAXHOST];
char*name;
char*localhost;
int  multiHomed = 0;
struct addrinfo  hints, *ai = NULL, *nai;
int  type;
+   int  rc;

-   if (connectionType == FamilyInternet6)
-   type = AF_INET6;
-   else
-   type = AF_INET;
+   rc = getnameinfo(originalAddress, addrlen, hostname, NI_MAXHOST,
+NULL, 0, 0);

-   data = connectionAddress->data;
-   hostent = gethostbyaddr ((char *)data,
-connectionAddress->length, type);
-   if (hostent) {
+   if (!rc) {
if (sourceAddress) {
bzero(&hints, sizeof(hints));
hints.ai_flags = AI_CANONNAME;
-   if (getaddrinfo(hostent->h_name, NULL, &hints, &ai) == 0) {
-   hostname = ai->ai_canonname;
+   if (getaddrinfo(hostname, NULL, &hints, &ai) == 0) {
for (nai = ai->ai_next; nai!=NULL; nai=nai->ai_next) {
if ((ai->ai_protocol == nai->ai_protocol) &&
-   (ai->ai_addrlen == nai->ai_addrlen) &&
-   (memcmp(ai->ai_addr,nai->ai_addr,
-   ai->ai_addrlen) != 0) ) {
+   (ai->ai_addrlen == nai->ai_addrlen) &&
+   (memcmp(ai->ai_addr, nai->ai_addr,
+   ai->ai_addrlen) != 0) ) {
multiHomed = 1;
}
}
}
-   } else {
-   hostname = hostent->h_name;
}
+   } else {
+   hostname[0] = '\0';
}

localhost = localHostname ();
@@ -566,7 +562,7 @@ NetworkAddressToName(
/*
 * protect against bogus host names
 */
-   if (hostname && hostname[0] && (hostname[0] != '.')
+   if (hostname[0] && (hostname[0] != '.')
&& !multiHomed)
{
if (!strcmp (localhost, hostname))
@@ -615,17 +611,7 @@ NetworkAddressToName(
freeaddrinfo(ai);
return NULL;
}
-   if (multiHomed) {
-   if (connectionType == FamilyInternet) {
-   data = (CARD8 *)
- &((struct sockaddr_in *)originalAddress)->
- sin_addr;
-   } else {
-   data = (CARD8 *)
- &((struct sockaddr_in6 *)originalAddress)->sin6_addr;
-   }
-   }
-   if (inet_ntop(type, data, name, INET6_ADDRSTRLEN) == NULL) {
+		if (getnameinfo(originalAddress, addrlen, name, INET6_ADDRSTRLEN,  
NULL, 0, NI_NUMERICHOST) != 0) {

free(name);
if (ai)
freeaddrinfo(ai);
@@ -1200,6 +1186,7 @@ manage (
name = NetworkAddressToName (pdpy->connectionType,
 &pdpy->connectionAddress,
 from,
+fromlen,
   

[PULL] 2 minor patches

[Jeremy Huddleston]

Workaround some silly input layouts on OSX and remove a redundancy in GLX.

The following changes since commit 579715f830fbbca9e1ecb17dc18176132f5969e7:
  Rami Ylimaki (1):
os: Prevent backtrace from being stopped in noreturn functions.

are available in the git repository at:

  git://anongit.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (2):
  XQuartz: Workaround weird key data reported on some layouts
  GLX: Remove a redundant initialization

 glx/indirect_dispatch.c |2 --
 hw/xquartz/quartzKeyboard.c |5 -
 2 files changed, 4 insertions(+), 3 deletions(-)



smime.p7s
Description: S/MIME cryptographic 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 app-xedit 2/4] xprint: remove Xedit-xprint resource file

[Jeremy Huddleston]

On Mar 26, 2010, at 05:27, Gaetan Nadon wrote:

> Remove configuration regarding xprint support
> 
> Signed-off-by: Gaetan Nadon 
> ---
> Makefile.am |2 -
> app-defaults/Xedit  |  468 +++
> app-defaults/Xedit-noxprint |  468 ---
> app-defaults/Xedit-xprint   |  565 ---
> configure.ac|3 -
> 5 files changed, 468 insertions(+), 1038 deletions(-)
> create mode 100644 app-defaults/Xedit
> delete mode 100644 app-defaults/Xedit-noxprint
> delete mode 100644 app-defaults/Xedit-xprint
> 
> diff --git a/Makefile.am b/Makefile.am
> index e4c4193..9252869 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -188,8 +188,6 @@ appman_PRE = xedit.man
> 
> EXTRA_DIST = \
>   app-defaults/Xedit-color \
> - app-defaults/Xedit-xprint \
> - app-defaults/Xedit-noxprint \
>   app-defaults/Xedit-sample \
>   lisp/README \
>   lisp/TODO \


Looks like you're missing a
+ app-defaults/Xedit

to match this next hunk:


> diff --git a/app-defaults/Xedit b/app-defaults/Xedit
> new file mode 100644
> index 000..b626bf3
> --- /dev/null
> +++ b/app-defaults/Xedit






smime.p7s
Description: S/MIME cryptographic 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 app-xedit 4/4] xprint: remove conditionally defined related C code

[Jeremy Huddleston]

Reviewed-by: Jeremy Huddleston 

On Mar 26, 2010, at 05:27, Gaetan Nadon wrote:

> Signed-off-by: Gaetan Nadon 
> ---
> commands.c |  114 
> xedit.c|   24 -
> xedit.h|6 ---
> 3 files changed, 0 insertions(+), 144 deletions(-)
> 
> diff --git a/commands.c b/commands.c
> index 2947dda..90a64ec 100644
> --- a/commands.c
> +++ b/commands.c
> @@ -29,10 +29,6 @@
> #include 
> #include 
> #include "xedit.h"
> -#ifdef INCLUDE_XPRINT_SUPPORT
> -#include "printdialog.h"
> -#include "print.h"
> -#endif /* INCLUDE_XPRINT_SUPPORT */
> #ifdef CRAY
> #include 
> #endif
> @@ -54,12 +50,6 @@
> #define Assertion(expr, msg) { if (!(expr)) { Error msg } }
> #define Log(x)   { if (True) printf x; }
> 
> -#ifdef INCLUDE_XPRINT_SUPPORT
> -static Widget printdialog_shell = NULL;
> -static Widget printdialog   = NULL;
> -static char   printJobNameBuffer[PATH_MAX+256];
> -#endif /* INCLUDE_XPRINT_SUPPORT */
> -
> void ResetSourceChanged(xedit_flist_item*);
> static void ResetDC(Widget, XtPointer, XtPointer);
> 
> @@ -523,110 +513,6 @@ ReallyDoLoad(char *name, char *filename)
> return (True);
> }
> 
> -#ifdef INCLUDE_XPRINT_SUPPORT
> -static void
> -printshellDestroyXtProc(Widget w, XtPointer client_data, XtPointer callData)
> -{
> -XawPrintDialogClosePrinterConnection(printdialog, False);
> -}
> -
> -static void
> -printOKXtProc(Widget w, XtPointer client_data, XtPointer callData)
> -{
> -XawPrintDialogCallbackStruct *pdcs = (XawPrintDialogCallbackStruct 
> *)callData;
> -Cardinal  n;
> -Arg   args[2];
> -Widgettextsource;
> -
> -Log(("printOKXtProc: OK.\n"));
> -
> -/* Get TextSource object */
> -n = 0;
> -XtSetArg(args[n], XtNtextSource, &textsource); n++;
> -XtGetValues(textwindow, args, n);
> -
> -Assertion(textsource != NULL, (("printOKXtProc: textsource == 
> NULL.\n")));
> -   
> -/* ||printJobNameBuffer| must live as long the print job prints
> - * because it is used for the job title AND the page headers... */
> -sprintf(printJobNameBuffer, "Xedit print job");
> -
> -DoPrintTextSource("Xedit",
> -  textsource, topwindow,
> -  pdcs->pdpy, pdcs->pcontext, pdcs->colorspace,
> -  printshellDestroyXtProc,
> -  printJobNameBuffer,
> -  pdcs->printToFile?pdcs->printToFileName:NULL);
> -
> -XtPopdown(printdialog_shell);
> -}
> -
> -static void
> -printCancelXtProc(Widget w, XtPointer client_data, XtPointer callData)
> -{
> -Log(("printCancelXtProc: cancel.\n"));
> -XtPopdown(printdialog_shell);
> -
> -Log(("destroying print dialog shell...\n"));
> -XtDestroyWidget(printdialog_shell);
> -printdialog_shell = NULL;
> -printdialog   = NULL;
> -Log(("... done\n"));
> -}
> -
> -
> -/*ARGSUSED*/
> -void
> -PrintFile(Widget w, XEvent *event, String *params, Cardinal *num_params)
> -{
> -DoPrint(w, NULL, NULL);
> -}
> -
> -/*ARGSUSED*/
> -void
> -DoPrint(Widget w, XtPointer client_data, XtPointer call_data)
> -{
> -  Dimension   width, height;
> -  Positionx, y;
> -  Widget  parent = topwindow;
> -  Log(("print!\n"));
> -  
> -  if (!printdialog) {
> -int n;
> -Arg args[20];
> -
> -n = 0;
> -XtSetArg(args[n], XtNallowShellResize, True); n++;
> -printdialog_shell = XtCreatePopupShell("printdialogshell",
> -   transientShellWidgetClass,
> -   topwindow, args, n);
> -n = 0;
> -printdialog = XtCreateManagedWidget("printdialog", 
> printDialogWidgetClass,
> -printdialog_shell, args, n);
> -XtAddCallback(printdialog, XawNOkCallback, printOKXtProc, NULL);
> -XtAddCallback(printdialog, XawNCancelCallback, printCancelXtProc, NULL);
> -
> -XtRealizeWidget(printdialog_shell);
> -  }
> -
> -  /* Center dialog */
> -  XtVaGetValues(printdialog_shell,
> -  XtNwidth,  &width,
> -  XtNheight, &height,
> -  NULL);
> -
> -  x = (Position)(XWidthOfScreen( XtScreen(parent)) - width)  / 2;
> -  y = (Position)(XHeightOfScreen(XtScreen(parent)) - height) / 3;
> -
> -  XtVaSetValues(printdialog_shell,
> -  XtNx, x,
> -  XtNy, y,

Re: [PATCH app-xedit 1/4] config: remove dependency on xaw8

[Jeremy Huddleston]

Reviewed-by: Jeremy Huddleston 

On Mar 26, 2010, at 05:27, Gaetan Nadon wrote:

> Remove configure option --enable-xprint
> Remove AM conditional USE_XPRINT
> 
> Signed-off-by: Gaetan Nadon 
> ---
> Makefile.am  |   11 ---
> configure.ac |   15 +++
> 2 files changed, 3 insertions(+), 23 deletions(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index ecb138c..e4c4193 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -127,17 +127,6 @@ if NEED_STRCASECMP
> xedit_SOURCES += strcasecmp.c
> endif
> 
> -if USE_XPRINT
> -xedit_CFLAGS += -DINCLUDE_XPRINT_SUPPORT
> -
> -xedit_SOURCES += \
> -print.c \
> -printdialog.c \
> -printdialog.h \
> -printdialogprivates.h \
> -print.h
> -endif
> -
> # lisp/lsp
> lisp_lsp_DEPENDENCIES = liblisp.a libre.a libmp.a
> lisp_lsp_CFLAGS = $(CWARNFLAGS) -I$(top_srcdir)/lisp/re 
> -I$(top_srcdir)/lisp/mp -DLISP -DLISPDIR=\"@lisp...@\" -D_BSD_SOURCE
> diff --git a/configure.ac b/configure.ac
> index 01c067b..a2b0eb7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -40,18 +40,9 @@ AC_PROG_INSTALL
> AC_PROG_RANLIB
> PKG_PROG_PKG_CONFIG
> 
> -AC_ARG_ENABLE(xprint,
> -   AS_HELP_STRING([--enable-xprint],
> -  [Compile with xprint support (default: disabled)]),
> -   [enable_xprint=$enableval], [enable_xprint=no])
> -AM_CONDITIONAL(USE_XPRINT, test x$enable_xprint = xyes)
> -if test x$enable_xprint = xyes; then
> -   PKG_CHECK_MODULES(PKGDEPS, xprintutil xp xaw8)
> -   print_noprint=xprint
> -else
> -   PKG_CHECK_MODULES(PKGDEPS, xaw7)
> -   print_noprint=noxprint
> -fi
> +PKG_CHECK_MODULES(PKGDEPS, xaw7)
> +print_noprint=noxprint
> +
> AC_CONFIG_LINKS([app-defaults/Xedit:app-defaults/Xedit-$print_noprint])
> 
> AC_ARG_WITH(lispdir, AS_HELP_STRING([--with-lispdir=PATH],
> -- 
> 1.6.0.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



smime.p7s
Description: S/MIME cryptographic 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 app-xedit 2/4] xprint: remove Xedit-xprint resource file

[Jeremy Huddleston]

On Mar 26, 2010, at 14:07, Gaetan Nadon wrote:

> EXTRA_DIST = \
>   app-defaults/Xedit-color \
> - app-defaults/Xedit-xprint \
> - app-defaults/Xedit-noxprint \
> + app-defaults/Xedit \
>   app-defaults/Xedit-sample \
>   lisp/README \
>   lisp/TODO \

With the above change,
Reviewed-by: Jeremy Huddleston 

> I was kind of expecting to be told that the xprint feature should not be
> removed.

I say good riddance.  There's no reason to keep it in our apps when our 
libraries and server don't even support it any more.

--Jeremy



smime.p7s
Description: S/MIME cryptographic 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 app-xdpyinfo 1/3] config: remove xprint feature which is obsolete

[Jeremy Huddleston]

Series Reviewed-by: Jeremy Huddleston 

On Mar 26, 2010, at 17:06, Gaetan Nadon wrote:

> Signed-off-by: Gaetan Nadon 
> ---
> configure.ac |   12 
> 1 files changed, 0 insertions(+), 12 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 8de5877..ac3f184 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -135,18 +135,6 @@ else
>   echo "without dmx"
> fi
> 
> -AC_ARG_WITH(xprint, AC_HELP_STRING([--without-xprint],[Disable xprint 
> support.]), 
> - [USE_XPRINT="$withval"], [USE_XPRINT="yes"])
> -if test "x$USE_XPRINT" != "xno" ; then
> - PKG_CHECK_MODULES(DPY_XPRINT, xp, 
> - [SAVE_CPPFLAGS="$CPPFLAGS"
> - CPPFLAGS="$CPPFLAGS $DPY_XPRINT_CFLAGS $DPY_X11_CFLAGS"
> - AC_CHECK_HEADERS([X11/extensions/Print.h],,,[#include 
> ])
> - CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"])
> -else
> - echo "without xprint"
> -fi
> -
> PKG_CHECK_MODULES(DPY_XTST, xtst, 
>   [SAVE_CPPFLAGS="$CPPFLAGS"
>   CPPFLAGS="$CPPFLAGS $DPY_XTST_CFLAGS $DPY_X11_CFLAGS"
> -- 
> 1.6.0.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



smime.p7s
Description: S/MIME cryptographic 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 libXfont] config: remove protection for AS_HELP_STRING for old autoconf

[Jeremy Huddleston]

I'm confused... what makes it 2.60 instead of 2.58?

On Mar 27, 2010, at 15:01, Gaetan Nadon wrote:

> No longer needed as modules will not configure with 2.57.
> AS_HELP_STRING was introduced in 2.58. The minimum level
> is now 2.60.
> 
> Signed-off-by: Gaetan Nadon 
> ---
> configure.ac |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index c75a041..852124a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -20,7 +20,7 @@ dnl  PERFORMANCE OF THIS SOFTWARE.
> dnl
> dnl Process this file with autoconf to create configure.
> 
> -AC_PREREQ([2.57])
> +AC_PREREQ([2.60])
> 
> AC_INIT([libXfont],
>   1.4.1,
> @@ -57,8 +57,6 @@ PKG_PROG_PKG_CONFIG
> AC_CHECK_HEADERS([endian.h poll.h sys/poll.h])
> AC_CHECK_FUNCS([poll])
> 
> -m4_ifdef([AS_HELP_STRING], , [m4_define([AS_HELP_STRING], 
> m4_defn([AC_HELP_STRING]))])
> -
> #
> # select libraries to include
> #
> -- 
> 1.6.0.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



smime.p7s
Description: S/MIME cryptographic 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

[PULL (updated)] 3 patches from XQuartz

[Jeremy Huddleston]

THe main one is for the crash reporter.  Without this, server crashes don't
generate a crash report, and X11.app just seems to quit "for no reason"

The following changes since commit 579715f830fbbca9e1ecb17dc18176132f5969e7:
  Rami Ylimaki (1):
os: Prevent backtrace from being stopped in noreturn functions.

are available in the git repository at:

  git://anongit.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (3):
  XQuartz: Workaround weird key data reported on some layouts
  GLX: Remove a redundant initialization
  darwin: Generate crash reports on FatalError()

 glx/indirect_dispatch.c   |2 --
 hw/xquartz/GL/capabilities.c  |3 +--
 hw/xquartz/darwin.c   |   10 +++---
 hw/xquartz/mach-startup/bundle-main.c |   11 ++-
 hw/xquartz/quartzKeyboard.c   |5 -
 os/log.c  |9 +
 6 files changed, 23 insertions(+), 17 deletions(-)




smime.p7s
Description: S/MIME cryptographic 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] OS: Add some noreturn and printf compiler attributes where appropriate

[Jeremy Huddleston]

Signed-off-by: Jeremy Huddleston 
---
 include/os.h |   28 +---
 os/log.c |4 +---
 2 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/include/os.h b/include/os.h
index 453ab82..957fc74 100644
--- a/include/os.h
+++ b/include/os.h
@@ -83,6 +83,15 @@ typedef struct _NewClientRec *NewClientPtr;
 #include 
 #include 
 
+/* XXX Need to check which GCC versions have the format(printf) attribute. */
+#if defined(__GNUC__) && (__GNUC__ > 2)
+#define _printf_attribute(a,b) __attribute((format(__printf__,a,b)))
+#define _noreturn_attribute __attribute((noreturn))
+#else
+#define _printf_attribute(a,b) /**/
+#define _noreturn_attribute /**/
+#endif
+
 #ifdef DDXBEFORERESET
 extern void ddxBeforeReset (void);
 #endif
@@ -226,9 +235,9 @@ extern _X_EXPORT pointer XNFrealloc(pointer /*ptr*/, 
unsigned long /*amount*/);
 
 extern _X_EXPORT char *Xstrdup(const char *s);
 extern _X_EXPORT char *XNFstrdup(const char *s);
-extern _X_EXPORT char *Xprintf(const char *fmt, ...);
+extern _X_EXPORT char *Xprintf(const char *fmt, ...) _printf_attribute(1,2);
 extern _X_EXPORT char *Xvprintf(const char *fmt, va_list va);
-extern _X_EXPORT char *XNFprintf(const char *fmt, ...);
+extern _X_EXPORT char *XNFprintf(const char *fmt, ...) _printf_attribute(1,2);
 extern _X_EXPORT char *XNFvprintf(const char *fmt, va_list va);
 
 typedef void (*OsSigHandlerPtr)(int /* sig */);
@@ -262,7 +271,7 @@ extern _X_EXPORT void OsBlockSignals (void);
 
 extern _X_EXPORT void OsReleaseSignals (void);
 
-extern _X_EXPORT void OsAbort (void);
+extern _X_EXPORT void OsAbort (void) _noreturn_attribute;
 
 #if !defined(WIN32)
 extern _X_EXPORT int System(char *);
@@ -488,13 +497,6 @@ typedef enum {
 X_UNKNOWN = -1 /* unknown -- this must always be last */
 } MessageType;
 
-/* XXX Need to check which GCC versions have the format(printf) attribute. */
-#if defined(__GNUC__) && (__GNUC__ > 2)
-#define _printf_attribute(a,b) __attribute((format(__printf__,a,b)))
-#else
-#define _printf_attribute(a,b) /**/
-#endif
-
 extern _X_EXPORT const char *LogInit(const char *fname, const char *backup);
 extern _X_EXPORT void LogClose(void);
 extern _X_EXPORT Bool LogSetParameter(LogParameter param, int value);
@@ -509,11 +511,7 @@ extern _X_EXPORT void LogMessage(MessageType type, const 
char *format, ...)
 extern _X_EXPORT void FreeAuditTimer(void);
 extern _X_EXPORT void AuditF(const char *f, ...) _printf_attribute(1,2);
 extern _X_EXPORT void VAuditF(const char *f, va_list args);
-extern _X_EXPORT void FatalError(const char *f, ...) _printf_attribute(1,2)
-#if defined(__GNUC__) && (__GNUC__ > 2)
-__attribute((noreturn))
-#endif
-;
+extern _X_EXPORT void FatalError(const char *f, ...) _printf_attribute(1,2) 
_noreturn_attribute;
 
 #ifdef DEBUG
 #define DebugF ErrorF
diff --git a/os/log.c b/os/log.c
index c1301d7..9f24c3a 100644
--- a/os/log.c
+++ b/os/log.c
@@ -402,9 +402,7 @@ LogMessage(MessageType type, const char *format, ...)
 va_end(ap);
 }
 
-#ifdef __GNUC__
-void AbortServer(void) __attribute__((noreturn));
-#endif
+void AbortServer(void) _noreturn_attribute;
 
 void
 AbortServer(void)
-- 
1.7.0.3




smime.p7s
Description: S/MIME cryptographic 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 libXfont] config: remove protection for AS_HELP_STRING for old autoconf

[Jeremy Huddleston]

Thanks.

Reviewed-by: Jeremy Huddleston 

On Mar 27, 2010, at 17:53, Gaetan Nadon wrote:

> On Sat, 2010-03-27 at 16:48 -0700, Jeremy Huddleston wrote:
> 
>> I'm confused... what makes it 2.60 instead of 2.58?
>> 
> 
> Sorry about the confusion.
> The 2 changes are not really connected. The de facto lowest common
> denominator
> for all x.org modules is 2.60 (4 years old). As I go along, I update the
> AC_PREREQ statement.
> 
> The m4_ifdef I am removing was put in place in 2005 so that a new (at
> the time) feature
> could be used on the old 2.57 level (8 years old now). 
> 
> I have yet to find a way of saying that clearly. No one uses 2.57
> anymore (automake 1.9 won't even installed)
> but if I write a patch just to bump up the number, then people get
> confused as well as it appears
> to be gratuitous. 
> 
> Thanks
> 
>> On Mar 27, 2010, at 15:01, Gaetan Nadon wrote:
>> 
>>> No longer needed as modules will not configure with 2.57.
>>> AS_HELP_STRING was introduced in 2.58. The minimum level
>>> is now 2.60.
>>> 
>>> Signed-off-by: Gaetan Nadon 
>>> ---
>>> configure.ac |4 +---
>>> 1 files changed, 1 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/configure.ac b/configure.ac
>>> index c75a041..852124a 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -20,7 +20,7 @@ dnl  PERFORMANCE OF THIS SOFTWARE.
>>> dnl
>>> dnl Process this file with autoconf to create configure.
>>> 
>>> -AC_PREREQ([2.57])
>>> +AC_PREREQ([2.60])
>>> 
>>> AC_INIT([libXfont],
>>> 1.4.1,
>>> @@ -57,8 +57,6 @@ PKG_PROG_PKG_CONFIG
>>> AC_CHECK_HEADERS([endian.h poll.h sys/poll.h])
>>> AC_CHECK_FUNCS([poll])
>>> 
>>> -m4_ifdef([AS_HELP_STRING], , [m4_define([AS_HELP_STRING], 
>>> m4_defn([AC_HELP_STRING]))])
>>> -
>>> #
>>> # select libraries to include
>>> #
>>> -- 
>>> 1.6.0.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
>> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic 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 x11proto] Add _X_NORETURN macro to signify functions that don't return

[Jeremy Huddleston]

Signed-off-by: Jeremy Huddleston 
---
 Xfuncproto.h.in |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/Xfuncproto.h.in b/Xfuncproto.h.in
index afdd95b..96a585c 100644
--- a/Xfuncproto.h.in
+++ b/Xfuncproto.h.in
@@ -117,4 +117,10 @@ in this Software without prior written authorization from 
The Open Group.
 # define _X_DEPRECATED
 #endif
 
+#if defined(__GNUC__) && ((__GNUC__ * 100 + __GNUC_MINOR__) >= 205)
+# define _X_NORETURN __attribute((noreturn))
+#else
+# define _X_NORETURN
+#endif /* GNUC  */
+
 #endif /* _XFUNCPROTO_H_ */
-- 
1.7.0.3



smime.p7s
Description: S/MIME cryptographic 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] OS: Add some noreturn and printf compiler attributes where appropriate

[Jeremy Huddleston]

On Mar 27, 2010, at 18:39, Alan Coopersmith wrote:
> 
>> +/* XXX Need to check which GCC versions have the format(printf) attribute. 
>> */
>> +#if defined(__GNUC__) && (__GNUC__ > 2)
>> +#define _printf_attribute(a,b) __attribute((format(__printf__,a,b)))
>> +#define _noreturn_attribute __attribute((noreturn))
> 
> Why not just use _X_ATTRIBUTE_PRINTF from X11/Xfuncproto.h ?
> Unfortunately there's no noreturn there, but we could add it.
> 
> (Obviously I'm biased towards having one place to update as the
> Sun compilers are growing __attribute compatibility for various
> of the attributes in new releases.)

I would rather have one location as well.  I just did it in os.h since it was 
already there (I just moved it up from below).

I sent a patch for x11proto that makes that change and will hold on this until 
that one hits a release.

--Jeremy





smime.p7s
Description: S/MIME cryptographic 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

[PULL (updated again)] 4 patches from XQuartz

[Jeremy Huddleston]

Sorry, we need one more.  A small regression was found in our 
release-candidate, and this fixes it.

I think this should be the last PULL request from XQuartz before 1.8 ships.


The following changes since commit 579715f830fbbca9e1ecb17dc18176132f5969e7:
  Rami Ylimaki (1):
os: Prevent backtrace from being stopped in noreturn functions.

are available in the git repository at:

  git://anongit.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (4):
  XQuartz: Workaround weird key data reported on some layouts
  GLX: Remove a redundant initialization
  darwin: Generate crash reports on FatalError()
  XQuartz: Re-query dixScreenOrigins as the value could've changed.

 glx/indirect_dispatch.c   |2 --
 hw/xquartz/GL/capabilities.c  |3 +--
 hw/xquartz/darwin.c   |   10 +++---
 hw/xquartz/mach-startup/bundle-main.c |   11 ++-
 hw/xquartz/quartz.c   |7 +--
 hw/xquartz/quartzKeyboard.c   |5 -
 os/log.c  |9 +
 os/utils.c|2 ++
 8 files changed, 30 insertions(+), 19 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: We're over the extension event limit -- what are we going to do about it?

[Jeremy Huddleston]

On Mar 29, 2010, at 08:23, Adam Jackson wrote:

> We could pretty easily bump DGA to major version 3, encode events with
> GE, and require newer client-side libs that translate back for ABI.
> After all, if you're using it _and_ you've updated your server, you can
> update your client libs too.  It'd be slightly gross - for maximal ABI
> compat the client libs would want to lie about the protocol major
> version number, in case old games check for == 2 - but then DGA is
> pretty gross all around.

What's keeping DGA on life-support these days?  I thought there was one last 
reason to keep it around, and XI2 was supposed to be the one to put the nail in 
that puppy's coffin.  Wouldn't it just be easier to punt DGA in 1.9?



___
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: libXfont: Changes to 'master'

[Jeremy Huddleston]

This introduced a regression on tinderbox:

http://tinderbox.x.org/builds/2010-03-31-0030/logs/libXfont


On Mar 30, 2010, at 10:19, Gaetan Nadon wrote:

> Makefile.am  |3 +--
> configure.ac |4 ++--
> 2 files changed, 3 insertions(+), 4 deletions(-)
> 
> New commits:
> commit 8e84687b26be6e8f5da4fce173c0a134eb07f4f3
> Author: Gaetan Nadon 
> Date:   Tue Mar 30 09:26:13 2010 -0400
> 
>config: replace obsolete AM_CONFIG_HEADER with AC_CONFIG_HEADERS
> 
>Both headers end up created by the same macro.
> 
>Reviewed-by: Dan Nicholson 
>Signed-off-by: Gaetan Nadon 
> 
> ___
> xorg-commit mailing list
> xorg-com...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg-commit

___
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: libXfont: Changes to 'master'

[Jeremy Huddleston]

On Mar 31, 2010, at 18:10, Gaetan Nadon wrote:

>> Oops, there's a couple issues with that patch.
>> 
>> 1. AC_CONFIG_HEADERS does not appear to make the config.h.in template
>> for you when there are multiple files passed to it. Separating it to
>> two calls to AC_CONFIG_HEADERS seems to do the trick.
>> 
> 
> It creates a file "config.h\n.in".

o.O

> Because the old one was not removed
> (even with distclean),

That is because it is part of 'make dist'

> The problem was unnoticed for me. It does not like filename separated by
> a new line.

I don't attempt to understand what autoconf does sometimes... 


___
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: libXfont: Changes to 'master'

[Jeremy Huddleston]

I have no idea why this was resent, sorry...

On Mar 31, 2010, at 14:46, Jeremy Huddleston wrote:

> This introduced a regression on tinderbox:
> 
> http://tinderbox.x.org/builds/2010-03-31-0030/logs/libXfont
> 
> 
> On Mar 30, 2010, at 10:19, Gaetan Nadon wrote:
> 
>> Makefile.am  |3 +--
>> configure.ac |4 ++--
>> 2 files changed, 3 insertions(+), 4 deletions(-)
>> 
>> New commits:
>> commit 8e84687b26be6e8f5da4fce173c0a134eb07f4f3
>> Author: Gaetan Nadon 
>> Date:   Tue Mar 30 09:26:13 2010 -0400
>> 
>>   config: replace obsolete AM_CONFIG_HEADER with AC_CONFIG_HEADERS
>> 
>>   Both headers end up created by the same macro.
>> 
>>   Reviewed-by: Dan Nicholson 
>>   Signed-off-by: Gaetan Nadon 
>> 
>> ___
>> xorg-commit mailing list
>> xorg-com...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xorg-commit
> 
> ___
> 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 xserver] doc: specify 1.6.1 as the minimum version for doxygen.

[Jeremy Huddleston]

Reviewed-by: Jeremy Huddleston 

On Apr 1, 2010, at 12:53, Gaetan Nadon wrote:

> Older versions generate filenames that are different from
> the ones listed in the Makefile.
> 
> Signed-off-by: Gaetan Nadon 
> ---
> configure.ac |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 5f08688..bee6563 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -34,10 +34,10 @@ AM_MAINTAINER_MODE
> 
> # Require xorg-macros: XORG_DEFAULT_OPTIONS
> m4_ifndef([XORG_MACROS_VERSION],
> -  [m4_fatal([must install xorg-macros 1.5 or later before running 
> autoconf/autogen])])
> -XORG_MACROS_VERSION(1.5)
> +  [m4_fatal([must install xorg-macros 1.6 or later before running 
> autoconf/autogen])])
> +XORG_MACROS_VERSION(1.6)
> XORG_DEFAULT_OPTIONS
> -XORG_WITH_DOXYGEN
> +XORG_WITH_DOXYGEN(1.6.1)
> 
> m4_ifndef([XORG_FONT_MACROS_VERSION], [m4_fatal([must install fontutil 1.1 or 
> later before running autoconf/autogen])])
> XORG_FONT_MACROS_VERSION(1.1)
> -- 
> 1.6.0.4
> 
> Resending for review (4th time)
> 
> This gives additional protection against doc generation failure
> that are hard to diagnose when the tool is at a lower level.
> 
> This patch makes use of the version checking feature added in util-macros
> 
> http://cgit.freedesktop.org/xorg/util/macros/commit/?id=2c833326fdd8303b5563eb9f621ff57e3bf5
> doc: Specify minimum xmlto version to XORG_WITH_DOXYGEN
> Adds an optional parameter to XORG_WITH_DOXYGEN to enforce a minimum version
> needed like the asciidoc version check. 
> Reviewed-by: Dan Nicholson  
> Signed-off-by: Gaetan Nadon 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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

[PULL] XQuartz.app version bump for 1.8

[Jeremy Huddleston]

I'd like to bump the version number of the XQuartz app bundle for 1.8.

Thanks,
Jeremy

The following changes since commit 67b814d9b2baea6beccfb1625a1e3f0b2ba7218b:
  Ruediger Oertel (1):
Remove now obsolete function chooseVideoDriver

are available in the git repository at:

  git://anongit.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (2):
  darwin: Correct inline assembly for  ___crashreporter_info__
  Bump bundle version to 2.5.1

 hw/xquartz/bundle/Info.plist.cpp  |4 ++--
 hw/xquartz/mach-startup/bundle-main.c |2 +-
 os/log.c  |2 +-
 3 files changed, 4 insertions(+), 4 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: Xorg 1.8.x branch policy?

[Jeremy Huddleston]

Keith? Peter?  I haven't seen a response to Alan's question, and I'm  
curious too... Is master to be 1.8.1, or is it to be 1.9?  What is the  
1.8 branch-point?  Are we delaying branching from master until 1.8.1?




On Apr 3, 2010, at 10:41, Alan Coopersmith wrote:


Will we be following the same model as Xorg 1.7.x branches for 1.8?
(i.e. anyone can push to -nominations, release manager pulls from that
branch to server-1.8-branch when doing a release/snapshot)

--
-Alan Coopersmith-alan.coopersm...@oracle.com
 Oracle Solaris Platform Engineering: X Window System

___
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




smime.p7s
Description: S/MIME cryptographic 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: X server 1.9 release thoughts

[Jeremy Huddleston]

On Apr 6, 2010, at 11:47, Daniel Stone wrote:


On Tue, Apr 06, 2010 at 09:30:47AM -0700, Keith Packard wrote:
Beyond that, one requirement that I see for merging output drivers  
would
be to shorten the X server release from the current 6 months down  
to 3
months or so. Otherwise I feel that the window of time between  
hardware

release and driver release could become too long. I'm up for this
cadence, but it would mean that we'd need to see major patches posted
and reviewed in the previous release cycle so that they could be  
applied

shortly after a release. I don't want to shorten the RC schedule by
much. If ABI/API churn is an issue, we could try freezing those for  
the

'odd' releases, but I'd rather avoid that as it can artificially
constrain development.


Er, is there no reason hardware enable (even if it's not entirely
fully-featured) can't be done in point releases?


Yeah, I thought the 6-week point release schedule was mainly to  
address this very concern amongst the drivers developers.


I think a 3-month major-release cycle will be very taxing, especially  
considering the increased codebase with drivers.


Another possibility to take some load off of the release manager might  
be allowing "assistant release manager" (or possibly "assistant to the  
release manager" ;>) positions for the drivers.  That way, Keith  
doesn't need to be the gate-keeper for an increasing code-base, and  
the driver developers still have the same manager for their driver in  
its new location as they did in its old location.





smime.p7s
Description: S/MIME cryptographic 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: X server 1.9 release thoughts

[Jeremy Huddleston]

On Apr 7, 2010, at 10:46, Keith Packard wrote:
> 
> Something that might help here is to publish the list of subsystems and
> who is the maintainer in charge of them. That should be in the project
> tree itself so that anyone can find the right person.

It already is...

http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/MAINTAINERS

___
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 libX11 3/4] man: Fix value of XkbAllComponentsMask in XkbGetKeyboard

[Jeremy Huddleston]

On Apr 8, 2010, at 05:14, Dirk Wallenstein wrote:
> 
> I tried in another thread but there are type divergence issues that
> would have to be solved additionally in a questionable separate effort.
> 
> Are you ok with the patch as is?

yes.

___
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

libX11 and xcb

[Jeremy Huddleston]

So what is the general recommendation at this point for how to ship libX11?  
I'm still shipping a build --without-xcb mainly because we wanted to play it 
safe during xcb's infancy.  Has anyone did performance comparisons recently?  
Are there any bugs or support issues with the switch that I should be aware of? 
 I've been using it locally without any problem, but I'd like to check in 
before shipping it.

--Jeremy

___
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] Misc XQuartz fixes

[Jeremy Huddleston]

The following changes since commit d7c98c1c81ae272f66edb05fde20f4c616604add:
  Keith Packard (1):
Merge remote branch 'whot/for-keith'

are available in the git repository at:

  git://people.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (4):
  XQuartz: Blacklist some oddball legacy Mac keycodes that break wine
  XQuartz: Add a defaults option to toggle Alt / Mode_switch
  XQuartz: Customize the NSDefaults id in the man file.
  XQuartz: Add a GUI preference for the Alt / Mode_switch toggle

 hw/xquartz/X11Application.h|1 +
 hw/xquartz/X11Application.m|   19 +-
 hw/xquartz/X11Controller.h |6 +-
 hw/xquartz/X11Controller.m |  102 +-
 .../English.lproj/main.nib/designable.nib  | 1791 
 .../English.lproj/main.nib/keyedobjects.nib|  Bin 41440 -> 45258 bytes
 hw/xquartz/doc/Makefile.am |2 +
 hw/xquartz/doc/Xquartz.man.pre |   39 +-
 hw/xquartz/quartz.c|1 +
 hw/xquartz/quartzCommon.h  |1 +
 hw/xquartz/quartzKeyboard.c|   91 +-
 hw/xquartz/quartzKeyboard.h|   10 +-
 12 files changed, 877 insertions(+), 1186 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: xdm: Changes to 'master'

[Jeremy Huddleston]

I wish I caught the AC_CONFIG_MACRO_DIR([m4]) change before xdm-1.1.10 shipped. 
 I *really* dislike it because it leads to build failures with libtool.  Yes, 
the ac_define_dir.m4 is good to have in there rather than acinclude.m4, but 
'make dist' also packages up a bunch of libtool cruft which can cause build 
failures.

If the builder runs 'autoreconf -fvi' from the tarball, the packager's libtool 
m4 macros will be used, and the builder's libtool will be used!

I just hit this with the new xdm tarball on Leopard which shipped 
libtool-1.5.22 ... sure, I can 'rm -rf m4/l{ib,}t*' first, but that should not 
be needed.

--Jeremy


On Mar 15, 2010, at 23:35, Alan Coopersmith wrote:

> .gitignore  |5 +
> Makefile.am |1 +
> acinclude.m4|   45 -
> auth.c  |4 ++--
> configure.ac|1 +
> m4/ac_define_dir.m4 |   45 +
> 6 files changed, 54 insertions(+), 47 deletions(-)
> 
> New commits:
> commit c9cdd56df50f280e90ba95cfa933222f94ad2677
> Author: Alan Coopersmith 
> Date:   Mon Mar 15 23:34:04 2010 -0700
> 
>Move m4 macros to m4 subdir as automake/libtool recommend
> 
>Signed-off-by: Alan Coopersmith 
> 
> commit b9226288b96f0c5988d2c2f52718674d39803a5e
> Author: Alan Coopersmith 
> Date:   Mon Mar 15 23:21:30 2010 -0700
> 
>Replace hardcoded NAMELEN of 14 for ancient SysV with MAXNAMELEN
> 
>Signed-off-by: Alan Coopersmith 
> 
> ___
> xorg-commit mailing list
> xorg-com...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg-commit

___
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: [PULL xinit] Cleanups

[Jeremy Huddleston]

Since we're on the subject of xinit...

Apple uses an xinitrc.d for modularizing xinitrc (you can see this in some 
#ifdef __APPLE__ magic) ... is this something we should enable for other 
architectures?  It's been useful here.

--Jeremy

On Apr 14, 2010, at 07:20, Alan Coopersmith wrote:

> Mikhail Gusarov wrote:
>> Alan,
>> 
>> please pull fixes from the repo
>>  git://anongit.freedesktop.org/~dottedmag/xinit cleanup
> 
> Sure, now you make it easy, after I'd saved 14 e-mail messages
> yesterday and git am'ed them.  8-)
> 
> Since I'd already done that, I went ahead and pushed that after
> verifying that git diff showed no difference to a branch pulled
> from your repo.
> 
> 
> -- 
>   -Alan Coopersmith-alan.coopersm...@oracle.com
>Oracle Solaris Platform Engineering: X Window System
> 
> ___
> 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

[PULL] Misc XQuartz fixes -- GLX, localization

[Jeremy Huddleston]

The following changes since commit 9ddbb03fa56aa73c3f417d8ee6433e45b94445b3:
  Peter Hutterer (1):
dix: Fix crash in DeliverGrabbedEvents.

are available in the git repository at:

  git://people.freedesktop.org/~jeremyhu/xserver master

Jeremy Huddleston (3):
  XQuartz: Localization update
  XQuartz: Fix possible NULL dereference in ListenOnOpenFD
  XQuartz GLX: Don't let garbage enter our pixel request

 hw/xquartz/GL/indirect.c   |2 +-
 .../Resources/Dutch.lproj/Localizable.strings  |  Bin 2616 -> 2786 bytes
 .../bundle/Resources/Dutch.lproj/locversion.plist  |4 +-
 .../Resources/Dutch.lproj/main.nib/designable.nib  |  104 +-
 .../Dutch.lproj/main.nib/keyedobjects.nib  |  Bin 46189 -> 45943 bytes
 .../Resources/French.lproj/Localizable.strings |  Bin 2708 -> 2894 bytes
 .../bundle/Resources/French.lproj/locversion.plist |4 +-
 .../Resources/French.lproj/main.nib/designable.nib |  105 +-
 .../French.lproj/main.nib/keyedobjects.nib |  Bin 55983 -> 55699 bytes
 .../Resources/German.lproj/Localizable.strings |  Bin 2632 -> 2812 bytes
 .../bundle/Resources/German.lproj/locversion.plist |4 +-
 .../Resources/German.lproj/main.nib/designable.nib |  106 +-
 .../German.lproj/main.nib/keyedobjects.nib |  Bin 52977 -> 52610 bytes
 .../Resources/Italian.lproj/Localizable.strings|  Bin 2618 -> 2802 bytes
 .../Resources/Italian.lproj/locversion.plist   |4 +-
 .../Italian.lproj/main.nib/designable.nib  |  108 +-
 .../Italian.lproj/main.nib/keyedobjects.nib|  Bin 50126 -> 49748 bytes
 .../Resources/Japanese.lproj/Localizable.strings   |  Bin 2166 -> 2320 bytes
 .../Resources/Japanese.lproj/locversion.plist  |4 +-
 .../Japanese.lproj/main.nib/designable.nib |  125 +-
 .../Japanese.lproj/main.nib/keyedobjects.nib   |  Bin 47803 -> 47584 bytes
 .../Resources/Spanish.lproj/Localizable.strings|  Bin 2562 -> 2744 bytes
 .../Resources/Spanish.lproj/locversion.plist   |4 +-
 .../Spanish.lproj/main.nib/designable.nib  |   96 +-
 .../Spanish.lproj/main.nib/keyedobjects.nib|  Bin 53635 -> 53366 bytes
 .../bundle/Resources/ar.lproj/InfoPlist.strings|  Bin 0 -> 320 bytes
 .../bundle/Resources/ar.lproj/Localizable.strings  |  Bin 0 -> 2452 bytes
 .../bundle/Resources/ar.lproj/locversion.plist |   14 +
 .../Resources/ar.lproj/main.nib/designable.nib | 3955 
 .../Resources/ar.lproj/main.nib/keyedobjects.nib   |  Bin 0 -> 52847 bytes
 .../bundle/Resources/da.lproj/Localizable.strings  |  Bin 2554 -> 2734 bytes
 .../bundle/Resources/da.lproj/locversion.plist |4 +-
 .../Resources/da.lproj/main.nib/designable.nib |   82 +-
 .../Resources/da.lproj/main.nib/keyedobjects.nib   |  Bin 51757 -> 51511 bytes
 .../bundle/Resources/fi.lproj/Localizable.strings  |  Bin 2614 -> 2778 bytes
 .../bundle/Resources/fi.lproj/locversion.plist |4 +-
 .../Resources/fi.lproj/main.nib/designable.nib |  167 +-
 .../Resources/fi.lproj/main.nib/keyedobjects.nib   |  Bin 53385 -> 53083 bytes
 .../bundle/Resources/ko.lproj/Localizable.strings  |  Bin 2140 -> 2290 bytes
 .../bundle/Resources/ko.lproj/locversion.plist |4 +-
 .../Resources/ko.lproj/main.nib/designable.nib |   82 +-
 .../Resources/ko.lproj/main.nib/keyedobjects.nib   |  Bin 46727 -> 46478 bytes
 .../bundle/Resources/no.lproj/Localizable.strings  |  Bin 2576 -> 2758 bytes
 .../bundle/Resources/no.lproj/locversion.plist |4 +-
 .../Resources/no.lproj/main.nib/designable.nib |   82 +-
 .../Resources/no.lproj/main.nib/keyedobjects.nib   |  Bin 50330 -> 50084 bytes
 .../bundle/Resources/pl.lproj/Localizable.strings  |  Bin 2508 -> 2672 bytes
 .../bundle/Resources/pl.lproj/locversion.plist |4 +-
 .../Resources/pl.lproj/main.nib/designable.nib |   92 +-
 .../Resources/pl.lproj/main.nib/keyedobjects.nib   |  Bin 52516 -> 52193 bytes
 .../bundle/Resources/pt.lproj/Localizable.strings  |  Bin 2654 -> 2834 bytes
 .../bundle/Resources/pt.lproj/locversion.plist |4 +-
 .../Resources/pt.lproj/main.nib/designable.nib |   82 +-
 .../Resources/pt.lproj/main.nib/keyedobjects.nib   |  Bin 52942 -> 52696 bytes
 .../Resources/pt_PT.lproj/Localizable.strings  |  Bin 2598 -> 2784 bytes
 .../bundle/Resources/pt_PT.lproj/locversion.plist  |4 +-
 .../Resources/pt_PT.lproj/main.nib/designable.nib  |  112 +-
 .../pt_PT.lproj/main.nib/keyedobjects.nib  |  Bin 54065 -> 53711 bytes
 .../bundle/Resources/ru.lproj/Localizable.strings  |  Bin 2656 -> 2826 bytes
 .../bundle/Resources/ru.lproj/locversion.plist |4 +-
 .../Resources/ru.lproj/main.nib/designable.nib |  110 +-
 .../Resources/ru.lproj/main.nib/keyedobjects.nib   |  Bin 55338 -> 54972 bytes
 .../bundle/Resources/sv.lproj/Localizable.strings  |  Bin 2498 -> 2682 bytes
 .../bun

[PATCH xinit] Enable support for an xinitrc.d directory

[Jeremy Huddleston]

This was already done on darwin and Gentoo.  Now others can benefit.

Signed-off-by: Jeremy Huddleston 
---
 xinitrc.cpp |6 +-
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git /xinitrc.cpp /xinitrc.cpp
new file mode 100644
index 379b1f3..7e582b0 100644
--- /xinitrc.cpp
+++ /xinitrc.cpp
@@ -84,17 +84,13 @@ fi
 XCOMM This is the fallback case if nothing else is executed above
 #endif /* !defined(__SCO__)  && !defined(__UNIXWARE__) */
 
-#ifdef __APPLE__
-
 if [ -d XINITDIR/xinitrc.d ] ; then
-   for f in XINITDIR/xinitrc.dXSLASHGLOB.sh ; do
+   for f in XINITDIR/xinitrc.dXSLASHGLOB ; do
[ -x "$f" ] && . "$f"
done
unset f
 fi
 
-#endif
-
 TWM &
 XCLOCK -geometry 50x50-1+1 &
 XTERM -geometry 80x50+494+51 &
-- 
1.7.0.4


I dropped the .sh suffix to match what Gentoo is doing.

___
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 xinit] Enable support for an xinitrc.d directory

[Jeremy Huddleston]

On Apr 15, 2010, at 11:56, Julien Cristau wrote:

>> if [ -d XINITDIR/xinitrc.d ] ; then
>> -for f in XINITDIR/xinitrc.dXSLASHGLOB.sh ; do
>> +for f in XINITDIR/xinitrc.dXSLASHGLOB ; do

> I think I'd keep the .sh suffix.  That would avoid picking up emacs foo~
> files, or similar.  Seems sane otherwise.

I made that change mainly to match Gentoo.  I think consistency is better here. 
 Remi, can you chime in here.

Also, does emacs preserve executable permissions on *~ files?  We're checking [ 
-x "$f" ]




___
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: Bell confusion with master vs. slave devices in Xorg 1.7.6

[Jeremy Huddleston]

Yeah... I was seeing this as well.  I brought it up last month:
http://lists.x.org/archives/xorg-devel/2010-March/006265.html

And ended up just letting core ring it (DDXRingBell):
http://cgit.freedesktop.org/~jeremyhu/xserver/commit/?id=eac7cdabecafb7c505795207182ab2578d672c06

I don't have a chance to read/respond to this right now, but there might be 
something useful in that thread.

--Jeremy

On Apr 16, 2010, at 22:27, Alan Coopersmith wrote:

> Several users have complained to me about their X server bells on
> recent builds of OpenSolaris - definitely with Xorg 1.7.x releases,
> I don't know if it affected Xorg 1.6.x before that as well.
> 
> The complaints I've gotten are two-fold: the bell volume is
> uncontrollable, and when the beep sounds, it plays twice
> (stuck at the loud volume).
> 
> It looks like we're seeing this because unlike the evdev driver,
> the kbd driver has a BellProc set to sound the keyboard device
> bell (if present - the Solaris kernel redirects to an audio
> device if not).
> 
> When the keyboard gets associated with the Virtual Core Keyboard,
> the DeepCopyDeviceClasses copies the BellProc pointer to the
> Virtual Core Keyboard.   When an XBell request comes in, the
> ProcBell function in dix/devices.c loops through all the devices,
> and calls the BellProc in the master and any associated slaves,
> resulting in the KbdBell() function from kbd_drv getting called
> twice, once off the Virtual Core Keyboard and once off the slave
> representing the physical keyboard.
> 
> If you try to silence this with 'xset b 0' though, it does not
> loop through all the devices, and only sets the volume on the
> master.   You can see the slave still have the default volume of
> 50 by running 'xinput get-feedbacks keyboard'.   When ProcBell
> loops through the devices though, it uses the volume from each
> device.
> 
> Fixing this portion seems a simple matter of changing ProcBell to use
> the master keyboard volume on all slaves of that device as well:
> 
> --- dix/devices.c~Fri Apr 16 19:29:30 2010
> +++ dix/devices.c Fri Apr 16 20:54:31 2010
> @@ -2037,7 +2037,7 @@
>   if (rc != Success)
>   return rc;
> XkbHandleBell(FALSE, FALSE, dev, newpercent,
> -  &dev->kbdfeed->ctrl, 0, None, NULL, client);
> +  &keybd->kbdfeed->ctrl, 0, None, NULL, client);
> }
> }
> 
> This would let you keep per-device bell settings, and have those used when
> you call XDeviceBell on the specific device instead of the master.  It could
> also allow you to have xset called in your .xinitrc and have its volume 
> setting
> stick even if the physical keyboard hasn't been associated with the core 
> device
> yet, but that is currently thwarted by the DeepCopy overriding the core 
> devices
> keyboard feedback settings when the device is connected to the master.
> 
> Alternatively, DoChangeKeyboardControl could set the bell volumes on all the
> slaves, but that also doesn't solve the problem of initializing the settings
> from .xinitrc.
> 
> As for the double bell, the two options there seem to be either removing the
> copying of BellProc in the DeepCopy code, or changing ProcBell to call it on
> either the master or the slave, but not both.  Since the Solaris 
> implementation
> of xf86OSRingBell also makes noise, via /dev/audio, I'm tempted to do both.
> By not copying BellProc, the virtual keyboard is left with it's BellProc set 
> to
> CoreKeyboardBell, which unwraps down to xf86OSRingBell, so that would be used
> when no other bell device is present, but if any slaves have a bell, we could
> skip the master.
> 
> --- Xi/exevents.c~Fri Apr 16 21:48:19 2010
> +++ Xi/exevents.c Fri Apr 16 21:48:37 2010
> @@ -413,7 +413,6 @@
> return;
> }
> }
> -(*k)->BellProc = it->BellProc;
> (*k)->CtrlProc = it->CtrlProc;
> (*k)->ctrl = it->ctrl;
> if ((*k)->xkb_sli)
> 
> --- dix/devices.c~2010-04-16 21:49:26.132804948 -0700
> +++ dix/devices.c 2010-04-16 22:19:16.742406867 -0700
> @@ -2015,6 +2015,7 @@ ProcBell(ClientPtr client)
> int base = keybd->kbdfeed->ctrl.bell;
> int newpercent;
> int rc;
> +int rung = 0;
> REQUEST(xBellReq);
> REQUEST_SIZE_MATCH(xBellReq);
> 
> @@ -2029,17 +2030,28 @@ ProcBell(ClientPtr client)
> else
>   newpercent = base - newpercent + stuff->percent;
> 
> +/* first try to ring the bells on the slaves */
> for (dev = inputInfo.devices; dev; dev = dev->next) {
> -if ((dev == keybd || (!IsMaster(dev) && dev->u.master == keybd)) &&
> +if ((!IsMaster(dev) && dev->u.master == keybd) &&
> dev->kbdfeed && dev->kbdfeed->BellProc) {
> 
>   rc = XaceHook(XACE_DEVICE_ACCESS, client, dev, DixBellAccess);
> - if (rc != Success)
> - return rc;
> -XkbHandleBell(FALSE, FALSE, dev, newpercent,
> -  

pCompositeClip

[Jeremy Huddleston]

So I've been battling a rather annoying bug rendering borders in XQuartz:

http://xquartz.macosforge.org/trac/ticket/290

Everything works fine when the window is located at the screen origin.  
Interestingly, another recent regression also results in some window contents 
getting clipped as if the clipping bounds were translated to the origin:

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

so my assumption is that these two are related.  I've figured out a workaround 
for the first issue (below) which essentially sets the clipping region in 
miPaintWindow to the entire screen.  In some runs through, it looks like this 
clipping region was getting set to (0,0  x ), and 
the rects being drawn were in the screen's coordinate system (which is 
expected).

Now, why would this be happening?

As I did some resizing of the window, I noticed the following:

GC: 0 x:670-870 y:335-535 drawable: 670 335, pWin->drawable: 670 335
GC: 0 x:560-874 y:225-556 drawable: 560 225, pWin->drawable: 560 225
GC: 1 x:0-333 y:0-377 drawable: 0 0, pWin->drawable: 670 335
GC: 0 x:560-893 y:225-580 drawable: 560 225, pWin->drawable: 560 225
GC: 1 x:0-333 y:0-377 drawable: 0 0, pWin->drawable: 670 335
GC: 0 x:560-893 y:225-580 drawable: 560 225, pWin->drawable: 560 225
GC: 0 x:560-910 y:225-598 drawable: 560 225, pWin->drawable: 560 225
GC: 0 x:560-910 y:225-598 drawable: 560 225, pWin->drawable: 560 225

ErrorF("GC: %d x:%d-%d y:%d-%d drawable: %d %d, pWin->drawable: %d %d\n", what,
   pGC->pCompositeClip->extents.x1, pGC->pCompositeClip->extents.x2,
   pGC->pCompositeClip->extents.y1, pGC->pCompositeClip->extents.y2,
   drawable->x, drawable->y, pWin->drawable.x, pWin->drawable.y);

The window I was resizing was from border.c in 
http://xquartz.macosforge.org/trac/ticket/290

Thanks for the help... now it's time for me to sleep...

--Jeremy

diff --git a/mi/miexpose.c b/mi/miexpose.c
index 6776064..b43777d 100644
--- a/mi/miexpose.c
+++ b/mi/miexpose.c
@@ -680,6 +680,19 @@ miPaintWindow(WindowPtr pWin, RegionPtr prgn, int what)
prect->height = pbox->y2 - pbox->y1;
 }
 prect -= numRects;
+
+#ifdef XQUARTZ
+/* Looks like our clipping isn't set right for some reason:
+ * http://xquartz.macosforge.org/trac/ticket/290
+ */
+if(what == PW_BORDER) {
+   pGC->pCompositeClip->extents.x1 = 0;
+   pGC->pCompositeClip->extents.y1 = 0;
+   pGC->pCompositeClip->extents.x2 = drawable->pScreen->width;
+   pGC->pCompositeClip->extents.y2 = drawable->pScreen->height;
+}
+#endif
+
 (*pGC->ops->PolyFillRect)(drawable, pGC, numRects, prect);
 xfree(prect);
 

___
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: pCompositeClip

[Jeremy Huddleston]

I did a little bit more diving into this, and it looks like the drawable we get 
from:
pixmap = (*pScreen->GetWindowPixmap) ((WindowPtr) drawable);
drawable = &pixmap->drawable;
has some odd (to me) properties:

1) The resulting GC operation for PolyFillRect is damagePolyFillRect rather 
than RootlessPolyFillRect ... why is this not using our RootlessPolyFillRect?
2) the drawable is in relative to the window rather than the screen.  Why is 
this?

If I offset the drawable's x/y by the appropriate amount, we don't write the 
valid memory and die in flames.  If I instead offset the clip region by this 
amount, everything works out fine:

Note that the correct offset is actually from the passed region, not from the 
window.

There are so many coordinate systems involved here that I'm not sure what the 
correct one should be.  Does this added bit of info help point to a possible 
underlying cause?  I'm going to start diving into ValidateGC to figure out why 
pCompositeClip is being set as it is, but I suspect someone out there (Keith?) 
understands this much better than I do.

if(what == PW_BORDER) {
pGC->pCompositeClip->extents.x1 += prgn->extents.x1;
pGC->pCompositeClip->extents.y1 += prgn->extents.y1;
pGC->pCompositeClip->extents.x2 += prgn->extents.x1;
pGC->pCompositeClip->extents.y2 += prgn->extents.y1;
}


On Apr 18, 2010, at 04:14, Jeremy Huddleston wrote:

> So I've been battling a rather annoying bug rendering borders in XQuartz:
> 
> http://xquartz.macosforge.org/trac/ticket/290
> 
> Everything works fine when the window is located at the screen origin.  
> Interestingly, another recent regression also results in some window contents 
> getting clipped as if the clipping bounds were translated to the origin:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=26124
> 
> so my assumption is that these two are related.  I've figured out a 
> workaround for the first issue (below) which essentially sets the clipping 
> region in miPaintWindow to the entire screen.  In some runs through, it looks 
> like this clipping region was getting set to (0,0  x  height>), and the rects being drawn were in the screen's coordinate system 
> (which is expected).
> 
> Now, why would this be happening?
> 
> As I did some resizing of the window, I noticed the following:
> 
> GC: 0 x:670-870 y:335-535 drawable: 670 335, pWin->drawable: 670 335
> GC: 0 x:560-874 y:225-556 drawable: 560 225, pWin->drawable: 560 225
> GC: 1 x:0-333 y:0-377 drawable: 0 0, pWin->drawable: 670 335
> GC: 0 x:560-893 y:225-580 drawable: 560 225, pWin->drawable: 560 225
> GC: 1 x:0-333 y:0-377 drawable: 0 0, pWin->drawable: 670 335
> GC: 0 x:560-893 y:225-580 drawable: 560 225, pWin->drawable: 560 225
> GC: 0 x:560-910 y:225-598 drawable: 560 225, pWin->drawable: 560 225
> GC: 0 x:560-910 y:225-598 drawable: 560 225, pWin->drawable: 560 225
> 
> ErrorF("GC: %d x:%d-%d y:%d-%d drawable: %d %d, pWin->drawable: %d %d\n", 
> what,
>   pGC->pCompositeClip->extents.x1, pGC->pCompositeClip->extents.x2,
>   pGC->pCompositeClip->extents.y1, pGC->pCompositeClip->extents.y2,
>   drawable->x, drawable->y, pWin->drawable.x, pWin->drawable.y);
> 
> The window I was resizing was from border.c in 
> http://xquartz.macosforge.org/trac/ticket/290
> 
> Thanks for the help... now it's time for me to sleep...
> 
> --Jeremy
> 
> diff --git a/mi/miexpose.c b/mi/miexpose.c
> index 6776064..b43777d 100644
> --- a/mi/miexpose.c
> +++ b/mi/miexpose.c
> @@ -680,6 +680,19 @@ miPaintWindow(WindowPtr pWin, RegionPtr prgn, int what)
>   prect->height = pbox->y2 - pbox->y1;
> }
> prect -= numRects;
> +
> +#ifdef XQUARTZ
> +/* Looks like our clipping isn't set right for some reason:
> + * http://xquartz.macosforge.org/trac/ticket/290
> + */
> +if(what == PW_BORDER) {
> + pGC->pCompositeClip->extents.x1 = 0;
> + pGC->pCompositeClip->extents.y1 = 0;
> + pGC->pCompositeClip->extents.x2 = drawable->pScreen->width;
> + pGC->pCompositeClip->extents.y2 = drawable->pScreen->height;
> +}
> +#endif
> +
> (*pGC->ops->PolyFillRect)(drawable, pGC, numRects, prect);
> xfree(prect);
> 
> 
> ___
> 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: Bell confusion with master vs. slave devices in Xorg 1.7.6

[Jeremy Huddleston]

So, I've finally read through this and I'm still not sure what the right 
solution is, but here are my 2 cents.

The real problem is the growing divide between Core and XInput.

The VCK should not result in an audio beep as it is a virtual device.

ProcBell should iterate through all physical (slave) devices and make those 
beep.

We should be able to control the volume for each device (via Xinput).

Setting volume through Core (xset b 0) should result in setting the volume on 
master (even though it doesn't beep... see below) and all slaves.

The deep copy should still copy bell proc (IMO) since that is what I'd expect 
from something called "deep copy"...

Why doesn't making DoChangeKeyboardControl set the volume on all slaves solve 
the .xinitrc issue?  Because the slave isn't attached when xinitrc is run?  Why 
not have the slave inherit the volume level of the master when it is attached?

--Jeremy



On Apr 16, 2010, at 22:27, Alan Coopersmith wrote:

> Several users have complained to me about their X server bells on
> recent builds of OpenSolaris - definitely with Xorg 1.7.x releases,
> I don't know if it affected Xorg 1.6.x before that as well.
> 
> The complaints I've gotten are two-fold: the bell volume is
> uncontrollable, and when the beep sounds, it plays twice
> (stuck at the loud volume).
> 
> It looks like we're seeing this because unlike the evdev driver,
> the kbd driver has a BellProc set to sound the keyboard device
> bell (if present - the Solaris kernel redirects to an audio
> device if not).
> 
> When the keyboard gets associated with the Virtual Core Keyboard,
> the DeepCopyDeviceClasses copies the BellProc pointer to the
> Virtual Core Keyboard.   When an XBell request comes in, the
> ProcBell function in dix/devices.c loops through all the devices,
> and calls the BellProc in the master and any associated slaves,
> resulting in the KbdBell() function from kbd_drv getting called
> twice, once off the Virtual Core Keyboard and once off the slave
> representing the physical keyboard.
> 
> If you try to silence this with 'xset b 0' though, it does not
> loop through all the devices, and only sets the volume on the
> master.   You can see the slave still have the default volume of
> 50 by running 'xinput get-feedbacks keyboard'.   When ProcBell
> loops through the devices though, it uses the volume from each
> device.
> 
> Fixing this portion seems a simple matter of changing ProcBell to use
> the master keyboard volume on all slaves of that device as well:
> 
> --- dix/devices.c~Fri Apr 16 19:29:30 2010
> +++ dix/devices.c Fri Apr 16 20:54:31 2010
> @@ -2037,7 +2037,7 @@
>   if (rc != Success)
>   return rc;
> XkbHandleBell(FALSE, FALSE, dev, newpercent,
> -  &dev->kbdfeed->ctrl, 0, None, NULL, client);
> +  &keybd->kbdfeed->ctrl, 0, None, NULL, client);
> }
> }
> 
> This would let you keep per-device bell settings, and have those used when
> you call XDeviceBell on the specific device instead of the master.  It could
> also allow you to have xset called in your .xinitrc and have its volume 
> setting
> stick even if the physical keyboard hasn't been associated with the core 
> device
> yet, but that is currently thwarted by the DeepCopy overriding the core 
> devices
> keyboard feedback settings when the device is connected to the master.
> 
> Alternatively, DoChangeKeyboardControl could set the bell volumes on all the
> slaves, but that also doesn't solve the problem of initializing the settings
> from .xinitrc.
> 
> As for the double bell, the two options there seem to be either removing the
> copying of BellProc in the DeepCopy code, or changing ProcBell to call it on
> either the master or the slave, but not both.  Since the Solaris 
> implementation
> of xf86OSRingBell also makes noise, via /dev/audio, I'm tempted to do both.
> By not copying BellProc, the virtual keyboard is left with it's BellProc set 
> to
> CoreKeyboardBell, which unwraps down to xf86OSRingBell, so that would be used
> when no other bell device is present, but if any slaves have a bell, we could
> skip the master.
> 
> --- Xi/exevents.c~Fri Apr 16 21:48:19 2010
> +++ Xi/exevents.c Fri Apr 16 21:48:37 2010
> @@ -413,7 +413,6 @@
> return;
> }
> }
> -(*k)->BellProc = it->BellProc;
> (*k)->CtrlProc = it->CtrlProc;
> (*k)->ctrl = it->ctrl;
> if ((*k)->xkb_sli)
> 
> --- dix/devices.c~2010-04-16 21:49:26.132804948 -0700
> +++ dix/devices.c 2010-04-16 22:19:16.742406867 -0700
> @@ -2015,6 +2015,7 @@ ProcBell(ClientPtr client)
> int base = keybd->kbdfeed->ctrl.bell;
> int newpercent;
> int rc;
> +int rung = 0;
> REQUEST(xBellReq);
> REQUEST_SIZE_MATCH(xBellReq);
> 
> @@ -2029,17 +2030,28 @@ ProcBell(ClientPtr client)
> else
>   newpercent = base - newpercent + stuff->percen