[PATCH 3/3] present: Do not replace Pixmaps on redirected Window on unflip

[Chris Wilson]

When unflipping, we may find that our flip window has been redirected.
If we replace the redirected Window with the Screen Pixmap we then have
mutliple fullscreen Windows believing that their own the Screen Pixmap -
multiple fullscreen Windows that are being flipped by Clients, and so
continue to flip causing popping between e.g. the compositor and the
game.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 present/present.c | 28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/present/present.c b/present/present.c
index a53dc11..ba88f79 100644
--- a/present/present.c
+++ b/present/present.c
@@ -374,12 +374,17 @@ present_set_tree_pixmap_visit(WindowPtr window, void 
*data)
 }
 
 static void
-present_set_tree_pixmap(WindowPtr window, PixmapPtr pixmap)
+present_set_tree_pixmap(WindowPtr window,
+PixmapPtr expected,
+PixmapPtr pixmap)
 {
 struct pixmap_visit visit;
 ScreenPtr   screen = window-drawable.pScreen;
 
 visit.old = (*screen-GetWindowPixmap)(window);
+if (expected  visit.old != expected)
+return;
+
 visit.new = pixmap;
 if (visit.old == visit.new)
 return;
@@ -390,6 +395,7 @@ static void
 present_set_abort_flip(ScreenPtr screen)
 {
 present_screen_priv_ptr screen_priv = present_screen_priv(screen);
+PixmapPtr pixmap = (*screen-GetScreenPixmap)(screen);
 
 /* Switch back to using the screen pixmap now to avoid
  * 2D applications drawing to the wrong pixmap.
@@ -397,10 +403,11 @@ present_set_abort_flip(ScreenPtr screen)
 
 if (screen_priv-flip_window)
 present_set_tree_pixmap(screen_priv-flip_window,
-  (*screen-GetScreenPixmap)(screen));
+screen_priv-flip_pixmap,
+pixmap);
 
 if (screen-root)
-present_set_tree_pixmap(screen-root, 
(*screen-GetScreenPixmap)(screen));
+present_set_tree_pixmap(screen-root, NULL, pixmap);
 
 screen_priv-flip_pending-abort_flip = TRUE;
 }
@@ -414,10 +421,12 @@ present_unflip(ScreenPtr screen)
 assert (!screen_priv-unflip_event_id);
 assert (!screen_priv-flip_pending);
 
-if (screen_priv-flip_window)
-present_set_tree_pixmap(screen_priv-flip_window, pixmap);
+if (screen_priv-flip_pixmap  screen_priv-flip_window)
+present_set_tree_pixmap(screen_priv-flip_window,
+screen_priv-flip_pixmap,
+pixmap);
 
-present_set_tree_pixmap(screen-root, pixmap);
+present_set_tree_pixmap(screen-root, NULL, pixmap);
 
 /* Update the screen pixmap with the current flip pixmap contents
  */
@@ -645,9 +654,10 @@ present_execute(present_vblank_ptr vblank, uint64_t ust, 
uint64_t crtc_msc)
  */
 if (screen_priv-flip_window  screen_priv-flip_window != 
window)
 present_set_tree_pixmap(screen_priv-flip_window,
-  
(*screen-GetScreenPixmap)(screen));
-present_set_tree_pixmap(window, pixmap);
-present_set_tree_pixmap(screen-root, pixmap);
+screen_priv-flip_pixmap,
+
(*screen-GetScreenPixmap)(screen));
+present_set_tree_pixmap(window, NULL, pixmap);
+present_set_tree_pixmap(screen-root, NULL, pixmap);
 
 /* Report update region as damaged
  */
-- 
2.1.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 1/3] present: Requery pending flips with the right sync_flip mode

[Chris Wilson]

When verifying whether a pending flip is still valid, we need to pass
down the orignal sync_flip mode (e.g. if the driver only supports sync
flips, verifying a async flip will falsely fail).

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 present/present.c  | 5 +++--
 present/present_priv.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/present/present.c b/present/present.c
