On Mon, Feb 07, 2011 at 06:21:31PM +0100, carl...@gnome.org wrote:
From: Carlos Garnacho carl...@gnome.org
The previous XKB info was being returned instead of the current
one, producing inconsistent results between the latest events
and the modifiers/group returned by this call.
The following patches fix points to uninitialised bytes errors
reported by valgrind when running Xorg. The four patches are quite
similar so maybe they should be squashed into just one or two, but I
made it this way so that there wouldn't be huge commit messages.
Ander Conselvan de Oliveira (4):
==== Syscall param writev(vector[...]) points to uninitialised byte(s)
====at 0x4AB5154: writev (writev.c:51)
====by 0x7C7C3: _XSERVTransWritev (Xtrans.c:912)
====by 0x61C8B: FlushClient (io.c:924)
====by 0x62743: FlushAllOutput (io.c:668)
====by
==543== Syscall param writev(vector[...]) points to uninitialised byte(s)
==543==at 0x4AB7154: writev (writev.c:51)
==543==by 0x8935B: _XSERVTransWritev (Xtrans.c:912)
==543==by 0x6C55F: FlushClient (io.c:924)
==543==by 0x6D013: FlushAllOutput (io.c:668)
==543==by 0x27A83:
==537== Syscall param writev(vector[...]) points to uninitialised byte(s)
==537==at 0x4AB7154: writev (writev.c:51)
==537==by 0x8935B: _XSERVTransWritev (Xtrans.c:912)
==537==by 0x6C55F: FlushClient (io.c:924)
==537==by 0x6CCF3: WriteToClient (io.c:846)
==537==by 0xD51D3:
==== Syscall param writev(vector[...]) points to uninitialised byte(s)
====at 0x4AB5154: writev (writev.c:51)
====by 0x7C7C3: _XSERVTransWritev (Xtrans.c:912)
====by 0x61C8B: FlushClient (io.c:924)
====by 0x62423: WriteToClient (io.c:846)
====by 0xCE39B:
On 02/08/2011 01:23 AM, Peter Hutterer wrote:
On Mon, Feb 07, 2011 at 11:32:27PM +0100, Simon Thum wrote:
This introduces hysteresis into the driver's processing. It significantly
reduces noise motion, i.e. now the pad does no longer generate a stream of
sub-pixel events when just holding the
I'm currently working on make xawtv and xf86-video-v4l fully functional, in
order to
allow us to test the overlay part of the V4L2 API.
I just sent a big patch replacing the old API to the new one, so the driver
should be
working now. However, only a very few set of drivers will benefit from
On 8 February 2011 10:42, Mauro Carvalho Chehab mche...@redhat.com wrote:
@@ -57,16 +65,16 @@ static MODULESETUPPROTO(v4lSetup);
static XF86ModuleVersionInfo v4lVersRec =
{
- v4l,
- MODULEVENDORSTRING,
- MODINFOSTRING1,
- MODINFOSTRING2,
-
Hi Thierry,
Em 08-02-2011 08:12, Thierry Vignaud escreveu:
On 8 February 2011 10:42, Mauro Carvalho Chehab mche...@redhat.com wrote:
@@ -57,16 +65,16 @@ static MODULESETUPPROTO(v4lSetup);
static XF86ModuleVersionInfo v4lVersRec =
{
-v4l,
-MODULEVENDORSTRING,
-
Hi Thierry,
Em 08-02-2011 08:12, Thierry Vignaud escreveu:
On 8 February 2011 10:42, Mauro Carvalho Chehab mche...@redhat.com wrote:
@@ -57,16 +65,16 @@ static MODULESETUPPROTO(v4lSetup);
static XF86ModuleVersionInfo v4lVersRec =
{
-v4l,
-MODULEVENDORSTRING,
-
The xf86-video-v4l video driver calls xf86XVQueryOffscreenImages()
function in order to probe for the Xv FOURCC formats supported for
PutVideo ops. However, as this support is deprecated on most of
the modern drivers, a call to this method will cause a crash:
X: ../../../include/privates.h:115:
I'm currently working on make xawtv and xf86-video-v4l fully functional, in
order to
allow us to test the overlay part of the V4L2 API.
I just sent a big patch replacing the old API to the new one, so the driver
should be
working now. However, only a very few set of drivers will benefit from
Daniel == Daniel Stone dan...@fooishbar.org writes:
We expose a few features of the physical device through the X
driver, but other information is available only through the kernel
directly. There is no way of associating an input device with the X
device it spawned off short of parsing
Hi,
Attached is the diff between the last multitouch spec posted to the
list, and what I've just pushed to my p.fd.o repository. This takes in
a lot of stuff I discussed with Peter during LCA, including:
Pointer emulation: We'd hoped it'd be simpler, but as soon as Peter
pointed out that we need
Peter == Peter Hutterer peter.hutte...@who-t.net writes:
Hi,
Maybe another property is needed to satisfy that. What about Device
UID, which is string setup by the driver. On evdev, it uses
EVIOCGPHYS, but it's up to the driver since it has the most details
about the device. I still
On Tue, 2011-02-08 at 11:10 +0200, ext Ander Conselvan de Oliveira
wrote:
The following patches fix points to uninitialised bytes errors
reported by valgrind when running Xorg. The four patches are quite
similar so maybe they should be squashed into just one or two, but I
made it this way so
On 15:04 Thu 03 Feb , Alan Coopersmith wrote:
Sure, but remember that GSoC projects are supposed to be equivalent to a
full-time job for 3 months, so it would have to be a bit more than just
fixing the documentation for a single library.
Unfortunately, GSoC projects have to be coding, not
The following changes since commit ea1ffd3e60bdcedbec5a6f28929f8677bf45d450:
Merge remote branch 'whot/for-keith' (2011-02-02 15:19:55 -0800)
are available in the git repository at:
ssh://people.freedesktop.org/~ajax/xserver for-keithp
Adam Jackson (8):
xf86vidmode: warning fix
On Mon, 7 Feb 2011 18:21:31 +0100, carl...@gnome.org wrote:
From: Carlos Garnacho carl...@gnome.org
The previous XKB info was being returned instead of the current
one, producing inconsistent results between the latest events
and the modifiers/group returned by this call.
Note that core
On Tue, 8 Feb 2011 10:53:19 +, Daniel Stone dan...@fooishbar.org wrote:
This
means that one touch event may be simultaneously sending touch events
through to touch clients, and enqueuing emulated pointer events as the
device is frozen for a grab. Fun times.
Does this mean the WM cannot
Hi,
On Tue, Feb 08, 2011 at 10:12:19AM -0800, Keith Packard wrote:
On Tue, 8 Feb 2011 10:53:19 +, Daniel Stone dan...@fooishbar.org wrote:
This
means that one touch event may be simultaneously sending touch events
through to touch clients, and enqueuing emulated pointer events as the
Hi,
On Tue, Feb 08, 2011 at 10:08:36AM -0800, Keith Packard wrote:
On Mon, 7 Feb 2011 18:21:31 +0100, carl...@gnome.org wrote:
From: Carlos Garnacho carl...@gnome.org
The previous XKB info was being returned instead of the current
one, producing inconsistent results between the latest
Hi,
On Tue, Feb 08, 2011 at 06:24:47PM +, Daniel Stone wrote:
If the WM consumes the event and indicates so to the server with
Sync{Pointer,Both}, this is treated the same as a client calling
XIAllowTouchEvents with XITouchOwnerAccept: the app gets a TouchEnd
event indicating that the
On Tue, 8 Feb 2011 18:24:47 +, Daniel Stone dan...@fooishbar.org wrote:
Either way, the end result is (should be?) indistinguishable from the WM
having a touch grab instead of a pointer grab, to everyone else in the
stack.
Ok, it's crazy complicated, but sounds like what we want.
Should
At least with my CFLAGS, this is all I'm getting that isn't about lack of
prototypes or declarations. Most of these are pretty trivial but there's
a couple that would fix actual bugs.
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives:
glxcmds.c: In function ‘__glXChangeDrawableAttributes’:
glxcmds.c:3464:8: warning: ‘screen’ may be used uninitialized in this function
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/dmx/glxProxy/glxcmds.c | 31 ---
1 files changed, 12 insertions(+), 19
glxcmds.c: In function ‘__glXGetDrawableAttributes’:
glxcmds.c:3295:8: warning: ‘screen’ may be used uninitialized in this function
glxcmds.c:3298:8: warning: ‘attribs_size’ may be used uninitialized in this
function
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/dmx/glxProxy/glxcmds.c |
glxcmds.c: In function ‘CreateContext.clone.6’:
glxcmds.c:105:19: warning: ‘be_fbconfigId’ may be used uninitialized in this
function
glxcmds.c:104:14: warning: ‘be_vid’ may be used uninitialized in this function
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/dmx/glxProxy/glxcmds.c |4
glxcmds.c: In function ‘CreateGLXPixmap’:
glxcmds.c:1641:22: warning: ‘pGlxScreen’ may be used uninitialized in this
function
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/dmx/glxProxy/glxcmds.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
glxcmds.c: In function ‘CreateGLXPixmap’:
glxcmds.c:1663:20: warning: comparison between pointer and integer
glxcmds.c:1663:38: warning: comparison between pointer and integer
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/dmx/glxProxy/glxcmds.c |2 +-
1 files changed, 1 insertions(+), 1
render2swap.c:264:13: warning: ‘swapArray’ defined but not used
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/dmx/glxProxy/render2swap.c | 54 -
1 files changed, 0 insertions(+), 54 deletions(-)
diff --git a/hw/dmx/glxProxy/render2swap.c
glxsingle.c: In function ‘__glXDisp_ReadPixels’:
glxsingle.c:760:11: warning: ‘buf’ may be used uninitialized in this function
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/dmx/glxProxy/glxsingle.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
glxvendor.c: In function ‘__glXVForwardAllWithReply’:
glxvendor.c:284:10: warning: ‘be_buf’ may be used uninitialized in this function
glxvendor.c:285:10: warning: ‘be_buf_size’ may be used uninitialized in this
function
Signed-off-by: Adam Jackson a...@redhat.com
---
glxvendor.c: In function ‘__glXVForwardPipe0WithReply’:
glxvendor.c:205:10: warning: ‘be_buf’ may be used uninitialized in this function
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/dmx/glxProxy/glxvendor.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On 02/08/2011 09:18 AM, Donnie Berkholz wrote:
On 15:04 Thu 03 Feb , Alan Coopersmith wrote:
Sure, but remember that GSoC projects are supposed to be equivalent to a
full-time job for 3 months, so it would have to be a bit more than just
fixing the documentation for a single library.
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
Based on previous review comments I updated the patches.
Main change is the code to track the client life explicitly from Christopher.
I tough that DRI2DrawableRef held same information but it can't practically
used. That modification required
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
If client calls DRI2CreateDrawable multiple times for same drawable
DRI2 creates multiple references. Multiple references cause DRI2 send
multiple invalidate events for same client.
Problem is triggered because client side EGL implementation is
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
DRI2 swaps may complete after Drawable has been destroyed. This causes
memory management problems as DRI2 internal state is tighly coupled with
Drawable.
DRI2DrawablePtr can be used to access DRI2 functionality. This provides
option that DRI2
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
To let DRI2Drawable exists longer than Drawable driver has to use
DRI2DrawablePtr to complete swaps and MSC waits. This allows DRI2 to
clean up after all operations complete without accessing the freed
DrawablePtr.
v2:
* Refactor interface to
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
Asynchronous request like SwapBuffers can still reference Drawable after
the Drawable has been freed. DRI2Drawable cleanup should be delayed
until all asynchronous operations have completed.
Reference counted DRI2Drawable helps to keep
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
EGLImage requires that image siblings stay valid until all of them has
been freed. Base EGLImage is only required for creating new siblings.
http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_image_base.txt
To keep DRI2Drawable until all
From: Christopher James Halse Rogers christopher.halse.rog...@canonical.com
Clients can terminate with pending SwapBuffers requests waiting
for the trigger, potentially a long way in the future.
Track these requests so we don't end up delivering
SwapBuffersComplete to an entirely unrelated
From: Christopher James Halse Rogers christopher.halse.rog...@canonical.com
The SwapBuffers request requires that we trigger the swap at some point
in the future. Sane drivers implement this by passing this request to
something that will trigger a callback with the buffer pointers
at the
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
DRI2SwapComplete is too late for front to fake front copy if swap is
completed asynchronously. Client could be able to use fake front already
before swap completes.
Moving front to fake front solves the problem but requires that driver
is capable
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
If client disconnects and new client gets same id DRI2 events may end to
wrong client. DRI2 reference list can be checked to see if the client
still owns the DRI2Drawable.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
From: Pauli Nieminen ext-pauli.niemi...@nokia.com
glx should cleanup DRI2Drawable when GLXDrawable is destroyed.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
glx/glxdri2.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/glx/glxdri2.c
I was wondering about an idea- and rather than stumble around (for
weeks) on my own, I want to ask you WAY SMARTER guys about it:
As you already know, I'm planning to bring some decent support for
additional mouse buttons into Qt (things which GTK2 already has). For
many, many years, the
For the series:
Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
xorg-devel@lists.x.org: X.Org development
49 matches
Mail list logo
