please test: Xlib/XCB fixes
Josh and I sorted out a bunch of Xlib bugs this week, especially in support for multi-threaded applications. I'm embarrassed that I hadn't realized the thread support was so bad--but there are so few threaded Xlib apps, and even fewer that are open source. One important fix is in libxcb master. Several more fixes are in libX11 master, but my invasive rework of xcb_io.c is in an xlib-xcb-thread-fixes branch pending testing and/or review. http://cgit.freedesktop.org/xorg/lib/libX11/log/?h=xlib-xcb-thread-fixes These changes need testing to make sure I didn't introduce regressions for the single-threaded applications that were already working. And of course, if anyone has multi-threaded apps that were failing, please retest them and let me know if these patches helped. Also, please review these patches. The final patch of the libX11 series adds lots of comments--including things I had to explain to Josh while he was reviewing--and the new invariants it maintains are relatively straightforward, so I hope others can make sense of it too. While most of the bugs we fixed affected only clients using the connection from multiple threads, some additional fixes affect single-threaded applications as well. I believe at least these bugs have been solved by these changes: - https://bugs.freedesktop.org/show_bug.cgi?id=26545 - https://bugs.freedesktop.org/show_bug.cgi?id=27595 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535534 If you can take some time to go through your favorite bug tracking system looking for other bugs that sound relevant, please do. Since I have all this stuff swapped in now, this would be a good time to bring more Xlib/XCB-related bug reports to my attention... :-) Hoping to be Done With Xlib any day now, Jamey signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Merged proto package
On Sat, Apr 17, 2010 at 09:20:45PM -0700, Keith Packard wrote: On Fri, 16 Apr 2010 22:45:02 +0200, olafbuddenha...@gmx.net wrote: On Tue, Apr 06, 2010 at 06:43:22PM -0700, Keith Packard wrote: This isn't a git super-module, Well, why not? I don't think the wire protocol is a place where we should be encouraging a mix-n-match approach to development or releases. This part of the repository doesn't change all that often, and changes here really should get more rigorous scrutiny and testing than anything else we work on. Finally, an argument from either side I can get behind. ;) Cheers, Daniel pgpGq0h9jdBO0.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] Print git describe output into the log file.
On Fri, Apr 16, 2010 at 11:00:50AM -0700, Dan Nicholson wrote: On Fri, Apr 16, 2010 at 10:32 AM, Gaetan Nadon mems...@videotron.ca wrote: On Fri, 2010-04-16 at 06:31 -0700, Dan Nicholson wrote: It might be nicer, but could get messy when you consider all the corner cases. True, and the mess can be contained in a macro. Reusing the design for ChangeLog is worth a shot. Not to mention the script brings a mess of it's own in the build. It introduces multiple points of failure. Finding a home for the mess is not obvious. But the reason we put the ChangeLog mess in a macro is because it would be used across all the modules. If it's only being used here, then you might as well put it in the Makefile where it can be clean instead of a shell variable that's substituted. Unless we think this is going to be used in a lot places. I don't see why not. People are going to copy it and/or patch it in anyway, and as with ChangeLog, it'll just get out of hand and we'll wish we'd have used a macro in the first place. Cheers, Daniel pgpOaYttqP2iO.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] xfree86: dga needs to the master keyboard state (#27573)
On Fri, Apr 16, 2010 at 04:35:22PM +1000, Peter Hutterer wrote: GetPairedDevice() may not always return the keyboard, resulting in a null-pointer derefernce when accessing the XKB state. X.Org Bug 27573 http://bugs.freedesktop.org/show_bug.cgi?id=27573 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Reviewed-by: Daniel Stone dan...@fooishbar.org pgpMKIOl3hKNb.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 resent] configure: introduce --{enable, disable}-syscall-clock
On Fri, Apr 16, 2010 at 03:10:19PM +0300, Tiago Vignatti wrote: Some Linux systems might not want to link against rt and pthread libraries simply to implement monotonic clock (GetTimeInMillis). For those, use a direct syscall instead. This is discouraged if someone doesn't know what's doing. This patch keeps the new syscall version disabled by default - therefore not changing the original behaviour of the xserver build. One, using this patch, should worry about a possible performance degradation due it's not going through optimized code in C library. Therefore, the simple program bellow (kudos to Adam Jackson) should performs equally in the practice, for both syscall and C library implementation: #ifdef SYSCALL_MONOTONIC_CLOCK #define clock_gettime(a, b) syscall(SYS_clock_gettime, a, b) #endif [...] Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com --- Myself, ajax, alanc and others discussed already on IRC about the performance degradation. We all ran the program above, obtaining equally results within different environments. Jesus wept. We've spent the last six years _deleting_ this kind of code. ;) Was there any actual performance degradation from linking librt in the end, or was it just about memory usage? I remember the Intel guys saying that just linking to libpthread made lock overhead show up in their profiles, but IIRC the solution to that was to remove superfluous locks ... Cheers, Daniel pgp9ptpyTINHX.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] exa: don't need to check for NULL pointer if we already assumed it has a value
On Sat, Apr 17, 2010 at 08:45:38AM -0700, Dan Nicholson wrote: It seems it would be better to check ps unless you're pretty sure pScreen always has a PictureScreen. Looking at this code showed me another bug. #ifdef RENDER PictureScreenPtrps = GetPictureScreenIfSet(pScreen); #endif if (ps-Glyphs == exaGlyphs) exaGlyphsFini(pScreen); Shouldn't this whole block be under RENDER like the later accesses to ps? Incidentally, if you just change the conditional to if (ps ps-Glyphs == exaGlyphs), then the NULL pointer won't be dereferenced either. Eh. This is configure.ac ... from 1st July, 2005: dnl dnl A bunch of configuration values which shouldn't be optional dnl AC_DEFINE(RENDER,1,[Support RENDER extension]) EXTENSION_LIBS=$EXTENSION_LIBS '$(top_builddir)/render/librender.la' EXTENSION_INCS=$EXTENSION_INCS '-I$(top_srcdir)/render' Cheers, Daniel pgpWrWqyvcOCV.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] xkb: Fix omissions in geometry initialization #27679
On Sat, Apr 17, 2010 at 09:36:23PM +0200, Dirk Wallenstein wrote: _XkbCopyGeom did not copy all of the data from the source geometry. This resulted in failures when trying to obtain the keymap from a server where the default geometry has not been replaced by a custom configuration. Signed-off-by: Dirk Wallenstein hals...@t-online.de Thanks -- seems entirely correct. Reviewed-by: Daniel Stone dan...@fooishbar.org pgpzvRUOMZwYQ.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: [PULL] XKB fixes
On Mon, Apr 19, 2010 at 05:30:48PM +1000, Daniel Stone wrote: On Mon, Apr 19, 2010 at 10:17:08AM +1000, Peter Hutterer wrote: Keith, please pull from my repo below. It contains Benjamin's overflow fix and the xkb cleanup for PointerKeys. Might be good to get Dirk's _XkbCopyGeom fix in with this too, since that's been confusing everyone who's ever run xkbcomp. Haven't had the time to review it yet, it'll have to wait a bit. 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] xfree86: dga needs to the master keyboard state (#27573)
On Fri, Apr 16, 2010 at 16:35:22 +1000, Peter Hutterer wrote: GetPairedDevice() may not always return the keyboard, resulting in a null-pointer derefernce when accessing the XKB state. X.Org Bug 27573 http://bugs.freedesktop.org/show_bug.cgi?id=27573 Ben followed up on the bug and unfortunately this didn't fix it :( 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] xfree86: dga needs to the master keyboard state (#27573)
On Mon, Apr 19, 2010 at 11:26:23AM +0200, Julien Cristau wrote: On Fri, Apr 16, 2010 at 16:35:22 +1000, Peter Hutterer wrote: GetPairedDevice() may not always return the keyboard, resulting in a null-pointer derefernce when accessing the XKB state. X.Org Bug 27573 http://bugs.freedesktop.org/show_bug.cgi?id=27573 Ben followed up on the bug and unfortunately this didn't fix it :( I'll still merge that patch in though, because there's the potential that it fixes another issue (whether that's an actual use-case or not is another question). I'll remove the bug references though. 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: Live builds (was: Merged proto package)
On Sun, 18 Apr 2010 19:30:31 +0200 Dirk Wallenstein hals...@t-online.de wrote: A full-fledged meta-git repo management tool suite would be nice. Such an application would, for example, be able to: - inform about the state of the modules (dirty, ahead of origin/master, not on master, etc) - swap in and out personal trees. Maybe simply per symlinks. - check out a particular katamari version of each module Does something similar exist already? One might assume that all larger projects, like for example desktop environments, could need something like that. check out peter hutterer's git supermodule: $ git clone git://people.freedesktop.org/~whot/X11R7.5.git $ cd X11R7.5 $ git submodule init git submodule update $ ./TINDERBOX /opt/xorg-7.5 and the corresponding man-pages... :) cheers, Flo ___ 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: [PATCHv2 1/2] DRI2: Track DRI2 drawables as resources, not privates
On Fre, 2010-04-09 at 14:18 -0400, Kristian Høgsberg wrote:
The main motivation here is to have the resource system clean up the
DRI2 drawable automatically so glx doesn't have to. Right now, the
glx drawable resource must be destroyed before the X drawable, so that
calling DRI2DestroyDrawable doesn't crash. By making the DRI2
drawable a resource, GLX doesn't have to worry about that and the
resource destruction order becomes irrelevant.
https://bugs.freedesktop.org/show_bug.cgi?id=26394
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
There's a problem with this change (and potentially in DRI2SwapEvent()
even before it): at least the pixmaps backing redirected windows still
have -drawable.id == 0. This can result in weird behaviour with a GLX
compositing manager, e.g. when running the same app twice in a row: the
second window will show a static snapshot of the first one, because the
compositing manager gets the DRI2 front buffer from the first, since
destroyed window.
The patch below fixes that symptom, but I'm not sure it's correct. Right
now I'm getting memory corruption when logging out or just restarting
compiz, but then again people seem to be reporting such symptoms against
server-1.8-branch anyway.
BTW, shouldn't ProcDRI2DestroyDrawable() still destroy/unreference the
DRI2 drawable resource?
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 9752003..87918d9 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -451,7 +451,7 @@ __glXDRIscreenCreateDrawable(__GLXscreen *screen,
private-base.waitGL = __glXDRIdrawableWaitGL;
private-base.waitX= __glXDRIdrawableWaitX;
-if (DRI2CreateDrawable(pDraw)) {
+if (DRI2CreateDrawable(pDraw, drawId)) {
xfree(private);
return NULL;
}
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 642ea19..05da225 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -125,13 +125,16 @@ DRI2GetDrawable(DrawablePtr pDraw)
}
int
-DRI2CreateDrawable(DrawablePtr pDraw)
+DRI2CreateDrawable(DrawablePtr pDraw, XID id)
{
DRI2ScreenPtr ds = DRI2GetScreen(pDraw-pScreen);
DRI2DrawablePtr pPriv;
CARD64 ust;
intrc;
+if (!pDraw-id)
+ pDraw-id = id;
+
rc = dixLookupResourceByType((pointer *) pPriv, pDraw-id,
dri2DrawableRes, NULL, DixReadAccess);
if (rc == Success || rc != BadValue)
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index a695c6d..42dd66e 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -199,7 +199,7 @@ extern _X_EXPORT Bool DRI2Connect(ScreenPtr pScreen,
extern _X_EXPORT Bool DRI2Authenticate(ScreenPtr pScreen, drm_magic_t magic);
-extern _X_EXPORT int DRI2CreateDrawable(DrawablePtr pDraw);
+extern _X_EXPORT int DRI2CreateDrawable(DrawablePtr pDraw, XID id);
extern _X_EXPORT void DRI2DestroyDrawable(DrawablePtr pDraw);
diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
index 78f897b..6015126 100644
--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -167,7 +167,7 @@ ProcDRI2CreateDrawable(ClientPtr client)
pDrawable, status))
return status;
-status = DRI2CreateDrawable(pDrawable);
+status = DRI2CreateDrawable(pDrawable, stuff-drawable);
if (status != Success)
return status;
--
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: please test: Xlib/XCB fixes
Am 19.04.2010 08:33, schrieb Jamey Sharp: Hoping to be Done With Xlib any day now, Jamey I could follow your reasoning and the changes make sense to me. But I don't know the overall system enough to pretend that's a review. Maybe a good gsoc/student project would be to model Xlib/xcb concurrency in e.g. promela, then strike 'Hoping', place 'Confident'. Or similar. Just my 5c, Simon ___ 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: please test: Xlib/XCB fixes
Does you guys have any flowcharts/diagrams/etc of any of the blocks/functions/pieces? I'm trying to round up any and all useful information for any/all of X. thanks, Matt On Mon, Apr 19, 2010 at 7:49 PM, Simon Thum simon.t...@gmx.de wrote: Am 19.04.2010 08:33, schrieb Jamey Sharp: Hoping to be Done With Xlib any day now, Jamey I could follow your reasoning and the changes make sense to me. But I don't know the overall system enough to pretend that's a review. Maybe a good gsoc/student project would be to model Xlib/xcb concurrency in e.g. promela, then strike 'Hoping', place 'Confident'. Or similar. Just my 5c, Simon ___ 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 v2] Print git describe output into the log file.
On Mon, Apr 19, 2010 at 12:05 AM, Daniel Stone dan...@fooishbar.org wrote: On Fri, Apr 16, 2010 at 11:00:50AM -0700, Dan Nicholson wrote: On Fri, Apr 16, 2010 at 10:32 AM, Gaetan Nadon mems...@videotron.ca wrote: On Fri, 2010-04-16 at 06:31 -0700, Dan Nicholson wrote: It might be nicer, but could get messy when you consider all the corner cases. True, and the mess can be contained in a macro. Reusing the design for ChangeLog is worth a shot. Not to mention the script brings a mess of it's own in the build. It introduces multiple points of failure. Finding a home for the mess is not obvious. But the reason we put the ChangeLog mess in a macro is because it would be used across all the modules. If it's only being used here, then you might as well put it in the Makefile where it can be clean instead of a shell variable that's substituted. Unless we think this is going to be used in a lot places. I don't see why not. People are going to copy it and/or patch it in anyway, and as with ChangeLog, it'll just get out of hand and we'll wish we'd have used a macro in the first place. True. This is probably more me thinking a variable substituted from a shell script is the wrong way to distribute this and wishing you could install 3rd party automake rules. -- 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: please test: Xlib/XCB fixes
Jamey Sharp wrote: Josh and I sorted out a bunch of Xlib bugs this week, especially in support for multi-threaded applications. I'm embarrassed that I hadn't realized the thread support was so bad--but there are so few threaded Xlib apps, and even fewer that are open source. This sounds great. Writing threaded GL apps has been a challenge because of threading bugs in Xlib. If you have a Mesa tree built, try progs/xdemos/glthreads. If you use a software renderer (swrast or softpipe) you'll be drawing everything through Xlib. -Brian ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH input-evdev 00/10] Configuration upgrades
On Mon, 2010-04-19 at 09:58 +1000, Peter Hutterer wrote: On Sat, Apr 17, 2010 at 07:28:00PM -0400, Gaetan Nadon wrote: Patch #1 concept has been reviewed but code is different Patch #7 is a change that has not been reviewed in other patches yet. Other changes have been reviewed in other patches Gaetan Nadon (10): config: remove AH_TOP autoheader statement config: update AC_PREREQ statement to 2.60 replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: remove unrequired AC_HEADER_STDC config: refactor and comment the sdkdir distcheck workaround config: replace deprecated INCLUDES with AM_CPPFLAGS config: optional extension check for inputproto not required config: fix warnings, m4 quoting and layout include: EXTRA_DIST is not required for header files. man: Use Autoconf provided $(AM_V_GEN)$(SED) Makefile.am |2 +- configure.ac| 63 -- include/Makefile.am |1 - man/Makefile.am |4 +-- src/Makefile.am |3 +- src/evdev.c |1 + 6 files changed, 34 insertions(+), 40 deletions(-) Reviewed-by: Peter Hutterer peter.hutte...@who-t.net except for that one comment I sent separately. Can you pop this into your $HOME please and I'll pull from there. Want to get a few test runs in before it lands on master, just in case. Peter, Done. Other input drivers have similar changes.In some cases, I am not certain of what is the best option: --enable-debug: there are 3 input drivers and one video driver with this config option. I am not sure this should be exposed on the package public interface if only used by x.org developers at development time. If it's a good thing, perhaps it should be on all drivers. Many video drivers have a *DEBUG* kind of #define, but no configure option, The actual name varies. I guess there is no architected way of turning debug on several packages using the same method. joystick: the enable-debug option is always on by default. Very unusual. aiptek/evdev only runs Linux while joystick runs on Linux/BSD. Should these be conditional compiled so as to build on any platform? If they were part of xserver, they would have to be. The following changes since commit aaf65e7bfacd9501c4475a579d92c3bc60409893: Paulo Ricardo Zanoni (1): Don't set pEvdev-rel for mouse wheel events are available in the git repository at: git://people.freedesktop.org/~gnadon/xf86-input-evdev master Gaetan Nadon (10): config: remove AH_TOP autoheader statement config: update AC_PREREQ statement to 2.60 replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: remove unrequired AC_HEADER_STDC config: refactor and comment the sdkdir distcheck workaround config: replace deprecated INCLUDES with AM_CPPFLAGS config: optional extension check for inputproto not required config: require macros 1.4, fix warnings, m4 quotings and layout include: EXTRA_DIST is not required for header files. man: Use Autoconf provided $(AM_V_GEN)$(SED) Makefile.am |2 +- configure.ac| 63 -- include/Makefile.am |1 - man/Makefile.am |4 +-- src/Makefile.am |3 +- src/evdev.c |1 + 6 files changed, 34 insertions(+), 40 deletions(-) thanks! Cheers, Peter 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
[PATCH] RFC: Only match against event[0-9] in udev rules for vmmouse
It looks like the udev rule was matched against two devices which caused
the driver to be loaded twice. We shouldn't match against the other
device because it will very seldom send bogus events. Some of the bug
this caused was buttons getting stuck.
---
tools/69-xorg-vmmouse.rules.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/69-xorg-vmmouse.rules.in b/tools/69-xorg-vmmouse.rules.in
index 0d7f028..602afb6 100644
--- a/tools/69-xorg-vmmouse.rules.in
+++ b/tools/69-xorg-vmmouse.rules.in
@@ -1 +1 @@
-ACTION==add|change, ENV{ID_INPUT_MOUSE}==?*, ATTRS{description}==i8042
AUX port, PROGRAM=__BIN_PREFIX__/vmmouse_detect, ENV{ID_INPUT.tags}=vmmouse
+ACTION==add|change, ENV{ID_INPUT_MOUSE}==?*, ATTRS{description}==i8042
AUX port, KERNEL==event[0-9]*, PROGRAM=__BIN_PREFIX__/vmmouse_detect,
ENV{ID_INPUT.tags}=vmmouse
--
1.6.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] RFC: Only match against event[0-9] in udev rules for vmmouse
On Mon, 2010-04-19 at 15:37 +0100, Jakob Bornecrantz wrote:
It looks like the udev rule was matched against two devices which caused
the driver to be loaded twice. We shouldn't match against the other
device because it will very seldom send bogus events. Some of the bug
this caused was buttons getting stuck.
---
tools/69-xorg-vmmouse.rules.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/69-xorg-vmmouse.rules.in b/tools/69-xorg-vmmouse.rules.in
index 0d7f028..602afb6 100644
--- a/tools/69-xorg-vmmouse.rules.in
+++ b/tools/69-xorg-vmmouse.rules.in
@@ -1 +1 @@
-ACTION==add|change, ENV{ID_INPUT_MOUSE}==?*, ATTRS{description}==i8042
AUX port, PROGRAM=__BIN_PREFIX__/vmmouse_detect,
ENV{ID_INPUT.tags}=vmmouse
+ACTION==add|change, ENV{ID_INPUT_MOUSE}==?*, ATTRS{description}==i8042
AUX port, KERNEL==event[0-9]*, PROGRAM=__BIN_PREFIX__/vmmouse_detect,
ENV{ID_INPUT.tags}=vmmouse
Reviewed-by: Michel Dänzer daen...@vmware.com
--
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: Bell confusion with master vs. slave devices in Xorg 1.7.6
Peter Hutterer wrote: Why not have the slave inherit the volume level of the master when it is attached? Careful here - a client may change the bell on just one device and detach it (or implicitly detach with a grab). In this case, the device shouldn't inherit the bell volume from the master again - that's why it was set on the device directly. Where the above approach would work is on the first EnableDevice() for this device - this is guaranteed to be the first attachment and the one where we may change the bell volume based on the MD. Should xset on the VCK update the values in defaultKeyboardControl then? -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Is Xvnc a X exension or X driver?
(I've cc'ed xorg-devel, since this is really much more of a developer topic than a user topic.) Zhang, Xing Z wrote: Hi experts: I am looking into code of tigervnc, the Xvnc contains a vnc X server which seems a X driver or extension ( it locates at tigervnc-1.0.1/unix/xserver/hw/vnc). VNC includes an X extension, but Xvnc itself is an X server using the hw/vnc DDX layer. Originally X support for different hardware was delivered by having a different DDX layer for each, resulting in multiple different X servers and changing X servers to use different types. In the current code, the hw/xfree86 layer provides a common DDX layer for many types of hardware with loadable driver modules for each type, but there are still other DDX layers for other types of X server, such as Xvnc, Xvfb Xnest, as well as the kdrive DDX layer which supports multiple hardware types using the older model of per-hardware X server binaries. Could anyone point me a programming howto followed by above implementation? I gone through documentations on X.org, but didn't find programming manual of such a extension/driver. There isn't a lot of up-to-date documentation on X server internals - not many people are interested in spending the huge amounts of time required to write a programming manual that less than 100 people will ever read. Documents that do exist (though not necessarily completely up-to-date): * Definition of the Porting Layer for the X v11 Sample Server: html: http://www.x.org/releases/X11R7.5/doc/core/Xserver-spec.html pdf: http://www.x.org/releases/X11R7.5/doc/core/Xserver-spec.pdf * The X Window System Server, Elias Israel, Erik Fortune, Digital Press, ISBN 1-8-096-3, 1993. (X11R5 era, though some basic concepts are still unchanged) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] unifdef -B -DRENDER to always include RENDER code
This patch was created with:
git ls-files '*.[ch]' | while read f; do unifdef -B -DRENDER -o $f $f; done
Signed-off-by: Keith Packard kei...@keithp.com
---
Xext/panoramiX.c |6 --
Xext/panoramiX.h |2 --
exa/exa.c | 10 --
exa/exa_priv.h |6 --
exa/exa_render.c |2 --
exa/exa_unaccel.c | 10 --
fb/fb.h|4
fb/fbpict.c|8
fb/fbtrap.c|3 ---
hw/dmx/dmx.h |4
hw/dmx/dmxclient.h |2 --
hw/dmx/dmxextension.c | 10 --
hw/dmx/dmxinit.c |4
hw/dmx/dmxscrinit.c|8
hw/dmx/dmxwindow.c |8
hw/dmx/dmxwindow.h |2 --
hw/kdrive/src/kdrive.c |2 --
hw/vfb/InitOutput.c|4
hw/xfree86/common/xf86Config.c |4
hw/xfree86/common/xf86Init.c | 10 --
hw/xfree86/common/xf86VGAarbiter.c | 12
hw/xfree86/common/xf86VGAarbiterPriv.h |6 --
hw/xfree86/modes/xf86Crtc.c|4
hw/xfree86/modes/xf86Cursors.c |2 --
hw/xfree86/shadowfb/shadow.c | 16
hw/xfree86/xaa/xaa.h |7 ---
hw/xfree86/xaa/xaaInit.c |4
hw/xfree86/xaa/xaaInitAccel.c |2 --
hw/xfree86/xaa/xaaStateChange.c|6 --
hw/xfree86/xaa/xaaWrapper.c| 12
hw/xfree86/xaa/xaalocal.h |7 ---
hw/xfree86/xaa/xaawrap.h |2 --
hw/xquartz/darwin.c|2 --
hw/xquartz/mach-startup/launchd_fd.h |2 +-
hw/xwin/InitOutput.c |2 --
hw/xwin/win.h |2 --
hw/xwin/winscrinit.c |2 --
hw/xwin/winwin32rootless.c |7 ---
hw/xwin/winwin32rootlesswndproc.c |6 --
include/cursor.h |2 --
include/globals.h |2 --
mi/miinitext.c | 10 --
miext/cw/cw.c | 10 --
miext/cw/cw.h |2 --
miext/cw/cw_render.c |3 ---
miext/damage/damage.c |7 ---
miext/damage/damagestr.h |4
miext/rootless/rootlessCommon.h|4
miext/rootless/rootlessScreen.c|6 --
miext/shadow/shadow.h |2 --
os/utils.c |8
randr/randrstr.h |2 --
randr/rrinfo.c |2 --
randr/rrscreen.c |4
xfixes/region.c| 10 --
55 files changed, 1 insertions(+), 289 deletions(-)
diff --git a/Xext/panoramiX.c b/Xext/panoramiX.c
index cfeba01..96eb8f9 100644
--- a/Xext/panoramiX.c
+++ b/Xext/panoramiX.c
@@ -52,9 +52,7 @@ Equipment Corporation.
#include globals.h
#include servermd.h
#include resource.h
-#ifdef RENDER
#include picturestr.h
-#endif
#include modinit.h
#include protocol-versions.h
@@ -589,9 +587,7 @@ void PanoramiXExtensionInit(int argc, char *argv[])
ProcVector[X_StoreColors] = PanoramiXStoreColors;
ProcVector[X_StoreNamedColor] = PanoramiXStoreNamedColor;
-#ifdef RENDER
PanoramiXRenderInit ();
-#endif
}
extern Bool CreateConnectionBlock(void);
@@ -891,9 +887,7 @@ static void PanoramiXResetProc(ExtensionEntry* extEntry)
{
inti;
-#ifdef RENDER
PanoramiXRenderReset ();
-#endif
screenInfo.numScreens = PanoramiXNumScreens;
for (i = 256; i--; )
ProcVector[i] = SavedProcVector[i];
diff --git a/Xext/panoramiX.h b/Xext/panoramiX.h
index cca4c52..463a994 100644
--- a/Xext/panoramiX.h
+++ b/Xext/panoramiX.h
@@ -69,11 +69,9 @@ typedef struct {
struct {
Bool shared;
} pix;
-#ifdef RENDER
struct {
Bool root;
} pict;
-#endif
char raw_data[4];
} u;
} PanoramiXRes;
diff --git a/exa/exa.c b/exa/exa.c
index 590d9a5..dcfa4b3 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -753,9 +753,7 @@ static Bool
exaCloseScreen(int i, ScreenPtr pScreen)
{
ExaScreenPriv(pScreen);
-#ifdef RENDER
PictureScreenPtr ps = GetPictureScreenIfSet(pScreen);
-#endif
if (ps-Glyphs == exaGlyphs)
exaGlyphsFini(pScreen);
@@ -778,7 +776,6 @@ exaCloseScreen(int i, ScreenPtr pScreen)
unwrap(pExaScr, pScreen, ChangeWindowAttributes);
unwrap(pExaScr, pScreen, BitmapToRegion);
unwrap(pExaScr, pScreen, CreateScreenResources);
-#ifdef RENDER
if (ps) {
Re: [PATCH] unifdef -B -DRENDER to always include RENDER code
On Mon, 19 Apr 2010 09:53:32 -0700, Keith Packard kei...@keithp.com wrote: This patch was created with: git ls-files '*.[ch]' | while read f; do unifdef -B -DRENDER -o $f $f; done This is not an actual proposal to apply this patch, I just wanted to start discussion on what we could do if we really want to eliminate the silly 'we have to have this #define' stuff in our configuration. Are there existing #defines that we require for all X servers? Is RENDER one of them? -- keith.pack...@intel.com pgpljVKGVjBu0.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
[PATCH xserver] coverity findings v2
Hi, I had check all commentaries people gave and reworked accordingly. Let's see if now looks better for you. Besides, the last two patches here no one commented, so I'm resending. Both concern a not reached very old code (so gray hair people are very welcome to comment on :). Thanks, Tiago Vignatti (8): xfree86: check for NULL pointer before dereferences it in parser code Xi: check for NULL pointer before dereferences it in ListButtonInfo dix: check for NULL pointer before dereferences it in DeviceEnterLeaveEvent exa: don't need to check for NULL pointer if we already assumed it has a value xkb: check for NULL pointer before dereferences it in XkbWriteXKBSymbols xkb: check for NULL pointer before dereferences it in XkbAddClientResource xfree86: fix not reached code in tty code xfree86: fix not reached code in fi1236 driver from i2c Xi/xiquerydevice.c |5 - dix/events.c |6 +- exa/exa.c| 14 ++ hw/xfree86/i2c/fi1236.c |4 hw/xfree86/os-support/shared/posix_tty.c | 13 - hw/xfree86/parser/scan.c |7 +-- xkb/xkbEvents.c |3 +-- xkb/xkbout.c |2 +- 8 files changed, 22 insertions(+), 32 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
[PATCH] xfree86: check for NULL pointer before dereferences it in parser code
Seems to be harmless. Meh.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
hw/xfree86/parser/scan.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/parser/scan.c b/hw/xfree86/parser/scan.c
index 8aab0cf..06710d5 100644
--- a/hw/xfree86/parser/scan.c
+++ b/hw/xfree86/parser/scan.c
@@ -845,10 +845,13 @@ static int
ConfigFilter(const struct dirent *de)
{
const char *name = de-d_name;
- size_t len = strlen(name);
+ size_t len;
size_t suflen = strlen(XCONFIGSUFFIX);
- if (!name || name[0] == '.' || len = suflen)
+ if (!name || name[0] == '.')
+ return 0;
+ len = strlen(name);
+ if(len = suflen)
return 0;
if (strcmp(name[len-suflen], XCONFIGSUFFIX) != 0)
return 0;
--
1.6.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] exa: don't need to check for NULL pointer if we already assumed it has a value
the alternative would be to check ps in the beginning of the function.
---
exa/exa.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 590d9a5..b2bd1c5 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -779,14 +779,12 @@ exaCloseScreen(int i, ScreenPtr pScreen)
unwrap(pExaScr, pScreen, BitmapToRegion);
unwrap(pExaScr, pScreen, CreateScreenResources);
#ifdef RENDER
-if (ps) {
- unwrap(pExaScr, ps, Composite);
- if (pExaScr-SavedGlyphs)
- unwrap(pExaScr, ps, Glyphs);
- unwrap(pExaScr, ps, Trapezoids);
- unwrap(pExaScr, ps, Triangles);
- unwrap(pExaScr, ps, AddTraps);
-}
+unwrap(pExaScr, ps, Composite);
+if (pExaScr-SavedGlyphs)
+ unwrap(pExaScr, ps, Glyphs);
+unwrap(pExaScr, ps, Trapezoids);
+unwrap(pExaScr, ps, Triangles);
+unwrap(pExaScr, ps, AddTraps);
#endif
xfree (pExaScr);
--
1.6.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xkb: check for NULL pointer before dereferences it in XkbAddClientResource
---
xkb/xkbEvents.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/xkb/xkbEvents.c b/xkb/xkbEvents.c
index 33741e9..9755f98 100644
--- a/xkb/xkbEvents.c
+++ b/xkb/xkbEvents.c
@@ -1041,8 +1041,7 @@ XkbInterestPtrinterest;
return ((interest-resource==id)?interest:NULL);
interest = interest-next;
}
-interest = xalloc(sizeof(XkbInterestRec));
-bzero(interest,sizeof(XkbInterestRec));
+interest = xcalloc(1, sizeof(XkbInterestRec));
if (interest) {
interest-dev = dev;
interest-client = client;
--
1.6.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Xi: check for NULL pointer before dereferences it in ListButtonInfo
Both dev and dev-button are already used before their checking were being performed. So check on the beginning. Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com --- Xi/xiquerydevice.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/Xi/xiquerydevice.c b/Xi/xiquerydevice.c index 435868d..47ab688 100644 --- a/Xi/xiquerydevice.c +++ b/Xi/xiquerydevice.c @@ -247,6 +247,9 @@ ListButtonInfo(DeviceIntPtr dev, xXIButtonInfo* info, Bool reportState) int mask_len; int i; +if (!dev || !dev-button) + return 0; + mask_len = bytes_to_int32(bits_to_bytes(dev-button-numButtons)); info-type = ButtonClass; @@ -259,7 +262,7 @@ ListButtonInfo(DeviceIntPtr dev, xXIButtonInfo* info, Bool reportState) memset(bits, 0, mask_len * 4); if (reportState) - for (i = 0; dev dev-button i dev-button-numButtons; i++) + for (i = 0; i dev-button-numButtons; i++) if (BitIsOn(dev-button-down, i)) SetBit(bits, i); -- 1.6.0.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xkb: check for NULL pointer before dereferences it in XkbWriteXKBSymbols
just moved the srv assignment to before it's being used.
---
xkb/xkbout.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xkb/xkbout.c b/xkb/xkbout.c
index 68ede90..9daac9a 100644
--- a/xkb/xkbout.c
+++ b/xkb/xkbout.c
@@ -354,7 +354,6 @@ XkbServerMapPtr srv;
Bool showActions;
map= xkb-map;
-srv= xkb-server;
if ((!xkb)||(!map)||(!map-syms)||(!map-key_sym_map)) {
_XkbLibError(_XkbErrMissingSymbols,XkbWriteXKBSymbols,0);
return FALSE;
@@ -376,6 +375,7 @@ BoolshowActions;
}
if (tmp0)
fprintf(file,\n);
+srv= xkb-server;
for (i=xkb-min_key_code;i=xkb-max_key_code;i++) {
Boolsimple;
if ((int)XkbKeyNumSyms(xkb,i)1)
--
1.6.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xfree86: fix not reached code in fi1236 driver from i2c
This issue was introduced in the first dump of the code in 2004. I haven't
check what's the correct fix for it so I simply kept the behaviour of someone
calling this and removed the unreachable code.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
hw/xfree86/i2c/fi1236.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/i2c/fi1236.c b/hw/xfree86/i2c/fi1236.c
index 7c39edb..61224ea 100644
--- a/hw/xfree86/i2c/fi1236.c
+++ b/hw/xfree86/i2c/fi1236.c
@@ -398,10 +398,6 @@ int TUNER_get_afc_hint(FI1236Ptr f)
{
if(f-afc_timer_installed)return TUNER_STILL_TUNING;
return f-last_afc_hint;
-if(f-type==TUNER_TYPE_MT2032)
- return MT2032_get_afc_hint(f);
- else
- return FI1236_get_afc_hint(f);
}
static void MT2032_dump_status(FI1236Ptr f)
--
1.6.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xfree86: fix not reached code in tty code
CLEARRTS_SUPPORT cannot be triggered at all.
Both commit logs and google don't show any clear reference about it, so I'd
vote to just delete.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
hw/xfree86/os-support/shared/posix_tty.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/hw/xfree86/os-support/shared/posix_tty.c
b/hw/xfree86/os-support/shared/posix_tty.c
index 4ba8599..f77f902 100644
--- a/hw/xfree86/os-support/shared/posix_tty.c
+++ b/hw/xfree86/os-support/shared/posix_tty.c
@@ -338,19 +338,6 @@ xf86SetSerial (int fd, pointer options)
xf86MarkOptionUsedByName (options, ClearDTR);
}
- if ((xf86SetBoolOption (options, ClearRTS, FALSE)))
- {
-#ifdef CLEARRTS_SUPPORT
- val = TIOCM_RTS;
- SYSCALL (ioctl(fd, TIOCMBIC, val));
-#else
- xf86Msg (X_WARNING,
-Option ClearRTS not supported on this OS\n);
- return (-1);
-#endif
- xf86MarkOptionUsedByName (options, ClearRTS);
- }
-
SYSCALL (r = tcsetattr (fd, TCSANOW, t));
return (r);
}
--
1.6.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: please test: Xlib/XCB fixes
On Mon, Apr 19, 2010 at 4:49 AM, Simon Thum simon.t...@gmx.de wrote: I could follow your reasoning and the changes make sense to me. But I don't know the overall system enough to pretend that's a review. It's a good data point, anyway. Thanks! Am 19.04.2010 08:33, schrieb Jamey Sharp: Hoping to be Done With Xlib any day now, Jamey Maybe a good gsoc/student project would be to model Xlib/xcb concurrency in e.g. promela, then strike 'Hoping', place 'Confident'. Or similar. Yes, I used to know someone who used Promela/Spin, and that would be awesome. We actually have proofs or proof sketches for parts of XCB, so for example I am Confident that pure XCB applications will never fail to insert GetInputFocus requests when needed to maintain sequence number synchronization, and also that it will always do so at the last possible instant. (I can also prove by counterexample that Xlib doesn't have either of these properties :-/ which would require huge ABI changes to fix.) We haven't used model-checkers for that, just logic and Hoare triples or Z. Jamey ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH input-evdev 00/10] Configuration upgrades
On Sat, Apr 17, 2010 at 4:28 PM, Gaetan Nadon mems...@videotron.ca wrote: Patch #1 concept has been reviewed but code is different Patch #7 is a change that has not been reviewed in other patches yet. Other changes have been reviewed in other patches Gaetan Nadon (10): config: remove AH_TOP autoheader statement config: update AC_PREREQ statement to 2.60 replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: remove unrequired AC_HEADER_STDC config: refactor and comment the sdkdir distcheck workaround config: replace deprecated INCLUDES with AM_CPPFLAGS config: optional extension check for inputproto not required config: fix warnings, m4 quoting and layout include: EXTRA_DIST is not required for header files. man: Use Autoconf provided $(AM_V_GEN)$(SED) Makefile.am | 2 +- configure.ac | 63 -- include/Makefile.am | 1 - man/Makefile.am | 4 +-- src/Makefile.am | 3 +- src/evdev.c | 1 + 6 files changed, 34 insertions(+), 40 deletions(-) These all looked reasonable to me, but I didn't test. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ 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 util-macros] XORG_GIT_MODULE_VERSION: writes module version in xorg-git-version.h
Generates the git module version according to the git describe HEAD If the git module has pending changes, it appends -dirty to the version tag Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 916b472..efb2e53 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -1009,3 +1009,21 @@ mv \$(top_srcdir)/.INSTALL.tmp \$(top_srcdir)/INSTALL) \ echo 'util-macros \pkgdatadir\ from xorg-macros.pc not found: installing possibly empty INSTALL.' 2) AC_SUBST([INSTALL_CMD]) ]) # XORG_INSTALL + +# XORG_GIT_MODULE_VERSION() +# - +# Minimum version: 1.8.0 +# +# Generates the git module version according to the git describe HEAD +# If the git module has pending changes, it appends -dirty to the version tag +# +AC_DEFUN([XORG_GIT_MODULE_VERSION], [ +GIT_MODULE_VERSION_CMD=VER=\`GIT_DIR=\$(top_srcdir)/.git git describe HEAD 2/dev/null\`; \ +DVER=\`GIT_DIR=\$(top_srcdir)/.git git diff-index HEAD 2/dev/null\`; \ +OUTSTR=\\#undef XORG_GIT_VERSION\ ; \ +OUTFILE=\xorg-git-version.h\; \ +test -n \\$\$VER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER\ test -n \\$\$DVER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER-dirty\; \ +test -e \\$\$OUTFILE\ || echo \\$\$OUTSTR\ \\$\$OUTFILE\; \ +CONTENT=\`cat \$\$OUTFILE\` test \\$\$CONTENT\ = \\$\$OUTSTR\ || echo \$\$OUTSTR \$\$OUTFILE; +AC_SUBST([GIT_MODULE_VERSION_CMD]) +]) # XORG_GIT_MODULE_VERSION -- 1.6.0.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH input-evdev 00/10] Configuration upgrades
On Mon, 2010-04-19 at 11:48 -0700, Dan Nicholson wrote: On Sat, Apr 17, 2010 at 4:28 PM, Gaetan Nadon mems...@videotron.ca wrote: Patch #1 concept has been reviewed but code is different Patch #7 is a change that has not been reviewed in other patches yet. Other changes have been reviewed in other patches Gaetan Nadon (10): config: remove AH_TOP autoheader statement config: update AC_PREREQ statement to 2.60 replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: remove unrequired AC_HEADER_STDC config: refactor and comment the sdkdir distcheck workaround config: replace deprecated INCLUDES with AM_CPPFLAGS config: optional extension check for inputproto not required config: fix warnings, m4 quoting and layout include: EXTRA_DIST is not required for header files. man: Use Autoconf provided $(AM_V_GEN)$(SED) Makefile.am |2 +- configure.ac| 63 -- include/Makefile.am |1 - man/Makefile.am |4 +-- src/Makefile.am |3 +- src/evdev.c |1 + 6 files changed, 34 insertions(+), 40 deletions(-) These all looked reasonable to me, but I didn't test. Thanks. I provided a pull request for Peter, he wants to git it a spin. Reviewed-by: Dan Nicholson dbn.li...@gmail.com 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 util-macros] XORG_GIT_MODULE_VERSION: writes module version in xorg-git-version.h
On Mon, Apr 19, 2010 at 11:52 AM, Gaetan Nadon mems...@videotron.ca wrote: Generates the git module version according to the git describe HEAD If the git module has pending changes, it appends -dirty to the version tag Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 916b472..efb2e53 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -1009,3 +1009,21 @@ mv \$(top_srcdir)/.INSTALL.tmp \$(top_srcdir)/INSTALL) \ echo 'util-macros \pkgdatadir\ from xorg-macros.pc not found: installing possibly empty INSTALL.' 2) AC_SUBST([INSTALL_CMD]) ]) # XORG_INSTALL + +# XORG_GIT_MODULE_VERSION() +# - +# Minimum version: 1.8.0 +# +# Generates the git module version according to the git describe HEAD +# If the git module has pending changes, it appends -dirty to the version tag +# +AC_DEFUN([XORG_GIT_MODULE_VERSION], [ +GIT_MODULE_VERSION_CMD=VER=\`GIT_DIR=\$(top_srcdir)/.git git describe HEAD 2/dev/null\`; \ +DVER=\`GIT_DIR=\$(top_srcdir)/.git git diff-index HEAD 2/dev/null\`; \ +OUTSTR=\\#undef XORG_GIT_VERSION\ ; \ +OUTFILE=\xorg-git-version.h\; \ IMO, OUTFILE should just be $...@. Then the module has flexibility over what the header is called. +test -n \\$\$VER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER\ test -n \\$\$DVER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER-dirty\; \ I don't I like dirty going in the version since it doesn't really provide any further information. That could be one string change or it could be a revamp of a subsystem. However, if it is kept, can we split this in two lines? test -n \\$\$VER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER\; \ test -n \\$\$DVER\ OUTSTR=\\$\$OUTSTR-dirty\; \ If VER isn't set, DVER won't be either. +test -e \\$\$OUTFILE\ || echo \\$\$OUTSTR\ \\$\$OUTFILE\; \ +CONTENT=\`cat \$\$OUTFILE\` test \\$\$CONTENT\ = \\$\$OUTSTR\ || echo \$\$OUTSTR \$\$OUTFILE; +AC_SUBST([GIT_MODULE_VERSION_CMD]) +]) # XORG_GIT_MODULE_VERSION -- 1.6.0.4 I wish it didn't have to be done this way. This is absolutely nasty. That said, it seems like it would work. -- 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 util-macros] XORG_GIT_MODULE_VERSION: writes module version in xorg-git-version.h
On Mon, Apr 19, 2010 at 14:52:55 -0400, Gaetan Nadon wrote: Generates the git module version according to the git describe HEAD If the git module has pending changes, it appends -dirty to the version tag Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 916b472..efb2e53 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -1009,3 +1009,21 @@ mv \$(top_srcdir)/.INSTALL.tmp \$(top_srcdir)/INSTALL) \ echo 'util-macros \pkgdatadir\ from xorg-macros.pc not found: installing possibly empty INSTALL.' 2) AC_SUBST([INSTALL_CMD]) ]) # XORG_INSTALL + +# XORG_GIT_MODULE_VERSION() +# - +# Minimum version: 1.8.0 +# +# Generates the git module version according to the git describe HEAD +# If the git module has pending changes, it appends -dirty to the version tag +# +AC_DEFUN([XORG_GIT_MODULE_VERSION], [ +GIT_MODULE_VERSION_CMD=VER=\`GIT_DIR=\$(top_srcdir)/.git git describe HEAD 2/dev/null\`; \ +DVER=\`GIT_DIR=\$(top_srcdir)/.git git diff-index HEAD 2/dev/null\`; \ +OUTSTR=\\#undef XORG_GIT_VERSION\ ; \ +OUTFILE=\xorg-git-version.h\; \ +test -n \\$\$VER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER\ test -n \\$\$DVER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER-dirty\; \ +test -e \\$\$OUTFILE\ || echo \\$\$OUTSTR\ \\$\$OUTFILE\; \ +CONTENT=\`cat \$\$OUTFILE\` test \\$\$CONTENT\ = \\$\$OUTSTR\ || echo \$\$OUTSTR \$\$OUTFILE; +AC_SUBST([GIT_MODULE_VERSION_CMD]) +]) # XORG_GIT_MODULE_VERSION As I said in reply to the initial patch by Peter I'd like a way to disable this, because packages might be built from a git tree, which might be unrelated to the xorg one, or outside of any git tree. What's the output like if not building from git? Does 'make GIT_MODULE_VERSION_CMD=:' work to disable it (I guess not, because anything trying to include xorg-git-version.h will be unhappy)? Other than that, I guess it looks about as nasty as an automake macro usually looks... I wish it was more readable, still, there are too many \s here for my liking... 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] unifdef -B -DRENDER to always include RENDER code
Keith Packard wrote: On Mon, 19 Apr 2010 09:53:32 -0700, Keith Packard kei...@keithp.com wrote: This patch was created with: git ls-files '*.[ch]' | while read f; do unifdef -B -DRENDER -o $f $f; done This is not an actual proposal to apply this patch, I just wanted to start discussion on what we could do if we really want to eliminate the silly 'we have to have this #define' stuff in our configuration. Are there existing #defines that we require for all X servers? Is RENDER one of them? I dunno. But if we go for it, we're going have an implementation that exceeds the protocol. Is that valid? Tiago ___ 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] unifdef -B -DRENDER to always include RENDER code
I almost asked about why we still had #ifdef RENDER when seeing the discussion
on Tiago's patches last week, I'm not sure if there's any point in keeping the
#ifdefs any more.
diff --git a/hw/vfb/InitOutput.c b/hw/vfb/InitOutput.c
index e7dd1d9..0428f0a 100644
--- a/hw/vfb/InitOutput.c
+++ b/hw/vfb/InitOutput.c
@@ -248,10 +248,8 @@ ddxUseMsg(void)
{
ErrorF(-screen scrn WxHxD set screen's width, height, depth\n);
ErrorF(-pixdepths list-of-int support given pixmap depths\n);
-#ifdef RENDER
ErrorF(+/-render turn on/of RENDER extension support
(default on)\n);
-#endif
Not really part of the unifdef patch, but a second patch to do s/of/off/ in that
message would be good.
Also, you seem to have somehow pulled in some non-RENDER related changes
(perhaps
because it realized the 0 made these always-dead already?):
diff --git a/hw/xwin/winwin32rootless.c b/hw/xwin/winwin32rootless.c
index c225a44..ac30621 100755
--- a/hw/xwin/winwin32rootless.c
+++ b/hw/xwin/winwin32rootless.c
@@ -894,9 +894,6 @@ winMWExtWMUpdateRegion (RootlessFrameID wid, RegionPtr
pDamage)
SIZE szWin;
POINT ptSrc;
#endif
-#if CYGMULTIWINDOW_DEBUG 0
- winDebug (winMWExtWMUpdateRegion (%08x)\n, pRLWinPriv);
-#endif
#if 0
szWin.cx = pRLWinPriv-dwWidth;
szWin.cy = pRLWinPriv-dwHeight;
@@ -938,10 +935,6 @@ winMWExtWMDamageRects (RootlessFrameID wid, int nCount,
const BoxRec *pRects,
{
win32RootlessWindowPtr pRLWinPriv = (win32RootlessWindowPtr) wid;
const BoxRec *pEnd;
-#if CYGMULTIWINDOW_DEBUG 0
- winDebug (winMWExtWMDamageRects (%08x, %d, %08x, %d, %d)\n,
- pRLWinPriv, nCount, pRects, shift_x, shift_y);
-#endif
for (pEnd = pRects + nCount; pRects pEnd; pRects++) {
RECT rcDmg;
diff --git a/hw/xwin/winwin32rootlesswndproc.c
b/hw/xwin/winwin32rootlesswndproc.c
index 4d7afee..a985c20 100755
--- a/hw/xwin/winwin32rootlesswndproc.c
+++ b/hw/xwin/winwin32rootlesswndproc.c
@@ -519,9 +519,6 @@ winMWExtWMWindowProc (HWND hwnd, UINT message,
break;
case WM_MOUSEMOVE:
-#if CYGMULTIWINDOW_DEBUG 0
- winDebug (winMWExtWMWindowProc - WM_MOUSEMOVE\n);
-#endif
/* Unpack the client area mouse coordinates */
ptMouse.x = GET_X_LPARAM(lParam);
ptMouse.y = GET_Y_LPARAM(lParam);
@@ -576,9 +573,6 @@ winMWExtWMWindowProc (HWND hwnd, UINT message,
return 0;
case WM_NCMOUSEMOVE:
-#if CYGMULTIWINDOW_DEBUG 0
- winDebug (winMWExtWMWindowProc - WM_NCMOUSEMOVE\n);
-#endif
/*
* We break instead of returning 0 since we need to call
* DefWindowProc to get the mouse cursor changes
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] unifdef -B -DRENDER to always include RENDER code
Date: Mon, 19 Apr 2010 14:27:11 -0700 From: Alan Coopersmith alan.coopersm...@oracle.com I almost asked about why we still had #ifdef RENDER when seeing the discussion on Tiago's patches last week, I'm not sure if there's any point in keeping the #ifdefs any more. I believe almost no modern applications work anymore without RENDER. At least that was my experience a year or three ago when trying applications that used the cairo library with drivers that didn't provide RENDER. In many cases they just crashed. ___ 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 Thu, Feb 18, 2010 at 06:07:14AM -0800, 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 Dan, is xtest really licensed under the Artistic license? I have some changes pending to clean up a whole lot of warnings, but I just noticed this term in the license: 3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, [...] I'd like to avoid having to go through and add a change note to all 551 files I've touched so far. -- Aaron ___ 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 Mon, Apr 19, 2010 at 2:42 PM, Aaron Plattner aplatt...@nvidia.com wrote: On Thu, Feb 18, 2010 at 06:07:14AM -0800, 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 Dan, is xtest really licensed under the Artistic license? I have some changes pending to clean up a whole lot of warnings, but I just noticed this term in the license: 3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, [...] I'd like to avoid having to go through and add a change note to all 551 files I've touched so far. I think the Artistic license applies to the bundled tet code (the test platform) in src/. This is what License says. However, everything under xts5 (the test suite itself) appears to be under the X11 license. So, if you've kept your modifications to xts5/, you're OK. Of course, now it appears I'll have to do that to address the hacking I did to the test platform to make it behave reasonably. What a weak license. -- 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] unifdef -B -DRENDER to always include RENDER code
On Tue, 20 Apr 2010 00:00:39 +0300, Tiago Vignatti vigna...@freedesktop.org wrote: But if we go for it, we're going have an implementation that exceeds the protocol. Is that valid? Sure, there's nothing saying that we have to be able to not provide certain extensions in the sample implementation; the core X protocol just isn't useable by the bulk of X applications these days without some of the 'standard' extensions. -- keith.pack...@intel.com pgprWGIvdxXNr.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] unifdef -B -DRENDER to always include RENDER code
On Mon, 19 Apr 2010 14:27:11 -0700, Alan Coopersmith alan.coopersm...@oracle.com wrote: Not really part of the unifdef patch, but a second patch to do s/of/off/ in that message would be good. Yeah, as you can imagine, any patch that changes as much as the RENDER stuff should be entirely mechanical. Also, you seem to have somehow pulled in some non-RENDER related changes (perhaps because it realized the 0 made these always-dead already?): Hrm. unifdef has the '-k' option (which I didn't use) that is supposed to leave #if lines that have constant expressions, and also '-K' which leaves expressions with and || undefined; looks like I need to add -K to leave this particular expression alone. -#if CYGMULTIWINDOW_DEBUG 0 - winDebug (winMWExtWMUpdateRegion (%08x)\n, pRLWinPriv); -#endif I looked over the patch but clearly missed this piece. -- keith.pack...@intel.com pgpTc1X4Xwl3S.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] unifdef -B -DRENDER to always include RENDER code
Keith Packard wrote: On Tue, 20 Apr 2010 00:00:39 +0300, Tiago Vignatti vigna...@freedesktop.org wrote: But if we go for it, we're going have an implementation that exceeds the protocol. Is that valid? Sure, there's nothing saying that we have to be able to not provide certain extensions in the sample implementation; the core X protocol just isn't useable by the bulk of X applications these days without some of the 'standard' extensions. Render would not be the first always-built extension in the X.Org implementation. SHAPE XKB were similarly unifdefed in the last couple of release cycles. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Is Xvnc a X exension or X driver?
While I'm not interested in writing a manual, I am trying to round up and organize existing docs and info. and I am really interested in any diagrams and such that people might have/know of for Xserver internals or how different pieces interact. If anyone has any docs/diagrams/handscanned cocktail napkins they find useful or helpful, please send me a like or copy. thanks, Matt On Mon, Apr 19, 2010 at 11:08 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: (I've cc'ed xorg-devel, since this is really much more of a developer topic than a user topic.) Zhang, Xing Z wrote: Hi experts: I am looking into code of tigervnc, the Xvnc contains a vnc X server which seems a X driver or extension ( it locates at tigervnc-1.0.1/unix/xserver/hw/vnc). VNC includes an X extension, but Xvnc itself is an X server using the hw/vnc DDX layer. Originally X support for different hardware was delivered by having a different DDX layer for each, resulting in multiple different X servers and changing X servers to use different types. In the current code, the hw/xfree86 layer provides a common DDX layer for many types of hardware with loadable driver modules for each type, but there are still other DDX layers for other types of X server, such as Xvnc, Xvfb Xnest, as well as the kdrive DDX layer which supports multiple hardware types using the older model of per-hardware X server binaries. Could anyone point me a programming howto followed by above implementation? I gone through documentations on X.org, but didn't find programming manual of such a extension/driver. There isn't a lot of up-to-date documentation on X server internals - not many people are interested in spending the huge amounts of time required to write a programming manual that less than 100 people will ever read. Documents that do exist (though not necessarily completely up-to-date): * Definition of the Porting Layer for the X v11 Sample Server: html: http://www.x.org/releases/X11R7.5/doc/core/Xserver-spec.html pdf: http://www.x.org/releases/X11R7.5/doc/core/Xserver-spec.pdf * The X Window System Server, Elias Israel, Erik Fortune, Digital Press, ISBN 1-8-096-3, 1993. (X11R5 era, though some basic concepts are still unchanged) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xkb: check for NULL pointer before dereferences it in XkbWriteXKBSymbols
Tiago Vignatti wrote:
just moved the srv assignment to before it's being used.
---
xkb/xkbout.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xkb/xkbout.c b/xkb/xkbout.c
index 68ede90..9daac9a 100644
--- a/xkb/xkbout.c
+++ b/xkb/xkbout.c
@@ -354,7 +354,6 @@ XkbServerMapPtr srv;
Bool showActions;
map= xkb-map;
-srv= xkb-server;
if ((!xkb)||(!map)||(!map-syms)||(!map-key_sym_map)) {
But you're still dereferencing xkb-map before checking xkb is not NULL.
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xfree86: check for NULL pointer before dereferences it in parser code
On Mon, Apr 19, 2010 at 08:58:02PM +0300, Tiago Vignatti wrote:
Seems to be harmless. Meh.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
hw/xfree86/parser/scan.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/parser/scan.c b/hw/xfree86/parser/scan.c
index 8aab0cf..06710d5 100644
--- a/hw/xfree86/parser/scan.c
+++ b/hw/xfree86/parser/scan.c
@@ -845,10 +845,13 @@ static int
ConfigFilter(const struct dirent *de)
{
const char *name = de-d_name;
- size_t len = strlen(name);
+ size_t len;
size_t suflen = strlen(XCONFIGSUFFIX);
- if (!name || name[0] == '.' || len = suflen)
+ if (!name || name[0] == '.')
+ return 0;
+ len = strlen(name);
+ if(len = suflen)
return 0;
if (strcmp(name[len-suflen], XCONFIGSUFFIX) != 0)
return 0;
--
1.6.0.4
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
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] Xi: check for NULL pointer before dereferences it in ListButtonInfo
On Mon, Apr 19, 2010 at 08:58:03PM +0300, Tiago Vignatti wrote: Both dev and dev-button are already used before their checking were being performed. So check on the beginning. Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com --- Xi/xiquerydevice.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/Xi/xiquerydevice.c b/Xi/xiquerydevice.c index 435868d..47ab688 100644 --- a/Xi/xiquerydevice.c +++ b/Xi/xiquerydevice.c @@ -247,6 +247,9 @@ ListButtonInfo(DeviceIntPtr dev, xXIButtonInfo* info, Bool reportState) int mask_len; int i; +if (!dev || !dev-button) + return 0; + mask_len = bytes_to_int32(bits_to_bytes(dev-button-numButtons)); info-type = ButtonClass; @@ -259,7 +262,7 @@ ListButtonInfo(DeviceIntPtr dev, xXIButtonInfo* info, Bool reportState) memset(bits, 0, mask_len * 4); if (reportState) - for (i = 0; dev dev-button i dev-button-numButtons; i++) + for (i = 0; i dev-button-numButtons; i++) if (BitIsOn(dev-button-down, i)) SetBit(bits, i); -- 1.6.0.4 Reviewed-by: Peter Hutterer peter.hutte...@who-t.net rather superfluous given the checks by the callers, but.. 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] dix: check for NULL pointer before dereferences it in DeviceEnterLeaveEvent
On Mon, Apr 19, 2010 at 08:58:04PM +0300, Tiago Vignatti wrote: mouse is already used before its checking should be performed. So check on the beginning instead. --- dix/events.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/dix/events.c b/dix/events.c index 6541652..8bec8af 100644 --- a/dix/events.c +++ b/dix/events.c @@ -4360,6 +4360,10 @@ DeviceEnterLeaveEvent( (mode == XINotifyPassiveUngrab type == XI_Enter)) return; +if (!mouse) +return; +grab = mouse-deviceGrab.grab; + there's something missing here, the assignment is still there - 6 lines above this hunk. also, not really a big fan of this change, if mouse is NULL we have other issues and I'd rather the server fails than be quiet about it. missing enter/leave events are nasty to debug. so if you just want to shut up coverity, remove all the mouse != NULL checks here but leave the rest there a landmine. Cheers, Peter btlen = (mouse-button) ? bits_to_bytes(mouse-button-numButtons) : 0; btlen = bytes_to_int32(btlen); len = sizeof(xXIEnterEvent) + btlen * 4; @@ -4378,7 +4382,7 @@ DeviceEnterLeaveEvent( event-root_x = FP1616(mouse-spriteInfo-sprite-hot.x, 0); event-root_y = FP1616(mouse-spriteInfo-sprite-hot.y, 0); -for (i = 0; mouse mouse-button i mouse-button-numButtons; i++) +for (i = 0; mouse-button i mouse-button-numButtons; i++) if (BitIsOn(mouse-button-down, i)) SetBit(event[1], i); -- 1.6.0.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xkb: check for NULL pointer before dereferences it in XkbAddClientResource
On Mon, Apr 19, 2010 at 08:58:07PM +0300, Tiago Vignatti wrote:
---
xkb/xkbEvents.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/xkb/xkbEvents.c b/xkb/xkbEvents.c
index 33741e9..9755f98 100644
--- a/xkb/xkbEvents.c
+++ b/xkb/xkbEvents.c
@@ -1041,8 +1041,7 @@ XkbInterestPtr interest;
return ((interest-resource==id)?interest:NULL);
interest = interest-next;
}
-interest = xalloc(sizeof(XkbInterestRec));
-bzero(interest,sizeof(XkbInterestRec));
+interest = xcalloc(1, sizeof(XkbInterestRec));
if (interest) {
interest-dev = dev;
interest-client = client;
--
1.6.0.4
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xfree86: fix not reached code in tty code
On Mon, Apr 19, 2010 at 08:58:08PM +0300, Tiago Vignatti wrote:
CLEARRTS_SUPPORT cannot be triggered at all.
Both commit logs and google don't show any clear reference about it, so I'd
vote to just delete.
man mousedrv
I'd leave the else branch there.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
hw/xfree86/os-support/shared/posix_tty.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/hw/xfree86/os-support/shared/posix_tty.c
b/hw/xfree86/os-support/shared/posix_tty.c
index 4ba8599..f77f902 100644
--- a/hw/xfree86/os-support/shared/posix_tty.c
+++ b/hw/xfree86/os-support/shared/posix_tty.c
@@ -338,19 +338,6 @@ xf86SetSerial (int fd, pointer options)
xf86MarkOptionUsedByName (options, ClearDTR);
}
- if ((xf86SetBoolOption (options, ClearRTS, FALSE)))
- {
-#ifdef CLEARRTS_SUPPORT
- val = TIOCM_RTS;
- SYSCALL (ioctl(fd, TIOCMBIC, val));
-#else
- xf86Msg (X_WARNING,
- Option ClearRTS not supported on this OS\n);
- return (-1);
-#endif
- xf86MarkOptionUsedByName (options, ClearRTS);
- }
-
SYSCALL (r = tcsetattr (fd, TCSANOW, t));
return (r);
}
--
1.6.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH util-macros] XORG_GIT_MODULE_VERSION: writes module version in xorg-git-version.h
On Mon, Apr 19, 2010 at 11:00:08PM +0200, Julien Cristau wrote: On Mon, Apr 19, 2010 at 14:52:55 -0400, Gaetan Nadon wrote: Generates the git module version according to the git describe HEAD If the git module has pending changes, it appends -dirty to the version tag Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 916b472..efb2e53 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -1009,3 +1009,21 @@ mv \$(top_srcdir)/.INSTALL.tmp \$(top_srcdir)/INSTALL) \ echo 'util-macros \pkgdatadir\ from xorg-macros.pc not found: installing possibly empty INSTALL.' 2) AC_SUBST([INSTALL_CMD]) ]) # XORG_INSTALL + +# XORG_GIT_MODULE_VERSION() +# - +# Minimum version: 1.8.0 +# +# Generates the git module version according to the git describe HEAD +# If the git module has pending changes, it appends -dirty to the version tag +# +AC_DEFUN([XORG_GIT_MODULE_VERSION], [ +GIT_MODULE_VERSION_CMD=VER=\`GIT_DIR=\$(top_srcdir)/.git git describe HEAD 2/dev/null\`; \ +DVER=\`GIT_DIR=\$(top_srcdir)/.git git diff-index HEAD 2/dev/null\`; \ +OUTSTR=\\#undef XORG_GIT_VERSION\ ; \ +OUTFILE=\xorg-git-version.h\; \ +test -n \\$\$VER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER\ test -n \\$\$DVER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER-dirty\; \ +test -e \\$\$OUTFILE\ || echo \\$\$OUTSTR\ \\$\$OUTFILE\; \ +CONTENT=\`cat \$\$OUTFILE\` test \\$\$CONTENT\ = \\$\$OUTSTR\ || echo \$\$OUTSTR \$\$OUTFILE; +AC_SUBST([GIT_MODULE_VERSION_CMD]) +]) # XORG_GIT_MODULE_VERSION my eyes! As I said in reply to the initial patch by Peter I'd like a way to disable this, because packages might be built from a git tree, which might be unrelated to the xorg one, or outside of any git tree. What's the output like if not building from git? Does 'make GIT_MODULE_VERSION_CMD=:' work to disable it (I guess not, because anything trying to include xorg-git-version.h will be unhappy)? it simply sets the #undef and nothing will be printed to the log file. Is there any specific argument against _running_ the macro as long if it doesn't add anything to the logfile? Gaetan: I'm not a big fan of the -dirty either but I guess if others want it we can leave it in. Two questions though: - If modules start using this macro, do they stillhave to add to DISTCLEANFILES and friends? - This macro only gets invoked on automake runs, right? So if I pull and just rebuild, would it update the git version? 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 util-macros] XORG_GIT_MODULE_VERSION: writes module version in xorg-git-version.h
On Mon, 2010-04-19 at 12:14 -0700, Dan Nicholson wrote: On Mon, Apr 19, 2010 at 11:52 AM, Gaetan Nadon mems...@videotron.ca wrote: Generates the git module version according to the git describe HEAD If the git module has pending changes, it appends -dirty to the version tag Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 916b472..efb2e53 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -1009,3 +1009,21 @@ mv \$(top_srcdir)/.INSTALL.tmp \$(top_srcdir)/INSTALL) \ echo 'util-macros \pkgdatadir\ from xorg-macros.pc not found: installing possibly empty INSTALL.' 2) AC_SUBST([INSTALL_CMD]) ]) # XORG_INSTALL + +# XORG_GIT_MODULE_VERSION() +# - +# Minimum version: 1.8.0 +# +# Generates the git module version according to the git describe HEAD +# If the git module has pending changes, it appends -dirty to the version tag +# +AC_DEFUN([XORG_GIT_MODULE_VERSION], [ +GIT_MODULE_VERSION_CMD=VER=\`GIT_DIR=\$(top_srcdir)/.git git describe HEAD 2/dev/null\`; \ +DVER=\`GIT_DIR=\$(top_srcdir)/.git git diff-index HEAD 2/dev/null\`; \ +OUTSTR=\\#undef XORG_GIT_VERSION\ ; \ +OUTFILE=\xorg-git-version.h\; \ IMO, OUTFILE should just be $...@. Then the module has flexibility over what the header is called. Done +test -n \\$\$VER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER\ test -n \\$\$DVER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER-dirty\; \ I don't I like dirty going in the version since it doesn't really provide any further information. That could be one string change or it could be a revamp of a subsystem. It does warn the person trying to debug that the tag and commit info may not be representative due to local changes. It's not enough, but better than nothing. Otherwise it is misleading. There is a hole, however. There may be local commits. To make it better until new ideas come forward, I change the -dirty for -with-uncommitted-changes. However, if it is kept, can we split this in two lines? Done. test -n \\$\$VER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER\; \ test -n \\$\$DVER\ OUTSTR=\\$\$OUTSTR-dirty\; \ If VER isn't set, DVER won't be either. +test -e \\$\$OUTFILE\ || echo \\$\$OUTSTR\ \\$\$OUTFILE\; \ +CONTENT=\`cat \$\$OUTFILE\` test \\$\$CONTENT\ = \\$\$OUTSTR\ || echo \$\$OUTSTR \$\$OUTFILE; +AC_SUBST([GIT_MODULE_VERSION_CMD]) +]) # XORG_GIT_MODULE_VERSION -- 1.6.0.4 I wish it didn't have to be done this way. This is absolutely nasty. It does not have to be that way. We have reviewed the spec for the function and we have two different implementation with pros and cons. I thought it was worth a try, I think it was. It is indeed nastier than expected, but no worse than the rest of the generated makefile. It gives a sense of where the limits are. That said, it seems like it would work. -- 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: [PATCH input-evdev 00/10] Configuration upgrades
On Mon, Apr 19, 2010 at 09:28:24AM -0400, Gaetan Nadon wrote: On Mon, 2010-04-19 at 09:58 +1000, Peter Hutterer wrote: On Sat, Apr 17, 2010 at 07:28:00PM -0400, Gaetan Nadon wrote: Patch #1 concept has been reviewed but code is different Patch #7 is a change that has not been reviewed in other patches yet. Other changes have been reviewed in other patches Gaetan Nadon (10): config: remove AH_TOP autoheader statement config: update AC_PREREQ statement to 2.60 replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: remove unrequired AC_HEADER_STDC config: refactor and comment the sdkdir distcheck workaround config: replace deprecated INCLUDES with AM_CPPFLAGS config: optional extension check for inputproto not required config: fix warnings, m4 quoting and layout include: EXTRA_DIST is not required for header files. man: Use Autoconf provided $(AM_V_GEN)$(SED) Makefile.am |2 +- configure.ac| 63 -- include/Makefile.am |1 - man/Makefile.am |4 +-- src/Makefile.am |3 +- src/evdev.c |1 + 6 files changed, 34 insertions(+), 40 deletions(-) Reviewed-by: Peter Hutterer peter.hutte...@who-t.net except for that one comment I sent separately. Can you pop this into your $HOME please and I'll pull from there. Want to get a few test runs in before it lands on master, just in case. Peter, Done. Other input drivers have similar changes.In some cases, I am not certain of what is the best option: --enable-debug: there are 3 input drivers and one video driver with this config option. I am not sure this should be exposed on the package public interface if only used by x.org developers at development time. If it's a good thing, perhaps it should be on all drivers. Many video drivers have a *DEBUG* kind of #define, but no configure option, The actual name varies. I guess there is no architected way of turning debug on several packages using the same method. I'd like there to be a --enable-debug configure option for all packages where it makes sense. and it is used outside of developer circles too, e.g. we build the wacom package in Fedora Rawhide with --enable-debug (but not in F12/F13). joystick: the enable-debug option is always on by default. Very unusual. yeah, that seems a bit odd. might want to talk to Sascha there. aiptek/evdev only runs Linux while joystick runs on Linux/BSD. Should these be conditional compiled so as to build on any platform? If they were part of xserver, they would have to be. not sure what you mean here. IIRC they're conditional in the build.sh script and I'd say that's good enough. they're in the same boat as e.g. libAppleWM, if you're trying to manually build it on a non-supported platform then you'll see a bunch of errors. if you want to put a platform check in to bail out configure with a nice error message, that'd work for me too though. The following changes since commit aaf65e7bfacd9501c4475a579d92c3bc60409893: Paulo Ricardo Zanoni (1): Don't set pEvdev-rel for mouse wheel events are available in the git repository at: git://people.freedesktop.org/~gnadon/xf86-input-evdev master Gaetan Nadon (10): config: remove AH_TOP autoheader statement config: update AC_PREREQ statement to 2.60 replace deprecated AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: remove unrequired AC_HEADER_STDC config: refactor and comment the sdkdir distcheck workaround config: replace deprecated INCLUDES with AM_CPPFLAGS config: optional extension check for inputproto not required config: require macros 1.4, fix warnings, m4 quotings and layout include: EXTRA_DIST is not required for header files. man: Use Autoconf provided $(AM_V_GEN)$(SED) Makefile.am |2 +- configure.ac| 63 -- include/Makefile.am |1 - man/Makefile.am |4 +-- src/Makefile.am |3 +- src/evdev.c |1 + 6 files changed, 34 insertions(+), 40 deletions(-) pulled, thanks. will be upstream in a bit. 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
[PATCH v2 util-macros] XORG_GIT_MODULE_VERSION: writes module version in xorg-git-version.h
Generates the git module version according to the git describe HEAD The module version number may be appended with-uncommitted-changes If not building under git, #undef XORG_GIT_VERSION is written Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 916b472..66c8e98 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -1009,3 +1009,23 @@ mv \$(top_srcdir)/.INSTALL.tmp \$(top_srcdir)/INSTALL) \ echo 'util-macros \pkgdatadir\ from xorg-macros.pc not found: installing possibly empty INSTALL.' 2) AC_SUBST([INSTALL_CMD]) ]) # XORG_INSTALL + +# XORG_GIT_MODULE_VERSION() +# - +# Minimum version: 1.8.0 +# +# Generates the git module version according to the git describe HEAD +# The module version number may be appended with-uncommitted-changes +# If not building under git, #undef XORG_GIT_VERSION is written +# +AC_DEFUN([XORG_GIT_MODULE_VERSION], [ +GIT_MODULE_VERSION_CMD=VER=\`GIT_DIR=\$(top_srcdir)/.git git describe HEAD 2/dev/null\`; \ +DVER=\`GIT_DIR=\$(top_srcdir)/.git git diff-index HEAD 2/dev/null\`; \ +OUTSTR=\\#undef XORG_GIT_VERSION\ ; \ +OUTFILE=\$(@); \ +test -n \\$\$VER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER\; \ +test -n \\$\$DVER\ OUTSTR=\\$\$OUTSTR-with-uncommitted-changes\; \ +test -e \\$\$OUTFILE\ || echo \\$\$OUTSTR\ \\$\$OUTFILE\; \ +CONTENT=\`cat \$\$OUTFILE\` test \\$\$CONTENT\ = \\$\$OUTSTR\ || echo \$\$OUTSTR \$\$OUTFILE; +AC_SUBST([GIT_MODULE_VERSION_CMD]) +]) # XORG_GIT_MODULE_VERSION -- 1.6.0.4 Second edition Use $@ for OUTFILE Replace -dirty with -with-uncommitted-changes Split test for VER and DVER ___ 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 util-macros] XORG_GIT_MODULE_VERSION: writes module version in xorg-git-version.h
On Tue, 2010-04-20 at 10:54 +1000, Peter Hutterer wrote: On Mon, Apr 19, 2010 at 11:00:08PM +0200, Julien Cristau wrote: On Mon, Apr 19, 2010 at 14:52:55 -0400, Gaetan Nadon wrote: Generates the git module version according to the git describe HEAD If the git module has pending changes, it appends -dirty to the version tag Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 916b472..efb2e53 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -1009,3 +1009,21 @@ mv \$(top_srcdir)/.INSTALL.tmp \$(top_srcdir)/INSTALL) \ echo 'util-macros \pkgdatadir\ from xorg-macros.pc not found: installing possibly empty INSTALL.' 2) AC_SUBST([INSTALL_CMD]) ]) # XORG_INSTALL + +# XORG_GIT_MODULE_VERSION() +# - +# Minimum version: 1.8.0 +# +# Generates the git module version according to the git describe HEAD +# If the git module has pending changes, it appends -dirty to the version tag +# +AC_DEFUN([XORG_GIT_MODULE_VERSION], [ +GIT_MODULE_VERSION_CMD=VER=\`GIT_DIR=\$(top_srcdir)/.git git describe HEAD 2/dev/null\`; \ +DVER=\`GIT_DIR=\$(top_srcdir)/.git git diff-index HEAD 2/dev/null\`; \ +OUTSTR=\\#undef XORG_GIT_VERSION\ ; \ +OUTFILE=\xorg-git-version.h\; \ +test -n \\$\$VER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER\ test -n \\$\$DVER\ OUTSTR=\\#define XORG_GIT_VERSION \$\$VER-dirty\; \ +test -e \\$\$OUTFILE\ || echo \\$\$OUTSTR\ \\$\$OUTFILE\; \ +CONTENT=\`cat \$\$OUTFILE\` test \\$\$CONTENT\ = \\$\$OUTSTR\ || echo \$\$OUTSTR \$\$OUTFILE; +AC_SUBST([GIT_MODULE_VERSION_CMD]) +]) # XORG_GIT_MODULE_VERSION my eyes! As I said in reply to the initial patch by Peter I'd like a way to disable this, because packages might be built from a git tree, which might be unrelated to the xorg one, or outside of any git tree. What's the output like if not building from git? Does 'make GIT_MODULE_VERSION_CMD=:' work to disable it (I guess not, because anything trying to include xorg-git-version.h will be unhappy)? it simply sets the #undef and nothing will be printed to the log file. Is there any specific argument against _running_ the macro as long if it doesn't add anything to the logfile? Gaetan: I'm not a big fan of the -dirty either but I guess if others want it we can leave it in. Two questions though: If you remotely help someone debugging a problem, you would like to know if tag/commit is really the code he is running or if there are local changes. With the commit number you can cross-reference the master repo and detect unpsuhed local commits. With the -dirty (now called -with-uncommitted-changes) you now the code is tainted with local changes you know nothing about. It's just additional info. - If modules start using this macro, do they stillhave to add to DISTCLEANFILES and friends? - This macro only gets invoked on automake runs, right? So if I pull and just rebuild, would it update the git version? All options are available in the Makefile.am regarding the invocation of the macro (or your original script). I have not paid attention to that, it looks you had it covered. The problem domain is similar to ChangeLog. You need a trigger when a new commit is available, but the best we could do is a dist hook. And you may not be running off git. What use case was this feature designed for? One suggested a dependency on a git file that changes with the HEAD commit, don't recall what the objections were. I'll think about it some more. Cheers, Peter 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
Coverity fixes for xf86-input-evdev
Hi Peter, Most of these fixes are quite minor and related to memory leaks from xf86...StrOption. They fix all Coverity errors in evdev apart from one dead-code error in EvdevUtilButtonEventToButtonNumber which I have intentionally left unmodified (in case that code changes in the future.) Event dead_error_condition: On this path, the condition button 32U could not be true 2225if (button EVDEV_MAXBUTTONS) Event dead_error_line: Cannot reach dead statement return 0U; 2226return 0; src/draglock.c |2 ++ src/emuWheel.c |2 +- src/evdev.c| 20 3 files changed, 15 insertions(+), 9 deletions(-) -- Oliver. ___ 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/7] evdev: leaked_storage: EvdevAddAbsClass: Variable mode goes out of scope
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com --- src/evdev.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index c3b44bb..aae9b23 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -1235,6 +1235,7 @@ EvdevAddAbsClass(DeviceIntPtr device) pEvdev-flags |= EVDEV_RELATIVE_MODE; else xf86Msg(X_INFO, %s: unknown mode, use default\n, pInfo-name); +xfree(mode); } return Success; -- 1.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 6/7] dragLock: leaked_storage: EvdevDragLockPreInit: Variable option_string goes out of scope
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com --- src/draglock.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/draglock.c b/src/draglock.c index 6157cae..a7ad974 100644 --- a/src/draglock.c +++ b/src/draglock.c @@ -145,6 +145,8 @@ EvdevDragLockPreInit(InputInfoPtr pInfo) if (next_num != NULL *next_num == '\0') next_num = NULL; } + +xfree(option_string); } /* Updates DragLock button state and fires button event messges */ -- 1.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 4/7] evdev: leaked_storage: EvdevInitButtonMapping: Variable mapping goes out of scope
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com
---
src/evdev.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 9fe952e..6992c68 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1371,15 +1371,16 @@ EvdevInitButtonMapping(InputInfoPtr pInfo)
/* Check for user-defined button mapping */
if ((mapping = xf86CheckStrOption(pInfo-options, ButtonMapping, NULL)))
{
-char*s = ;
+char*map, *s = ;
int btn = 0;
xf86Msg(X_CONFIG, %s: ButtonMapping '%s'\n, pInfo-name, mapping);
+map = mapping;
while (s *s != '\0' nbuttons EVDEV_MAXBUTTONS)
{
-btn = strtol(mapping, s, 10);
+btn = strtol(map, s, 10);
-if (s == mapping || btn 0 || btn EVDEV_MAXBUTTONS)
+if (s == map || btn 0 || btn EVDEV_MAXBUTTONS)
{
xf86Msg(X_ERROR,
%s: ... Invalid button mapping. Using defaults\n,
@@ -1389,8 +1390,9 @@ EvdevInitButtonMapping(InputInfoPtr pInfo)
}
pEvdev-btnmap[nbuttons++] = btn;
-mapping = s;
+map = s;
}
+xfree(mapping);
}
for (i = nbuttons; i ArrayLength(pEvdev-btnmap); i++)
--
1.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 1/7] evdev: leaked_storage: EvdevPreInit: Variable str goes out of scope
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com --- src/evdev.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index d133870..c3b44bb 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -2071,6 +2071,7 @@ EvdevPreInit(InputDriverPtr drv, IDevPtr dev, int flags) num_calibration = sscanf(str, %d %d %d %d, calibration[0], calibration[1], calibration[2], calibration[3]); +xfree(str); if (num_calibration == 4) EvdevSetCalibration(pInfo, num_calibration, calibration); else -- 1.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 3/7] evdev: var_assign: EvdevCacheCompare: NEGATIVE return value of ioctl assigned to unsigned variable len
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com
---
src/evdev.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index aae9b23..9fe952e 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1631,8 +1631,7 @@ static int
EvdevCacheCompare(InputInfoPtr pInfo, BOOL compare)
{
EvdevPtr pEvdev = pInfo-private;
-size_t len;
-int i;
+int i, len;
char name[1024] = {0};
unsigned long bitmask[NLONGS(EV_CNT)] = {0};
--
1.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 7/7] evdev: checked_return: EvdevProbe: Unchecked call
Called function ioctl whose return value should be checked (checked 10
out of 11 times)
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com
---
src/evdev.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 6992c68..ccea90d 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1782,8 +1782,9 @@ EvdevProbe(InputInfoPtr pInfo)
xf86Msg(X_ERROR, Grab failed. Device already configured?\n);
return 1;
}
-} else if (pEvdev-grabDevice) {
-ioctl(pInfo-fd, EVIOCGRAB, (void *)0);
+} else if (pEvdev-grabDevice ioctl(pInfo-fd, EVIOCGRAB, (void *)0)) {
+xf86Msg(X_WARNING, %s: Release failed (%s)\n, pInfo-name,
+ strerror(errno));
}
/* Trinary state for ignoring axes:
--
1.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 5/7] emuWheel: leaked_storage: EvdevWheelEmuHandleButtonMap: Variable option_string goes out of scope
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com
---
src/emuWheel.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/emuWheel.c b/src/emuWheel.c
index 3f0dfd4..afafff7 100644
--- a/src/emuWheel.c
+++ b/src/emuWheel.c
@@ -232,8 +232,8 @@ EvdevWheelEmuHandleButtonMap(InputInfoPtr pInfo,
WheelAxisPtr pAxis, char* axis_
} else {
xf86Msg(X_WARNING, %s: Invalid %s value:\%s\\n,
pInfo-name, axis_name, option_string);
-
}
+ xfree(option_string);
/* Clean up and log what happened */
if (msg) {
--
1.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: [PATCH] xfree86: check for NULL pointer before dereferences it in parser code
On Mon, Apr 19, 2010 at 10:58 AM, Tiago Vignatti
tiago.vigna...@nokia.com wrote:
Seems to be harmless. Meh.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
hw/xfree86/parser/scan.c | 7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/parser/scan.c b/hw/xfree86/parser/scan.c
index 8aab0cf..06710d5 100644
--- a/hw/xfree86/parser/scan.c
+++ b/hw/xfree86/parser/scan.c
@@ -845,10 +845,13 @@ static int
ConfigFilter(const struct dirent *de)
{
const char *name = de-d_name;
- size_t len = strlen(name);
+ size_t len;
size_t suflen = strlen(XCONFIGSUFFIX);
- if (!name || name[0] == '.' || len = suflen)
+ if (!name || name[0] == '.')
+ return 0;
+ len = strlen(name);
+ if(len = suflen)
return 0;
if (strcmp(name[len-suflen], XCONFIGSUFFIX) != 0)
return 0;
--
1.6.0.4
There's still the outside possibility your platform's scandir could
pass a NULL dirent, but let's hope it's not that stupid.
Reviewed-by: Dan Nicholson dbn.li...@gmail.com
___
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: Coverity fixes for xf86-input-evdev
On Tue, Apr 20, 2010 at 07:11:15AM +0300, Oliver McFadden wrote: Hi Peter, Most of these fixes are quite minor and related to memory leaks from xf86...StrOption. They fix all Coverity errors in evdev apart from one dead-code error in EvdevUtilButtonEventToButtonNumber which I have intentionally left unmodified (in case that code changes in the future.) thank you, but please rewrite some of the commit messages. emuWheel: leaked_storage: EvdevWheelEmuHandleButtonMap: Variable option_string goes out of scope that's rather stilted and aside from the line width issue a simple emuWheel: plug memory leak for option_string would do. or since the patches are quite similar anyway, you could squash the five of them into one patch. evdev: check ioctl return value in EvdevProbe and print warning on failure. would be nicer to read, and I think the negative assignment can be written less confusing too. aside from that, Reviewed-by: Peter Hutterer peter.hutte...@who-t.net feel free to send me a pull request for them. Cheers, Peter Event dead_error_condition: On this path, the condition button 32U could not be true 2225 if (button EVDEV_MAXBUTTONS) Event dead_error_line: Cannot reach dead statement return 0U; 2226 return 0; src/draglock.c |2 ++ src/emuWheel.c |2 +- src/evdev.c| 20 3 files changed, 15 insertions(+), 9 deletions(-) -- Oliver. ___ 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