index 4a1cf0c..ce978f4 100644
--- a/present/present.c
+++ b/present/present.c
@@ -453,6 +453,7 @@ present_flip_notify(present_vblank_ptr vblank, uint64_t 
ust, uint64_t crtc_msc)
 screen_priv-flip_window = vblank-window;
 screen_priv-flip_serial = vblank-serial;
 screen_priv-flip_pixmap = vblank-pixmap;
+screen_priv-flip_sync = vblank-sync_flip;
 screen_priv-flip_idle_fence = vblank-idle_fence;
 
 vblank-pixmap = NULL;
@@ -541,14 +542,14 @@ present_check_flip_window (WindowPtr window)
  * Check current flip
  */
 if (window == screen_priv-flip_window) {
-if (!present_check_flip(screen_priv-flip_crtc, window, 
screen_priv-flip_pixmap, FALSE, NULL, 0, 0))
+if (!present_check_flip(screen_priv-flip_crtc, window, 
screen_priv-flip_pixmap, screen_priv-flip_sync, NULL, 0, 0))
 present_unflip(screen);
 }
 }
 
 /* Now check any queued vblanks */
 xorg_list_for_each_entry(vblank, window_priv-vblank, window_list) {
-if (vblank-queued  vblank-flip  
!present_check_flip(vblank-crtc, window, vblank-pixmap, FALSE, NULL, 0, 0))
+if (vblank-queued  vblank-flip  
!present_check_flip(vblank-crtc, window, vblank-pixmap, vblank-sync_flip, 
NULL, 0, 0))
 vblank-flip = FALSE;
 }
 }
diff --git a/present/present_priv.h b/present/present_priv.h
index f5c1652..110c925 100644
--- a/present/present_priv.h
+++ b/present/present_priv.h
@@ -93,6 +93,7 @@ typedef struct present_screen_priv {
 uint32_tflip_serial;
 PixmapPtr   flip_pixmap;
 present_fence_ptr   flip_idle_fence;
+Boolflip_sync;
 
 present_screen_info_ptr info;
 } present_screen_priv_rec, *present_screen_priv_ptr;
-- 
2.1.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 2/3] present: When cancelling a pending synchronous flip, requeue it

[Chris Wilson]

The vblank event request for a synchronous flip is scheduled for the
vblank before the target flip msc (so that the flip itself appears at
the right frame). If we cancel that flip and so wish to schedule a
copy instead, that copy needs to be postponed by a frame in order for it
be performed at the requested time.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 present/present.c  | 16 +++-
 present/present_priv.h |  1 +
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/present/present.c b/present/present.c
index ce978f4..a53dc11 100644
--- a/present/present.c
+++ b/present/present.c
@@ -549,8 +549,13 @@ present_check_flip_window (WindowPtr window)
 
 /* Now check any queued vblanks */
 xorg_list_for_each_entry(vblank, window_priv-vblank, window_list) {
-if (vblank-queued  vblank-flip  
!present_check_flip(vblank-crtc, window, vblank-pixmap, vblank-sync_flip, 
NULL, 0, 0))
+if (vblank-queued  vblank-flip  
!present_check_flip(vblank-crtc, window, vblank-pixmap, vblank-sync_flip, 
NULL, 0, 0)) {
 vblank-flip = FALSE;
+if (vblank-sync_flip) {
+vblank-requeue = TRUE;
+vblank-target_msc++;
+}
+}
 }
 }
 
@@ -585,6 +590,15 @@ present_execute(present_vblank_ptr vblank, uint64_t ust, 
uint64_t crtc_msc)
 present_screen_priv_ptr screen_priv = present_screen_priv(screen);
 uint8_t mode;
 
