Re: [ANNOUNCE] xorg-server 1.7.5.901
On Friday 05 of March 2010, Peter Hutterer wrote: The first and likely only RC for 1.7.6 with a bunch of fixes all over the place. This release finally brings the RECORD extension back, promised for more-or-less every point release since 1.7.0. There's one more record-related patch on the list that I want to get into 1.7.6 but other than that I think we're shaping up quite nicely. Note that the minimum requirements have changed to libselinux 2.0.86 (released before 1.7.0 came out, so that shouldn't be an issue for most of you). I have kernel without selinux compiled in but xserver with xselinux support enabled. The result is that it starts but then hangs with black screen at (II) Initializing built-in extension DAMAGE (and the next line should be something like) (II) AIGLX: enabled GLX_MESA_copy_sub_buffer http://pastebin.ca/1823566 Didn't test 1.7.5 or any other version with selinux enabled. 1.7.5.901 was first here with selinux. Disabling xselinux and the problem is gone. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [ANNOUNCE] xorg-server 1.7.5.901
On Fri, 2010-03-05 at 08:51 +0100, Arkadiusz Miskiewicz wrote: On Friday 05 of March 2010, Peter Hutterer wrote: The first and likely only RC for 1.7.6 with a bunch of fixes all over the place. This release finally brings the RECORD extension back, promised for more-or-less every point release since 1.7.0. There's one more record-related patch on the list that I want to get into 1.7.6 but other than that I think we're shaping up quite nicely. Note that the minimum requirements have changed to libselinux 2.0.86 (released before 1.7.0 came out, so that shouldn't be an issue for most of you). I have kernel without selinux compiled in but xserver with xselinux support enabled. The result is that it starts but then hangs with black screen at (II) Initializing built-in extension DAMAGE (and the next line should be something like) (II) AIGLX: enabled GLX_MESA_copy_sub_buffer http://pastebin.ca/1823566 Is there more information in the X server's stderr output? (Should be in the g/kdm log file if you're using that) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCHv10 4/5] dri2: Support the DRI2InvalidateBuffers event.
Peter Hutterer peter.hutte...@who-t.net writes:
On Mon, Mar 01, 2010 at 08:19:44PM +0100, Francisco Jerez wrote:
Bumps the supported DRI2 protocol version.
Signed-off-by: Francisco Jerez curroje...@riseup.net
---
v10: Move resource allocation to dri2ext.c.
configure.ac|2 +-
hw/xfree86/dri2/dri2.c | 122
+++
hw/xfree86/dri2/dri2.h |6 ++
hw/xfree86/dri2/dri2ext.c | 75 ++-
include/protocol-versions.h |2 +-
5 files changed, 204 insertions(+), 3 deletions(-)
[...]
+static void
+DRI2ConfigNotify(WindowPtr pWin, int x, int y, int w, int h, int bw,
+ WindowPtr pSib)
+{
+DrawablePtr pDraw = (DrawablePtr)pWin;
+ScreenPtr pScreen = pDraw-pScreen;
+DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
+DRI2DrawablePtr dd = DRI2GetDrawable(pDraw);
+
+if (ds-ConfigNotify) {
+UNWRAP(pScreen, ds, ConfigNotify);
+(*pScreen-ConfigNotify)(pWin, x, y, w, h, bw, pSib);
+WRAP(pScreen, ds, ConfigNotify, DRI2ConfigNotify);
+}
I don't think this is correct just yet. You're always forcing
DRI2ConfigNotify back after the wrap. What you should be doing though is
popping back whatever was there before. Otherwise, having a different
nesting order will screw up the wrapping code.
See 664ac92d8bbe956dd6fd80fac5dc3161028803b2 for a case where this has
bitten us once already. this may not be possible with the current code, but
better be safe than sorry.
I thought the whole point of this unwrap-call-and-rewrap model was that
each link in the chain can safely assume that it'll be at the top of the
stack whenever it's called.
If we cannot rely on this assumption anyway, could you explain me how
the change you're proposing is better than a plain:
+if (ds-ConfigNotify)
+ (*ds-ConfigNotify)(pWin, x, y, w, h, bw, pSib);
+
IIUC, the roots of the problem fixed by 664ac92d8 were functions like
ProcXFixesHideCursor that were calling CursorDisplayCursor directly
instead of invoking the whole chain.
+
+if (dd (dd-width != w || dd-height != h))
+DRI2InvalidateDrawable(pDraw);
+}
+
Bool
DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
{
@@ -869,6 +989,8 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
dixSetPrivate(pScreen-devPrivates, dri2ScreenPrivateKey, ds);
+WRAP(pScreen, ds, ConfigNotify, DRI2ConfigNotify);
this one is fine, since you're initializing it here.
Cheers,
Peter
+
xf86DrvMsg(pScreen-myNum, X_INFO, [DRI2] Setup complete\n);
for (i = 0; i sizeof(driverTypeNames) / sizeof(driverTypeNames[0]);
i++) {
if (i ds-numDrivers ds-driverNames[i]) {
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index 1c8626b..1d5190f 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -265,4 +265,10 @@ extern _X_EXPORT void DRI2WaitMSCComplete(ClientPtr
client, DrawablePtr pDraw,
int frame, unsigned int tv_sec,
unsigned int tv_usec);
+extern _X_EXPORT int DRI2TrackClient(DrawablePtr pDraw, int id,
+ void (*invalidate)(DrawablePtr, void *),
+ void (*destroy)(DrawablePtr, void *),
+ void *priv);
+extern _X_EXPORT void DRI2UntrackClient(DrawablePtr pDraw, int id);
+
#endif
diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
index bd92fd3..5644fe5 100644
--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -52,6 +52,7 @@
static ExtensionEntry *dri2Extension;
static RESTYPE dri2DrawableRes;
+static RESTYPE dri2ClientRefRes;
static Bool
validDrawable(ClientPtr client, XID drawable, Mask access_mode,
@@ -197,6 +198,60 @@ ProcDRI2DestroyDrawable(ClientPtr client)
return client-noClientException;
}
+static void
+DRI2InvalidateEvent(DrawablePtr pDraw, void *priv)
+{
+XID *id = priv;
+ClientPtr client = clients[CLIENT_ID(*id)];
+xDRI2InvalidateBuffers event;
+
+if (!client || client-clientGone)
+return;
+
+event.type = DRI2EventBase + DRI2_InvalidateBuffers;
+event.sequenceNumber = client-sequence;
+event.drawable = pDraw-id;
+
+WriteEventsToClient(client, 1, (xEvent *)event);
+}
+
+static void
+DRI2InvalidateDestroy(DrawablePtr pDraw, void *priv)
+{
+XID *id = priv;
+
+FreeResource(*id, dri2ClientRefRes);
+xfree(id);
+}
+
+static int
+track_client(ClientPtr client, DrawablePtr pDraw)
+{
+XID *id;
+int ret = BadAlloc;
+
+id = xalloc(sizeof(*id));
+if (!id)
+goto fail;
+
+/* Allocate a new resource for the client. */
+*id = FakeClientID(client-index);
+if (!AddResource(*id, dri2ClientRefRes, pDraw))
+goto fail;
+
+ret = DRI2TrackClient(pDraw,
[PULL] Minor bug-fixes discovered by static analysis.
are available in the git repository at: git://gitorious.org/omcfadde/xserver.git analysis Oliver McFadden (5): exa: exaFinishAccess: Overrun of static array pExaScr-access of size 6 at position 6 with index variable i fb: fbFinishScreenInit: leaked_storage: Variable (visuals|depths) goes out of scope parser: xf86readConfigFile: unreachable: This code cannot be reached: free(val.str); common: xf86Configure: alloc_strlen: Allocated memory does not have space for the terminating NUL of the string Xext: IdleTimeBlockHandler: unsigned_compare: Comparing unsigned less than zero is never true. timeout 0UL Xext/sync.c |4 +--- exa/exa.c |4 ++-- fb/fbscreen.c |4 hw/xfree86/common/xf86Configure.c |2 +- hw/xfree86/parser/read.c |4 ++-- 5 files changed, 10 insertions(+), 8 deletions(-) ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [ANNOUNCE] xorg-server 1.7.5.901
2010/3/5 Arkadiusz Miskiewicz ar...@maven.pl: On Friday 05 of March 2010, Michel Dänzer wrote: On Fri, 2010-03-05 at 08:51 +0100, Arkadiusz Miskiewicz wrote: On Friday 05 of March 2010, Peter Hutterer wrote: The first and likely only RC for 1.7.6 with a bunch of fixes all over the place. This release finally brings the RECORD extension back, promised for more-or-less every point release since 1.7.0. There's one more record-related patch on the list that I want to get into 1.7.6 but other than that I think we're shaping up quite nicely. Note that the minimum requirements have changed to libselinux 2.0.86 (released before 1.7.0 came out, so that shouldn't be an issue for most of you). I have kernel without selinux compiled in but xserver with xselinux support enabled. The result is that it starts but then hangs with black screen at (II) Initializing built-in extension DAMAGE (and the next line should be something like) (II) AIGLX: enabled GLX_MESA_copy_sub_buffer http://pastebin.ca/1823566 Is there more information in the X server's stderr output? (Should be in the g/kdm log file if you're using that) Ah, there is, some incorrect linking: /usr/bin/X: symbol lookup error: /usr/lib64/xorg/modules/extensions/libextmod.so: undefined symbol: is_selinux_enabled The reason behind this problem coming up now is the change from AC_CHECK_LIB to PKG_CHECK_MODULES for getting the selinux libs. When we were using AC_CHECK_LIB, -lselinux -laudit were inadvertently being set in $LIBS, which meant they where linked to every binary in the source tree. Now, with PKG_CHECK_MODULES, we're explicitly using $SELINUX_LIBS, and apparently not doing a good enough job of it. Is X at least linked to the right libraries? If not, then I think what we need to do is add them Xext/libXextmodule.la. Something like the attached patch should work, but I'm not sure it's the right thing. -- Dan 0001-Xext-Link-to-external-libraries-when-necessary.patch Description: application/mbox ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Fix null pointer dereference in xf86_reload_cursors().
On Mar 01, 10 02:11:36 +0100, Cyril Brulebois wrote: Upon resume, X may try to dereference a null pointer, which has been reported in Debian bug #507916 (http://bugs.debian.org/507916). Jim Paris came up with a patch which solves the problem for him. Here's a (hopefully) fixed version of his patch (without the typo). Cc: Jim Paris j...@jtan.com Signed-off-by: Cyril Brulebois k...@debian.org --- hw/xfree86/modes/xf86Cursors.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c index 385848b..d6e747f 100644 --- a/hw/xfree86/modes/xf86Cursors.c +++ b/hw/xfree86/modes/xf86Cursors.c @@ -611,7 +611,7 @@ xf86_reload_cursors (ScreenPtr screen) cursor_screen_priv = dixLookupPrivate(screen-devPrivates, xf86CursorScreenKey); /* return if HW cursor is inactive, to avoid displaying two cursors */ -if (!cursor_screen_priv-isUp) +if (!cursor_screen_priv || !cursor_screen_priv-isUp) return; scrn = xf86Screens[screen-myNum]; -- 1.7.0 Reviewed-By: Matthias Hopf mh...@suse.de Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 3/3] XQuartz: remove undefined XSERVER_CFLAGS variable
This is a variable local to configure.ac which is not AC_SUBST() It is undefined in any generated Makefile. Reviewed-by: Jeremy Huddleston jerem...@apple.com Signed-off-by: Gaetan Nadon mems...@videotron.ca --- hw/xquartz/GL/Makefile.am |2 +- hw/xquartz/Makefile.am |4 ++-- hw/xquartz/mach-startup/Makefile.am |2 +- hw/xquartz/xpr/Makefile.am |2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/hw/xquartz/GL/Makefile.am b/hw/xquartz/GL/Makefile.am index 9b61305..af89077 100644 --- a/hw/xquartz/GL/Makefile.am +++ b/hw/xquartz/GL/Makefile.am @@ -1,5 +1,5 @@ noinst_LTLIBRARIES = libCGLCore.la -AM_CFLAGS = $(XSERVER_CFLAGS) $(DIX_CFLAGS) +AM_CFLAGS = $(DIX_CFLAGS) AM_CPPFLAGS = \ -I$(top_srcdir) \ -I$(top_srcdir)/glx \ diff --git a/hw/xquartz/Makefile.am b/hw/xquartz/Makefile.am index 65c70b0..96b139f 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) -AM_OBJCFLAGS = $(XSERVER_CFLAGS) $(DIX_CFLAGS) +AM_CFLAGS = $(DIX_CFLAGS) +AM_OBJCFLAGS = $(DIX_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 334f06d..4dff45a 100644 --- a/hw/xquartz/mach-startup/Makefile.am +++ b/hw/xquartz/mach-startup/Makefile.am @@ -3,7 +3,7 @@ AM_CPPFLAGS = \ -DXSERVER_VERSION=\$(VERSION)\ \ -DX11BINDIR=\$(bindir)\ -AM_CFLAGS = $(XSERVER_CFLAGS) $(DIX_CFLAGS) +AM_CFLAGS = $(DIX_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 ba7b258..763a7cd 100644 --- a/hw/xquartz/xpr/Makefile.am +++ b/hw/xquartz/xpr/Makefile.am @@ -1,6 +1,6 @@ noinst_LTLIBRARIES = libXquartzXpr.la -AM_CFLAGS = $(XSERVER_CFLAGS) $(DIX_CFLAGS) +AM_CFLAGS = $(DIX_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
[PATCH util-macros 0/1] Add XORG_PROJECT_ALL_CFLAGS for X.Org project compiler options
Following the review http://lists.x.org/archives/xorg-devel/2010-February/005894.html here is the proposed patch after a few prototyping iterations. Requirements - Provides a hook for an emergency system fix due to compiler behavior change - Allow for an easy way to experiment various compiler options on the system on a private local build - Implement project wide policies such as warning and optimization flags The word system here refers to all modules shipped as part of a release. Macros -- XORG_PROJECT_WARN_CFLAGS: defines Automake variable $(PROJECT_WARN_CFLAGS) $(PROJECT_WARN_CFLAGS): contains -Wall and friends plus $(STRICT_CFLAGS) (but no -fno-strict-aliasing) XORG_PROJECT_OPTIMIZE_CFLAGS: defines Automake variable $(PROJECT_OPTIMIZE_CFLAGS) $(PROJECT_OPTIMIZE_CFLAGS): contains -fno-strict-aliasing XORG_PROJECT_ALL_CFLAGS: defines Automake variable $(PROJECT_ALL_CFLAGS) $(PROJECT_ALL_CFLAGS):=$PROJECT_WARN_CFLAGS $PROJECT_OPTIMIZE_CFLAGS The existing STRICT_CFLAGS had to be integrated in the new macro to preserve backward compatibility (--enable-strict-compilation) Usage in Makefile.am AM_CFLAGS = [...] $(PROJECT_ALL_CFLAGS) [...] (replacing CWARNFLAGS in all modules) $(PROJECT_ALL_CFLAGS) will be added to modules which never had CWARNFLAGS before. Backward compatibility -- CWARNFLAGS is left intact and is available to all modules, past, present and future. The util-macros package versioning -- For those unfamiliar with the util-macros package, the versioning strategy is to add modify, e.g. add new features and fix bugs in existing features. This does not allow to remove or change a functionality upon which current and past modules depend. The concept of minimum version is used, meaning the oldest macros package against which a module can function correctly, even if it missing some features or bug fixes. Extensibility - This patch follows the macros package versioning, so the CWARNFLAGS macro cannot be removed. It will therefore be available for future module versions. It will always be defined in the Makefile in addition to PROJECT_ALL_CFLAGS. If in the future we ever need to remove or change one of the new *_CFLAGS, we will be in the same situation as we are today. Rather than creating a new set of variable names, we can modify the macros package versioning strategy (for compiler options only) whereby older modules will receive older versions of the compiler options and newer modules get newer ones. A design is in place with commented out code to illustrate how this would work. We can, if we want, use this strategy to make unavailable CWARNFLAGS for new versions of modules. Gaetan Nadon (1): Add XORG_PROJECT_ALL_CFLAGS for X.Org project compiler options xorg-macros.m4.in | 171 +++-- 1 files changed, 165 insertions(+), 6 deletions(-) ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH util-macros 1/1] Add XORG_PROJECT_ALL_CFLAGS for X.Org project compiler options
This macro is defined as containing a set of required compiler options for all X.Org modules, including xserver, libraries, drivers, fonts and apps. Additional compiler options are added locally by the each module. These options are set in each module makefile like this: AM_CFLAGS = $(PROJECT_ALL_CFLAGS) ... See Automake 27.6 Flag Variables Ordering. All Makefile.am should have it for C code targets for the following reasons: - Provides a hook for an emergency system fix due to compiler behavior change - Allow for an easy way to experiment various compiler options on the system on a private local build - Implement project wide policies such as warning flags As an organizing principle, this macro does not contain discrete compiler options but rather aggregates macros containing options based on their categories. Backward compatibility: the variable CWARNFLAGS is still available for older modules using it. Modules requesting version 1.7.0 or higher should not use it. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in | 171 +++-- 1 files changed, 165 insertions(+), 6 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 478e5fe..79de080 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -36,6 +36,8 @@ dnl DEALINGS IN THE SOFTWARE. # # See the minimum version comment for each macro you use to see what # version you require. +# xorg_macros_needed is required by XORG_PROJECT_ALL_CFLAGS related macros +# m4_defun([XORG_MACROS_VERSION],[ m4_define([vers_have], [...@version@]) m4_define([maj_have], m4_substr(vers_have, 0, m4_index(vers_have, [.]))) @@ -47,6 +49,7 @@ m4_if(m4_version_compare(vers_have, [$1]), -1, m4_undefine([vers_have]) m4_undefine([maj_have]) m4_undefine([maj_needed]) +m4_define([xorg_macros_needed],[$1]) ]) # XORG_MACROS_VERSION # XORG_PROG_RAWCPP() @@ -304,7 +307,7 @@ AC_SUBST(MAKE_PDF) AC_SUBST(MAKE_HTML) ]) # XORG_CHECK_DOCBOOK -# XORG_WITH_XMLTO +# XORG_WITH_XMLTO([MIN-VERSION]) # # Minimum version: 1.5.0 # @@ -352,6 +355,20 @@ elif test x$use_xmlto = xno ; then else AC_MSG_ERROR([--with-xmlto expects 'yes' or 'no']) fi +m4_ifval([$1], +[if test $have_xmlto = yes; then +# scrape the xmlto version +AC_MSG_CHECKING([the xmlto version]) +xmlto_version=`$XMLTO --version 2/dev/null | cut -d' ' -f3` +AC_MSG_RESULT([$xmlto_version]) +AS_VERSION_COMPARE([$xmlto_version], [$1], +[if test x$use_xmlto = xauto; then +AC_MSG_WARN([xmlto version $xmlto_version found, but $1 needed]) +have_xmlto=no +else +AC_MSG_ERROR([xmlto version $xmlto_version found, but $1 needed]) +fi]) +fi]) AM_CONDITIONAL([HAVE_XMLTO], [test $have_xmlto = yes]) ]) # XORG_CHECK_XMLTO @@ -870,11 +887,12 @@ AM_CONDITIONAL(MAKE_LINT_LIB, [test x$make_lint_lib != xno]) # XORG_CWARNFLAGS # --- # Minimum version: 1.2.0 +# Deprecated since 1.7.0. Use XORG_PROJECT_ALL_CFLAGS # # Defines CWARNFLAGS to enable C compiler warnings. # AC_DEFUN([XORG_CWARNFLAGS], [ -AC_REQUIRE([AC_PROG_CC]) +AC_REQUIRE([XORG_STRICT_OPTION]) if test x$GCC = xyes ; then CWARNFLAGS=-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes \ -Wmissing-declarations -Wnested-externs -fno-strict-aliasing \ @@ -890,6 +908,10 @@ else CWARNFLAGS=-v fi fi + +# Add strict cflags from xorg_strict_option which are also warning flags +CWARNFLAGS=$CWARNFLAGS $STRICT_CFLAGS + AC_SUBST(CWARNFLAGS) ]) # XORG_CWARNFLAGS @@ -898,10 +920,11 @@ AC_SUBST(CWARNFLAGS) # Minimum version: 1.3.0 # # Add configure option to enable strict compilation +# STRICT_CFLAGS is included in deprecated CWARNFLAGS and PROJECT_WARN_CFLAGS +# It cannot (and never could) be invoked directly from configure.ac AC_DEFUN([XORG_STRICT_OPTION], [ AC_REQUIRE([AC_PROG_CC]) AC_REQUIRE([AC_PROG_CC_C99]) -AC_REQUIRE([XORG_CWARNFLAGS]) AC_ARG_ENABLE(strict-compilation, AS_HELP_STRING([--enable-strict-compilation], @@ -918,8 +941,6 @@ if test x$STRICT_COMPILE = xyes; then STRICT_CFLAGS=-Werror fi fi -CWARNFLAGS=$CWARNFLAGS $STRICT_CFLAGS -AC_SUBST([CWARNFLAGS]) ]) # XORG_STRICT_OPTION # XORG_DEFAULT_OPTIONS @@ -929,8 +950,11 @@ AC_SUBST([CWARNFLAGS]) # Defines default options for X.Org modules. # AC_DEFUN([XORG_DEFAULT_OPTIONS], [ -XORG_CWARNFLAGS XORG_STRICT_OPTION +XORG_CWARNFLAGS +XORG_PROJECT_WARN_CFLAGS +XORG_PROJECT_OPTIMIZE_CFLAGS +XORG_PROJECT_ALL_CFLAGS XORG_RELEASE_VERSION XORG_CHANGELOG XORG_INSTALL @@ -955,3 +979,138 @@ mv \$(top_srcdir)/.INSTALL.tmp \$(top_srcdir)/INSTALL) \ echo 'util-macros \pkgdatadir\ from xorg-macros.pc not found: installing possibly empty INSTALL.' 2) AC_SUBST([INSTALL_CMD]) ]) # XORG_INSTALL + +# XORG_PROJECT_ALL_CFLAGS +# --- +# Minimum version: 1.7.0 +# +# Defines Automake PROJECT_ALL_CFLAGS variable. +# +#
[PATCH modular] build.sh: add xf86-input-penmount to the regular build
This module has a yearly release and is included in Debian.
Signed-off-by: Gaetan Nadon mems...@videotron.ca
---
build.sh |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/build.sh b/build.sh
index 1ba8bf5..79ae83a 100755
--- a/build.sh
+++ b/build.sh
@@ -484,6 +484,7 @@ build_driver_input() {
build driver xf86-input-acecad
build driver xf86-input-keyboard
build driver xf86-input-mouse
+build driver xf86-input-penmount
build driver xf86-input-synaptics
build driver xf86-input-void
}
--
1.6.0.4
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Patch] hw/xwin: remove glx subdirectory.
On 2010-03-05 08:42, Luc Verhaegen wrote: This code was the only reference left in the glproto glcore.h cruft (previous patch), and turned out to be a bit crufty itself, as these files were only listed in EXTRA_DIST in hw/xwin. If someone planned to revive this code, then please do so from the repository history; but you'll have your work cut out for you anyway :) There is already some effort by Jon Turney to revive XWin OpenGL hardware acceleration, and we plan to work on this during the 1.8 cycle. Please do not push this w/o his ack. Yaakov Cygwin/X ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [ANNOUNCE] xorg-server 1.7.5.901
Dan Nicholson wrote: Is X at least linked to the right libraries? If not, then I think what we need to do is add them Xext/libXextmodule.la. Something like the attached patch should work, but I'm not sure it's the right thing. I've been carrying around some similar patches in our builds to add library linking to the modules (not libselinux of course, but others) to resolve symbols since we build most of the drivers with -z defs to catch missing symbol errors at build time instead of runtime, and the modules they link against thus need to resolve their symbols. I've been slacking on upstreaming it, but it hasn't seemed to cause any problems in the several years we've had it.(The -R path is to handle our multilib layout, and that part is definitely Solaris-specific.) --- hw/xfree86/dixmods/Makefile.am 2009-05-08 17:45:57.848078000 -0700 +++ hw/xfree86/dixmods/Makefile.am 2009-05-08 17:46:07.162324000 -0700 @@ -36,6 +36,7 @@ libdbe_la_SOURCES = dbemodule.c libfb_la_LDFLAGS = -avoid-version libfb_la_LIBADD = $(top_builddir)/fb/libfb.la +libfb_la_LIBADD += -lpixman-1 libfb_la_SOURCES = $(top_builddir)/fb/fbcmap_mi.c fbmodule.c libfb_la_CFLAGS = $(AM_CFLAGS) @@ -47,6 +48,8 @@ libwfb_la_CFLAGS = $(AM_CFLAGS) -DFB_ACC libglx_la_LDFLAGS = -avoid-version -mimpure-text if AIGLX GLXDRI_LIBRARY = $(top_builddir)/glx/libglxdri.la +libglx_la_LDFLAGS += -R$(extsmoduledir:amd64/extensions=extensions/amd64) +libglx_la_LDFLAGS += -Wl,-N,libdri.so -Wl,-N,libdri2.so endif libglx_la_LIBADD = \ $(top_builddir)/glx/libglx.la \ diff -urp -x '*~' -x '*.orig' hw/xfree86/int10/Makefile.am hw/xfree86/int10/Makefile.am --- hw/xfree86/int10/Makefile.am2007-10-17 07:01:23.0 -0700 +++ hw/xfree86/int10/Makefile.am2009-05-08 17:46:07.162854000 -0700 @@ -42,3 +42,5 @@ libint10_la_SOURCES = stub.c xf86int10mo endif EXTRA_DIST = xf86x86emu.h INT10.HOWTO + +libint10_la_LIBADD = $(PCIACCESS_LIBS) There's also a bunch to add a ton of -l flags to every driver too, but full -z defs linking of those relies on us building a linker mapfile in our builds that lists the symbols exported from the Xorg binary so that the linker can record those as resolved already, and I've not checked to see if the way I've done that is portable at all. An example of just adding the -l flags: http://src.opensolaris.org/source/xref/x-cons/xnv-clone/open-src/driver/xf86-video-intel/libraries.patch -- -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
Re: [Patch] hw/xwin: remove glx subdirectory.
On 05/03/2010 14:42, Luc Verhaegen wrote: This code was the only reference left in the glproto glcore.h cruft (previous patch), and turned out to be a bit crufty itself, as these files were only listed in EXTRA_DIST in hw/xwin. If someone planned to revive this code, then please do so from the repository history; but you'll have your work cut out for you anyway :) Actually, I have a rewrite for this code to actually make it do something useful again (see [1]), but since it depends on a few DIX changes which probably require review, I wasn't going to propose that until post-1.8. Given that, can we keep it around a bit longer, please :-) [1] http://cgit.freedesktop.org/~jturney/xserver/log/?h=cygwin-aiglx-for-master ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [ANNOUNCE] xorg-server 1.7.5.901
On Fri, Mar 5, 2010 at 8:15 AM, Alan Coopersmith alan.coopersm...@sun.com wrote: Dan Nicholson wrote: Is X at least linked to the right libraries? If not, then I think what we need to do is add them Xext/libXextmodule.la. Something like the attached patch should work, but I'm not sure it's the right thing. I've been carrying around some similar patches in our builds to add library linking to the modules (not libselinux of course, but others) to resolve symbols since we build most of the drivers with -z defs to catch missing symbol errors at build time instead of runtime, and the modules they link against thus need to resolve their symbols. I've been slacking on upstreaming it, but it hasn't seemed to cause any problems in the several years we've had it. (The -R path is to handle our multilib layout, and that part is definitely Solaris-specific.) --- hw/xfree86/dixmods/Makefile.am 2009-05-08 17:45:57.848078000 -0700 +++ hw/xfree86/dixmods/Makefile.am 2009-05-08 17:46:07.162324000 -0700 @@ -36,6 +36,7 @@ libdbe_la_SOURCES = dbemodule.c libfb_la_LDFLAGS = -avoid-version libfb_la_LIBADD = $(top_builddir)/fb/libfb.la +libfb_la_LIBADD += -lpixman-1 libfb_la_SOURCES = $(top_builddir)/fb/fbcmap_mi.c fbmodule.c libfb_la_CFLAGS = $(AM_CFLAGS) @@ -47,6 +48,8 @@ libwfb_la_CFLAGS = $(AM_CFLAGS) -DFB_ACC libglx_la_LDFLAGS = -avoid-version -mimpure-text if AIGLX GLXDRI_LIBRARY = $(top_builddir)/glx/libglxdri.la +libglx_la_LDFLAGS += -R$(extsmoduledir:amd64/extensions=extensions/amd64) +libglx_la_LDFLAGS += -Wl,-N,libdri.so -Wl,-N,libdri2.so endif libglx_la_LIBADD = \ $(top_builddir)/glx/libglx.la \ diff -urp -x '*~' -x '*.orig' hw/xfree86/int10/Makefile.am hw/xfree86/int10/Makefile.am --- hw/xfree86/int10/Makefile.am 2007-10-17 07:01:23.0 -0700 +++ hw/xfree86/int10/Makefile.am 2009-05-08 17:46:07.162854000 -0700 @@ -42,3 +42,5 @@ libint10_la_SOURCES = stub.c xf86int10mo endif EXTRA_DIST = xf86x86emu.h INT10.HOWTO + +libint10_la_LIBADD = $(PCIACCESS_LIBS) There's also a bunch to add a ton of -l flags to every driver too, but full -z defs linking of those relies on us building a linker mapfile in our builds that lists the symbols exported from the Xorg binary so that the linker can record those as resolved already, and I've not checked to see if the way I've done that is portable at all. An example of just adding the -l flags: http://src.opensolaris.org/source/xref/x-cons/xnv-clone/open-src/driver/xf86-video-intel/libraries.patch Yeah, this seems like a good idea. Just for sanity's sake, we should be doing the LIBADD at the level where the symbols are actually used instead of just piling a bunch of libraries onto the ddx. libtool will take care of pulling together the correct linking for us. I've been thinking about this for a while, but wading into the XORG_LIBS/XSERVER_LIBS/XSERVER_SYS_LIBS/X_PLEASE_GIVE_ME_A_HOME_LIBS quagmire doesn't seem like a fun way to spend my time. If I had to guess, Arkadiusz's issue is that he is linking with --as-needed, and the linker throws out -lselinux because Xorg doesn't actually need it. If the linking was done on libextmod.la, it would match to the actual symbols used. -- Dan ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2: fixup handling of last_swap_target
On Thu, 4 Mar 2010 23:42:06 +0100 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: On Mar 4, 2010, at 7:45 PM, Jesse Barnes wrote: I just pushed everything into my personal xserver tree, can you check them out and make sure I got your patches right? git://people.freedesktop.org/~jbarnes/xserver Ok pushed fixes for these issues to the repo above. I know you've put a lot of time into this already, but can you take another look to make sure I got everything? Note I left the swap interval default at 1 since GLX_MESA_swap_control should let us set it to 0 to get unthrottled behavior, which I just fixed and tested. Thanks a ton for your review, it's been very helpful. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Patch] hw/xwin: remove glx subdirectory.
Hi, Any new hw/xwin/glx code (thanks John Turney) does not need to include the glcore.h file. So best go ahead and sync up the gl headers and glapi/indirect code anyway between Mesa, glproto and xserver/glx. AFAICS should not be a problem for the xwin ddx. Thanks, Colin harrison ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xf86-video-intel 2/2] Fix handling of target_msc, divisor, remainder in I830DRI2ScheduleSwap()
On Sun, 21 Feb 2010 18:45:48 +0100 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: The current code in I830DRI2ScheduleSwap() only schedules the correct vblank events for the case divisor == 0, i.e., the simple glXSwapBuffers() case. In a glXSwapBuffersMscOML() request, divisor can be 0, which would go wrong. This modified code should handle target_msc, divisor, remainder and the different cases defined in the OML_sync_control extension correctly for the divisor 0 case. It also tries to make sure that the effective framecount of swap satisfies all constraints, taking the 1 frame delay in pageflipping mode and possible delays in blitting/exchange mode due to DRM_VBLANK_NEXTONMISS into account. The swap_interval logic in the X-Servers DRI2SwapBuffers() call expects the returned swap_target from the DDX to be reasonably accurate, otherwise implementation of swap_interval for the glXSwapBuffers() as defined in the SGI_swap_interval extension may become unreliable. For non-pageflipped mode, the returned swap_target is always correct due to the adjustments done by drmWaitVBlank(), as DRM_VBLANK_NEXTONMISS is set. In pageflipped mode, DRM_VBLANK_NEXTONMISS can't be used without severe impact on performance, so the code in I830DRI2ScheduleSwap() must make manual adjustments to the returned vbl.reply.sequence number. This patch adds the needed adjustments. Signed-off-by: Mario Kleiner mario.klei...@tuebingen.mpg.de --- I just fixed these up and pushed them into the tree along with another fix for handling offscreen drawables better. Tests indicate that OML swap divisor/remainder stuff is working correctly now. Thanks! -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
