"empty" model/layout for xkb
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
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
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
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?
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
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?
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
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
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
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
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?
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
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
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
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
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?
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
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
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
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
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?
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
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
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
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
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
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
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
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
-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
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
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.
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)
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
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
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
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
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
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
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
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
> 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)
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
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
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
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
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
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)
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)
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)
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)
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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'
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'
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'
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.
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
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?
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
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
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
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
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
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'
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
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
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
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
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
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
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
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
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