+if (vblank-requeue) {
+vblank-requeue = FALSE;
+if (Success == present_queue_vblank(screen,
+vblank-crtc,
+vblank-event_id,
+vblank-target_msc))
+return;
+}
+
 if (vblank-wait_fence) {
 if (!present_fence_check_triggered(vblank-wait_fence)) {
 present_fence_set_callback(vblank-wait_fence, 
present_wait_fence_triggered, vblank);
diff --git a/present/present_priv.h b/present/present_priv.h
index 110c925..7db4321 100644
--- a/present/present_priv.h
+++ b/present/present_priv.h
@@ -70,6 +70,7 @@ struct present_vblank {
 present_notify_ptr  notifies;
 int num_notifies;
 Boolqueued; /* on present_exec_queue */
+Boolrequeue;/* on queue, but target_msc has 
changed */
 Boolflip;   /* planning on using flip */
 Boolflip_ready; /* wants to flip, but waiting for 
previous flip or unflip */
 Boolsync_flip;  /* do flip synchronous to vblank */
-- 
2.1.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 xserver] ephyr: fix -no-host-grab argument processing

[Jürg Billeter]

Signed-off-by: Jürg Billeter j...@bitron.ch
---
 hw/kdrive/ephyr/ephyrinit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/kdrive/ephyr/ephyrinit.c b/hw/kdrive/ephyr/ephyrinit.c
index 897aa19..f02ac16 100644
--- a/hw/kdrive/ephyr/ephyrinit.c
+++ b/hw/kdrive/ephyr/ephyrinit.c
@@ -364,7 +364,7 @@ ddxProcessArgument(int argc, char **argv, int i)
 /* end Xnest compat */
 else if (!strcmp(argv[i], -no-host-grab)) {
 EphyrWantNoHostGrab = 1;
-return 2;
+return 1;
 }
 
 return KdProcessArgument(argc, argv, i);
-- 
2.3.0

___
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 3/3] present: Check for an invalid target CRTC before flipping

[Kenneth Graunke]

On Friday, February 06, 2015 08:25:44 AM Chris Wilson wrote:
 Once we have chosen the target CRTC, check for an error when querying
 the current MSC so we can report the error before attempting to record
 the uninitialised MSC/UST, and subsequently feeding garbage values to
 drmWaitVBlank.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  present/present.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/present/present.c b/present/present.c
 index 1ce587e..4a1cf0c 100644
 --- a/present/present.c
 +++ b/present/present.c
 @@ -727,7 +727,9 @@ present_pixmap(WindowPtr window,
  else if (!target_crtc)
   target_crtc = present_get_crtc(window);
  
 -present_get_ust_msc(screen, target_crtc, ust, crtc_msc);
 +ret = present_get_ust_msc(screen, target_crtc, ust, crtc_msc);
 +if (ret)
 + return ret;
  
  target_msc = present_window_to_crtc_msc(window, target_crtc, window_msc, 
 crtc_msc);

You've definitely found a bug here. Some drivers' get_ust_msc hooks
(UXA, modesetting) return BadMatch and leave crtc_msc uninitialized.  
At which point we'd happily continue and use rubbish values.

I discovered this today as well, when using valgrind to try and debug
some crashes in xf86-video-modesetting using my 'pageflip' branch:
[term1]# valgrind --vgdb-error=1 X
[term2]# gdb
[term2](gdb) target remote | vgdb
[term2](gdb) c
[term3]$ DISPLAY=:0 glxgears -fullscreen 
[term3]$ DISPLAY=:0 xset force dpms off
hit a key to DPMS on

valgrind will complain about the uninitialized values in the crtc_msc =
target_msc branch.

But...is an early return really the right thing to do?  I tested this
with xf86-video-modesetting and my 'pageflip' branch, and it caused
glxgears -fullscreen to die from a BadMatch error after a single DPMS
cycle.  I tried changing it to 'return Success', and that caused it to
stop drawing altogether.  I also tried it with UXA+DRI3, and it seemed
to break there as well.  So it seems like we need to do something more.

I can't see how this would affect SNA at all - SNA always returns
Success from sna_present_get_ust_msc(), so it shouldn't ever hit this
error path.  Instead, you seem to be using the last values.

Maybe present_get_usc_msc should never fail, and we should have drivers
return the last values, like SNA does?

Keith, Eric - thoughts?


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 3/3] present: Check for an invalid target CRTC before flipping

[Chris Wilson]

On Sun, Feb 08, 2015 at 02:10:07AM -0800, Kenneth Graunke wrote:
 On Friday, February 06, 2015 08:25:44 AM Chris Wilson wrote:
  Once we have chosen the target CRTC, check for an error when querying
  the current MSC so we can report the error before attempting to record
  the uninitialised MSC/UST, and subsequently feeding garbage values to
  drmWaitVBlank.
  
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  ---
   present/present.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)
  
  diff --git a/present/present.c b/present/present.c
  index 1ce587e..4a1cf0c 100644
  --- a/present/present.c
  +++ b/present/present.c
  @@ -727,7 +727,9 @@ present_pixmap(WindowPtr window,
   else if (!target_crtc)
  target_crtc = present_get_crtc(window);
   
  -present_get_ust_msc(screen, target_crtc, ust, crtc_msc);
  +ret = present_get_ust_msc(screen, target_crtc, ust, crtc_msc);
  +if (ret)
  +   return ret;
   
   target_msc = present_window_to_crtc_msc(window, target_crtc, 
  window_msc, crtc_msc);
 
 You've definitely found a bug here. Some drivers' get_ust_msc hooks
 (UXA, modesetting) return BadMatch and leave crtc_msc uninitialized.  
 At which point we'd happily continue and use rubbish values.
 
 I discovered this today as well, when using valgrind to try and debug
 some crashes in xf86-video-modesetting using my 'pageflip' branch:
 [term1]# valgrind --vgdb-error=1 X
 [term2]# gdb
 [term2](gdb) target remote | vgdb
 [term2](gdb) c
 [term3]$ DISPLAY=:0 glxgears -fullscreen 
 [term3]$ DISPLAY=:0 xset force dpms off
 hit a key to DPMS on
 
 valgrind will complain about the uninitialized values in the crtc_msc =
 target_msc branch.
 
 But...is an early return really the right thing to do?  I tested this
 with xf86-video-modesetting and my 'pageflip' branch, and it caused
 glxgears -fullscreen to die from a BadMatch error after a single DPMS
 cycle.  I tried changing it to 'return Success', and that caused it to
 stop drawing altogether.  I also tried it with UXA+DRI3, and it seemed
 to break there as well.  So it seems like we need to do something more.

The previous patch fixes that bug.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
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: [RFC 5/5] modesetting: Implement page flipping support for Present.

[Mario Kleiner]

Hi Kenneth,

i reviewed and tested the pageflip patches on top of XOrg 1.17.0.

Testing results so far:

My own pageflip stress tests on Intel HD 4000 Ivybridge mobile,
KDE/KWin, with external timing measurement equipment attached to get
true flip completion time and compare it against the present
timestamps, show it mostly works nicely, with robust and precise onset
time (almost no skipped frames) and precise onset timestamps, so
that's good. Tested both single display and dual-display, on a single
x-screen.

I also stress tested once on nouveau single display, without the
measurement equipment, looked mostly ok.

And i ran it the last few days on Intel HD Ironlake mobile, single
display on KDE/KWin, stress test and regular desktop use, all mostly
good.

However, i had a few crashes, usually after a few hours of light
desktop use, always ending with no backtrace, but :

[ 11093.538] (WW) modeset(0): flip queue failed: Device or resource busy

- There seems to be bugs in the error handling for that path, see my
comments interspersed below in the code for likely reason and fix, so
far untested.

Testing on GNOME-3 once got me a hang at the end of a testing session,
followed by a crash with this backtrace:

[ 38554.786] (EE) Backtrace:
[ 38554.786] (EE) 0: /usr/local/bin/X (xorg_backtrace+0x56) [0x58f246]
[ 38554.786] (EE) 1: /usr/local/bin/X (0x40+0x193399) [0x593399]
[ 38554.786] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6
(0x7fd28bcfc000+0x36eb0) [0x7fd28bd32eb0]
[ 38554.786] (EE) 3: /usr/local/bin/X (dixDestroyPixmap+0x4) [0x4347a4]
[ 38554.786] (EE) 4: /usr/local/bin/X (0x40+0x5ba92) [0x45ba92]
[ 38554.786] (EE) 5: /usr/local/bin/X (FreeClientResources+0x6c) [0x45cb4c]
[ 38554.786] (EE) 6: /usr/local/bin/X (CloseDownClient+0x70) [0x438680]
[ 38554.786] (EE) 7: /usr/local/bin/X (0x40+0x391ee) [0x4391ee]
[ 38554.786] (EE) 8: /usr/local/bin/X (0x40+0x3d34b) [0x43d34b]
[ 38554.786] (EE) 9: /lib/x86_64-linux-gnu/libc.so.6
(__libc_start_main+0xf5) [0x7fd28bd1dec5]
[ 38554.787] (EE) 10: /usr/local/bin/X (0x40+0x277ce) [0x4277ce]
[ 38554.787] (EE)
[ 38554.787] (EE) Segmentation fault at address 0xb40337

Could be unrelated to pageflipping bugs, just triggered by it?

See code below for review comments. Other than those it so far looks good to me.

On 1/29/15, Kenneth Graunke kenn...@whitecape.org wrote:
 Based on code by Keith Packard, Eric Anholt, and Jason Ekstrand.

 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 ---
  hw/xfree86/drivers/modesetting/driver.h  |  10 +
  hw/xfree86/drivers/modesetting/drmmode_display.c |  33 ++-
  hw/xfree86/drivers/modesetting/drmmode_display.h |   3 +
  hw/xfree86/drivers/modesetting/present.c | 363
 ++-
  4 files changed, 404 insertions(+), 5 deletions(-)

  Here's a first stab at implementing page flipping support for the
  modesetting driver, assuming you're using DRI3/Present.

  I've been running this all day, with cloned eDP and external DP monitors,
  with and without compositing, and it appears to be working fine.  I haven't
  seen any tearing with this patch; it was consistently present before while
  playing a game.  Jason Ekstrand also tested it.  drago01 also tested it on
  AMD.

  A couple of thoughts:
  1. The page flipping fields may need to be moved from modesettingRec to
 drmmode_crtc.  Not sure.
  2. Do we need to alter drmmode-front_bo at all?
  3. We can probably do this without Glamor, I just haven't tried it and
 hooked up the dumb BO stuff properly.  We should.
  4. DRI2 pageflipping?  I don't see any real point - it's a bunch of extra
 complexity for no real gain.  DRI3 is working fine.  We do need to port
 Mesa's EGL code to use DRI3, still, but that's doable.
  5. Option Pageflip...we should probably add one.  And man page updates.

  I doubt this is ready to merge, but I figured I'd send it so people could
  take a look and provide initial feedback.  This is pretty unfamiliar
  territory for me, so don't assume I know what I'm doing :)

 diff --git a/hw/xfree86/drivers/modesetting/driver.h
 b/hw/xfree86/drivers/modesetting/driver.h
 index 843a105..2d63cae 100644
 --- a/hw/xfree86/drivers/modesetting/driver.h
 +++ b/hw/xfree86/drivers/modesetting/driver.h
 @@ -101,6 +101,16 @@ typedef struct _modesettingRec {

  drmEventContext event_context;

 +/**
 + * Page flipping stuff.
 + *  @{
 + */
 +int flip_count;
 +uint64_t fe_msc;
 +uint64_t fe_usec;
 +struct ms_present_vblank_event *flip_vblank_event;
 +/** @} */
 +
  DamagePtr damage;
  Bool dirty_enabled;

 diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
 b/hw/xfree86/drivers/modesetting/drmmode_display.c
 index 1ea799b..7fd8669 100644
 --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
 +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
 @@ -50,7 +50,7 @@

  #include driver.h

 -static int
 +int
  drmmode_bo_destroy(drmmode_ptr drmmode, drmmode_bo *bo)
 

Re: [PATCH 0/3] present: Improve interactions with compositing manager

[Mario Kleiner]

Hi Keith and Owen,

it's a bit too late for XOrg 1.17, but i reviewed and tested
Keith's patchset, after rebasing the 3rd patch on top of 1.17-rc2.
The series has my

Reviewed-and-Tested-by: Mario Kleiner mario.kleiner...@gmail.com

My patch 1/3 is Keith's patch 3/3, just rebased and with my
review/test tags for convenience. Patch 2/3 is an extension of
Keith's idea to target vblanks more than 1 frame into the future,
on top of Keith's patch. There is no patch 3/3, the numbering is a
credit to my never ending struggles with git send-email ;)

