[PATCH 0/6] More fixes for configure
From: Yaakov Selkowitz yselkow...@users.sourceforge.net The primary goal of these patches is for the xserver build to succeed on Cygwin when configure is run without any arguments. They are otherwise unrelated, except that Add configure option for WindowsWM depends on Don't enable ROOTLESS_WORKAROUND to apply. Jon TURNEY (1): Don't enable ROOTLESS_WORKAROUND, it breaks composite Yaakov Selkowitz (5): Cygwin/X: Add configure option for WindowsWM Disable setuid configure test on Cygwin Use SED set by libtool macros Ignore linuxdoc generated docs Cygwin/X: Disable unsupported extensions in configure configure.ac | 46 - hw/dmx/doc/.gitignore |3 ++ hw/xfree86/doc/sgml/.gitignore |4 +++ 3 files changed, 34 insertions(+), 19 deletions(-) create mode 100644 hw/xfree86/doc/sgml/.gitignore ___ 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] Disable setuid configure test on Cygwin
From: Yaakov Selkowitz yselkow...@users.sourceforge.net Only Xorg is installed setuid, so there is no need to run this configure test on Cygwin. Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net --- configure.ac |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 762565d..6b3c002 100644 --- a/configure.ac +++ b/configure.ac @@ -661,6 +661,7 @@ AC_ARG_ENABLE(install-setuid, AC_MSG_CHECKING([to see if we can install the Xorg server as root]) if test x$SETUID = xauto ; then case $host_os in + cygwin*)SETUID=no ;; darwin*)SETUID=no ;; *) case $host_cpu in -- 1.6.6.1 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Use SED set by libtool macros
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
We now use libtool, which calls AC_PROG_SED and sets SED as the path to
a fully-functional 'sed' (which may also be called 'gsed' if GNU sed is
installed alongside a proprietary version). Therefore we should respect
this value of SED so we are sure to use the correct one.
This is a follow up to commit 9be4157391edf0c5fc4ee36adfb1eb1c3bdb8e3b.
Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net
---
configure.ac |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 6b3c002..e9f9453 100644
--- a/configure.ac
+++ b/configure.ac
@@ -77,7 +77,6 @@ AC_PROG_LEX
AC_PROG_YACC
AC_SYS_LARGEFILE
XORG_PROG_RAWCPP
-AC_PATH_PROG(SED,sed)
# Quoted so that make will expand $(CWARNFLAGS) in makefiles to allow
# easier overrides at build time.
@@ -1152,8 +1151,8 @@ fi
dnl XKM_OUTPUT_DIR (used in code) must end in / or file names get hosed
dnl XKB_COMPILED_DIR (used in Makefiles) must not or install-sh gets confused
-XKBOUTPUT=`echo $XKBOUTPUT/ | sed 's|/*$|/|'`
-XKB_COMPILED_DIR=`echo $XKBOUTPUT | sed 's|/*$||'`
+XKBOUTPUT=`echo $XKBOUTPUT/ | $SED 's|/*$|/|'`
+XKB_COMPILED_DIR=`echo $XKBOUTPUT | $SED 's|/*$||'`
AC_DEFINE_DIR(XKM_OUTPUT_DIR, XKBOUTPUT, [Path to XKB output dir])
AC_SUBST(XKB_COMPILED_DIR)
@@ -1631,11 +1630,11 @@ if test x$XORG = xyes; then
AC_CHECK_HEADERS([sys/vt.h], [solaris_vt=yes], [solaris_vt=no])
# Check for minimum supported release
AC_MSG_CHECKING([Solaris version])
- OS_MINOR=`echo ${host_os}|sed -e 's/^.*solaris2\.//' -e
s'/\..*$//'`
+ OS_MINOR=`echo ${host_os}|$SED -e 's/^.*solaris2\.//' -e
s'/\..*$//'`
if test ${OS_MINOR} -ge 7 ; then
AC_MSG_RESULT(Solaris ${OS_MINOR})
else
- AC_MSG_RESULT(Solaris `echo ${host_os}|sed -e
's/^.*solaris//`)
+ AC_MSG_RESULT(Solaris `echo ${host_os}|$SED -e
's/^.*solaris//`)
fi
if test ${OS_MINOR} -lt 8 ; then
AC_MSG_ERROR([This release no longer supports Solaris
versions older than Solaris 8.])
--
1.6.6.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Cygwin/X: Disable unsupported extensions in configure
From: Yaakov Selkowitz yselkow...@users.sourceforge.net Several extensions are not supported by XWin, some of which are enabled by default in configure. We forcefully disable these early on so that configure will succeed without arguments and without the corresponding proto installed. Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net --- configure.ac | 14 +- 1 files changed, 9 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 55e9156..6a2afd1 100644 --- a/configure.ac +++ b/configure.ac @@ -721,8 +721,16 @@ XORG_CHECK_LINUXDOC dnl Handle installing libxf86config AM_CONDITIONAL(INSTALL_LIBXF86CONFIG, [test x$INSTALL_LIBXF86CONFIG = xyes]) -dnl XQuartz DDX Detection... Yes, it's ugly to have it here... but we need to handle this early on +dnl DDX Detection... Yes, it's ugly to have it here... but we need to +dnl handle this early on so that we don't require unsupported extensions case $host_os in + cygwin*) + DGA=no + DRI2=no + XF86VIDMODE=no + XSELINUX=no + XV=no + ;; darwin*) DRI2=no @@ -1882,10 +1890,6 @@ if test x$XWIN = xyes; then AC_DEFINE(DDXOSVERRORF, 1, [Use OsVendorVErrorF]) AC_DEFINE(DDXBEFORERESET, 1, [Use ddxBeforeReset ]) - if test x$XF86VIDMODE = xyes; then - AC_MSG_NOTICE([Disabling XF86VidMode extension]) - XF86VIDMODE=no - fi fi AM_CONDITIONAL(XWIN, [test x$XWIN = xyes]) AM_CONDITIONAL(XWIN_MULTIWINDOW, [test x$XWIN = xyes]) -- 1.6.6.1 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Don't enable ROOTLESS_WORKAROUND, it breaks composite
From: Jon TURNEY jon.tur...@dronecode.org.uk This possibly brings back whatever the bug is in http://bugs.freedesktop.org/show_bug.cgi?id=1168 for -rootless mode, but since we don't have reproduction steps for that, I can't test that... Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk Tested-by: Yaakov Selkowitz yselkow...@users.sourceforge.net Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net --- configure.ac |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index d379b3a..36b4dd9 100644 --- a/configure.ac +++ b/configure.ac @@ -1834,7 +1834,6 @@ if test x$XWIN = xyes; then dnl if we have windowswmproto, build rootless extension for multwindowextwm mode if test x$WINDOWSWM = xyes ; then AC_DEFINE(ROOTLESS,1,[Build Rootless code]) - CFLAGS=$CFLAGS -DROOTLESS_WORKAROUND fi ;; mingw*) -- 1.6.6.1 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Cygwin/X: Add configure option for WindowsWM
From: Yaakov Selkowitz yselkow...@users.sourceforge.net WindowsWM support is still experimental, and uses the Rootless extension which currently breaks the simultaneous build of the other DDXs (see commit b3415187e92960cbff784108b5a3a8d130dc34c5). So we disable it by default for now; once the latter issue is fixed we can make this 'auto'. Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net --- configure.ac | 21 + 1 files changed, 13 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index a27a220..762565d 100644 --- a/configure.ac +++ b/configure.ac @@ -631,6 +631,7 @@ AC_ARG_ENABLE(xaa, AS_HELP_STRING([--enable-xaa], [Build XAA (defa AC_ARG_ENABLE(vgahw, AS_HELP_STRING([--enable-vgahw], [Build Xorg with vga access (default: enabled)]), [VGAHW=$enableval], [VGAHW=yes]) AC_ARG_ENABLE(vbe,AS_HELP_STRING([--enable-vbe], [Build Xorg with VBE module (default: enabled)]), [VBE=$enableval], [VBE=yes]) AC_ARG_ENABLE(int10-module, AS_HELP_STRING([--enable-int10-module], [Build Xorg with int10 module (default: enabled)]), [INT10MODULE=$enableval], [INT10MODULE=yes]) +AC_ARG_ENABLE(windowswm, AS_HELP_STRING([--enable-windowswm], [Build XWin with WindowsWM extension (default: no)]), [WINDOWSWM=$enableval], [WINDOWSWM=no]) dnl DDXes. AC_ARG_ENABLE(xorg, AS_HELP_STRING([--enable-xorg], [Build Xorg server (default: auto)]), [XORG=$enableval], [XORG=auto]) @@ -1819,26 +1820,30 @@ fi AC_MSG_RESULT([$XWIN]) if test x$XWIN = xyes; then - PKG_CHECK_EXISTS($WINDOWSWMPROTO, [WINDOWSWM=yes], [WINDOWSWM=no]) AC_DEFINE_DIR(SYSCONFDIR, sysconfdir, [Location of system.XWinrc]) AC_DEFINE_DIR(DEFAULT_LOGDIR, logdir, [Default log location]) AC_DEFINE_UNQUOTED(XORG_VERSION_CURRENT, [$VENDOR_RELEASE], [Current Xorg version]) AC_DEFINE_UNQUOTED(__VENDORDWEBSUPPORT__, [$VENDOR_WEB], [Vendor web address for support]) AC_CHECK_TOOL(WINDRES, windres) + + PKG_CHECK_MODULES([XWINMODULES],[x11 xdmcp xau xfont]) + + if test x$WINDOWSWM = xauto; then + PKG_CHECK_EXISTS($WINDOWSWMPROTO, [WINDOWSWM=yes], [WINDOWSWM=no]) + fi + if test x$WINDOWSWM = xyes ; then + PKG_CHECK_MODULES(WINDOWSWM, $WINDOWSWMPROTO) + XWINMODULES_CFLAGS=$XWINMODULES_CFLAGS $WINDOWSWM_CFLAGS + AC_DEFINE(ROOTLESS,1,[Build Rootless code]) + fi + case $host_os in cygwin*) XWIN_SERVER_NAME=XWin - PKG_CHECK_MODULES([XWINMODULES],[x11 xdmcp xau xfont]) AC_DEFINE(HAS_DEVWINDOWS,1,[Cygwin has /dev/windows for signaling new win32 messages]) - - dnl if we have windowswmproto, build rootless extension for multwindowextwm mode - if test x$WINDOWSWM = xyes ; then - AC_DEFINE(ROOTLESS,1,[Build Rootless code]) - fi ;; mingw*) XWIN_SERVER_NAME=Xming - PKG_CHECK_MODULES([XWINMODULES],[x11 xdmcp xau xfont]) AC_DEFINE(RELOCATE_PROJECTROOT,1,[Make PROJECT_ROOT relative to the xserver location]) AC_DEFINE(HAS_WINSOCK,1,[Use Windows sockets]) XWIN_SYS_LIBS=-lwinsock2 -- 1.6.6.1 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Multitouch followup: gesture recognition?
Only replying to one email, answers to both of your comments. On Wed, Mar 24, 2010 at 12:06:30AM +0100, Simon Thum wrote: [CC'ing Pter, see below] Am 23.03.2010 18:42, schrieb Florian Echtler: Just for my understanding: when talking about a special client, you think of something like a (compositing) window manager? Yes, 'special' since it registers itself for rights (and duties) only one client shall possess. why? can't the same library be used by multiple clients (thus unifying the gesture types) but the clients divide up the available region. This works well for button presses, couldn't it work with gestures as well? A library can be done 'right now', since apps are free to do so. It has the advantage of a close connection to the consuming app, but also the associated disadvantages. In particular, how to cope with global gestures, e.g. switching an app or backgrounding it? Apparently, such things should be consistent. I imagine a desktop environment might want to put up such a special client, like they have preference for their WM. Quite correct; this is a problem my standalone library also has right now. It's currently only supporting fullscreen clients properly. I'm no expert in X event routing, maybe this isn't such a big problem after all. As said, it's just a sketch. X events provide coordinates in root coordinates but also in event coordinates. My naïve view would be to start registering gestures for event coordinates 0/0 through to client width/height but _continue_ with the gesture rec stuff if the events coords fall outside the window after the first attempts. this way you can easily have two clients that share the same gesture lib. the main issue is with full-screen handling as you said - it'd be interesting to know if this could be solved with grabs (that's kind-of what they're for). § A new 'gesture' event gets created, like: [...] A prosaic example would be an app learning that there's a DIRECTED_DRAGGING gesture going on, starting at (200, 100)@70 degrees, now being at (300, 100)@95 deg and use this information to navigate within a 3D-view. Also note the omission of (x,y) from the general gesture event, since I'd deem it specific. Other gestures may not have a primary x,y. I agree, this is quite similar to the way I have implemented it right now. This applies, e.g., to a relative motion gesture which only delivers a vector. I took this particular example from a table project I'll be working with soon. It actually covers a vector _and_ a movement, independently derived from two touch points. Nice for camera navigation. § A special gesture client (composite-like) This client might receive events as discussed - but all of them - by virtue of registering with the server. It analyzes the stream, and whenever it thinks something important happened, it tells the server. The server then dispatches a corresponding gesture event, according to its state and some constraints given by the special client (e.g. Florian's event regions, gesture-specific delivery constraints, ...) which may not be part of the event as delivered. What kind of events are you considering here? The hypothetical gesture event, as arriving in a gesture-aware client. It may not contain information like delivery constraints; it's business is just that it got the event. Could a client generate new XI events? I don't have the impression this would suit it, though I could be wrong. At any rate, a client can't create a new event _type_. It can create some events though, e.g. via XTst, of predefined types. My idea was that the special client instructs the server what gesture events to generate and how to dispatch them, whenever it thinks it has spotted a gesture. The server tracks some minimal state to ensure consistency and dispatches on behalf of the special gesture client. Peter, maybe you can comment how suitable current mechanisms for input events from clients might be? it's reasonably easy to add new events to XI2 for testing and get them delivered to all clients. that'd be good enough for a hack, anyway. clients can't really do that though. my idea so far in that regard was that the library has two interfaces - a preprocessed one for library-internal gesture events and a raw interface for those clients that like pain. One reason why I'd rather not have the gesture library hooked into the server is that these libraries require quite some run-time tweaking - such a library would be worth its own extension including all disadvantages that come from that. The important point here is that gesture events are asynchronous, so there's no need to wait inside the event loop. Gestures correlate to, but don't strictly depend on other input events. Their timestamps may not be in order for this reason. Could you elaborate on that a bit more? I fear I'm missing some background information here. All X events have a
Re: [PATCH] Use SED set by libtool macros
Le 24/03/2010 07:21, Yaakov (Cygwin/X) a écrit : From: Yaakov Selkowitz yselkow...@users.sourceforge.net We now use libtool, which calls AC_PROG_SED and sets SED as the path to a fully-functional 'sed' (which may also be called 'gsed' if GNU sed is installed alongside a proprietary version). Therefore we should respect this value of SED so we are sure to use the correct one. Then configure should still call AC_PROG_SED explicitely. Relying on libtool's macros for that _will_ bite us at some point. The rest of the patch is fine. Cheers, Rémi ___ 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
A question for Xserver debug
Hi,all I am debugging the xserver code now. But one thing has puzzled me. When I add some modification to /dix/main.c , then make make install. Though the new main.c file has been compiled, no modification effect display. After that, I do some modification to /hw/xfree86/common/xf86Init.c. Do the same steps. The modification to main.c displays at the same time. Why this happens?? Thanks, Frank ___ 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] Fix x86emu builds when using non-gnu compilers
On Mon, 22 Mar 2010 18:03:53 -0700, Alan Coopersmith alan.coopersm...@sun.com wrote: Since 64-bit types are now required by x86emu, assumes all platforms either have a 64-bit long or a 64-bit long long (defined by C99). Don't we assume stdint.h exists yet? -- keith.pack...@intel.com pgpNk1IAuTQ77.pgp Description: PGP 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] Fix crash when all glyphs of a given depth are freed, but not all glyphsets
On Tue, 23 Mar 2010 12:39:30 -0400, Peter Harris phar...@opentext.com wrote: On 2010-03-23 12:26, Dan Nicholson wrote: I think Keith usually looks for an explicit CC to imply that patches are ready to be applied. I did CC: Keith. I'm just travelling; anything Cc'd to me ends up in my 'patchq' mailbox and gets applied unless I see dissent about it, sometimes it just takes a day or two if I'm stuck in an airplane or meetings. -- keith.pack...@intel.com pgp3ppbwmc9Rv.pgp Description: PGP 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] Fix crash when all glyphs of a given depth are freed, but not all glyphsets
On Wed, 2010-03-24 at 13:03 +0100, Keith Packard wrote: On Tue, 23 Mar 2010 12:39:30 -0400, Peter Harris phar...@opentext.com wrote: On 2010-03-23 12:26, Dan Nicholson wrote: I think Keith usually looks for an explicit CC to imply that patches are ready to be applied. I did CC: Keith. I'm just travelling; anything Cc'd to me ends up in my 'patchq' mailbox and gets applied unless I see dissent about it, sometimes it just takes a day or two if I'm stuck in an airplane or meetings. I suspect the confusion arose from the fact that posts sent out from the list don't show you in CC: even if the sender put you there. I think this is probably due to something in your list subscription settings. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ 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] Fix x86emu builds when using non-gnu compilers
Keith Packard wrote: On Mon, 22 Mar 2010 18:03:53 -0700, Alan Coopersmith alan.coopersm...@sun.com wrote: Since 64-bit types are now required by x86emu, assumes all platforms either have a 64-bit long or a 64-bit long long (defined by C99). Don't we assume stdint.h exists yet? Not yet - and I didn't dig to find out why, but some of the x86emu files that include this specifically avoid including system headers. (Could be more of the ancient xf86 module loader sillyness or something deeper.) -- -Alan Coopersmith- alan.coopersm...@sun.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
Re: A question for Xserver debug
Huang, FrankR wrote: Hi,all I am debugging the xserver code now. But one thing has puzzled me. When I add some modification to /dix/main.c , then make make install. Though the new main.c file has been compiled, no modification effect display. After that, I do some modification to /hw/xfree86/common/xf86Init.c. Do the same steps. The modification to main.c displays at the same time. Why this happens?? No one has ever gone through the exercise of ensuring the complex dependencies are properly setup to force rebuilding the Xorg server any time any related file changes. Sometimes you just have to manually rm hw/xfree86/Xorg and then make install. If this annoys you, we're happy to review proposed patches to improve it. -- -Alan Coopersmith- alan.coopersm...@sun.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
Re: [PATCH] Use SED set by libtool macros
On Wed, Mar 24, 2010 at 12:53 AM, Rémi Cardona r...@gentoo.org wrote: Le 24/03/2010 07:21, Yaakov (Cygwin/X) a écrit : From: Yaakov Selkowitz yselkow...@users.sourceforge.net We now use libtool, which calls AC_PROG_SED and sets SED as the path to a fully-functional 'sed' (which may also be called 'gsed' if GNU sed is installed alongside a proprietary version). Therefore we should respect this value of SED so we are sure to use the correct one. Then configure should still call AC_PROG_SED explicitely. Relying on libtool's macros for that _will_ bite us at some point. Agreed. I think what libtool's use of AC_PROG_SED tells us is that we can safely use it too (not like we wouldn't require sed anyway). But, yeah, this is a good fix. -- Dan ___ 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] Fix x86emu builds when using non-gnu compilers
On Wed, 24 Mar 2010 06:12:52 -0700, Alan Coopersmith alan.coopersm...@sun.com wrote: Not yet - and I didn't dig to find out why, but some of the x86emu files that include this specifically avoid including system headers. (Could be more of the ancient xf86 module loader sillyness or something deeper.) include/input.h uses stdint.h, clearly it's part of our required system interface for the server now. -- keith.pack...@intel.com pgp5kVWIvGBZU.pgp Description: PGP 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: [Pixman] [PATCH] Fix server crash in pixman (to be discussed) (fwd)
Grrr. Still wrong mailing list. Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ---BeginMessage--- On Mar 24, 10 13:25:13 +0200, Jonathan Morton wrote: Drawing a string containing spaces but also other characters would result in a non-degenerate region, presumably. So the bug might be triggered by a string containing only a space. Sounds reasonable. It may be appropriate to use a belt and braces approach here - prevent the degenerate regions from being created, *and* have the PIXREGION_NIL macro handle them. Also sounds reasonable. Glyphs are apparently only rendered in a few places in the Xserver, so this should be doable. Exa apparently already handles this correctly. Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ---End Message--- ___ 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 2] Xserver: Don't call CompositePicture() for empty glyphs
On Mar 24, 10 13:08:01 +0100, Matthias Hopf wrote:
It may be appropriate to use a belt and braces approach here - prevent
the degenerate regions from being created, *and* have the PIXREGION_NIL
macro handle them.
Ok, commit pushed in pixman.
The following patch for the Xserver should fix the issue as well.
Please review and commit!
Thanks
Matthias
--
Matthias Hopf mh...@suse.de ____ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de
From d6601c8641901cbe21e77453718eeae74251a442 Mon Sep 17 00:00:00 2001
From: Matthias Hopf mh...@suse.de
Date: Wed, 24 Mar 2010 14:38:36 +0100
Subject: [PATCH] Don't call CompositePicture() for empty glyphs.
Fixes Novell bug 568811:
VNC Installation aborts right in the middle due to an assertion in Xvnc/libpixman
Signed-off-by: Matthias Hopf mh...@suse.de
---
exa/exa_glyphs.c |3 +++
render/glyph.c |2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/exa/exa_glyphs.c b/exa/exa_glyphs.c
index fd14e9b..f647854 100644
--- a/exa/exa_glyphs.c
+++ b/exa/exa_glyphs.c
@@ -374,6 +374,9 @@ exaGlyphCacheUploadGlyph(ScreenPtr pScreen,
ExaPixmapPriv(pGlyphPixmap);
PixmapPtr pCachePixmap = (PixmapPtr)cache-picture-pDrawable;
+if (! pGlyph-info.width || ! pGlyph-info.height)
+ return;
+
if (!pExaScr-info-UploadToScreen || pExaScr-swappedOut || pExaPixmap-accel_blocked)
goto composite;
diff --git a/render/glyph.c b/render/glyph.c
index 0b864ad..66fef09 100644
--- a/render/glyph.c
+++ b/render/glyph.c
@@ -705,7 +705,7 @@ miGlyphs (CARD8 op,
glyph = *glyphs++;
pPicture = GlyphPicture (glyph)[pScreen-myNum];
- if (pPicture)
+ if (pPicture glyph-info.width glyph-info.height)
{
if (maskFormat)
{
--
1.6.0.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
GSoC project idea: input support for XCB
Hello, I have already updated SummerOfCodeIdeas wiki page about that but as it's coming a bit late in the GSoC schedule, I'm also posting this here. So, here is a project idea for the GSoC: One of the main area preventing XCB wide adoption over Xlib is input support. There are some information there[0] (incomplete ATM but it's a work in progress) about the current status. This SoC project involves porting Xlib keyboard functions to XCB and working on related X extensions (such as XKB, XKB2...). You don't really have to know XCB, so this project would definitely be a really good starting point if you are interested in low-level X programming and work on something that will be widely used (XCB is supposed to be the future of X client library). If a student is interested in writing a proposal for this subject, don't hesitate to send an email to x...@lists.freedesktop.org. Regards, Arnaud Fontaine [0] http://xcb.freedesktop.org/XCBToDoKeyboard ___ 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
On Mar 23, 10 06:45:00 -0700, Alan Coopersmith wrote: Matthias Hopf wrote: On Mar 22, 10 17:50:38 -0700, Jeremy Huddleston wrote: Actually, it was a valid error. The assignment was doing |= rather than =, and the current value was garbage. ? |= looks correct. Jeremy's right though - the struct is allocated on the stack, uninitialized, 2 lines previous, and no value was set first so the |= is doing cn.changedControls = (uninitalized) | XkbControlsEnabledMask; Eeek. Yes, overlooked that. 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@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/2] xts5: Remove an unneeded $(EXEEXT)
tprogs lists the test programs without $(EXEEXT), so substituting the $(EXEEXT) with .c to get BUILD_SOURCES fails to work correctly when $(EXEEXT) isn't empty Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- xts5/XI/Makefile.am |2 +- xts5/XIproto/Makefile.am |2 +- xts5/Xlib10/Makefile.am |2 +- xts5/Xlib11/Makefile.am |2 +- xts5/Xlib12/Makefile.am |2 +- xts5/Xlib13/Makefile.am |2 +- xts5/Xlib14/Makefile.am |2 +- xts5/Xlib15/Makefile.am |2 +- xts5/Xlib16/Makefile.am |2 +- xts5/Xlib17/Makefile.am |2 +- xts5/Xlib3/Makefile.am |2 +- xts5/Xlib4/Makefile.am |2 +- xts5/Xlib5/Makefile.am |2 +- xts5/Xlib6/Makefile.am |2 +- xts5/Xlib7/Makefile.am |2 +- xts5/Xlib8/Makefile.am |2 +- xts5/Xlib9/Makefile.am |2 +- xts5/Xopen/Makefile.am |2 +- xts5/Xproto/Makefile.am |2 +- 19 files changed, 19 insertions(+), 19 deletions(-) diff --git a/xts5/XI/Makefile.am b/xts5/XI/Makefile.am index 2364f2f..7c6e95a 100644 --- a/xts5/XI/Makefile.am +++ b/xts5/XI/Makefile.am @@ -14,7 +14,7 @@ LDADD = $(top_builddir)/src/tet3/tcm/libtcmmain.la \ testprogdir = $(libexecdir)/$(subdir) nobase_testprog_PROGRAMS = $(tprogs) -BUILT_SOURCES = $(tprogs:$(EXEEXT)=.c) +BUILT_SOURCES = $(tprogs:=.c) CLEANFILES = $(BUILT_SOURCES) tprogs = \ diff --git a/xts5/XIproto/Makefile.am b/xts5/XIproto/Makefile.am index 3200200..986f864 100644 --- a/xts5/XIproto/Makefile.am +++ b/xts5/XIproto/Makefile.am @@ -14,7 +14,7 @@ LDADD = $(top_builddir)/src/tet3/tcm/libtcmmain.la \ testprogdir = $(libexecdir)/$(subdir) nobase_testprog_PROGRAMS = $(tprogs) -BUILT_SOURCES = $(tprogs:$(EXEEXT)=.c) +BUILT_SOURCES = $(tprogs:=.c) CLEANFILES = $(BUILT_SOURCES) tprogs = \ diff --git a/xts5/Xlib10/Makefile.am b/xts5/Xlib10/Makefile.am index 1d72573..2812de5 100644 --- a/xts5/Xlib10/Makefile.am +++ b/xts5/Xlib10/Makefile.am @@ -14,7 +14,7 @@ LDADD = $(top_builddir)/src/tet3/tcm/libtcmmain.la \ testprogdir = $(libexecdir)/$(subdir) nobase_testprog_PROGRAMS = $(tprogs) -BUILT_SOURCES = $(tprogs:$(EXEEXT)=.c) +BUILT_SOURCES = $(tprogs:=.c) CLEANFILES = $(BUILT_SOURCES) tprogs = \ diff --git a/xts5/Xlib11/Makefile.am b/xts5/Xlib11/Makefile.am index 4d4834f..68fa129 100644 --- a/xts5/Xlib11/Makefile.am +++ b/xts5/Xlib11/Makefile.am @@ -14,7 +14,7 @@ LDADD = $(top_builddir)/src/tet3/tcm/libtcmmain.la \ testprogdir = $(libexecdir)/$(subdir) nobase_testprog_PROGRAMS = $(tprogs) -BUILT_SOURCES = $(tprogs:$(EXEEXT)=.c) +BUILT_SOURCES = $(tprogs:=.c) CLEANFILES = $(BUILT_SOURCES) tprogs = \ diff --git a/xts5/Xlib12/Makefile.am b/xts5/Xlib12/Makefile.am index b215452..36728e2 100644 --- a/xts5/Xlib12/Makefile.am +++ b/xts5/Xlib12/Makefile.am @@ -14,7 +14,7 @@ LDADD = $(top_builddir)/src/tet3/tcm/libtcmmain.la \ testprogdir = $(libexecdir)/$(subdir) nobase_testprog_PROGRAMS = $(tprogs) -BUILT_SOURCES = $(tprogs:$(EXEEXT)=.c) +BUILT_SOURCES = $(tprogs:=.c) CLEANFILES = $(BUILT_SOURCES) tprogs = \ diff --git a/xts5/Xlib13/Makefile.am b/xts5/Xlib13/Makefile.am index 14ff948..855f247 100644 --- a/xts5/Xlib13/Makefile.am +++ b/xts5/Xlib13/Makefile.am @@ -14,7 +14,7 @@ LDADD = $(top_builddir)/src/tet3/tcm/libtcmmain.la \ testprogdir = $(libexecdir)/$(subdir) nobase_testprog_PROGRAMS = $(tprogs) -BUILT_SOURCES = $(tprogs:$(EXEEXT)=.c) +BUILT_SOURCES = $(tprogs:=.c) CLEANFILES = $(BUILT_SOURCES) tprogs = \ diff --git a/xts5/Xlib14/Makefile.am b/xts5/Xlib14/Makefile.am index 9d50b46..df11217 100644 --- a/xts5/Xlib14/Makefile.am +++ b/xts5/Xlib14/Makefile.am @@ -15,7 +15,7 @@ LDADD = $(top_builddir)/src/tet3/tcm/libtcmmain.la \ testprogdir = $(libexecdir)/$(subdir) nobase_testprog_PROGRAMS = $(tprogs) -BUILT_SOURCES = $(tprogs:$(EXEEXT)=.c) +BUILT_SOURCES = $(tprogs:=.c) CLEANFILES = $(BUILT_SOURCES) tprogs = \ diff --git a/xts5/Xlib15/Makefile.am b/xts5/Xlib15/Makefile.am index e9b0ddf..a9029ed 100644 --- a/xts5/Xlib15/Makefile.am +++ b/xts5/Xlib15/Makefile.am @@ -14,7 +14,7 @@ LDADD = $(top_builddir)/src/tet3/tcm/libtcmmain.la \ testprogdir = $(libexecdir)/$(subdir) nobase_testprog_PROGRAMS = $(tprogs) -BUILT_SOURCES = $(tprogs:$(EXEEXT)=.c) +BUILT_SOURCES = $(tprogs:=.c) CLEANFILES = $(BUILT_SOURCES) XDefaultString_LDADD = $(LDADD) $(top_builddir)/xts5/src/libXR5/libXR5.la diff --git a/xts5/Xlib16/Makefile.am b/xts5/Xlib16/Makefile.am index eabe0ad..debecac 100644 --- a/xts5/Xlib16/Makefile.am +++ b/xts5/Xlib16/Makefile.am @@ -14,7 +14,7 @@ LDADD = $(top_builddir)/src/tet3/tcm/libtcmmain.la \ testprogdir = $(libexecdir)/$(subdir) nobase_testprog_PROGRAMS = $(tprogs) -BUILT_SOURCES = $(tprogs:$(EXEEXT)=.c) +BUILT_SOURCES = $(tprogs:=.c) CLEANFILES = $(BUILT_SOURCES) XrmCombineDatabase_LDADD = $(LDADD) $(top_builddir)/xts5/src/libXR5/libXR5.la diff --git a/xts5/Xlib17/Makefile.am b/xts5/Xlib17/Makefile.am index 4bd7bf0..b0a1547 100644 --- a/xts5/Xlib17/Makefile.am +++ b/xts5/Xlib17/Makefile.am
Re: [PATCH] Fix typos in the swap functions
On Mar 22, 10 11:20:15 -0700, Ian Romanick wrote: From: Tomas Carnecky t...@dbservice.com This should fix bug #3539. Signed-off-by: Tomas Carnecky t...@dbservice.com Signed-off-by: Ian Romanick ian.d.roman...@intel.com 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@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: DRI2 fixes
On Mar 22, 2010, at 11:03 PM, Jesse Barnes wrote: This is a collection of fixes from my personal server tree targeting the 1.8 release. They're mostly small fixes, but they fix a few important (i.e. common) cases with the new protocol code. Please review; I'll make any necessary changes, add the Reviewed-by tags, and push to Keith. Hi Jesse, done. You can add a reviewed-by from me on all relevant patches if you like -- i pulled them from your xserver-tree and checked on that. I didn't test any of them (no suitable hardware) but did a paper + pencil + brain review and looks good to me. thanks, -mario ___ 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: [ANNOUNCE] xorg-server 1.7.99.902
On Wed, Mar 24, 2010 at 06:05:27AM +0100, Stefan Dirsch wrote:
On Mon, Mar 22, 2010 at 07:59:18AM -0700, Dan Nicholson wrote:
2. Make the handling of missing sections from an existing
configuration behave more like the full autoconfig. In other words, if
there's a missing Screen section, generate multiple Screen/Device
pairs with fallbacks. I think this is the correct fix, but I'm not
that familiar with the autoconfig code so I don't think I could whip
up a patch that fast.
I've now attached a patch to
https://bugs.freedesktop.org/show_bug.cgi?id=27229
which does that. It works fine for us.
Looks pretty good from my understanding, but I'd like to polish it a bit more
before applying it. I'm gonna do the review here since I'm not that familiar
with that part of the code.
The first thing is that it would be great if this was a git formatted patch
with a commit message. But if it's easier to keep it as a separate patch, can
you add some information to the patch header? It would also be great if there
could be some comments in the code. It looks like multiple Screen sections are
being handled, but not really.
Now to the patch.
--- hw/xfree86/common/xf86AutoConfig.c
+++ hw/xfree86/common/xf86AutoConfig.c
@@ -539,34 +541,13 @@
}
}
-static char*
-chooseVideoDriver(void)
-{
-char *chosen_driver = NULL;
-int i;
-char *matches[20]; /* If we have more than 20 drivers we're in trouble */
-
-listPossibleVideoDrivers(matches, 20);
-
-/* TODO Handle multiple drivers claiming to support the same PCI ID */
-chosen_driver = matches[0];
-
-xf86Msg(X_DEFAULT, Matched %s for the autoconfigured driver\n,
- chosen_driver);
-
-for (i = 0; matches[i] ; i++) {
-if (matches[i] != chosen_driver) {
-xfree(matches[i]);
-}
-}
-
-return chosen_driver;
-}
-
GDevPtr
autoConfigDevice(GDevPtr preconf_device)
{
-GDevPtr ptr = NULL;
+GDevPtr ptr = NULL, cptr = NULL;
+char *matches[20]; /* If we have more than 20 drivers we're in trouble */
+int num_matches = 0, num_screens = 0, i;
+screenLayoutPtr slp;
if (!xf86configptr) {
return NULL;
@@ -589,14 +571,49 @@
ptr-driver = NULL;
}
if (!ptr-driver) {
-ptr-driver = chooseVideoDriver();
+ listPossibleVideoDrivers(matches, 20);
+ for (; matches[num_matches] ; num_matches++);
Coding style issues for here and the rest of the patch.
* Let's not mix tabs and spaces. The rest of this function uses all spaces.
* We don't typically pad the parameters with trailing spaces.
* Wrap at 78 columns unless it becomes really unreadable.
* Spaces between operators, please. (i=1;inum_screens;i++) is not very
readable.
* Please add a blank line here or there to break up the action.
+ slp = xf86ConfigLayout.screens;
+ if (slp) {
+ for (; slp[num_screens].screen ; num_screens++);
+ xf86ConfigLayout.screens = xnfcalloc(1,(num_screens+num_matches+1)
* sizeof(screenLayoutRec));
+ xf86ConfigLayout.screens[0] = slp[0];
+ }
+ for (i=0; inum_matches;i++) {
+ if (i==0) {
+ ptr-driver = matches[0];
+ if (slp !xf86ConfigLayout.screens[0].screen-device) {
+ xf86ConfigLayout.screens[0].screen-device = ptr;
+ ptr-myScreenSection = xf86ConfigLayout.screens[0].screen;
+ }
+ } else {
+ if (slp) {
+ xf86ConfigLayout.screens[i].screen = xnfcalloc(1,
sizeof(confScreenRec));
+ if(!xf86ConfigLayout.screens[i].screen)
+ return NULL;
+ memcpy(xf86ConfigLayout.screens[i].screen, slp[0].screen,
sizeof(confScreenRec));
+ }
+ cptr = xcalloc(1, sizeof(GDevRec));
It seems were making the decision here that if you had one Screen section,
you'll want more of them. Otherwise, we're just allocating another GDevPtr and
doing nothing with it. Probably the right thing to do is generate Screen
sections anyway, but that might be a more involved change. Here we should
probably return the first autoconfigured device (ptr) if there are no screen
sections and skip this whole loop.
+ if (!cptr)
+ return NULL;
+ memcpy(cptr, ptr, sizeof(GDevRec));
+ cptr-identifier = xnfcalloc(1,strlen(Autoconfigured Video
Device )+strlen(matches[i])+1);
+ sprintf(cptr-identifier, Autoconfigured Video Device %s,
matches[i]);
Seems you could use xnfalloc since you immediately memcpy/sprintf over the
allocations anyway.
+ cptr-driver = matches[i];
+ if (slp) {
+ xf86ConfigLayout.screens[i].screen-device = cptr;
+ cptr-myScreenSection = xf86ConfigLayout.screens[i].screen;
+ }
+ }
+ }
+ for (i=1;inum_screens;i++) {
+
Re: [ANNOUNCE] xorg-server 1.7.99.902
I'll try and look at the patch more carefully in a few days, but: On Wed, Mar 24, 2010 at 09:20:24 -0700, Dan Nicholson wrote: + if (!cptr) + return NULL; + memcpy(cptr, ptr, sizeof(GDevRec)); + cptr-identifier = xnfcalloc(1,strlen(Autoconfigured Video Device )+strlen(matches[i])+1); + sprintf(cptr-identifier, Autoconfigured Video Device %s, matches[i]); Seems you could use xnfalloc since you immediately memcpy/sprintf over the allocations anyway. cptr-identifier = Xprintf(Autoconfigured Video Device %s, matches[i]); should do what you want. Cheers, Julien ___ 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: [ANNOUNCE] xorg-server 1.7.99.902
On Wed, 24 Mar 2010, Stefan Dirsch wrote: On Mon, Mar 22, 2010 at 07:59:18AM -0700, Dan Nicholson wrote: 2. Make the handling of missing sections from an existing configuration behave more like the full autoconfig. In other words, if there's a missing Screen section, generate multiple Screen/Device pairs with fallbacks. I think this is the correct fix, but I'm not that familiar with the autoconfig code so I don't think I could whip up a patch that fast. I've now attached a patch to https://bugs.freedesktop.org/show_bug.cgi?id=27229 which does that. It works fine for us. Excellent, thanks Rüdiger! :) just what I've been missing since xorg.conf.d was pushed.. backported all of x.c.d/inputclass/etc on top of 1.7.6 and it seems to work great. -- Timo Aaltonen Systems Specialist IT Services, Aalto University School of Science and Technology ___ 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] Ignore linuxdoc generated docs
On Wed, 2010-03-24 at 01:21 -0500, Yaakov (Cygwin/X) wrote: From: Yaakov Selkowitz yselkow...@users.sourceforge.net Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net --- hw/dmx/doc/.gitignore |3 +++ hw/xfree86/doc/sgml/.gitignore |4 2 files changed, 7 insertions(+), 0 deletions(-) create mode 100644 hw/xfree86/doc/sgml/.gitignore diff --git a/hw/dmx/doc/.gitignore b/hw/dmx/doc/.gitignore index 5bfaef3..84b70c0 100644 --- a/hw/dmx/doc/.gitignore +++ b/hw/dmx/doc/.gitignore @@ -1,2 +1,5 @@ #Add Override for this directory and it's subdirectories html/ +*.html +*.pdf +*.ps diff --git a/hw/xfree86/doc/sgml/.gitignore b/hw/xfree86/doc/sgml/.gitignore new file mode 100644 index 000..2ee2ac5 --- /dev/null +++ b/hw/xfree86/doc/sgml/.gitignore @@ -0,0 +1,4 @@ +*.html +*.pdf +*.ps +*.txt Reviewed-by: Gaetan Nadon gaetan.na...@videotron.ca signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: A question for Xserver debug
On Wed, 2010-03-24 at 06:20 -0700, Alan Coopersmith wrote: Huang, FrankR wrote: Hi,all I am debugging the xserver code now. But one thing has puzzled me. When I add some modification to /dix/main.c , then make make install. Though the new main.c file has been compiled, no modification effect display. After that, I do some modification to /hw/xfree86/common/xf86Init.c. Do the same steps. The modification to main.c displays at the same time. Why this happens?? No one has ever gone through the exercise of ensuring the complex dependencies are properly setup to force rebuilding the Xorg server any time any related file changes. Sometimes you just have to manually rm hw/xfree86/Xorg and then make install. If this annoys you, we're happy to review proposed patches to improve it. I did add the 'relink' target for this reason. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Pixman] [PATCH] Fix server crash in pixman (to be discussed)
Hi Matthias, The following patch fixes Novell bug 568811: VNC Installation aborts right in the middle due to an assertion in Xvnc/libpixman The bug seems occur only on *very* special occasions (in this case, only in SLES, but *not* in SLED, which is based on the same code basis...). Backtrace looks as follows: #2 0xb71f7baa in __assert_fail () from /lib/libc.so.6 #3 0xb781feab in pixman_region_append_non_o (y2=value optimized out, y1=value optimized out, r_end=value optimized out, r=value optimized out, region=value optimized out) at pixman-region.c:670 #4 pixman_op (y2=value optimized out, y1=value optimized out, r_end=value optimized out, r=value optimized out, region=value optimized out) at pixman-region.c:996 #5 0xb7820dbe in pixman_region_union (new_reg=0x82ee57c, reg1=0x82ee57c, reg2=0xbfd77c90) at pixman-region.c:1439 #6 0x080f023b in miUnion (newReg=0x82ee57c, reg1=0x82ee57c, reg2=0xbfd77c90) at miregion.c:1005 Thanks for tracking down this issue. Please note that while pixman is not as strict as the X server in who can push to the repository, it is not a complete free-for-all. Committing small, obvious patches that fixes typos or oversights is fine, but don't commit non-obvious stuff without sending it to the mailing list and giving people time to comment on it. When we are this close to stable release, we need to be even more careful about what goes in. Patches committed between now and next week will likely ship without no testing at all. This patch in particular, I don't think shold ship with no testing at all. So please revert it, and we can consider it again for 0.19.x. Comments and questions: - Why are you seeing an assert in the first place? The asserts have been disabled since 0.16.4/0.17.6 because pixman shouldn't take down the X server with asserts for things that would otherwise be harmless. If you are using an older version than those in SLES, then you might want to either upgrade to 0.16.4, or backport ec6de472d042bec05aaa53f9d14bfbe23edbe01e which is the commit that disables asserts. - How does the degenerate region get created? If you call pixman_init_rectangle() with an empty rectangle, the region will be correctly initialized to have the 'data' field point to pixman_region_empty_data_. I believe the various operations all make sure that if the resulting region is empty, they will store a pointer to pixman_region_empty_data_ in the data field. For better or worse, the region code currently relies on this invariant, so users shouldn't be filling out the region data structure themselves. You can argue that this is bad and pixman should cope with regions initialized directly with empty rectangles, and I probably would agree; it may make sense to fix it in pixman 0.20. It certainly does not make sense to make this change with no testing this close to a stable release unless it is demonstrably a serious bug in pixman that is causing crashes. - The patch does not look wrong to me - a region with empty extents should probably be considered empty rather than degenerate. However, unless this issue is truly causing crashes, changing it is the kind of thing that could cause all kinds of mysterious bugs to show up and therefore definitely should not happen between a release candidate and a stable release. Did you carefully review all the code to make sure it always uses PIXMAN_NIL to check for empty regions? - The region code is rather tricky, so when bugs are fixed in it, I'd like to have tests/region-test.c updated to test the issue. That way - we have a clear way to reproduce the bug - we can verify that the bug is really fixed - we make sure it doesn't get reintroduced - Finally, we need much more detail in commit messages than Fixes Novell bug xx. Is that even a public bug? I couldn't figure out how to look at it. I did not create a Novell Login though. Soren ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X Test Suite Redux
On Wed, Mar 24, 2010 at 03:16:22PM +, Jon TURNEY wrote: On 18/02/2010 14:07, Dan Nicholson wrote: A while back Peter asked me about helping him add autotools support after he pulled xtest out of cvs into git. We got that handled pretty quickly, but I decided to spend some time making it actually easy to use. So, I give you the revamped XTS: git://people.freedesktop.org/~dbn/xtest.git I'm not sure the test results are actually useful right now, but it would be nice to start running the tests again and tracking the status. Let me know what you think. There are still a couple rough edges here and there. Below is the README that I wrote yesterday. Cool. A couple of patches to follow, which I needed to get it to build on cygwin. Applied, thanks. Is it just me, or does test XAllowEvents (19/29) currently crash the X server in DeliverGrabbedEvent()? (tested with both 1.7.5 and git master; a 1.6.0 X server I have around seems to survive that test, though) I haven't checked that test lately, but I've been running the suite on a 1.7.x series, and I haven't seen the server crash. -- Dan ___ 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: [Pixman] [PATCH] Fix server crash in pixman (to be discussed)
On Mar 24, 10 18:28:07 +0100, Soeren Sandmann wrote: Please note that while pixman is not as strict as the X server in who can push to the repository, it is not a complete free-for-all. Committing small, obvious patches that fixes typos or oversights is fine, but don't commit non-obvious stuff without sending it to the mailing list and giving people time to comment on it. Ok, just the comment from Jonathan indicated to me that I should commit. When we are this close to stable release, we need to be even more careful about what goes in. Patches committed between now and next week will likely ship without no testing at all. It definitely did help here. So there's at least minimal testing :) This patch in particular, I don't think shold ship with no testing at all. So please revert it, and we can consider it again for 0.19.x. I'm fine with that if you consider it problematic. Given that the situation it changes should actually not occur at all, I doubt there's any fallout, though. - Why are you seeing an assert in the first place? The asserts have been disabled since 0.16.4/0.17.6 because pixman shouldn't take down the X server with asserts for things that would otherwise be harmless. Apparently we're still using 0.16.0 in SLE11SP1. So that explains. I double checked that there were no related changes in the region code before fixing. However, what happens if the code would have been compiled with -NDEBUG? Is the code path stable with empty regions? If it is, it can be argued that the patch is not necessary, but it could also be argued that the assert() shouldn't have been there in the first place. If you are using an older version than those in SLES, then you might want to either upgrade to 0.16.4, or backport No chance. We are version and feature freeze for quite some time now. Time cycles are much different in enterprise products :-/ Especially in SLE11SP1, as changes to SLE11 should be as minimal as possible (and SLE11 is over a year old). ec6de472d042bec05aaa53f9d14bfbe23edbe01e That sounds more realistic. However, we don't have any other issues with assert()s, and there is a slim chance that this backport introduces additional regressions (asserts with side effects etc.). - How does the degenerate region get created? Unfortunately I don't know the offending Xserver code by heart. It probably has to be reviewed, I guess there are sleeping dragons there. - The patch does not look wrong to me - a region with empty extents should probably be considered empty rather than degenerate. However, unless this issue is truly causing crashes, changing it is the kind It is definitely causing crashes here, reproducibly, but only on very rare occasions (of which we run into one during installation :o] ) candidate and a stable release. Did you carefully review all the code to make sure it always uses PIXMAN_NIL to check for empty regions? No, but that shouldn't change behavior. Unless a single code snippet uses both PIXMAN_NIL and handcoded tests at the same time. - Finally, we need much more detail in commit messages than Fixes Novell bug xx. Understood. I thought the code change to be trivial in itself. Is that even a public bug? I couldn't figure out how to look at it. I did not create a Novell Login though. Unfortunately, no. Not that I did notice before, oops. You tend to miss those things if you're working with credentials set all the time... It doesn't contain much more information than the backtrace I published, though. 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@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Define/use pad_to_pow_two() instead of open coding it
à la the Linux Kernel's ALIGN macro.
Signed-off-by: Matt Turner matts...@gmail.com
---
hw/dmx/dmxpict.c |2 +-
hw/kdrive/ephyr/XF86dri.c |6 +++---
hw/xfree86/dixmods/extmod/xf86vmode.c |6 +++---
hw/xfree86/int10/generic.c| 13 ++---
hw/xfree86/os-support/bus/Sbus.c | 12 ++--
hw/xquartz/xpr/xprCursor.c|2 +-
include/misc.h| 16 ++--
miext/rootless/rootlessWindow.c |2 +-
os/utils.c|6 +++---
render/render.c |2 +-
10 files changed, 39 insertions(+), 28 deletions(-)
diff --git a/hw/dmx/dmxpict.c b/hw/dmx/dmxpict.c
index 072e3a6..51616bb 100644
--- a/hw/dmx/dmxpict.c
+++ b/hw/dmx/dmxpict.c
@@ -674,7 +674,7 @@ static int dmxProcRenderSetPictureFilter(ClientPtr client)
if (pPictPriv-pict) {
filter = (char *)(stuff + 1);
- params = (XFixed *)(filter + ((stuff-nbytes + 3) ~3));
+ params = (XFixed *)(filter + pad_to_pow_two(stuff-nbytes, 4));
nparams = ((XFixed *)stuff + client-req_len) - params;
XRenderSetPictureFilter(dmxScreen-beDisplay,
diff --git a/hw/kdrive/ephyr/XF86dri.c b/hw/kdrive/ephyr/XF86dri.c
index 08123d3..aef9828 100644
--- a/hw/kdrive/ephyr/XF86dri.c
+++ b/hw/kdrive/ephyr/XF86dri.c
@@ -222,7 +222,7 @@ XF86DRIOpenConnection (Display *dpy, int screen,
if (rep.length) {
if (!(*busIdString = (char *)Xcalloc(rep.busIdStringLength + 1, 1))) {
-_XEatData(dpy, ((rep.busIdStringLength+3) ~3));
+_XEatData(dpy, pad_to_pow_two(rep.busIdStringLength, 4));
UnlockDisplay(dpy);
SyncHandle();
TRACE(OpenConnection... return False);
@@ -317,7 +317,7 @@ Bool XF86DRIGetClientDriverName(Display *dpy, int screen,
if (rep.length) {
if (!(*clientDriverName = (char *)Xcalloc(rep.clientDriverNameLength +
1, 1))) {
-_XEatData(dpy, ((rep.clientDriverNameLength+3) ~3));
+_XEatData(dpy, pad_to_pow_two(rep.clientDriverNameLength, 4));
UnlockDisplay(dpy);
SyncHandle();
TRACE(GetClientDriverName... return False);
@@ -588,7 +588,7 @@ XF86DRIGetDeviceInfo (Display *dpy, int screen,
drm_handle_t *hFrameBuffer,
if (rep.length) {
if (!(*pDevPrivate = (void *)Xcalloc(rep.devPrivateSize, 1))) {
-_XEatData(dpy, ((rep.devPrivateSize+3) ~3));
+_XEatData(dpy, pad_to_pow_two(rep.devPrivateSize, 4));
UnlockDisplay(dpy);
SyncHandle();
TRACE(GetDeviceInfo... return False);
diff --git a/hw/xfree86/dixmods/extmod/xf86vmode.c
b/hw/xfree86/dixmods/extmod/xf86vmode.c
index a304a42..d3f1a44 100644
--- a/hw/xfree86/dixmods/extmod/xf86vmode.c
+++ b/hw/xfree86/dixmods/extmod/xf86vmode.c
@@ -1522,7 +1522,7 @@ ProcXF86VidModeSetGammaRamp(ClientPtr client)
if(stuff-size != VidModeGetGammaRampSize(stuff-screen))
return BadValue;
-length = (stuff-size + 1) ~1;
+length = pad_to_pow_two(stuff-size, 2);
REQUEST_FIXED_SIZE(xXF86VidModeSetGammaRampReq, length * 6);
@@ -1553,7 +1553,7 @@ ProcXF86VidModeGetGammaRamp(ClientPtr client)
REQUEST_SIZE_MATCH(xXF86VidModeGetGammaRampReq);
-length = (stuff-size + 1) ~1;
+length = pad_to_pow_two(stuff-size, 2);
if(stuff-size) {
ramplen = length * 3 * sizeof(CARD16);
@@ -2067,7 +2067,7 @@ SProcXF86VidModeSetGammaRamp(ClientPtr client)
REQUEST_AT_LEAST_SIZE(xXF86VidModeSetGammaRampReq);
swaps(stuff-size, n);
swaps(stuff-screen, n);
-length = ((stuff-size + 1) ~1) * 6;
+length = pad_to_pow_two(stuff-size, 2) * 6;
REQUEST_FIXED_SIZE(xXF86VidModeSetGammaRampReq, length);
SwapRestS(stuff);
return ProcXF86VidModeSetGammaRamp(client);
diff --git a/hw/xfree86/int10/generic.c b/hw/xfree86/int10/generic.c
index 9d39e99..399250e 100644
--- a/hw/xfree86/int10/generic.c
+++ b/hw/xfree86/int10/generic.c
@@ -56,8 +56,7 @@ int10MemRec genericMem = {
static void MapVRam(xf86Int10InfoPtr pInt);
static void UnmapVRam(xf86Int10InfoPtr pInt);
#ifdef _PC
-#define GET_HIGH_BASE(x) (((V_BIOS + (x) + getpagesize() - 1)/getpagesize()) \
- * getpagesize())
+#define GET_HIGH_BASE(x) (pad_to_pow_two(V_BIOS + (x), getpagesize()))
#endif
static void *sysMem = NULL;
@@ -81,9 +80,9 @@ read_legacy_video_BIOS(struct pci_device *dev, unsigned char
*Buf)
{
const ADDRESS Base = 0xC;
const int Len = 0x1 * 2;
-const int pagemask = getpagesize() - 1;
-const ADDRESS offset = Base ~pagemask;
-const unsigned long size = ((Base + Len + pagemask) ~pagemask) - offset;
+const int pagesize = getpagesize();
+const ADDRESS offset = Base ~(pagesize - 1);
+const unsigned long size = pad_to_pow_two(Base + Len, pagesize) - offset;
unsigned char *ptr, *src;
int len;
@@ -304,7 +303,7 @@
[PATCH all drivers] config: set more appropriate default drivers location
The current value is based on $lib which is based on the driver package $prefix. The driver object code will be installed in the correct xserver location only if both the driver package and the xserver package have the same prefix. This patch obtains the drivers object code location from the installed xserver package through the xorg-server.pc file. The server default location for drivers object code is based on its own $lib but this may have been changed at configuration time (using with-module-dir). In any case, the resulting net location is returned. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- configure.ac |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index c1fae22..c3f33a2 100644 --- a/configure.ac +++ b/configure.ac @@ -55,9 +55,9 @@ AH_TOP([#include xorg-server.h]) AC_ARG_WITH(xorg-module-dir, AC_HELP_STRING([--with-xorg-module-dir=DIR], - [Default xorg module directory [[default=$libdir/xorg/modules]]]), + [Default xorg module directory [[default=$moduledir/xorg/modules]]]), [moduledir=$withval], -[moduledir=$libdir/xorg/modules]) +[moduledir=`$PKG_CONFIG --variable=moduledir xorg-server`]) AC_ARG_ENABLE(dri, AC_HELP_STRING([--disable-dri], [Disable DRI support [[default=auto]]]), -- 1.6.0.4 My assumption is that the drivers can only be loaded if they are located in the running server xorg/modules/drivers directory that it knows about at configuration time. If that is correct, the only value that with-xorg-module-dir can be given is the value that the server returns through the xorg-server .pc file. After searching in 2005 archives, I found out some distro did not install our .pc files or did not install the pkg-config package. Is it still the case? Would all of our build not fail? http://lists.x.org/archives/xorg/2006-November/019654.html It's the first I hear about the pkg-config method not being reliable. ___ 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: [Pixman] [PATCH] Fix server crash in pixman (to be discussed)
Matthias Hopf mh...@suse.de writes: This patch in particular, I don't think shold ship with no testing at all. So please revert it, and we can consider it again for 0.19.x. I'm fine with that if you consider it problematic. Given that the situation it changes should actually not occur at all, I doubt there's any fallout, though. I do consider it problematic. Thanks for reverting it. - Why are you seeing an assert in the first place? The asserts have been disabled since 0.16.4/0.17.6 because pixman shouldn't take down the X server with asserts for things that would otherwise be harmless. Apparently we're still using 0.16.0 in SLE11SP1. So that explains. I double checked that there were no related changes in the region code before fixing. However, what happens if the code would have been compiled with -NDEBUG? Is the code path stable with empty regions? If it is, it can be argued that the patch is not necessary, but it could also be argued that the assert() shouldn't have been there in the first place. Who knows? Who knows if it's stable even *with* the patch? That's why I don't want it in for 0.18.0. If you are using an older version than those in SLES, then you might want to either upgrade to 0.16.4, or backport No chance. We are version and feature freeze for quite some time now. Time cycles are much different in enterprise products :-/ Especially in SLE11SP1, as changes to SLE11 should be as minimal as possible (and SLE11 is over a year old). ec6de472d042bec05aaa53f9d14bfbe23edbe01e That sounds more realistic. However, we don't have any other issues with assert()s, and there is a slim chance that this backport introduces additional regressions (asserts with side effects etc.). If it were *my* enterprise product, I'd definitely get rid of the assertions, because they are known to take down the X server in various situations. That's your call of course. As of 0.17.6 the assertions are not even enabled in unstable releases because the only result were that they get triggered by the same old X server issues, which just causes people to not test the pixman releases. Soren ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Pixman] [PATCH] Fix server crash in pixman (to be discussed)
On Mar 24, 10 19:19:15 +0100, Soeren Sandmann wrote: However, what happens if the code would have been compiled with -NDEBUG? Is the code path stable with empty regions? If it is, it can be argued that the patch is not necessary, but it could also be argued that the assert() shouldn't have been there in the first place. Who knows? Who knows if it's stable even *with* the patch? That's why I don't want it in for 0.18.0. Right. I just want to indicate that just disabling the assert()s typically is no solution for issues like this. That sounds more realistic. However, we don't have any other issues with assert()s, and there is a slim chance that this backport introduces additional regressions (asserts with side effects etc.). If it were *my* enterprise product, I'd definitely get rid of the assertions, because they are known to take down the X server in various situations. That's your call of course. If it was *my* enterprise product, I would've done quite a number of things differently ;-) I'm not entirely sure ATM, but you have a point. As of 0.17.6 the assertions are not even enabled in unstable releases because the only result were that they get triggered by the same old X server issues, which just causes people to not test the pixman releases. Which is problematic, because in this case the Xserver isn't fixed. No, I don't have a good solution to this dilemma. 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@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 all drivers] config: set more appropriate default drivers location
On Wed, Mar 24, 2010 at 11:11 AM, Gaetan Nadon mems...@videotron.ca wrote: The current value is based on $lib which is based on the driver package $prefix. The driver object code will be installed in the correct xserver location only if both the driver package and the xserver package have the same prefix. This patch obtains the drivers object code location from the installed xserver package through the xorg-server.pc file. The server default location for drivers object code is based on its own $lib but this may have been changed at configuration time (using with-module-dir). In any case, the resulting net location is returned. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- configure.ac | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index c1fae22..c3f33a2 100644 --- a/configure.ac +++ b/configure.ac @@ -55,9 +55,9 @@ AH_TOP([#include xorg-server.h]) AC_ARG_WITH(xorg-module-dir, AC_HELP_STRING([--with-xorg-module-dir=DIR], - [Default xorg module directory [[default=$libdir/xorg/modules]]]), + [Default xorg module directory [[default=$moduledir/xorg/modules]]]), [moduledir=$withval], - [moduledir=$libdir/xorg/modules]) + [moduledir=`$PKG_CONFIG --variable=moduledir xorg-server`]) AC_ARG_ENABLE(dri, AC_HELP_STRING([--disable-dri], [Disable DRI support [[default=auto]]]), -- 1.6.0.4 My assumption is that the drivers can only be loaded if they are located in the running server xorg/modules/drivers directory that it knows about at configuration time. If that is correct, the only value that with-xorg-module-dir can be given is the value that the server returns through the xorg-server .pc file. You can set the module path with -modulepath on the command line or ModulePath in a Files section in xorg.conf. So, you can definitely handle drivers that are in a different prefix. More problematic, this will break distcheck unless you set it back under $prefix with DISTCHECK_CONFIGURE_FLAGS. This is like the chat we had about drivers installing headers outside the xorg $includedir (which we might want to revisit since it's doing the opposite unnecessarily). After searching in 2005 archives, I found out some distro did not install our .pc files or did not install the pkg-config package. Is it still the case? Would all of our build not fail? http://lists.x.org/archives/xorg/2006-November/019654.html I doubt it would happen nowadays, but you could easily make it fallback to $libdir/xorg/modules if nothing came from pkg-config. -- Dan ___ 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] Detect system XKB installation paths
On 2010-03-23 08:29, Dan Nicholson wrote:
I've wanted to do this for a while, but there are a couple issues.
FWIW, I'm trying to keep in mind several different scenarios:
1) where xserver is being built to update an existing version with the
same prefix, e.g. by distributors. This patch shouldn't change anything
in that case.
2) where only xserver is built against system-installed dependencies but
with a separate prefix, e.g. from git where no arguments are passed to
autogen.sh (which then defaults to /usr/local vs. the system /usr).
Without something like this, the server builds but fails to run because
it expects these packages in its prefix.
3) where a complete X.Org system is built in a separate prefix from the
system-installed version, such as jhbuild. Within jhbuild we could
certainly add xkeyboard-config and xkbcomp as dependencies of xserver
(if they are not already) without creating a hard dep for other scenarios.
4) where X.Org is being cross-compiled, we need to be sure not to pick
up the build system's installation.
Why exclude cross compiling? Using PKG_CHECK_EXISTS or AC_PATH_PROG
have no problems in those situations.
My concern was (4) above. I'm not that familiar with cross-compiling;
it makes sense that the pkg-config call should work, but wouldn't
AC_PATH_PROG be prone to pick up the build system's xkbconf?
Check if DEFAULT_XKB_PATH is empty and set it to ${datadir}/X11/xkb if
so. Then we can fallback gracefully on older xkeyboard-config
installations.
In what case would DEFAULT_XKB_PATH be empty? The PKG_CHECK_EXISTS will
do nothing if the .pc file is not present (meaning that either
xkeyboard-config is not installed or it is an older version w/o that
file).
The only drawback is that there's never been a hard requirement on
having xkeyboard-config installed before xserver, and we risk picking
up the host's installation instead of the one the user expects. Still
the CHECKING/RESULT is nice and informs people.
This does not add a *hard* dep on xkeyboard-config at configure time; if
xkeyboard-config.pc is not present, you end up with $datadir/X11/xkb
just as before. Adding a dep within the scope of jhbuild would fix that
case but should not be necessary for other scenarios.
Same argument as above where we're likely to pick up the host's
xkbcomp since there was no hard requirement before. Hopefully they'd
see the result in the output.
Which is why I didn't want to do this if cross-compiling. Besides that
and jhbuild (easily fixable), how else might this break things?
We should remove this stupid macro and just #define the path to
xkbcomp until some glorious future where it doesn't need to be forked
from the server. That's a separate patch, but --with-xkbcomp would be
better.
That would require a more extensive patch affecting at least three .c
files in xkb/.
Yaakov
Cygwin/X
___
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] xcursorgen: Upgraded to work with libpng14
Hi,
Could someone with commit privileges please push this? I think it has
been sitting around long enough.
Cody Maloney
On Sun, Mar 14, 2010 at 12:07 AM, Cody Maloney
cmalo...@theoreticalchaos.com wrote:
Thanks for the comments. Here's an updated patch. It looks like
png_jmpbuf has actually been available since libpng 1.0.6 or before
when png_ptr-jmpbuf was first deprecated.
From: Cody Maloney cmalo...@theoreticalchaos.com
setjmp(png_ptr-jmpbuf) is depreceated so removed it and changed the
configure.ac version number to accept libpng12 or libpng14
Signed-off-by: Cody Maloney cmalo...@theoreticalchaos.com
Tested-by: Yaakov Selkowitz yselkow...@users.sourceforge.net
---
configure.ac | 2 +-
xcursorgen.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e7344ba..7a57230 100644
--- a/configure.ac
+++ b/configure.ac
@@ -18,7 +18,7 @@ AC_PROG_INSTALL
XORG_DEFAULT_OPTIONS
# Checks for pkg-config packages
-PKG_CHECK_MODULES(XCURSORGEN, x11 xcursor libpng12)
+PKG_CHECK_MODULES(XCURSORGEN, x11 xcursor libpng = 1.2.0)
AC_SUBST(XCURSORGEN_CFLAGS)
AC_SUBST(XCURSORGEN_LIBS)
diff --git a/xcursorgen.c b/xcursorgen.c
index fc80f6d..daae18b 100644
--- a/xcursorgen.c
+++ b/xcursorgen.c
@@ -196,7 +196,7 @@ load_image (struct flist *list, char *prefix)
return NULL;
}
- if (setjmp (png-jmpbuf))
+ if (setjmp (png_jmpbuf(png)))
{
png_destroy_read_struct (png, info, NULL);
return NULL;
--
1.7.0.2
On Sat, Mar 13, 2010 at 10:42 PM, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
On 2010-03-13 00:19, Cody Maloney wrote:
setjmp(png_ptr-jmpbuf) is depreceated so removed it and bumped the
version number in configure.ac
---
configure.ac | 2 +-
xcursorgen.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index e7344ba..0255ba3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -18,7 +18,7 @@ AC_PROG_INSTALL
XORG_DEFAULT_OPTIONS
# Checks for pkg-config packages
-PKG_CHECK_MODULES(XCURSORGEN, x11 xcursor libpng12)
+PKG_CHECK_MODULES(XCURSORGEN, x11 xcursor libpng14)
Make this libpng = 1.2.0 instead of libpng14. png_jmpbuf is available in
1.2 as well and IMO it's a bit early to outright *require* libpng14.
diff --git a/xcursorgen.c b/xcursorgen.c
index fc80f6d..daae18b 100644
--- a/xcursorgen.c
+++ b/xcursorgen.c
@@ -196,7 +196,7 @@ load_image (struct flist *list, char *prefix)
return NULL;
}
- if (setjmp (png-jmpbuf))
+ if (setjmp (png_jmpbuf(png)))
{
png_destroy_read_struct (png,info, NULL);
return NULL;
--
1.7.0.2
With the above-noted change:
Tested-by: Yaakov Selkowitz yselkow...@users.sourceforge.net
Yaakov
Cygwin/X
___
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] Define/use pad_to_pow_two() instead of open coding it
From: Matt Turner matts...@gmail.com
Date: Wed, 24 Mar 2010 13:57:15 -0400
diff --git a/hw/dmx/dmxpict.c b/hw/dmx/dmxpict.c
index 072e3a6..51616bb 100644
--- a/hw/dmx/dmxpict.c
+++ b/hw/dmx/dmxpict.c
@@ -674,7 +674,7 @@ static int dmxProcRenderSetPictureFilter(ClientPtr client)
if (pPictPriv-pict) {
filter = (char *)(stuff + 1);
- params = (XFixed *)(filter + ((stuff-nbytes + 3) ~3));
+ params = (XFixed *)(filter + pad_to_pow_two(stuff-nbytes, 4));
Sorry, but to me this isn't an improvement. I probably spend to much
time on kernel hacking, but the origional is immediately obvious to
me, whereas the new line makes me think you're trying to align to a
16-byte boundary.
___
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] Define/use pad_to_pow_two() instead of open coding it
On Wed, Mar 24, 2010 at 2:56 PM, Mark Kettenis mark.kette...@xs4all.nl wrote:
From: Matt Turner matts...@gmail.com
Date: Wed, 24 Mar 2010 13:57:15 -0400
diff --git a/hw/dmx/dmxpict.c b/hw/dmx/dmxpict.c
index 072e3a6..51616bb 100644
--- a/hw/dmx/dmxpict.c
+++ b/hw/dmx/dmxpict.c
@@ -674,7 +674,7 @@ static int dmxProcRenderSetPictureFilter(ClientPtr
client)
if (pPictPriv-pict) {
filter = (char *)(stuff + 1);
- params = (XFixed *)(filter + ((stuff-nbytes + 3) ~3));
+ params = (XFixed *)(filter + pad_to_pow_two(stuff-nbytes, 4));
Sorry, but to me this isn't an improvement. I probably spend to much
time on kernel hacking, but the origional is immediately obvious to
me, whereas the new line makes me think you're trying to align to a
16-byte boundary.
Hmm, yes, I see what you're saying. I changed the name to try to make
it explicitly obvious that 'alignment' must be a power of two, but I
see it is actually a little confusing.
What would you suggest for the name of the function?
Thanks,
Matt
___
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 Test Suite Redux
On 24/03/2010 17:33, Dan Nicholson wrote:
Applied, thanks.
Is it just me, or does test XAllowEvents (19/29) currently crash the
X server in DeliverGrabbedEvent()? (tested with both 1.7.5 and git
master; a 1.6.0 X server I have around seems to survive that test,
though)
I haven't checked that test lately, but I've been running the suite on
a 1.7.x series, and I haven't seen the server crash.
Odd. I probably should have mentioned that 1.7.6-1.fc12 crashes as well, so
it's not XWin-specific. Here's a backtrace:
$ gdb --args /opt/wip/jhbuild/install/bin/X :1
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i686-pc-cygwin...
(gdb) r
Starting program: /opt/wip/jhbuild/install/bin/X :1
[New thread 5888.0xd74]
[New thread 5888.0xc08]
InitConnectionLimits: MaxClients = 255
Welcome to the XWin X Server
Vendor: The X.Org Foundation
Release: 1.7.99.902 (10799902)
Tag: xorg-server-1.7.99.902-25-ge086b99
[...]
Program received signal SIGSEGV, Segmentation fault.
0x0056e4d4 in DeliverGrabbedEvent (event=0x22c434, thisDev=0x11631f8,
deactivateGrab=0) at /opt/wip/jhbuild/git/xorg/xserver/dix/events.c:3977
3977if ((dev-deviceGrab.sync.state ==
FREEZE_BOTH_NEXT_EVENT)
(gdb) list
3972for (dev = inputInfo.devices; dev; dev = dev-next)
3973{
3974if (dev == thisDev)
3975continue;
3976FreezeThaw(dev, TRUE);
3977if ((dev-deviceGrab.sync.state ==
FREEZE_BOTH_NEXT_EVENT)
3978(CLIENT_BITS(grab-resource) ==
3979 CLIENT_BITS(dev-deviceGrab.sync.other-resource)))
3980dev-deviceGrab.sync.state = FROZEN_NO_EVENT;
3981else
(gdb) p dev
$1 = (DeviceIntPtr) 0x11634b0
(gdb) p grab
$2 = (GrabPtr) 0x1163234
(gdb) p dev-deviceGrab.sync.other
$3 = (GrabPtr) 0x0
I don't know if this just needs a check that sync.other is non-null before we
try and dereference it, or if that indicates a deeper problem...
___
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 all drivers] config: set more appropriate default drivers location
On Wed, 2010-03-24 at 11:25 -0700, Dan Nicholson wrote:
On Wed, Mar 24, 2010 at 11:11 AM, Gaetan Nadon mems...@videotron.ca wrote:
The current value is based on $lib which is based on the driver package
$prefix. The driver object code will be installed in the correct xserver
location
only if both the driver package and the xserver package have the same
prefix.
This patch obtains the drivers object code location from the installed
xserver
package through the xorg-server.pc file. The server default location for
drivers
object code is based on its own $lib but this may have been changed at
configuration
time (using with-module-dir). In any case, the resulting net location is
returned.
Signed-off-by: Gaetan Nadon mems...@videotron.ca
---
configure.ac |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index c1fae22..c3f33a2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -55,9 +55,9 @@ AH_TOP([#include xorg-server.h])
AC_ARG_WITH(xorg-module-dir,
AC_HELP_STRING([--with-xorg-module-dir=DIR],
- [Default xorg module directory
[[default=$libdir/xorg/modules]]]),
+ [Default xorg module directory
[[default=$moduledir/xorg/modules]]]),
[moduledir=$withval],
-[moduledir=$libdir/xorg/modules])
+[moduledir=`$PKG_CONFIG --variable=moduledir xorg-server`])
AC_ARG_ENABLE(dri, AC_HELP_STRING([--disable-dri],
[Disable DRI support [[default=auto]]]),
--
1.6.0.4
My assumption is that the drivers can only be loaded if they are located
in the running server xorg/modules/drivers directory that it knows
about at configuration time. If that is correct, the only value that
with-xorg-module-dir can be given is the value that the server returns
through the xorg-server .pc file.
You can set the module path with -modulepath on the command line or
ModulePath in a Files section in xorg.conf.
I wasn't aware of that. It's an additional workaround for a bad default
value.
So, you can definitely
handle drivers that are in a different prefix. More problematic, this
will break distcheck unless you set it back under $prefix with
DISTCHECK_CONFIGURE_FLAGS. This is like the chat we had about drivers
installing headers outside the xorg $includedir (which we might want
to revisit since it's doing the opposite unnecessarily).
I think this issue with distcheck (which fails for a user without write
permission in moduledir) is quite
exaggerated. All instructions I have seen on the net for people
installing drivers require them to have root password.
For someone who is creating a tarball to be published to others, it's
the least to ask. Running this
target is mandatory, there are other ways of testing.
In any case, there 5 easy workarounds for distcheck:
- configure the driver package with moduledir=some comfy
location and then run distcheck.
- configure the driver package with libdir=some comfy location
and then run distcheck.
- we add DISTCHECK_CONFIGURE_FLAGS =
--with-xorg-module-dir='$${libdir}/xorg/modules'.
- we add DISTCHECK_CONFIGURE_FLAGS =
--libdir='$${libdir}/xorg/modules'.
- run 'make all dist distcheckclean' in a VPATH build which
would be the exact equivalent of distcheck.
The question remains: would `$PKG_CONFIG --variable=moduledir
xorg-server` not be a better default option?
- The configuration would not fail when different prefixes are
used for driver and xserver (without config swicth)
- Thousands of people would no longer be forced to hunt for and
supply the correct driver location
- All drivers could be build with no additional configure
switches
- With one workaround above, the few people creating tarball
without password would not be affected.
Example of instructions found on the net:
./configure --with-xorg-module-dir=/usr/lib/xorg/modules
make sudo make install
Thanks
After searching in 2005 archives, I found out some distro did not install
our .pc files or did not install the pkg-config package. Is it still the
case?
Would all of our build not fail?
http://lists.x.org/archives/xorg/2006-November/019654.html
I doubt it would happen nowadays, but you could easily make it
fallback to $libdir/xorg/modules if nothing came from pkg-config.
--
Dan
signature.asc
Description: This is a digitally signed message part
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Detect system XKB installation paths
On Wed, Mar 24, 2010 at 11:42 AM, Yaakov (Cygwin/X)
yselkow...@users.sourceforge.net wrote:
On 2010-03-23 08:29, Dan Nicholson wrote:
I've wanted to do this for a while, but there are a couple issues.
FWIW, I'm trying to keep in mind several different scenarios:
1) where xserver is being built to update an existing version with the same
prefix, e.g. by distributors. This patch shouldn't change anything in that
case.
Agreed.
2) where only xserver is built against system-installed dependencies but
with a separate prefix, e.g. from git where no arguments are passed to
autogen.sh (which then defaults to /usr/local vs. the system /usr). Without
something like this, the server builds but fails to run because it expects
these packages in its prefix.
Yeah, this is the one I've always wanted to fix. This is a spot where
xkb is a little special, though. You _can_ get the xserver to use your
system xkb files, but trying to use the system xkbcomp with local xkb
files can be problematic due to xkbcomp's handling of paths. This is
why symlink to your host's xkbcomp in $xprefix/bin is not actually a
useful suggestion. But that's a little orthogonal to this patch.
3) where a complete X.Org system is built in a separate prefix from the
system-installed version, such as jhbuild. Within jhbuild we could
certainly add xkeyboard-config and xkbcomp as dependencies of xserver (if
they are not already) without creating a hard dep for other scenarios.
If this patch lands, we would most certainly want to make them deps of
the xserver in jhbuild and build.sh.
4) where X.Org is being cross-compiled, we need to be sure not to pick up
the build system's installation.
Why exclude cross compiling? Using PKG_CHECK_EXISTS or AC_PATH_PROG
have no problems in those situations.
My concern was (4) above. I'm not that familiar with cross-compiling; it
makes sense that the pkg-config call should work, but wouldn't AC_PATH_PROG
be prone to pick up the build system's xkbconf?
No more than situations 1-3 above, but I suppose that's the reason
AC_CHECK_FILE bails on cross compiling. Since we're actually encoding
runtime dependencies, I think we'd want to pick up the tools in the
cross prefix. Maybe it's safer to default to paths under $prefix in
that case. Let's leave it your way until someone that this actually
affects complains.
Check if DEFAULT_XKB_PATH is empty and set it to ${datadir}/X11/xkb if
so. Then we can fallback gracefully on older xkeyboard-config
installations.
In what case would DEFAULT_XKB_PATH be empty? The PKG_CHECK_EXISTS will do
nothing if the .pc file is not present (meaning that either xkeyboard-config
is not installed or it is an older version w/o that file).
Ah, right. There isn't an existing version of xkeyboard-config.pc that
doesn't have xkb_base variable. Probably fine.
The only drawback is that there's never been a hard requirement on
having xkeyboard-config installed before xserver, and we risk picking
up the host's installation instead of the one the user expects. Still
the CHECKING/RESULT is nice and informs people.
This does not add a *hard* dep on xkeyboard-config at configure time; if
xkeyboard-config.pc is not present, you end up with $datadir/X11/xkb just as
before. Adding a dep within the scope of jhbuild would fix that case but
should not be necessary for other scenarios.
Sooner or later, though, we'll have system copies of
xkeyboard-config.pc, which means you'll get /usr/share/X11/xkb when
you might not have expected it. I think that's OK, but we need to fix
the build tools and make sure people know about it.
Same argument as above where we're likely to pick up the host's
xkbcomp since there was no hard requirement before. Hopefully they'd
see the result in the output.
Which is why I didn't want to do this if cross-compiling. Besides that and
jhbuild (easily fixable), how else might this break things?
Cases 2 and 3 above. Things can get broken trying to mix your system
xkbcomp (with builtin path /usr/share/X11/xkb) and local xkb files. I
think we just have to make sure people understand this change. I just
wanted to note the drawback of it.
We should remove this stupid macro and just #define the path to
xkbcomp until some glorious future where it doesn't need to be forked
from the server. That's a separate patch, but --with-xkbcomp would be
better.
That would require a more extensive patch affecting at least three .c files
in xkb/.
Yep, some other day unless Daniel lands xkb2 and nukes xkbcomp from orbit.
--
Dan
___
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: [Pixman] [PATCH] Fix server crash in pixman (to be discussed)
Matthias Hopf mh...@suse.de writes: On Mar 24, 10 19:19:15 +0100, Soeren Sandmann wrote: However, what happens if the code would have been compiled with -NDEBUG? Is the code path stable with empty regions? If it is, it can be argued that the patch is not necessary, but it could also be argued that the assert() shouldn't have been there in the first place. Who knows? Who knows if it's stable even *with* the patch? That's why I don't want it in for 0.18.0. Right. I just want to indicate that just disabling the assert()s typically is no solution for issues like this. Here are some bugs that have caused asserts: - The X server constructed a region directly from a list of rectangles that wasn't XY banded. This eventually caused asserts. - The X server directly initialized the extents rectangle to an empty rectangle. (That's at least what I think is going on with your bug here). - 16 bit integer overflows from a very large CopyArea caused the region to look strange which caused asserts. The first one was fixed in the X server, and the second one could be. The third one is difficult to do anything about because we really do need regions with unsigned 16 bit extents. Relying on signed integer overflow, which is undefined in C, is pretty dubious. The solution to the third one is to simply move to 32 bit regions. Things that should happen: - X server should be moved to 32 bit pixman regions - All the region macros and miRegion should go away - In particular, the X server should stop calling pixman_region_set_static_pointers(). (This function only exists to preserve the driver ABI) - pixman gets a new ABI in which the 16 bit regions don't exist anymore, and in which the names of the fields are changed. - X server is made to compile against the new ABI. Then asserts could be reenabled, but even then, crashing the X server is not something to be done lightly. Soren ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Define/use pad_to_pow_two() instead of open coding it
On Wed, 24 Mar 2010 14:59:04 -0400, Matt Turner matts...@gmail.com wrote:
On Wed, Mar 24, 2010 at 2:56 PM, Mark Kettenis mark.kette...@xs4all.nl
wrote:
From: Matt Turner matts...@gmail.com
Date: Wed, 24 Mar 2010 13:57:15 -0400
diff --git a/hw/dmx/dmxpict.c b/hw/dmx/dmxpict.c
index 072e3a6..51616bb 100644
--- a/hw/dmx/dmxpict.c
+++ b/hw/dmx/dmxpict.c
@@ -674,7 +674,7 @@ static int dmxProcRenderSetPictureFilter(ClientPtr
client)
if (pPictPriv-pict) {
filter = (char *)(stuff + 1);
- params = (XFixed *)(filter + ((stuff-nbytes + 3) ~3));
+ params = (XFixed *)(filter + pad_to_pow_two(stuff-nbytes, 4));
Sorry, but to me this isn't an improvement. I probably spend to much
time on kernel hacking, but the origional is immediately obvious to
me, whereas the new line makes me think you're trying to align to a
16-byte boundary.
Hmm, yes, I see what you're saying. I changed the name to try to make
it explicitly obvious that 'alignment' must be a power of two, but I
see it is actually a little confusing.
What would you suggest for the name of the function?
ALIGN, like the kernel.
pgp9Qh0jYm4Xt.pgp
Description: PGP 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] Define/use pad_to_pow_two() instead of open coding it
On Wed, Mar 24, 2010 at 4:29 PM, Eric Anholt e...@anholt.net wrote:
On Wed, 24 Mar 2010 14:59:04 -0400, Matt Turner matts...@gmail.com wrote:
On Wed, Mar 24, 2010 at 2:56 PM, Mark Kettenis mark.kette...@xs4all.nl
wrote:
From: Matt Turner matts...@gmail.com
Date: Wed, 24 Mar 2010 13:57:15 -0400
diff --git a/hw/dmx/dmxpict.c b/hw/dmx/dmxpict.c
index 072e3a6..51616bb 100644
--- a/hw/dmx/dmxpict.c
+++ b/hw/dmx/dmxpict.c
@@ -674,7 +674,7 @@ static int dmxProcRenderSetPictureFilter(ClientPtr
client)
if (pPictPriv-pict) {
filter = (char *)(stuff + 1);
- params = (XFixed *)(filter + ((stuff-nbytes + 3) ~3));
+ params = (XFixed *)(filter + pad_to_pow_two(stuff-nbytes, 4));
Sorry, but to me this isn't an improvement. I probably spend to much
time on kernel hacking, but the origional is immediately obvious to
me, whereas the new line makes me think you're trying to align to a
16-byte boundary.
Hmm, yes, I see what you're saying. I changed the name to try to make
it explicitly obvious that 'alignment' must be a power of two, but I
see it is actually a little confusing.
What would you suggest for the name of the function?
ALIGN, like the kernel.
Got it.
Please see attached. (just the same patch with s/pad_to_pow_two/ALIGN/)
Matt
0001-Define-use-ALIGN-instead-of-open-coding-it.patch
Description: Binary data
___
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] Define/use pad_to_pow_two() instead of open coding it
On Wed, Mar 24, 2010 at 4:29 PM, Eric Anholt e...@anholt.net wrote:
On Wed, 24 Mar 2010 14:59:04 -0400, Matt Turner matts...@gmail.com wrote:
On Wed, Mar 24, 2010 at 2:56 PM, Mark Kettenis mark.kette...@xs4all.nl
wrote:
From: Matt Turner matts...@gmail.com
Date: Wed, 24 Mar 2010 13:57:15 -0400
diff --git a/hw/dmx/dmxpict.c b/hw/dmx/dmxpict.c
index 072e3a6..51616bb 100644
--- a/hw/dmx/dmxpict.c
+++ b/hw/dmx/dmxpict.c
@@ -674,7 +674,7 @@ static int dmxProcRenderSetPictureFilter(ClientPtr
client)
if (pPictPriv-pict) {
filter = (char *)(stuff + 1);
- params = (XFixed *)(filter + ((stuff-nbytes + 3) ~3));
+ params = (XFixed *)(filter + pad_to_pow_two(stuff-nbytes, 4));
Sorry, but to me this isn't an improvement. I probably spend to much
time on kernel hacking, but the origional is immediately obvious to
me, whereas the new line makes me think you're trying to align to a
16-byte boundary.
Hmm, yes, I see what you're saying. I changed the name to try to make
it explicitly obvious that 'alignment' must be a power of two, but I
see it is actually a little confusing.
What would you suggest for the name of the function?
ALIGN, like the kernel.
I prefer ALIGN as well.
Alex
___
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 all drivers] config: set more appropriate default drivers location
On Wed, Mar 24, 2010 at 12:38 PM, Gaetan Nadon mems...@videotron.ca wrote:
On Wed, 2010-03-24 at 11:25 -0700, Dan Nicholson wrote:
On Wed, Mar 24, 2010 at 11:11 AM, Gaetan Nadon mems...@videotron.ca wrote:
The current value is based on $lib which is based on the driver package
$prefix. The driver object code will be installed in the correct xserver
location
only if both the driver package and the xserver package have the same
prefix.
This patch obtains the drivers object code location from the installed
xserver
package through the xorg-server.pc file. The server default location for
drivers
object code is based on its own $lib but this may have been changed at
configuration
time (using with-module-dir). In any case, the resulting net location is
returned.
Signed-off-by: Gaetan Nadon mems...@videotron.ca
---
configure.ac | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index c1fae22..c3f33a2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -55,9 +55,9 @@ AH_TOP([#include xorg-server.h])
AC_ARG_WITH(xorg-module-dir,
AC_HELP_STRING([--with-xorg-module-dir=DIR],
- [Default xorg module directory
[[default=$libdir/xorg/modules]]]),
+ [Default xorg module directory
[[default=$moduledir/xorg/modules]]]),
[moduledir=$withval],
- [moduledir=$libdir/xorg/modules])
+ [moduledir=`$PKG_CONFIG --variable=moduledir xorg-server`])
AC_ARG_ENABLE(dri, AC_HELP_STRING([--disable-dri],
[Disable DRI support [[default=auto]]]),
--
1.6.0.4
My assumption is that the drivers can only be loaded if they are located
in the running server xorg/modules/drivers directory that it knows
about at configuration time. If that is correct, the only value that
with-xorg-module-dir can be given is the value that the server returns
through the xorg-server .pc file.
You can set the module path with -modulepath on the command line or
ModulePath in a Files section in xorg.conf.
I wasn't aware of that. It's an additional workaround for a bad default
value.
So, you can definitely
handle drivers that are in a different prefix. More problematic, this
will break distcheck unless you set it back under $prefix with
DISTCHECK_CONFIGURE_FLAGS. This is like the chat we had about drivers
installing headers outside the xorg $includedir (which we might want
to revisit since it's doing the opposite unnecessarily).
I think this issue with distcheck (which fails for a user without write
permission in moduledir) is quite
exaggerated. All instructions I have seen on the net for people installing
drivers require them to have root password.
For someone who is creating a tarball to be published to others, it's the
least to ask. Running this
target is mandatory, there are other ways of testing.
I would agree that it's a not a very useful feature, but that's what
distcheck does. And we want distcheck to pass so that people rely on
it when they make tarballs. It's like adding code workarounds for
compiler warnings so that the important warnings don't get lost in the
noise.
In any case, there 5 easy workarounds for distcheck:
Yep, I'm just noting that your patches need to have one because
breaking distcheck is not OK.
- configure the driver package with moduledir=some comfy location and then
run distcheck.
- configure the driver package with libdir=some comfy location and then
run distcheck.
- we add DISTCHECK_CONFIGURE_FLAGS =
--with-xorg-module-dir='$${libdir}/xorg/modules'.
I'd prefer this since it's the most foolproof.
- we add DISTCHECK_CONFIGURE_FLAGS = --libdir='$${libdir}/xorg/modules'.
- run 'make all dist distcheckclean' in a VPATH build which would be the
exact equivalent of distcheck.
The question remains: would `$PKG_CONFIG --variable=moduledir xorg-server`
not be a better default option?
- The configuration would not fail when different prefixes are used for
driver and xserver (without config swicth)
- Thousands of people would no longer be forced to hunt for and supply the
correct driver location
- All drivers could be build with no additional configure switches
- With one workaround above, the few people creating tarball without
password would not be affected.
Example of instructions found on the net:
./configure --with-xorg-module-dir=/usr/lib/xorg/modules
make sudo make install
I don't feel that strongly about the value as long as it doesn't break
things. I can see arguments in either direction.
--
Dan
___
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 xserver] Cleanup some comments in SpriteRec
Signed-off-by: Fernando Carrijo fcarr...@yahoo.com.br
---
include/inputstr.h | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/inputstr.h b/include/inputstr.h
index 15184d0..2acd704 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -386,8 +386,16 @@ typedef struct {
int spriteTraceSize;
int spriteTraceGood;
-ScreenPtr pEnqueueScreen; /* screen events are being delivered to */
-ScreenPtr pDequeueScreen; /* screen events are being dispatched to */
+/* Due to delays incurred by event processing, it is possible that the
+ * pointer has crossed screen boundaries between the period of time in
+ * which it begins generating events and the instant in which those
+ * events get delivered to clients.
+ *
+ * pEnqueueScreen: screen the pointer was on when the event was generated
+ * pDequeueScreen: screen the pointer was on when the event was delivered
+ */
+ScreenPtr pEnqueueScreen;
+ScreenPtr pDequeueScreen;
} SpriteRec, *SpritePtr;
--
1.6.3.3
___
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] Cleanup some comments in SpriteRec
On Wed, Mar 24, 2010 at 08:11:34PM -0300, Fernando Carrijo wrote:
Signed-off-by: Fernando Carrijo fcarr...@yahoo.com.br
---
include/inputstr.h | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/inputstr.h b/include/inputstr.h
index 15184d0..2acd704 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -386,8 +386,16 @@ typedef struct {
int spriteTraceSize;
int spriteTraceGood;
-ScreenPtr pEnqueueScreen; /* screen events are being delivered to */
-ScreenPtr pDequeueScreen; /* screen events are being dispatched to */
+/* Due to delays incurred by event processing, it is possible that the
+ * pointer has crossed screen boundaries between the period of time in
+ * which it begins generating events and the instant in which those
+ * events get delivered to clients.
+ *
+ * pEnqueueScreen: screen the pointer was on when the event was generated
+ * pDequeueScreen: screen the pointer was on when the event was delivered
+ */
+ScreenPtr pEnqueueScreen;
+ScreenPtr pDequeueScreen;
} SpriteRec, *SpritePtr;
--
1.6.3.3
As discussed on IRC, I've reworded it a bit and merged it in. Thanks for
the patch.
Cheers,
Peter
___
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 AC_PROG_SED and respect its result
Le 24/03/2010 20:03, Yaakov (Cygwin/X) a écrit : From: Yaakov Selkowitz yselkow...@users.sourceforge.net AC_PROG_SED sets SED as the path to a fully-functional 'sed' (which may also be called 'gsed' if GNU sed is installed alongside a proprietary version). This is a follow up to commit 9be4157391edf0c5fc4ee36adfb1eb1c3bdb8e3b. Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net Reviewed-by: Rémi Cardona r...@gentoo.org Cheers, Rémi ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] kdrive: Bump evdev maxKeycode
On Tue, Mar 23, 2010 at 01:03:53AM +0600, Mikhail Gusarov wrote: There are keycodes 193 in evdev, e.g. KEY_WIMAX which is 246 . Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net Reviewed-by: Peter Hutterer peter.hutte...@who-t.net Acked-by: Adam Jackson a...@nwnk.net Acked-by: Daniel Stone dan...@fooishbar.org pgpE9lx0gaRiY.pgp Description: PGP 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: [xserver patch] Optimize shadowUpdatePacked()
On Mon, Mar 22, 2010 at 08:13:42PM +0200, Adrian Bunk wrote: From: Ilpo Ruotsalainen ilpo.ruotsalai...@movial.com http://bugs.freedesktop.org/show_bug.cgi?id=26973 Signed-off-by: Adrian Bunk adrian.b...@movial.com --- We already ship this patch in the ARM Linux Internet Platform, and it looks like a good candidate for upstream inclusion. The #define PickBit can be deleted, but that's unrelated. I assume you're only using this for rotation? If so, it'd be much better to bang up a quick skeleton RandR 1.2 implementation that could reuse the software rotation code from Xorg, which will be accelerated far better through pixman's insanely-optimised CopyArea. Cheers, Daniel pgpKDHZ2keH8y.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] os: Prevent backtrace from being stopped in noreturn functions.
On Wed, Mar 17, 2010 at 12:16:57PM +0200, Rami Ylimaki wrote: There are two noreturn functions in the X server: FatalError and AbortServer. Having any of those two functions in the middle of a call stack will prevent unwinding the program properly and stops the backtrace at those functions in gdb. The file containing FatalError and AbortServer, os/log.c, has to be compiled with the -mapcs-frame option on ARM to get proper backtraces. Automake imposes its own restrictions on compiling individual source files with different options. The recommended way to do this is to put os/log.c into a convenience library and add this library inside os/libos.la. See the documentation of GNU Automake manual, version 1.11.1, section 27.8 Per-Object Flags Emulation, for details. Signed-off-by: Rami Ylimaki ext-rami.ylim...@nokia.com --- Fixed based on previous review feedback. I'm aware that GCC should also be fixed at some point, but nevertheless it'd be nice to get this fix integrated upstream because we don't have the possibility to switch to a patched GCC anytime soon. Yeah, I know this is unpleasant, but ... Reviewed-by: Daniel Stone dan...@fooishbar.org pgpkVq13n0OTJ.pgp Description: PGP 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 Tue, Mar 23, 2010 at 10:30:24AM -0700, Jeremy Huddleston wrote: 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 rand() is part of ISO C ... Cheers, Daniel pgplavpFovuak.pgp Description: PGP 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] configure: enable udev backend as auto
On Wed, Mar 24, 2010 at 11:08:55AM +1000, Peter Hutterer wrote: Due to the checks in configure, this means it gets priority over HAL if libudev is found. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- Is it time yet to ring the bells on HAL? Fedora's been building with udev enabled for quite a while now and IIRC Debian for even longer. I think switching to udev as the default for 1.8 is a good idea. As long as Debian testing and Lucid or whatever are shipping a reasonable version of udev by then, sure. With that proviso -- Acked-by: Daniel Stone dan...@fooishbar.org Cheers, Daniel pgpyqtfL67acf.pgp Description: PGP 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] Ignore linuxdoc generated docs
On Wed, 2010-03-24 at 15:52 -0500, Yaakov (Cygwin/X) wrote: On 2010-03-24 01:21, Yaakov (Cygwin/X) wrote: --- a/hw/dmx/doc/.gitignore +++ b/hw/dmx/doc/.gitignore @@ -1,2 +1,5 @@ # Add Override for this directory and it's subdirectories html/ +*.html +*.pdf +*.ps Are hw/dmx/doc/*.txt really supposed to be in git? They are generated at build time from SGML. In a perfect world, no. This was done so that platform not having the doc generation tool can still be able to read the doc in txt form. A side-effect of having a file both in git and generated is that git will refuse to rebase due to a non clean directory following a make. The doc generation is disabled by default, so this should not happen often. I think the patch you have submitted is the best one can do under the circumstances. Yaakov Cygwin/X ___ 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 signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] configure: enable udev backend as auto
On Wed, Mar 24, 2010 at 04:06:30PM +1100, Daniel Stone wrote: On Wed, Mar 24, 2010 at 11:08:55AM +1000, Peter Hutterer wrote: Due to the checks in configure, this means it gets priority over HAL if libudev is found. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- Is it time yet to ring the bells on HAL? Fedora's been building with udev enabled for quite a while now and IIRC Debian for even longer. I think switching to udev as the default for 1.8 is a good idea. As long as Debian testing and Lucid or whatever are shipping a reasonable version of udev by then, sure. With that proviso -- Acked-by: Daniel Stone dan...@fooishbar.org well, if not they can still disable it when required. This only changes the _default_, HAL is still there anyway. I'd rather move off the fdi files as soon as possible. Cheers, Peter ___ 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] configure: enable udev backend as auto
On Wed, Mar 24, 2010 at 16:06:30 +1100, Daniel Stone wrote: On Wed, Mar 24, 2010 at 11:08:55AM +1000, Peter Hutterer wrote: Due to the checks in configure, this means it gets priority over HAL if libudev is found. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- Is it time yet to ring the bells on HAL? Fedora's been building with udev enabled for quite a while now and IIRC Debian for even longer. I think switching to udev as the default for 1.8 is a good idea. As long as Debian testing and Lucid or whatever are shipping a reasonable version of udev by then, sure. Debian unstable has been using (a previous version of) this code since January 7th, Debian testing since January 27th, and Ubuntu lucid since December 7th, AFAICT. Other than a couple of initial glitches (which got fixed upstream) it seems to be working fine. Cheers, Julien ___ 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 all drivers] config: set more appropriate default drivers location
On Wed, 2010-03-24 at 14:23 -0700, Dan Nicholson wrote:
On Wed, Mar 24, 2010 at 12:38 PM, Gaetan Nadon mems...@videotron.ca wrote:
On Wed, 2010-03-24 at 11:25 -0700, Dan Nicholson wrote:
On Wed, Mar 24, 2010 at 11:11 AM, Gaetan Nadon mems...@videotron.ca wrote:
The current value is based on $lib which is based on the driver package
$prefix. The driver object code will be installed in the correct xserver
location
only if both the driver package and the xserver package have the same
prefix.
This patch obtains the drivers object code location from the installed
xserver
package through the xorg-server.pc file. The server default location for
drivers
object code is based on its own $lib but this may have been changed at
configuration
time (using with-module-dir). In any case, the resulting net location is
returned.
Signed-off-by: Gaetan Nadon mems...@videotron.ca
---
configure.ac |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index c1fae22..c3f33a2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -55,9 +55,9 @@ AH_TOP([#include xorg-server.h])
AC_ARG_WITH(xorg-module-dir,
AC_HELP_STRING([--with-xorg-module-dir=DIR],
- [Default xorg module directory
[[default=$libdir/xorg/modules]]]),
+ [Default xorg module directory
[[default=$moduledir/xorg/modules]]]),
[moduledir=$withval],
-[moduledir=$libdir/xorg/modules])
+[moduledir=`$PKG_CONFIG --variable=moduledir xorg-server`])
AC_ARG_ENABLE(dri, AC_HELP_STRING([--disable-dri],
[Disable DRI support [[default=auto]]]),
--
1.6.0.4
My assumption is that the drivers can only be loaded if they are located
in the running server xorg/modules/drivers directory that it knows
about at configuration time. If that is correct, the only value that
with-xorg-module-dir can be given is the value that the server returns
through the xorg-server .pc file.
You can set the module path with -modulepath on the command line or
ModulePath in a Files section in xorg.conf.
I wasn't aware of that. It's an additional workaround for a bad default
value.
So, you can definitely
handle drivers that are in a different prefix. More problematic, this
will break distcheck unless you set it back under $prefix with
DISTCHECK_CONFIGURE_FLAGS. This is like the chat we had about drivers
installing headers outside the xorg $includedir (which we might want
to revisit since it's doing the opposite unnecessarily).
I think this issue with distcheck (which fails for a user without write
permission in moduledir) is quite
exaggerated. All instructions I have seen on the net for people installing
drivers require them to have root password.
For someone who is creating a tarball to be published to others, it's the
least to ask. Running this
target is mandatory, there are other ways of testing.
I would agree that it's a not a very useful feature, but that's what
distcheck does. And we want distcheck to pass so that people rely on
it when they make tarballs. It's like adding code workarounds for
compiler warnings so that the important warnings don't get lost in the
noise.
I am a big supporter of distcheck. I fixed it in several packages.
In any case, there 5 easy workarounds for distcheck:
Yep, I'm just noting that your patches need to have one because
breaking distcheck is not OK.
Only for those who don't have write permissions in the modules
directory.
- configure the driver package with moduledir=some comfy location and then
run distcheck.
- configure the driver package with libdir=some comfy location and then
run distcheck.
- we add DISTCHECK_CONFIGURE_FLAGS =
--with-xorg-module-dir='$${libdir}/xorg/modules'.
I'd prefer this since it's the most foolproof.
Agreed
- we add DISTCHECK_CONFIGURE_FLAGS = --libdir='$${libdir}/xorg/modules'.
- run 'make all dist distcheckclean' in a VPATH build which would be the
exact equivalent of distcheck.
The question remains: would `$PKG_CONFIG --variable=moduledir xorg-server`
not be a better default option?
- The configuration would not fail when different prefixes are used for
driver and xserver (without config swicth)
- Thousands of people would no longer be forced to hunt for and supply the
correct driver location
- All drivers could be build with no additional configure switches
- With one workaround above, the few people creating tarball without
password would not be affected.
Example of instructions found on the net:
./configure --with-xorg-module-dir=/usr/lib/xorg/modules
make sudo make install
I don't feel that strongly about the value as long as it doesn't break
things. I can see arguments in either direction.
Then there is no point in changing it.
[PULL] input fixes for 1.8
Keith, Please pull from my repo for a set of 1.8 fixes. The most obvious fix is the change to use udev by default if available rather than requiring it be explicitly enabled at configure time. The rest are fixes with little impact. Cheers, Peter The following changes since commit 3083c5d0c4386cdd7083b7a83ac72fdad2f1e61e: Michel Dänzer (1): Xext: Fix cursor reference counting hazard. are available in the git repository at: git://people.freedesktop.org/~whot/xserver.git for-keith Fernando Carrijo (1): Cleanup some comments in SpriteRec Jeremy Huddleston (1): XKB: Fix garbage initialization Peter Hutterer (4): configure: Always define XINPUT. xfree86: remove if 1 from the dawn of time. configure: enable udev backend as auto xfree86: merge driver from the input class into the options. configure.ac |3 ++- hw/xfree86/common/xf86Xinput.c |1 + hw/xfree86/os-support/shared/posix_tty.c | 10 -- include/inputstr.h | 12 ++-- xkb/xkbUtils.c |2 +- 5 files changed, 14 insertions(+), 14 deletions(-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Ignore linuxdoc generated docs
On 2010-03-24 19:57, Gaetan Nadon wrote: In a perfect world, no. This was done so that platform not having the doc generation tool can still be able to read the doc in txt form. A side-effect of having a file both in git and generated is that git will refuse to rebase due to a non clean directory following a make. The doc generation is disabled by default, so this should not happen often. I think the patch you have submitted is the best one can do under the circumstances. AFAIK no other generated txt files are in git. I somehow doubt that hw/dmx/doc/dmx.txt is more important than, say, hw/xfree86/doc/sgml/DESIGN.txt which is also generated and not in git. Any objections to a patch for their removal? Yaakov Cygwin/X ___ 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: A question for Xserver debug
Done as Alan said. rm /hw/xfree86/Xorg , then rebuild and install. The modificaiotn to main takes effect. The dependency is not build well for this. Ajax, how to do solve this? Thanks Frank Message: 8 Date: Wed, 24 Mar 2010 13:19:25 -0400 From: Adam Jackson a...@nwnk.net Subject: Re: A question for Xserver debug To: Alan Coopersmith alan.coopersm...@sun.com Cc: Huang, FrankR frankr.hu...@amd.com, xorg-devel@lists.x.org Message-ID: 1269451165.10304.146.ca...@atropine.boston.devel.redhat.com Content-Type: text/plain; charset=utf-8 On Wed, 2010-03-24 at 06:20 -0700, Alan Coopersmith wrote: Huang, FrankR wrote: Hi,all I am debugging the xserver code now. But one thing has puzzled me. When I add some modification to /dix/main.c , then make make install. Though the new main.c file has been compiled, no modification effect display. After that, I do some modification to /hw/xfree86/common/xf86Init.c. Do the same steps. The modification to main.c displays at the same time. Why this happens?? No one has ever gone through the exercise of ensuring the complex dependencies are properly setup to force rebuilding the Xorg server any time any related file changes. Sometimes you just have to manually rm hw/xfree86/Xorg and then make install. If this annoys you, we're happy to review proposed patches to improve it. I did add the 'relink' target for this reason. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/2] test: compare byte padding macros against the expected bytes.
We calculate the expected bytes for each value, let's use it. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- test/input.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/test/input.c b/test/input.c index 63d1a18..f6aef81 100644 --- a/test/input.c +++ b/test/input.c @@ -693,6 +693,7 @@ static void include_byte_padding_macros(void) g_assert(bits_to_bytes(i) = i/8); g_assert((bits_to_bytes(i) * 8) - i = 7); +g_assert(expected_bytes == bits_to_bytes(i)); } g_test_message(Testing bytes_to_int32()); @@ -703,6 +704,7 @@ static void include_byte_padding_macros(void) g_assert(bytes_to_int32(i) = i); g_assert((bytes_to_int32(i) * 4) - i = 3); +g_assert(expected_4byte == bytes_to_int32(i)); } g_test_message(Testing pad_to_int32); @@ -714,6 +716,7 @@ static void include_byte_padding_macros(void) g_assert(pad_to_int32(i) = i); g_assert(pad_to_int32(i) - i = 3); +g_assert(expected_bytes == pad_to_int32(i)); } } -- 1.6.6.1 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/2] test: reduce range of byte-padding macro tests.
Byte padding and conversion is interesting for the rage of 0-8 bytes, and
then interesting towards the end of the valid range (INT_MAX - 7 and INT_MAX
- 3).
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
test/input.c | 68 +++--
1 files changed, 51 insertions(+), 17 deletions(-)
diff --git a/test/input.c b/test/input.c
index f6aef81..99fd06c 100644
--- a/test/input.c
+++ b/test/input.c
@@ -680,45 +680,79 @@ static void dix_grab_matching(void)
g_assert(rc == TRUE);
}
-static void include_byte_padding_macros(void)
+static void test_bits_to_byte(int i)
{
-int i;
-g_test_message(Testing bits_to_bytes());
-
-/* the macros don't provide overflow protection */
-for (i = 0; i INT_MAX - 7; i++)
-{
int expected_bytes;
expected_bytes = (i + 7)/8;
g_assert(bits_to_bytes(i) = i/8);
g_assert((bits_to_bytes(i) * 8) - i = 7);
g_assert(expected_bytes == bits_to_bytes(i));
-}
+}
-g_test_message(Testing bytes_to_int32());
-for (i = 0; i INT_MAX - 3; i++)
-{
+static void test_bytes_to_int32(int i)
+{
int expected_4byte;
expected_4byte = (i + 3)/4;
g_assert(bytes_to_int32(i) = i);
g_assert((bytes_to_int32(i) * 4) - i = 3);
g_assert(expected_4byte == bytes_to_int32(i));
-}
-
-g_test_message(Testing pad_to_int32);
+}
-for (i = 0; i INT_MAX - 3; i++)
-{
+static void test_pad_to_int32(int i)
+{
int expected_bytes;
expected_bytes = ((i + 3)/4) * 4;
g_assert(pad_to_int32(i) = i);
g_assert(pad_to_int32(i) - i = 3);
g_assert(expected_bytes == pad_to_int32(i));
-}
+}
+static void include_byte_padding_macros(void)
+{
+g_test_message(Testing bits_to_bytes());
+
+/* the macros don't provide overflow protection */
+test_bits_to_byte(0);
+test_bits_to_byte(1);
+test_bits_to_byte(2);
+test_bits_to_byte(3);
+test_bits_to_byte(4);
+test_bits_to_byte(5);
+test_bits_to_byte(6);
+test_bits_to_byte(0xFF);
+test_bits_to_byte(0x100);
+test_bits_to_byte(INT_MAX - 9);
+test_bits_to_byte(INT_MAX - 8);
+
+g_test_message(Testing bytes_to_int32());
+
+test_bytes_to_int32(0);
+test_bytes_to_int32(1);
+test_bytes_to_int32(2);
+test_bytes_to_int32(3);
+test_bytes_to_int32(4);
+test_bytes_to_int32(5);
+test_bytes_to_int32(6);
+test_bytes_to_int32(0xFF);
+test_bytes_to_int32(0x100);
+test_bytes_to_int32(INT_MAX - 4);
+test_bytes_to_int32(INT_MAX - 3);
+
+g_test_message(Testing pad_to_int32);
+test_pad_to_int32(0);
+test_pad_to_int32(1);
+test_pad_to_int32(2);
+test_pad_to_int32(3);
+test_pad_to_int32(4);
+test_pad_to_int32(5);
+test_pad_to_int32(6);
+test_pad_to_int32(0xFF);
+test_pad_to_int32(0x100);
+test_pad_to_int32(INT_MAX - 4);
+test_pad_to_int32(INT_MAX - 3);
}
static void xi_unregister_handlers(void)
--
1.6.6.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] input fixes for 1.8
On Thu, 25 Mar 2010 11:36:31 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: Please pull from my repo for a set of 1.8 fixes. The most obvious fix is the change to use udev by default if available rather than requiring it be explicitly enabled at configure time. Are you sure we've got enough test coverage in the 1.8 release series to switch this close to the release? I know I haven't been running udev yet as it hasn't been the default... -- keith.pack...@intel.com pgpcVZXW5Uc0e.pgp Description: PGP 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] configure: enable udev backend as auto
On Thu, 25 Mar 2010 02:27:40 +0100, Julien Cristau jcris...@debian.org wrote: Debian unstable has been using (a previous version of) this code since January 7th, Debian testing since January 27th, and Ubuntu lucid since December 7th, AFAICT. Other than a couple of initial glitches (which got fixed upstream) it seems to be working fine. Thanks for getting this tested; I'll give it a try before pushing it out, just to satisfy my curiosity. -- keith.pack...@intel.com pgpcyej0fFATA.pgp Description: PGP 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
