For the series:
Reviewed-by: Alan Coopersmith
--
-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/arch
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 too-n
From: Pauli Nieminen
glx should cleanup DRI2Drawable when GLXDrawable is destroyed.
Signed-off-by: Pauli Nieminen
---
glx/glxdri2.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 027615a..79d7f55 100644
--- a/glx/glxdri2.c
+++
From: Pauli Nieminen
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
---
hw/xfree86/dri2/dri2.c | 73 +++--
From: Pauli Nieminen
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 to copy from new front to fa
From: Christopher James Halse Rogers
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 appropriate time.
The client can cause those
From: Christopher James Halse Rogers
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 client.
Signed-off-by: Christopher James Hal
From: Pauli Nieminen
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 siblings has been destroyed
From: Pauli Nieminen
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 DRI2Drawable around until
all request o
From: Pauli Nieminen
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 allow tracking when client is go
From: Pauli Nieminen
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 drawable can live longer than un
From: Pauli Nieminen
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 using
DRI2 directly.
DRI2 cod
From: Pauli Nieminen
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 quite some changes in other par
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.
Unfor
glxvendor.c: In function ‘__glXVForwardPipe0WithReply’:
glxvendor.c:205:10: warning: ‘be_buf’ may be used uninitialized in this function
Signed-off-by: Adam Jackson
---
hw/dmx/glxProxy/glxvendor.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/dmx/glxProxy/glxvendor
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
---
hw/dmx/glxProxy/glxvendor.c |4 ++--
1
glxsingle.c: In function ‘__glXForwardPipe0WithReply’:
glxsingle.c:218:10: warning: ‘be_buf’ may be used uninitialized in this function
Signed-off-by: Adam Jackson
---
hw/dmx/glxProxy/glxsingle.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/dmx/glxProxy/glxsingle.
glxsingle.c: In function ‘__glXForwardAllWithReply’:
glxsingle.c:300:10: warning: ‘be_buf’ may be used uninitialized in this function
glxsingle.c:301:10: warning: ‘be_buf_size’ may be used uninitialized in this
function
Signed-off-by: Adam Jackson
---
hw/dmx/glxProxy/glxsingle.c |4 ++--
1
glxsingle.c: In function ‘__glXDisp_ReadPixels’:
glxsingle.c:760:11: warning: ‘buf’ may be used uninitialized in this function
Signed-off-by: Adam Jackson
---
hw/dmx/glxProxy/glxsingle.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/dmx/glxProxy/glxsingle.c b/hw/dmx
render2swap.c:264:13: warning: ‘swapArray’ defined but not used
Signed-off-by: Adam Jackson
---
hw/dmx/glxProxy/render2swap.c | 54 -
1 files changed, 0 insertions(+), 54 deletions(-)
diff --git a/hw/dmx/glxProxy/render2swap.c b/hw/dmx/glxProxy/render2s
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
---
hw/dmx/glxProxy/glxcmds.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
d
glxcmds.c: In function ‘CreateGLXPixmap’:
glxcmds.c:1641:22: warning: ‘pGlxScreen’ may be used uninitialized in this
function
Signed-off-by: Adam Jackson
---
hw/dmx/glxProxy/glxcmds.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/dmx/glxProxy/glxcmds.c b/hw/dmx/glx
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
---
hw/dmx/glxProxy/glxcmds.c |4 ++--
1 files cha
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
---
hw/dmx/glxProxy/glxcmds.c | 42 +
glxcmds.c: In function ‘__glXChangeDrawableAttributes’:
glxcmds.c:3464:8: warning: ‘screen’ may be used uninitialized in this function
Signed-off-by: Adam Jackson
---
hw/dmx/glxProxy/glxcmds.c | 31 ---
1 files changed, 12 insertions(+), 19 deletions(-)
diff --git
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: http:
On Tue, 8 Feb 2011 18:24:47 +, Daniel Stone 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 probably clarify
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
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
> >
> > The previous XKB info was being returned instead of the current
> > one, producing inconsistent results between the latest events
>
Hi,
On Tue, Feb 08, 2011 at 10:12:19AM -0800, Keith Packard wrote:
> On Tue, 8 Feb 2011 10:53:19 +, Daniel Stone 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 f
On Tue, 8 Feb 2011 10:53:19 +, Daniel Stone 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 consume the 'click
On Mon, 7 Feb 2011 18:21:31 +0100, carl...@gnome.org wrote:
> From: Carlos Garnacho
>
> 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 events always r
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 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, no
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
> "Peter" == Peter Hutterer 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 think "Devic
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
> "Daniel" == Daniel Stone 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 the X.
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
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: di
Hi Thierry,
Em 08-02-2011 08:12, Thierry Vignaud escreveu:
> On 8 February 2011 10:42, Mauro Carvalho Chehab wrote:
>> @@ -57,16 +65,16 @@ static MODULESETUPPROTO(v4lSetup);
>>
>> static XF86ModuleVersionInfo v4lVersRec =
>> {
>> -"v4l",
>> -MODULEVENDORSTRING,
>> -MODIN
Hi Thierry,
Em 08-02-2011 08:12, Thierry Vignaud escreveu:
> On 8 February 2011 10:42, Mauro Carvalho Chehab wrote:
>> @@ -57,16 +65,16 @@ static MODULESETUPPROTO(v4lSetup);
>>
>> static XF86ModuleVersionInfo v4lVersRec =
>> {
>> -"v4l",
>> -MODULEVENDORSTRING,
>> -MODIN
On 8 February 2011 10:42, Mauro Carvalho Chehab wrote:
> @@ -57,16 +65,16 @@ static MODULESETUPPROTO(v4lSetup);
>
> static XF86ModuleVersionInfo v4lVersRec =
> {
> - "v4l",
> - MODULEVENDORSTRING,
> - MODINFOSTRING1,
> - MODINFOSTRING2,
> - XORG_VERSION_CURRENT
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 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 holdin
==== 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:
==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: XkbSen
==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: Dispa
==== 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 0x4AA5B:
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):
On Mon, Feb 07, 2011 at 06:21:31PM +0100, carl...@gnome.org wrote:
> From: Carlos Garnacho
>
> 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.
>
> Signed-off-by: Carlo
51 matches
Mail list logo