The commit message of patch 2/3 contains some test results on both
KDE/KWin and GNOME-3, the versions from KUbuntu 14.10. All done with
hardware timing measurement equipment to check when frames really show
up at the video output and if lying about timestamps and lag is reduced.

As you can see from those results, the patchset sort of helps on
an otherwise idle desktop under KDE/KWin, but not at all even with
one instance of glxgears running in parallel to the test app.

On GNOME-3 with my patch applied on top of Keith's it helps for vblanks  1
frame in the future, so it maybe could be useful for applications which
don't need fps == full video refresh rate, e.g., video players running
at 30/25/20/15 fps or similar. It doesn't work well for full 60 fps, as
Owen suspected. Strangely running a glxgears in the background on GNOME
does help all cases on GNOME, maybe by putting the gpu into a higher
performance state? This was on Intel HD-4000. I also did some testing on
nouveau with variable results.

Given the variability, there's probably not much of a point in applying those,
maybe at most after hiding them behind some xorg.conf option by default,
so people can experiment with it if they want. I don't care one way or
the other.

Maybe merging the first two patches as a cleanup would make sense.

-mario

___
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/3] present: Extend compositor optimization to presents 1 vblank into future.

[Mario Kleiner]

Same principle as keithp's original patch 3/3, extended to handle
target_msc  crtc_msc + 1

