Adam Jackson <a...@redhat.com> writes:
> ms_queue_vblank() returns false on failure.
>
> Reported-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Signed-off-by: Adam Jackson <a...@redhat.com>
Reviewed-by: Frank Binns <frank.bi...@imgtec.com>
> ---
>
Signed-off-by: Frank Binns <frank.bi...@imgtec.com>
---
hw/xfree86/parser/scan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xfree86/parser/scan.c b/hw/xfree86/parser/scan.c
index bac213a..6d46a56 100644
--- a/hw/xfree86/parser/scan.c
+++ b/hw/xfree86/parser/
On 30/11/14 11:51, Mario Kleiner wrote:
On 11/25/2014 09:31 AM, Frank Binns wrote:
Hi,
I sent exactly the same patch back in April. Despite getting a review-by
it was never merged. See:
http://lists.freedesktop.org/archives/mesa-dev/2014-April/058347.html
http://lists.freedesktop.org
Hi,
I sent exactly the same patch back in April. Despite getting a review-by
it was never merged. See:
http://lists.freedesktop.org/archives/mesa-dev/2014-April/058347.html
http://lists.freedesktop.org/archives/mesa-dev/2014-May/060432.html
Thanks
Frank
On 25/11/14 03:00, Mario Kleiner wrote:
On 04/06/14 21:15, Keith Packard wrote:
Right, it's reasonable for the kernel to not care whether the buffer is
idle or not when flipping. However, the application *does* care, and so
we need a way to not flip until rendering is complete. Whether that's
additional mechanism in the kernel, or
.
Reviewed-by: Keith Packard kei...@keithp.com
Signed-off-by: Frank Binns frank.bi...@imgtec.com
---
This was part of the present: various fixes series (see
http://lists.x.org/archives/xorg-devel/2014-May/042601.html) but I've
broken it out into an individual patch as this one was reviewed but
the others
On 28/05/14 08:14, Chris Wilson wrote:
If we close the Window prior to completing all the flips, we free the
vblank pointer but leave screen_priv-flip_pending dangling. This leads
to a host of invalid reads/writes as it is accessed from many locations,
e.g.:
==20302== Invalid write of size 4
-off-by: Frank Binns frank.bi...@imgtec.com
---
present/present.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/present/present.c b/present/present.c
index 73d5f69..dbd60cc 100644
--- a/present/present.c
+++ b/present/present.c
@@ -343,6 +343,26
expected that an unflip
will be performed. However, if the client terminates abnormally it's
possible that this will not happen meaning some of the resources are
leaked. This is avoided by cleaning up these resources at window
destruction time.
Signed-off-by: Frank Binns frank.bi...@imgtec.com
we might
have missed the vblank period. This results in tearing.
Fix this by always doing synced flips unless the client uses the
PresentOptionAsync flag when presenting a pixmap.
Signed-off-by: Frank Binns frank.bi...@imgtec.com
---
present/present.c | 6 +++---
1 file changed, 3 insertions(+), 3
(as patch 3 has now been
dropped).
Some issues still remain but these are fixed by the following patches
that are currently on the list but not in master:
- [PATCH] present: Queue flips for later execution
- [PATCH 3/6] present: Reorder Window teardown to avoid use-after-free
Frank Binns (3
On 26/04/14 00:39, Keith Packard wrote:
Frank Binns frank.bi...@imgtec.com writes:
As part of present's window destroy function, any vblanks associated with
the destroyed window are aborted and destroyed. However, this can include
a pending flip. This means that when the corresponding flip
On 26/04/14 00:52, Keith Packard wrote:
Frank Binns frank.bi...@imgtec.com writes:
In the case that synchronised page flips are being performed, it's
possible to hit this assert when killing an application. This is a
result of the pending flip being flagged as aborted, as part of
window
to
abort so the unflip is deferred until the pending flip completes. This
provides a window of opportunity for the 2D application to draw to the wrong
pixmap.
This problem is avoided by fixing up the root window pixmap immediately but
deferring the unflip as usual.
Signed-off-by: Frank Binns
we might have missed the vblank period. This results in
tearing.
Fix this by always doing synced flips unless the client uses the
PresentOptionAsync flag when presenting a pixmap.
Signed-off-by: Frank Binns frank.bi...@imgtec.com
---
present/present.c | 6 +++---
1 file changed, 3 insertions(+), 3
been received.
It doesn't appear that there is any problem with setting an aborted
pending flip's window to NULL. For this reason remove the assert.
Signed-off-by: Frank Binns frank.bi...@imgtec.com
---
present/present_screen.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
performed and, more importantly, the now idle pixmap is never
destroyed. This results in a leak between server resets.
Fix this by preventing any pending flip, associated with the window being
destroyed, from being aborted and destroyed during window destruction.
Signed-off-by: Frank Binns frank.bi
on server reset
Frank Binns (1):
xfixes: disable cursor on X server reset
dix/devices.c | 7 +++
dix/events.c| 2 +-
fb/fbscreen.c | 2 +-
xfixes/cursor.c | 2 ++
4 files changed, 7 insertions(+), 6 deletions(-)
--
1.8.5.4.gfd2
From: Brendan King brendan.k...@imgtec.com
The new current cursor was being referenced twice, resulting in a
memory leak when the current server generation ended.
Signed-off-by: Frank Binns frank.bi...@imgtec.com
---
dix/events.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The initial state of the cursor is set to disabled but this was
never be re-disabled during X server reset. This meant any
application run after an X server reset would have the cursor
displayed even if it hadn't requested this to be the case.
Signed-off-by: Frank Binns frank.bi...@imgtec.com
From: Brendan King brendan.k...@imgtec.com
Call FreePixmap() instead of free() to destroy the screen pixmap in
fbCloseScreen().
Signed-off-by: Frank Binns frank.bi...@imgtec.com
---
fb/fbscreen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fb/fbscreen.c b/fb/fbscreen.c
cleanup code
(miSpriteDeviceCursorCleanup()) not being called.
Ensures the DeviceCursorCleanup() function is called when the associated
input device is closed on server reset.
Signed-off-by: Frank Binns frank.bi...@imgtec.com
---
dix/devices.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions
Do let me know if that helps at all; I'm sorry I didn't get it out for
review earlier.
Thanks, that fixed some of the issues I was seeing. I've also had
to make some additional changes to fix some other problems.
I'll do my best to get some patches sent out in the next few days.
Thanks
On 16/04/14 21:29, Keith Packard wrote:
One can imagine changing the kernel interface so that a new flip request
would replace a pending one. The kernel could (presumably) detect when
the new flip buffer went idle and do the replacement then, rather than
immediately when the flip call was made.
On 16/04/14 21:26, Keith Packard wrote:
When a flip (or unflip) is pending and a flip request comes in, leave
it queued until the pending flip completes and then execute it.
Signed-off-by: Keith Packard kei...@keithp.com
Tested-by: Frank Binns frank.bi...@imgtec.com
Thanks
Frank
Hi,
I've been working on adding support for the present extension in the PVR
video driver and I've hit a couple of issues related to flipping:
1) When the display driver supports async flipping this mode of
operation is always used. This means that, when the swap interval is
none 0, the
26 matches
Mail list logo
