Hi,
This set fixes all resource leaks found inside the server by the Coverity
Static Code Analysis tool and considered by such as outstanding. I only skip a
few defects that are not interesting for MeeGo, such as font server stuff or
the xorg.conf generator code. Please, pull it Keith. There's
On Sun, Apr 3, 2011 at 3:22 AM, Alistair Leslie-Hughes
leslie_alist...@hotmail.com wrote:
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=17364
Signed-off-by: Alistair Leslie-Hughes leslie_alist...@hotmail.com
A couple comments.
1. Even though the bug report has the essential information,
Hi Jeremy,
On 04/04/2011 01:50 PM, ext Tiago Vignatti wrote:
Tiago Vignatti (23):
dix: remove unused debug code
dix: remove unused macro
xorg: remove unused pointer values all over the server
xfree86: dri2: fix memory leak and free resources properly
mi: fix
What is the official status of xf86-input-multitouch, anyway?
It doesn't appear to be an official X input driver, supported and
maintained on this list.
You'd need to ask Henrik Rydberg (Cc'd).
The xf86-input-multitouch driver is not yet part of any distro, but
that is likely to change
Henrik Rydberg rydb...@euromail.se (04/04/2011):
The xf86-input-multitouch driver is not yet part of any distro, but
that is likely to change within the coming six months.
kibi@caol-ila:~$ rmadison xf86-input-multitouch
xf86-input-multitouch | 1.0~rc2-2 | wheezy | source
xf86-input-multitouch
Hi,
While triaging bugs, I came across this one.
https://bugs.freedesktop.org/show_bug.cgi?id=14723
The basic issue is warnings during the compile.
The options
1. Add prototypes (like the patch attached to the bug) to silence the
warning.
2. Remove the functions, since they appear to be
Fixes LP: #736829 (https://bugs.launchpad.net/bugs/573006)
Re-fixes old X.Org Bug 29645
http://bugs.freedesktop.org/show_bug.cgi?id=29645
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
src/evdev.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/evdev.c
The current code overwrites *all* the stored axis values with whatever
came in from evdev. Evdev is a stateful protocol, so it only sends us
updates to the axis values that have changed. We need to only update
the values that have changed.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
On Wed, Mar 30, 2011 at 11:07:46PM -0700, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
This moves ChangeWindowAttributes to mi, and calls a new hook
that fb/exa can use to fixup the pixmap properly.
I've looked at XAA and it seems this should work there as well,
and I'm sure
On 04/ 4/11 05:01 AM, Alistair Leslie-Hughes wrote:
Hi,
While triaging bugs, I came across this one.
https://bugs.freedesktop.org/show_bug.cgi?id=14723
The basic issue is warnings during the compile.
The options
1. Add prototypes (like the patch attached to the bug) to silence the
It will fix two possible cases of use after free in RemoveDevice.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
dix/devices.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/dix/devices.c b/dix/devices.c
index 534931c..0288e15 100644
--- a/dix/devices.c
+++
When xf86XVFreeAdaptor is called more than once in xf86XVInitAdaptors (it may,
but not often), the conditional being changed in this patch will always take
true path and will keep freeing pAdaptor-pAttributes, thus letting the system
error-prone.
This patch fix such problem checking for a pointer
This seems a good convention to follow: if pointers are allocate outside a
given function, then free there as well when a failure occurs.
AllocARGBCursor and its callers were mixing up the freeing of resources and
causing a particular double free inside TileScreenSaver (srcbits and mskbits).
As a good practice and for eventual double frees.
The reason of this patch is due the resilience of xf86XVInitAdaptors, where
for any adaptor failure it's able to keep trying registering the following
ones.
I discussed briefly with Pauli and Ville about a bigger refactoring of such
function,
In the case of failure on AllocNewConnection, new_trans_conn cannot be
dereferenced because it's already freed. Swapping the order of this logic fix
the changes introduced in 04956b80431169e0ae713a3e6ba4cdc157ce3a66.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
CC: Jeremy Huddleston
No functional changes. Spaghetti code for the win! \o/
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
Reviewed-by: Nicolas Peninguy n...@lostgeeks.org
---
hw/xfree86/loader/loadmod.c | 32
1 files changed, 12 insertions(+), 20 deletions(-)
diff --git
On Sat, 2 Apr 2011 14:51:32 +0200, Matthieu Herrb matthieu.he...@laas.fr
wrote:
Matthieu Herrb (4):
Xi: take XI2 requests into account also for the swapping case.
Xi: add XI_Focus{In,Out} to swapped events.
Xext: fix test on extension number for the swapped case.
Xi:
On Mon, 4 Apr 2011 10:28:48 +1000, Peter Hutterer peter.hutte...@who-t.net
wrote:
Chase Douglas (3):
Clean up getValuatorEvents using array loop logic
Handle non continuous valuator data in getValuatorEvents
Don't report old relative values in getValuatorEvents
Matthieu
I just pushed them.
I'll cherry-pick this fix into stable once Keith adds it to master.
On Apr 4, 2011, at 10:54 AM, Tiago Vignatti wrote:
In the case of failure on AllocNewConnection, new_trans_conn cannot be
dereferenced because it's already freed. Swapping the order of this logic fix
This is a rather large pull request for a stable series, I admit, but I
think it's worthwhile. I've tested it on Intel GM45 with Gnome 3 and
everything works as before. I've also compared the clutter conformance
test runs from clutter 1.6.12 before and after this series, on the same
Are you planning on leaving the ChangeWindowAttrbutes screen hook there, or
is it slated for deletion? I ask because we currently wrap CWA so we can
watch for colormap changes on PseduoColor windows.
Can you give me a why?
What does the driver do with this information later, is it an
On Mon, Apr 04, 2011 at 01:24:10PM -0700, Dave Airlie wrote:
Are you planning on leaving the ChangeWindowAttrbutes screen hook there, or
is it slated for deletion? I ask because we currently wrap CWA so we can
watch for colormap changes on PseduoColor windows.
Can you give me a why?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/2011 11:17 AM, Nicolas Kaiser wrote:
diff --git a/src/mga_dri.c b/src/mga_dri.c
index 2723dd8..8b1d751 100644
--- a/src/mga_dri.c
+++ b/src/mga_dri.c
@@ -92,24 +92,24 @@ static Bool MGAInitVisualConfigs( ScreenPtr pScreen )
case 16:
On Mon, 4 Apr 2011 13:50:30 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
Tiago Vignatti (23):
dix: remove unused debug code
dix: remove unused macro
xorg: remove unused pointer values all over the server
xfree86: dri2: fix memory leak and free resources
On Tue, Apr 5, 2011 at 6:42 AM, Aaron Plattner aplatt...@nvidia.com wrote:
On Mon, Apr 04, 2011 at 01:24:10PM -0700, Dave Airlie wrote:
Are you planning on leaving the ChangeWindowAttrbutes screen hook there, or
is it slated for deletion? I ask because we currently wrap CWA so we can
watch
On Mon, Apr 04, 2011 at 02:26:42PM -0700, Dave Airlie wrote:
On Tue, Apr 5, 2011 at 6:42 AM, Aaron Plattner aplatt...@nvidia.com wrote:
On Mon, Apr 04, 2011 at 01:24:10PM -0700, Dave Airlie wrote:
Are you planning on leaving the ChangeWindowAttrbutes screen hook there,
or
is it slated
* Ian Romanick i...@freedesktop.org:
On 04/02/2011 11:17 AM, Nicolas Kaiser wrote:
diff --git a/src/mga_dri.c b/src/mga_dri.c
index 2723dd8..8b1d751 100644
--- a/src/mga_dri.c
+++ b/src/mga_dri.c
@@ -92,24 +92,24 @@ static Bool MGAInitVisualConfigs( ScreenPtr pScreen )
case 16:
On 04/ 4/11 03:24 PM, Nicolas Kaiser wrote:
* Ian Romanick i...@freedesktop.org:
On 04/02/2011 11:17 AM, Nicolas Kaiser wrote:
diff --git a/src/mga_dri.c b/src/mga_dri.c
index 2723dd8..8b1d751 100644
--- a/src/mga_dri.c
+++ b/src/mga_dri.c
@@ -92,24 +92,24 @@ static Bool
On Tue, Apr 5, 2011 at 7:37 AM, Aaron Plattner aplatt...@nvidia.com wrote:
On Mon, Apr 04, 2011 at 02:26:42PM -0700, Dave Airlie wrote:
On Tue, Apr 5, 2011 at 6:42 AM, Aaron Plattner aplatt...@nvidia.com wrote:
On Mon, Apr 04, 2011 at 01:24:10PM -0700, Dave Airlie wrote:
Are you planning on
Hey guys, it's way too early in this process to be worried about the
impacts to the driver interface. Dave -- just write whatever code you
like, and we'll figure out what it means to drivers later.
I thought we had general consensus that we wouldn't limit changes in the
X server to conform to
Replace deprecated X*alloc functions.
v2: mga_dri.c: properly use numConfigs and sizes in calloc()
Signed-off-by: Nicolas Kaiser ni...@nikai.net
---
src/mga_dga.c|2 +-
src/mga_dri.c| 82 +++---
src/mga_driver.c | 80
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2011 04:52 PM, Nicolas Kaiser wrote:
Replace deprecated X*alloc functions.
v2: mga_dri.c: properly use numConfigs and sizes in calloc()
Signed-off-by: Nicolas Kaiser ni...@nikai.net
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Hi ajax, (and I doubt Dave Reveman is reading).
Was just reading through the code, and was wondering why the composite
overlay window isn't marked as a panoramiX root window?
The panoramiX root annotation seems to mean that any drawing to the
window will be translated by the screenInfo x/y for
On Mon, Apr 04, 2011 at 09:40:14AM -0400, Chase Douglas wrote:
The current code overwrites *all* the stored axis values with whatever
came in from evdev. Evdev is a stateful protocol, so it only sends us
updates to the axis values that have changed. We need to only update
the values that have
From: Dave Airlie airl...@redhat.com
The xinerama version of this wasn't translating the coordinates correctly.
Running xcompmgr against a xinerama Xephyr setup, would never draw anything
on the second screen, and damage was occuring wrongly against the second screen.
anyone care to wonder if
35 matches
Mail list logo