1. If non-fullscreen window is redirected, schedule its vblank
   trigger event for 1 frame before target vblank, so offscreen
   copy and posting of damage happens in the frame before, through
   the regular present_execute() path, giving the compositor a
   chance to do its thing ahead of the target vblank.

2. After vblank_copy() posted the damage, it queues a new vblank
   event for 1 vblank into the future, which will call present_execute
   again, this time just for sending out the PresentCompleteNotify
   at the estimated vblank of true present completion.

   Unless something goes wrong with queueing, in which case it
   triggers immediate completion to avoid hangs, just as it does
   for unredirected copy presents.

Tested on Intel HD-4000 IvyBridge mobile with hardware timing
measurement equipment under KDE's KWin compositor and GNOME-3
for non-composited window copy swaps (= compositor off classic
mode), non-composited or unredirected fullscreen windows
(= kms-pageflip in use), and verified to do no harm to timing in
those cases. Testing the interesting case of redirected windows
under compositor, results are mixed:

1. KDE/KWin: Mostly correct timestamps (about 99% marking the correct
   vblank of true swap completion) under idle desktop. Things go
   downhill quickly if some additional load is present, e.g., a
   single instance of glxgears will cause at least 1 frame lag and
   all timestamps being 1 - 2 frames too early wrt. reality.

2. GNOME-3: Mostly correct timestamps for target_msc at least 2
   vblanks into the future (= 30 fps animation on 60 Hz panel),
   but almost always wrong - 1 frame too early - and somewhat
   jittery for 60 fps on 60 Hz panel. This on an otherwise idle
   desktop.

   When an instance of glxgears is running, timing *improves* to
   almost always correct timestamps for 60 fps, 30 fps, 20 fps,
   so somehow the extra load helps (gpu powermanagement upclocking,
   or somehow glxgears kicking the compositor in the right moment?)

Signed-off-by: Mario Kleiner mario.kleiner...@gmail.com
Tested-by: Mario Kleiner mario.kleiner...@gmail.com
---
 present/present.c | 90 +--
 1 file changed, 68 insertions(+), 22 deletions(-)

diff --git a/present/present.c b/present/present.c
index 2e7662a..b75017b 100644
--- a/present/present.c
+++ b/present/present.c
@@ -587,13 +587,16 @@ present_vblank_idle(present_vblank_ptr vblank)
 
 /*
  * Execute the present copy operation if it hasn't been done yet, then mark the
- * related objects as completed
+ * related objects as completed. Schedule a deferred completion for composited
+ * windows.
  */
-static void
+static Bool
 present_copy(present_vblank_ptr vblank)
 {
 if (!vblank-copied) {
-WindowPtr   window = vblank-window;
+WindowPtr   window = vblank-window;
+ScreenPtr   screen = vblank-screen;
+present_window_priv_ptr window_priv = 
present_get_window_priv(window, TRUE);
 
 vblank-copied = TRUE;
 
@@ -606,7 +609,46 @@ present_copy(present_vblank_ptr vblank)
 present_flush(window);
 
 present_vblank_idle(vblank);
+
+/* Was this a copy into a composited window? If so, queue a present
+ * completion 1 vblank into the future, as our best guess as to when
+ * the compositor will actually complete the presentation.
+ *
+ * Otherwise fallthrough to immediate completion. That's the right
+ * thing to do for a non-composited copy, and the best we can do for
+ * now in case this is called as a unredirected copy from a fallback
+ * caused by a failed PresentCompleteModeFlip.
+ */
+if (screen-GetWindowPixmap(window) != 
screen-GetScreenPixmap(screen)) {
+int ret;
+uint64_tust = 0, crtc_msc = 0;
+
+/* Re-add vblank to exec queue under same event_id */
+xorg_list_add(vblank-event_queue, present_exec_queue);
+xorg_list_append(vblank-window_list, window_priv-vblank);
+
+/* Queue one vblank from now into the future */
+ret = present_get_ust_msc(screen, vblank-crtc, ust, crtc_msc);
+
+if (ret == Success)
+ret = present_queue_vblank(screen, vblank-crtc,
+   vblank-event_id, crtc_msc + 1);
+
+/* On success, tell caller to not complete the present. Our 
deferred
+ * vblank event will do that by triggering present_execute() again.
+ */
+if (ret == Success)
+return TRUE;
+
+xorg_list_del(vblank-event_queue);
+xorg_list_del(vblank-window_list);
+
+DebugPresent((present_queue_vblank for deferred completion 
failed\n));
+}
 }
+
+/* Signal need for an immediate 

[PATCH 1/3] present: When composited, get the bits into the window pixmap immediately (v2)

[Mario Kleiner]

From: Keith Packard kei...@keithp.com

When a window is composited, we want to notify the compositing manager
of the new contents *before* the next frame, so that it can prepare
them for display at the next frame, instead of doing the copy at that
frame time, and notifying the compositor so that it would always be a
frame behind.

This change catches the common case of a operation destined for the
next frame and immediately performs the copy, leaving the queue entry
around so that the PresentComplete event can be delivered at the
target frame time. This should give applications the right answer if
the Compositor is able to get the frame constructed before that frame
happens, which is at least better than the current situation where the
client receives the PresentComplete notify at the target frame, but
the contents will not be displayed until a subsequent frame.

Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by: Mario Kleiner mario.kleiner...@gmail.com

v2 (mario): Trivial rebase on top of 1.17.0-rc2
Signed-off-by: Mario Kleiner mario.kleiner...@gmail.com
Tested-by: Mario Kleiner mario.kleiner...@gmail.com
---
 present/present.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/present/present.c b/present/present.c
index bb7f33c..2e7662a 100644
--- a/present/present.c
+++ b/present/present.c
@@ -890,8 +890,25 @@ present_pixmap(WindowPtr window,
 vblank-queued = TRUE;
 if ((pixmap  target_msc = crtc_msc) || (!pixmap  target_msc  
crtc_msc)) {
 ret = present_queue_vblank(screen, target_crtc, vblank-event_id, 
target_msc);
-if (ret == Success)
+if (ret == Success) {
+/* If the window is composited, and the contents are
+ * destined for the next frame, just do the copy, sending
+ * damage along to the compositor.
+ *
+ * Leave the vblank around to send the completion event at
+ * vblank time
+ */
+if (pixmap  window  vblank-mode == PresentCompleteModeCopy 
+(target_msc - crtc_msc) = 1 
+screen-GetWindowPixmap(window) != 
screen-GetScreenPixmap(screen))
+{
+DebugPresent((\tC %p %8lld: %08lx - %08lx\n, vblank, 
crtc_msc,
+ vblank-pixmap-drawable.id, 
vblank-window-drawable.id));
+present_copy(vblank);
+}
+
 return Success;
+}
 
 DebugPresent((present_queue_vblank failed\n));
 }
-- 
2.1.0

___
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 xserver] ephyr: fix -no-host-grab argument processing

[Alan Coopersmith]

On 02/ 8/15 02:34 AM, Jürg Billeter wrote:

Signed-off-by: Jürg Billeter j...@bitron.ch
---
  hw/kdrive/ephyr/ephyrinit.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/kdrive/ephyr/ephyrinit.c b/hw/kdrive/ephyr/ephyrinit.c
index 897aa19..f02ac16 100644
--- a/hw/kdrive/ephyr/ephyrinit.c
+++ b/hw/kdrive/ephyr/ephyrinit.c
@@ -364,7 +364,7 @@ ddxProcessArgument(int argc, char **argv, int i)
  /* end Xnest compat */
  else if (!strcmp(argv[i], -no-host-grab)) {
  EphyrWantNoHostGrab = 1;
-return 2;
+return 1;
  }

  return KdProcessArgument(argc, argv, i);



Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
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

Start Xorg with background image

[kirthika varadarajan]

Hi All,
 From linux driver I am writing an image to video buffer.

 When Xorg starts its clearing the video buffer and black screen is shown.
 Is there any way to retain the image in framebuffer which is written by
driver when
 xorg starts.

Any one have tried showing background image when Xorg starts or is there
any way to modify Xorg library to retain the frame buffer contents.

 Also I tried xorg with option -background none but still its clearing the
window.


 Suggest me the ways to retain the image.

Thanks and Regards,
Kiruthika
___
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 0/3] present: Improve interactions with compositing manager

[Keith Packard]

Mario Kleiner mario.kleiner...@gmail.com writes:

 Given the variability, there's probably not much of a point in applying those,
 maybe at most after hiding them behind some xorg.conf option by default,
 so people can experiment with it if they want. I don't care one way or
 the other.

Would be nice to see if we couldn't actually get compositors to take
advantage of present's ability to queue multiple updates per
frame. That, in combination with this series, should provide actual
improvements over the current situation.

-- 
-keith


signature.asc
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 3/3] present: Check for an invalid target CRTC before flipping

[Kenneth Graunke]

On Sunday, February 08, 2015 12:00:37 PM Chris Wilson wrote:
 On Sun, Feb 08, 2015 at 02:10:07AM -0800, Kenneth Graunke wrote:
  On Friday, February 06, 2015 08:25:44 AM Chris Wilson wrote:
   Once we have chosen the target CRTC, check for an error when querying
   the current MSC so we can report the error before attempting to record
   the uninitialised MSC/UST, and subsequently feeding garbage values to
   drmWaitVBlank.
   
   Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
   ---
present/present.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
   
   diff --git a/present/present.c b/present/present.c
   index 1ce587e..4a1cf0c 100644
   --- a/present/present.c
   +++ b/present/present.c
   @@ -727,7 +727,9 @@ present_pixmap(WindowPtr window,
else if (!target_crtc)
 target_crtc = present_get_crtc(window);

   -present_get_ust_msc(screen, target_crtc, ust, crtc_msc);
   +ret = present_get_ust_msc(screen, target_crtc, ust, crtc_msc);
   +if (ret)
   + return ret;

target_msc = present_window_to_crtc_msc(window, target_crtc, 
   window_msc, crtc_msc);
  
  You've definitely found a bug here. Some drivers' get_ust_msc hooks
  (UXA, modesetting) return BadMatch and leave crtc_msc uninitialized.  
  At which point we'd happily continue and use rubbish values.
  
  I discovered this today as well, when using valgrind to try and debug
  some crashes in xf86-video-modesetting using my 'pageflip' branch:
  [term1]# valgrind --vgdb-error=1 X
  [term2]# gdb
  [term2](gdb) target remote | vgdb
  [term2](gdb) c
  [term3]$ DISPLAY=:0 glxgears -fullscreen 
  [term3]$ DISPLAY=:0 xset force dpms off
  hit a key to DPMS on
  
  valgrind will complain about the uninitialized values in the crtc_msc =
  target_msc branch.
  
  But...is an early return really the right thing to do?  I tested this
  with xf86-video-modesetting and my 'pageflip' branch, and it caused
  glxgears -fullscreen to die from a BadMatch error after a single DPMS
  cycle.  I tried changing it to 'return Success', and that caused it to
  stop drawing altogether.  I also tried it with UXA+DRI3, and it seemed
  to break there as well.  So it seems like we need to do something more.
 
 The previous patch fixes that bug.
 -Chris

I was running with all three of your patches in this series.

--Ken


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