Re: [PATCH weston 0/3] Pointer locking revisited

[Axel Davy]

On 17/09/2014 21:39, Jonas Ådahl wrote :

Hi,

This short series introduces a pointer lock interface based on the
previous proposal[0] by Kristian Høgsberg from last year. The first patch
adds a protocol more or less equal to Kristians proposal, but moved out
of wl_seat into its own global object (currently _wl_pointer_lock), with
some concerns raised in the original thread addressed. The implementation
in weston is new. There was no point trying to rebase the previous
implementation due to the architectural changes done since that patch was
written.

The second patch introduces a client side API in toytoolkit, and the
forth makes use of that API in resizor, in the same way as in the
previous proposal, to resize its window.

Note that the reason for having the underscore prefix is to have the
possibility to push a stable variant to the wayland repo without
breaking any clients implementing the experimental version. The
intention is that _wl_pointer_lock ever would be considered an
official interface, it would be renamed to wl_pointer_lock.

In short, the interface works by having the client create a separate
wl_pointer object, using wl_pointer_lock.lock_pointer, that gets focus
until wl_pointer.release is requested and the surface gets deactivated.
If the locked pointer object is still not released when a surface
is activated again, the pointer will be implicitly locked to the special
wl_pointer object again.

Limitations with this approach include that it would, as far as I know,
not be possible to fully implement pointer warping support in Xwayland
only using this protocol. However, not sure if support for legacy
concepts is within the scope of an interface like this. Maybe Xwayland
needs some private way to communicate (privileged wl_xwayland interface?)
for these type of things? Maybe it could be emulated by locking if
warping is done with some heuristic for releasing the lock, but have not
tried to implement that.

We wouldn't be able to implement API of certain toolkits (for example
SDL, GLFW). This I suppose is not really a big deal as it wouldn't be the
first (global positions etc) and the use case is most likely to lock the
pointer and get relative motion events, and there is API available in
both those toolkits for that. Pointer confinement (absolute motion
events, but not letting the pointer leave the surface) is another
functionality that wouldn't be possible. It could be emulated by having
the client lock the pointer and draw the pointer itself given the
relative motion events, or simply added to this protocol in some way
(wl_pointer_lock.confine_pointer?).

In the previous thread, surface transformations came up as something that
needed to be thought through. In the updated protocol of this series, I
clarified that relative motion events are as if the surface has not been,
transformed. The reasoning behind this is more or less how typical use
case looks like: 1:st person 3D games. I would expect that the viewport
moves the same even if the window happen to have been transformed for
example zoomed or rotated.

Following the trend of keeping track of these kind of stuff, I filed[1] a
bug on BZ as well.

Thoughts? Is this the right way to go?


Jonas

[0] 
http://lists.freedesktop.org/archives/wayland-devel/2013-February/007635.html
[1] https://bugs.freedesktop.org/show_bug.cgi?id=84014

Jonas Ådahl (3):
   Introduce pointer lock interface
   clients: Introduce pointer lock API to toytoolkit
   resizor: Make resizor also use pointer locks for resizing

  Makefile.am   |  11 +-
  clients/resizor.c |  62 +++
  clients/window.c  | 177 +
  clients/window.h  |  42 +++
  desktop-shell/exposay.c   |   2 +-
  desktop-shell/shell.c |  10 +-
  protocol/pointer-lock.xml |  85 ++
  src/compositor.c  |   4 +
  src/compositor.h  |  21 +++-
  src/input.c   | 277 +-
  10 files changed, 678 insertions(+), 13 deletions(-)
  create mode 100644 protocol/pointer-lock.xml


Thanks for getting into this.

Could you clarify where the cursor should be during the lock,
and what should be the cursor position when a lock is ended ?

Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Xwayland/glamor broken after glamor-next merge

[Axel Davy]

On 01/09/2014 11:58, Steven Newbury wrote :

On Mon, 2014-09-01 at 10:49 +0100, Steven Newbury wrote:

On Mon, 2014-09-01 at 18:42 +0900, Michel Dänzer wrote:

  On 01.09.2014 18:08, Steven Newbury wrote:

   Since commit 6d4954884908ea9894fcfe9836db1ba7bb45be61 ("Merge
   remote-tracking branch 'origin/master' into glamor-next") I've
  just
   been getting completely black windows with anything other than
  really
   simple xlib apps such as xterm.  I've biscected it down the the
  above
   merge commit by running glxgears on each checkout.
   Am I the only one seeing this?

  No:

  https://bugs.freedesktop.org/show_bug.cgi?id=81800

  I think Axel Davy (Cc'd) tracked down the problem at some point.




Thanks, I need to work on my bug report searching skills... ;-)


Boyan Ding in the bug report tracked it down to commit
45ebc4e3fac7f1a85167d05e2833949b89f02d64 ("glamor: Add glamor_program
based copy acceleration")

I'll try to verify, and see if I can get some debug output if that
will help track it down.

I found a way to fix it, and I remember Markus Wick had written a proper 
patch.


I'm really surprised it is not already merged.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland v2] protocol: try to clarify frame callback semantics

[Axel Davy]

Hi,

I like very much the rewording proposed by Pekka.

But I dislike your proposition to send frame callbacks right away if the 
attached buffer has been attached for a long time.


Your argument seems to be that the client may manage to get to the next 
pageflip if the frame callback is called right away. But with this 
argument, I don't see why this behaviour would be only for buffers 
attached long ago (and then we refresh at a higher frequency than the 
screen refresh)


Moreover we may say we can always get the two behaviours with client 
side code:
. If we keep the current behaviour, the client could know it has 
attached a buffer for a long time (and that the frame callback it had 
put, was already called), so if it wants to try to hit next pageflip, it 
could just commit right away with a new attach
. With your proposition the client could always attach (and perhaps 
+damage) with a frame+commit (even with the old buffer not released), to 
be sure to get current behaviour.


I don't think having to do an attach with the old buffer is a good idea, 
and I favor Pekka's proposition.


Axel Davy

On 22/02/2014, Jason Ekstrand wrote :

Pekka,
Sorry this e-mail took so long to send.  Not much time lately.  The 
first time or two I read this suggested re-wording I didn't like it, 
but now it's starting to grow on me.  I still kind of like the idea of 
"the buffer you sent is now in use, go ahead and send the next one" 
but I don't know that it's that much better or that it actually 
changes anything.


The big thing I'd like to leave open (and I think your change does) is 
the following:  Suppose a client commits a buffer and then, several 
seconds later (after the attached buffer was first used), the user 
does something that causes the client to refresh.  If it does a 
frame+commit without an attach, the server should be able to respond 
immediately without waiting for another pageflip.  This way the client 
may be able to render in time for the next flip.  Sure, the client 
might be too slow and miss the flip, but that's really no worse than 
waiting before sending the frame callback.


Point is, it should be a compositor decision and I think you made that 
clear enough.


Looks good to me.
--Jason Ekstrand

Reviewed-by: Jason Ekstrand <mailto:ja...@jlekstrand.net>>


On Fri, Feb 21, 2014 at 7:46 AM, Pekka Paalanen <mailto:ppaala...@gmail.com>> wrote:


From: Pekka Paalanen mailto:pekka.paala...@collabora.co.uk>>

"the callback event will arrive after the next output refresh" is
wrong,
if you interpret "output refresh" as framebuffer flip or the
moment when
the new pixels turn into light the first time. Weston has probably
never
worked this way.

Weston triggers the frame callbacks when it submits repainting
commands
to the GPU, which is before the framebuffer flip.

Strike the incorrect claim, and the rest of the paragraph which no
longer offers useful information.

As a replacement, expand on the "throttling and driving animations"
characteristic. The main purpose is to let clients animate at the
display refresh rate, while avoiding drawing frames that will never be
presented.

The new claim is that the server should give some time between
triggering frame callbacks and repainting itself, for clients to draw
and commit. This is somewhat intimate with the repaint scheduling
algorithm a compositor uses, but hopefully the right intention.


Another point of this update is to imply, that frame callbacks should
not be used to count compositor repaint cycles nor monitor refresh
cycles. It has never been guaranteed to work. Removing the mention of
frame callback without an attach hopefully discourages such use.

v2: don't just remove a paragraph, but add useful information
about the
request's intent.

Signed-off-by: Pekka Paalanen mailto:pekka.paala...@collabora.co.uk>>
Cc: Axel Davy mailto:axel.d...@ens.fr>>
Cc: Jason Ekstrand mailto:ja...@jlekstrand.net>>
---
 protocol/wayland.xml | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index e1edbe5..6e370ad 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1059,22 +1059,32 @@
 

 
-  
-   Request notification when the next frame is displayed. Useful
-   for throttling redrawing operations, and driving animations.
+  
+   Request a notification when it is a good time start
drawing a new
+   frame, by creating a frame callback. This is useful for
throttling
+   redrawing operations, and driving animations.
+
+   When a client is animating on a wl_surface, it can use the

Re: [PATCH] xwayland: Destroy wl_buffers only after they are released

[Axel Davy]

Hi,

I've checked how it would behave when X closes properly,
and I think xwl_screen_close would need a new flush after the roundtrip:
. first flush: the server knows the wl_surface was destroyed
. dispatch: X gets the release
. missing flush: the server knows the wl_buffer has been destroyed.

Moreover I figured out that every windows and pixmaps should have been 
destroyed

before xwl_screen_close, making xwl_screen->window_list always empty,
so there is some useless code here.

I'm going to write a patch to do what you want on top of my tree with 
XWayland Present implementation, since

my XWayland Present patches are incompatible with yours.

Axel Davy

On 20/02/2014, Rui Matos wrote :

Destroying a wl_buffer that is still attached to a wl_surface is
undefined behavior according to the wayland protocol. We should delay
the destruction until we get the release event.

To achieve this we need to track ownership of wl_buffers, both our own
and the compositor's which occurs from either the first commit request
or the first commit request after a release event until the next
release event.
---

On 12 February 2014 08:54, Pekka Paalanen  wrote:

I assume the code never added a wl_buffer listener before, because if
it did, this patch would be a no-op. "wl_buffer_add_listener" is a
misnomer, there can only ever be one listener, and trying to "add"
another will not actually do anything.

Thanks for the headsup. But, indeed, there was nothing adding a
wl_buffer listener before.


Also, you rely on wl_buffer.release not having arrived before you add
the listener. With weston's gl-renderer, the release comes very soon
after each wl_surface.commit for wl_shm buffers. Maybe it works, maybe
it doesn't, but it seems very fragile. Did you check you don't leak
wl_buffers now?

Right, I was leaking in some cases. So, I came up with the solution
below which, if I'm reading the logs correctly, doesn't leak and works
correctly.

This solution abuses the user_data field to essentially keep two
toggle references, our own and the compositor's, and only destroys the
wl_buffer when both are dropped.

Thanks,
Rui

---
  hw/xfree86/xwayland/xwayland-cursor.c  |  4 ++-
  hw/xfree86/xwayland/xwayland-private.h |  4 +++
  hw/xfree86/xwayland/xwayland-window.c  |  8 +++---
  hw/xfree86/xwayland/xwayland.c | 50 ++
  4 files changed, 61 insertions(+), 5 deletions(-)

diff --git a/hw/xfree86/xwayland/xwayland-cursor.c 
b/hw/xfree86/xwayland/xwayland-cursor.c
index 2b3cb5e..232b038 100644
--- a/hw/xfree86/xwayland/xwayland-cursor.c
+++ b/hw/xfree86/xwayland/xwayland-cursor.c
@@ -125,6 +125,7 @@ xwl_realize_cursor(DeviceIntPtr device, ScreenPtr screen, 
CursorPtr cursor)
  cursor->bits->width, cursor->bits->height,
  cursor->bits->width * 4,
  WL_SHM_FORMAT_ARGB);
+_buffer_init(buffer);
  wl_shm_pool_destroy(pool);
  
  dixSetPrivate(&cursor->devPrivates,

@@ -143,7 +144,7 @@ xwl_unrealize_cursor(DeviceIntPtr device,
  xwl_screen = xwl_screen_get(screen);
  buffer = dixGetPrivate(&cursor->devPrivates,
 &xwl_screen->cursor_private_key);
-wl_buffer_destroy(buffer);
+_buffer_disown(buffer);
  
  return TRUE;

  }
@@ -176,6 +177,7 @@ xwl_seat_set_cursor(struct xwl_seat *xwl_seat)
  xwl_seat->x_cursor->bits->width,
  xwl_seat->x_cursor->bits->height);
  wl_surface_commit(xwl_seat->cursor);
+_buffer_commited(buffer);
  }
  
  static void

diff --git a/hw/xfree86/xwayland/xwayland-private.h 
b/hw/xfree86/xwayland/xwayland-private.h
index bdecf8a..41e7e13 100644
--- a/hw/xfree86/xwayland/xwayland-private.h
+++ b/hw/xfree86/xwayland/xwayland-private.h
@@ -137,4 +137,8 @@ void xwl_output_remove(struct xwl_output *output);
  
  extern const struct xserver_listener xwl_server_listener;
  
+void _buffer_commited(struct wl_buffer *buffer);

+void _buffer_disown(struct wl_buffer *buffer);
+void _buffer_init(struct wl_buffer *buffer);
+
  #endif /* _XWAYLAND_PRIVATE_H_ */
diff --git a/hw/xfree86/xwayland/xwayland-window.c 
b/hw/xfree86/xwayland/xwayland-window.c
index a2a8206..d18c7f6 100644
--- a/hw/xfree86/xwayland/xwayland-window.c
+++ b/hw/xfree86/xwayland/xwayland-window.c
@@ -62,10 +62,8 @@ xwl_window_attach(struct xwl_window *xwl_window, PixmapPtr 
pixmap)
  struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
  struct wl_callback *callback;
  
-/* We can safely destroy the buffer because we only use one buffer

- * per surface in xwayland model */
  if (xwl_window->buffer)
-wl_buffer_destroy(xwl_window->buffer);
+_buffer_disown(xwl_window->buffer);
  
  xwl_screen->driver->create_window_buffer(xwl_window, pixmap)

Re: Core protocol change; [RFC v2] Wayland presentation extension

[Axel Davy]

Hi,

If you read the above paragraph carefully, you see that the last
sentence CHANGES EXISTING WAYLAND CORE PROTOCOL BEHAVIOUR.

The change is very subtle. It means, that without a wl_surface.attach,
the buffer state is no longer applied on commit at all! To recap, the
buffer state is:
- frame callbacks (!)
- set_buffer_transform
- set_buffer_scale
- the src_* arguments of wl_viewport.set

The reason is explained in my recent email:
http://lists.freedesktop.org/archives/wayland-devel/2014-February/013293.html

An immediate commit without an attach should not apply any buffer
state, because previous queueing of frames may have left buffer state
that is incorrect for the currently showing buffer. Immediate commits
without attach are used to update surface (and shell!) state, and
applying incorrect buffer state could cause a visual glitch.

We could claim, that this change in the core protocol exists only if
the presentation extension is advertised by the server, but that would
cause a lot more work to fix clients that get bit by this change, rather
than fix the clients to always attach a wl_buffer when they want to
change buffer state, even if it is the same buffer they just attached
and committed already.

Therefore I would like to bring the concepts of surface state and
buffer state to the core protocol, and have the core procotol define
that buffer state is applied only if there is an attach.

In the past, we already changed the wl_surface.attach semantics to not
re-attach the "current" buffer again, when there is a wl_surface.commit.
The practical consequence of that was that a commit without an attach
cannot cause any wl_buffer on this surface to become reserved and
readable by the server, and hence no (new) wl.buffer.release would be
posted either.

That means that clients already need to re-attach the same wl_buffer
again, if they changed the buffer contents and want to show the new
image. I think this should mitigate the impact of the core protocol
change.

I guess the only interesting case is the frame callback, and whether
anyone (ab)uses it without an attach.

Would this proposition be acceptable?


Thanks,
pq



As Jason pointed, it's useful to be able to do frame+commit when we 
want, outside of the part of the program doing attach+damage+commit, and 
get the frame callback.

I agree the definition of the frame callback should be clarified though.

I think a clarification of frame shouldn't break existing programs.

I don't see the point of queuing frame callbacks, and that should be 
more apparent if we change frame meaning.


I've seen you proposed the change:

-   A client can request a frame callback even without an attach,
-   damage, or any other state changes. wl_surface.commit triggers
-   display update, so the callback event will arrive after the next
-   output refresh where the surface is visible.
-

Why not replace that by:

A client can request a frame callback even without an attach,
damage, or any other state changes. The frequency at which the frame
callbacks are called by the compositor is not defined,
but the client can expect it to be similar to the refresh rate if the 
surface is focused and visible on the screen.


Axel Davy


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v4] Fullscreen shell protocol

[Axel Davy]

On 14/02/2014, Jason Ekstrand wrote :

The following is yet another take on the fullscreen shell protocol.

If the client manages the inpust, it would likely want to use the 
display ability to draw cursors.


Thus your interface should integrate a way to create a cursor, and 
choose its location/sprite (and should take into account there could be 
several cursors).


Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xwayland: Destroy wl_buffers only after they are released

[Axel Davy]

Hi,

I have pending changes to this part to implement XWayland present support.

Instead a having the wl_buffer attached to a window, I attach it to a 
pixmap.


Could you test with this branch, and tell if you encounter the problems 
you have?


https://github.com/axeldavy/xserver/tree/xwayland-dri3-present

Thanks.

Axel Davy

On 11/02/2014, Rui Matos wrote :

Destroying a wl_buffer that is still attached to a wl_surface is
undefined behavior according to the wayland protocol. We should delay
the destruction until we get the release event.
---

So, I'm not sure why there was this comment saying that it was safe to
do this, perhaps it was in an old protocol version?

In any case, this has been making xwayland crash under mutter ever
since this mutter commit
https://git.gnome.org/browse/mutter/commit/?h=wayland&id=3e98ffaf9958366b584b360ac12bbc03cd070c07
 .

  hw/xfree86/xwayland/xwayland-window.c | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/hw/xfree86/xwayland/xwayland-window.c 
b/hw/xfree86/xwayland/xwayland-window.c
index a2a8206..a005cc6 100644
--- a/hw/xfree86/xwayland/xwayland-window.c
+++ b/hw/xfree86/xwayland/xwayland-window.c
@@ -43,6 +43,16 @@
  static DevPrivateKeyRec xwl_window_private_key;
  
  static void

+free_buffer(void *data, struct wl_buffer *buffer)
+{
+wl_buffer_destroy(buffer);
+}
+
+static const struct wl_buffer_listener buffer_listener = {
+free_buffer,
+};
+
+static void
  free_pixmap(void *data, struct wl_callback *callback, uint32_t time)
  {
  PixmapPtr pixmap = data;
@@ -62,10 +72,8 @@ xwl_window_attach(struct xwl_window *xwl_window, PixmapPtr 
pixmap)
  struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
  struct wl_callback *callback;
  
-/* We can safely destroy the buffer because we only use one buffer

- * per surface in xwayland model */
  if (xwl_window->buffer)
-wl_buffer_destroy(xwl_window->buffer);
+wl_buffer_add_listener(xwl_window->buffer, &buffer_listener, NULL);
  
  xwl_screen->driver->create_window_buffer(xwl_window, pixmap);
  
@@ -185,7 +193,7 @@ xwl_unrealize_window(WindowPtr window)

return ret;
  
  if (xwl_window->buffer)

-   wl_buffer_destroy(xwl_window->buffer);
+wl_buffer_add_listener(xwl_window->buffer, &buffer_listener, NULL);
  wl_surface_destroy(xwl_window->surface);
  xorg_list_del(&xwl_window->link);
  if (RegionNotEmpty(DamageRegion(xwl_window->damage)))


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v2] Wayland presentation extension (video protocol)

[Axel Davy]

On 10/02/2014, Jason Ekstrand wrote :




On Mon, Feb 10, 2014 at 3:53 AM, Pekka Paalanen <mailto:ppaala...@gmail.com>> wrote:


On Sat, 8 Feb 2014 15:23:29 -0600
Jason Ekstrand mailto:ja...@jlekstrand.net>> wrote:

> Pekka,
> First off, I think you've done a great job over-all.  I think it
will both
> cover most cases and work well  I've got a few comments below.

Thank you for the review. :-)
Replies below.

> On Thu, Jan 30, 2014 at 9:35 AM, Pekka Paalanen
mailto:ppaala...@gmail.com>> wrote:
>
> > Hi,
> >
> > it's time for a take two on the Wayland presentation extension.
> >
> >
> > 1. Introduction
> >
> > The v1 proposal is here:
> >
> >
http://lists.freedesktop.org/archives/wayland-devel/2013-October/011496.html
> >
> > In v2 the basic idea is the same: you can queue frames with a
> > target presentation time, and you can get accurate presentation
> > feedback. All the details are new, though. The re-design started
> > from the wish to handle resizing better, preferably without
> > clearing the buffer queue.
> >
> > All the changed details are probably too much to describe here,
> > so it is maybe better to look at this as a new proposal. It
> > still does build on Frederic's work, and everyone who commented
> > on it. Special thanks to Axel Davy for his counter-proposal and
> > fighting with me on IRC. :-)
> >
> > Some highlights:
> >
> > - Accurate presentation feedback is possible also without
> >   queueing.
> >
> > - You can queue also EGL-based rendering, and get presentation
> >   feedback if you want. Also EGL can do this internally, too, as
> >   long as EGL and the app do not try to use queueing at the
same time.
> >
> > - More detailed presentation feedback to better allow predicting
> >   future display refreshes.
> >
> > - If wl_viewport is used, neither video resolution changes nor
> >   surface (window) size changes alone require clearing the queue.
> >   Video can continue playing even during resizes.
...
> >   
> > 
> >   The main features of this interface are accurate
presentation
> >   timing feedback, and queued wl_surface content updates
to ensure
> >   smooth video playback while maintaining audio/video
> >   synchronization. Some features use the concept of a
presentation
> >   clock, which is defined in presentation.clock_id event.
> >
> >   Requests 'feedback' and 'queue' can be regarded as
additional
> >   wl_surface methods. They are part of the double-buffered
> >   surface state update mechanism, where other requests
first set
> >   up the state and then wl_surface.commit atomically
applies the
> >   state into use. In other words, wl_surface.commit submits a
> >   content update.
> >
> >   Interface wl_surface has requests to set surface related
state
> >   and buffer related state, because there is no separate
interface
> >   for buffer state alone. Queueing requires separating the
surface
> >   from buffer state, and buffer state can be queued while
surface
> >   state cannot.
> >
> >   Buffer state includes the wl_buffer from
wl_surface.attach, the
> >   state assigned by wl_surface requests frame,
> >   set_buffer_transform and set_buffer_scale, and any
> >   buffer-related state from extensions, for instance
> >   wl_viewport.set_source. This state is inherent to the buffer
> >   and the content update, rather than the surface.
> >
> >   Surface state includes all other state associated with
> >   wl_surfaces, like the x,y arguments of
wl_surface.attach, input
> >   and opaque regions, damage, and extension state like
> >   wl_viewport.destination. In general, anything expressed in
> >   surface local coordinates is better as surface state.
> >
> >   The standard way of posting new content to a surface
using the
> >   wl_surface requests damage, attach, and commit is called
> >   immediate content submission. This happens when a
> >   presentation.queue request has not been sent since the last

Re: [RFC v2] Wayland presentation extension (video protocol)

[Axel Davy]

On 08/02/2014, Axel Davy wrote :

Hi,


On 08/02/2014, Jason Ekstrand wrote :



  For each surface with queued content updates and matching main
  output, the compositor picks the update with the highest
  timestamp no later than a half frame period after the predicted
  presentation time. The intent is to pick the content update
  whose target timestamp as rounded to the output refresh period
  granularity matches the same display update as the
compositor is
  targeting, while not displaying any content update more than a


I'm not really following 100% here. It's not your fault, this is just 
a terribly awkward sort of thing to try and put into English.  It 
sounds to me like the following: If P0 is the time of the next 
present and P1 is the time of the one after that, you look for the 
largest thing less than the average of P1 and P2.  Is this correct?  
Why go for the average?  The client is going to have to adjust anyway.

If you target t, and P0 and P1 are possible pageflips time,
if P0That way the length of the intersection of the interval (t,t+time 
between two pageflips) and 'time interval at which it is displayed' is 
maximized.


Well it isn't really the reason why this is choosen (else one might say 
it would be better to maximize with (t-T/2,t+T/2) with T the time 
between two pageflips.).
The reason is more that you want to minimize the time at when the 
pageflip happens and t, so the real presentation time and t doesn't 
differ more than T/2.


Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v2] Wayland presentation extension (video protocol)

[Axel Davy]

Hi,


On 08/02/2014, Jason Ekstrand wrote :



  For each surface with queued content updates and matching main
  output, the compositor picks the update with the highest
  timestamp no later than a half frame period after the predicted
  presentation time. The intent is to pick the content update
  whose target timestamp as rounded to the output refresh period
  granularity matches the same display update as the compositor is
  targeting, while not displaying any content update more than a


I'm not really following 100% here. It's not your fault, this is just 
a terribly awkward sort of thing to try and put into English.  It 
sounds to me like the following: If P0 is the time of the next present 
and P1 is the time of the one after that, you look for the largest 
thing less than the average of P1 and P2.  Is this correct?  Why go 
for the average?  The client is going to have to adjust anyway.

If you target t, and P0 and P1 are possible pageflips time,
if P0That way the length of the intersection of the interval (t,t+time 
between two pageflips) and 'time interval at which it is displayed' is 
maximized.



  half frame period too early. If all the updates in the queue are
  already late, the highest timestamp update is taken regardless
  of how late it is. Once an update in a queue has been chosen,
  all remaining updates with an earlier timestamp in the queue are
  discarded.


Ok, I think what you are saying works.  Again, it's difficult to parse 
but these things always are.




My one latent concern is that I still don't think we're entirely 
handling the case that QtQuick wants.  What they want is to do their 
rendering a few frames in advance in case of CPU/GPU jitter.  
Technically, this extension handles this by the client simply doing a 
good job of guessing presentation times on a one-per-frame baseis. 
However, it doesn't allow for any damage tracking.  In the case of 
QtQuick they want a linear queue of buffers where no buffer ever gets 
skipped.  In this case, you could do damage tracking by allowing it to 
accumulate from one frame to another and you get all of the 
damage-tracking advantages that you had before.  I'm not sure how much 
this matters, but it might be worth thinking about it.


If they really want to work that way, why not doing this queue client 
side? It doesn't need to be done in the compositor.



Hope that helps,
--Jason Ekstrand


Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Fwd: Re: Help compiling mesa/gallium from git!

[Axel Davy]

The new mesa you built has no egl_gallium.so (since you have
--disable-gallium-egl), but you have not removed the old egl_gallium.so,
and it tries to load it, since it is here.

Axel Davy

Le 07/02/2014 18:30, Bill Spitzak a écrit :

In order to try to compile the new xserver for wayland, I updated mesa
to the latest git version, and now wayland does not work at all!
Considering it has worked for a long time I would like to try to fix
this, it is really unfortunate.

It does appear the problem is in egl gallium and it's software
fallback. Pekka you were just talking about this in another thread so
I thought you may have an idea what is wrong, or perhaps what I should
do to get around it.

Running weston in the debugger with the debug symbols turned on
produces this (this is from inside a terminal on X so I am using the
X11 compositor):

Starting program: /home/spitzak/install/bin/weston --modules=xwayland.so
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
Date: 2014-02-07 PST
[09:14:13.518] weston 1.4.0
   http://wayland.freedesktop.org/
   Bug reports to:
https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.4.0
   Build: 1.4.0-59-gc94d622 compositor: Move view
repositioning logic into shell (2014-02-05 17:36:00 -0800)
[09:14:13.518] OS: Linux, 3.2.0-58-generic, #88-Ubuntu SMP Tue Dec 3
17:37:58 UTC 2013, x86_64
[09:14:13.518] warning: XDG_RUNTIME_DIR "/run/shm" is not configured
correctly.  Unix access mode must be 0700 (current mode is 777),
and must be owned by the user (current owner is UID 0).
Refer to your distribution on how to get it, or
http://www.freedesktop.org/wiki/Specifications/basedir-spec
on how to implement it.
[09:14:13.519] Using config file '/home/spitzak/.config/weston.ini'
[09:14:13.519] Loading module
'/home/spitzak/install/lib/weston/x11-backend.so'
[09:14:13.619] initializing x11 backend
[09:14:13.621] Loading module
'/home/spitzak/install/lib/weston/gl-renderer.so'
libEGL debug: Native platform type: x11 (autodetected)
libEGL debug: EGL search path is /home/spitzak/install/lib/egl
libEGL debug: added /home/spitzak/install/lib/egl/egl_gallium.so to
module array
libEGL debug: added egl_dri2 to module array
libEGL debug: dlopen(/home/spitzak/install/lib/egl/egl_gallium.so)
libEGL info: use X11 for display 0x632e40
libEGL info: use software fallback

Program received signal SIGSEGV, Segmentation fault.
0x71b980af in egl_g3d_new_sw_screen (ndpy=,
ws=0x654040)
at common/egl_g3d.c:67
warning: Source file is more recent than executable.
67}

This does appear to be in egl_gallium.so, which is recently compiled,
I am not sure why I get the "Source file is more recent" error.

Mesa is built with the following config line, which is ridiculous
complex and probably the source of my troubles, but I really have no
idea what any of this means:

 ./autogen.sh --prefix=$WLD --enable-gles2 --disable-gallium-egl \
  --with-egl-platforms=wayland,x11,drm --enable-gbm \
  --enable-shared-glapi
--with-gallium-drivers=r300,r600,swrast,nouveau \
  --with-dri-drivers= --disable-dri3

Thanks for any help!
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel





___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Xserver errors

[Axel Davy]

Your bug is likely to be coming from the combination old XWayland/ 
recent Weston.


Try with main xwayland branch and xf86-video-wayland (forget about the 
outdated things you built)


Xwayland is divided in two parts: the Xwayland window manager (weston) 
and ... Xwayland (in the Xserver)


Axel Davy

Le 05/02/2014 18:46, Bill Spitzak a écrit :

On 02/05/2014 09:21 AM, Jasper St. Pierre wrote:

What compositor are you using


The X11 compositor you get when you run wayland under X.

My X system is stock Ubuntu running Unity, though I suspect that has 
little to do with it.



and how did you build Xwayland?


There is "xwayland" inside weston. Weston I am using the main branch, 
and I configure and compile and install it with:


./autogen.sh --prefix=$HOME/install --disable-setuid-install 
--disable-colord

make
make install

xserver: I am using the xwayland-1.12 branch from 
git://anongit.freedesktop.org/xorg/xserver. Configure/make/install is:


./autogen.sh --prefix=$HOME/install
make
make install

Also I am compiling/installing xserver after xwayland, not sure if 
this is the correct order.


I am rather mystified as to why there is both an xserver and xwayland 
code in weston, any quick explanation would be appreciated.



Did you
build xf86-video-wayland as well?


No, only xf86-video-ati, xf86-video-intel, xf86-video-wlshm. I had to 
compile tons of stuff in order to get xserver to compile, which is 
really annoying. Most of it I suspect is never used.


If I add this, how do I tell the Xserver that it exists? Do I just 
have to install it, or do I have to recomfigure and recompile Xserver?


I am also dubious that this has anything to do with it, as my test 
applications are not using xv.



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 2/2] Update configure and Makefile to support Present XWayland

[Axel Davy]

Signed-off-by: Axel Davy 
---
 configure.ac| 11 +--
 hw/xfree86/xwayland/Makefile.am |  2 +-
 present/Makefile.am | 24 +++-
 3 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 052a557..73468b2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1028,6 +1028,8 @@ if test "x$WAYLAND" = xyes; then
 PKG_CHECK_MODULES(XWAYLAND, $WAYLAND_MODULES)
AC_DEFINE(XORG_WAYLAND, 1, [Support wayland mode])
WAYLAND_SCANNER_RULES(['$(top_srcdir)/hw/xfree86/xwayland'])
+   WAYLAND_INC='-I$(top_srcdir)/hw/xfree86/xwayland'
+   WAYLAND_LIB='$(top_builddir)/hw/xfree86/xwayland/libxwayland.la'
 fi
 AM_CONDITIONAL(WAYLAND, [test "x$WAYLAND" = xyes])
 
@@ -1318,6 +1320,11 @@ if test "x$PRESENT" = xyes; then
SDK_REQUIRED_MODULES="$SDK_REQUIRED_MODULES $PRESENTPROTO"
PRESENT_INC='-I$(top_srcdir)/present'
PRESENT_LIB='$(top_builddir)/present/libpresent.la'
+   if test "x$WAYLAND" = xyes; then
+   
PRESENT_WAYLAND_LIB='$(top_builddir)/present/libpresentwayland.la'
+   else
+   PRESENT_WAYLAND_LIB='$(top_builddir)/present/libpresent.la'
+   fi
 fi
 
 AM_CONDITIONAL(XINERAMA, [test "x$XINERAMA" = xyes])
@@ -1756,7 +1763,7 @@ AC_EGREP_CPP([I_AM_SVR4],[
 AC_DEFINE([SVR4],1,[Define to 1 on systems derived from System V Release 4])
 AC_MSG_RESULT([yes])], AC_MSG_RESULT([no]))
 
-XSERVER_CFLAGS="$XSERVER_CFLAGS $CORE_INCS $XEXT_INC $COMPOSITE_INC 
$DAMAGE_INC $FIXES_INC $XI_INC $MI_INC $MIEXT_SYNC_INC $MIEXT_SHADOW_INC 
$MIEXT_LAYER_INC $MIEXT_DAMAGE_INC $RENDER_INC $RANDR_INC $FB_INC $DBE_INC 
$PRESENT_INC"
+XSERVER_CFLAGS="$XSERVER_CFLAGS $CORE_INCS $XEXT_INC $COMPOSITE_INC 
$DAMAGE_INC $FIXES_INC $XI_INC $MI_INC $MIEXT_SYNC_INC $MIEXT_SHADOW_INC 
$MIEXT_LAYER_INC $MIEXT_DAMAGE_INC $RENDER_INC $RANDR_INC $FB_INC $DBE_INC 
$PRESENT_INC  $WAYLAND_INC"
 
 dnl ---
 dnl DDX section.
@@ -1815,7 +1822,7 @@ if test "x$XORG" = xyes; then
XORG_OSINCS='-I$(top_srcdir)/hw/xfree86/os-support 
-I$(top_srcdir)/hw/xfree86/os-support/bus -I$(top_srcdir)/os'
XORG_INCS="$XORG_DDXINCS $XORG_OSINCS"
XORG_CFLAGS="$XORGSERVER_CFLAGS -DHAVE_XORG_CONFIG_H"
-   XORG_LIBS="$COMPOSITE_LIB $FIXES_LIB $XEXT_LIB $DBE_LIB $RECORD_LIB 
$RANDR_LIB $RENDER_LIB $DAMAGE_LIB $DRI3_LIB $PRESENT_LIB $MIEXT_SYNC_LIB 
$MIEXT_DAMAGE_LIB $XI_LIB $XKB_LIB"
+   XORG_LIBS="$COMPOSITE_LIB $FIXES_LIB $XEXT_LIB $DBE_LIB $RECORD_LIB 
$RANDR_LIB $RENDER_LIB $DAMAGE_LIB $DRI3_LIB $PRESENT_WAYLAND_LIB $WAYLAND_LIB 
$MIEXT_SYNC_LIB $MIEXT_DAMAGE_LIB $XI_LIB $XKB_LIB"
 
dnl ==
dnl symbol visibility
diff --git a/hw/xfree86/xwayland/Makefile.am b/hw/xfree86/xwayland/Makefile.am
index cc45444..ce70bfc 100644
--- a/hw/xfree86/xwayland/Makefile.am
+++ b/hw/xfree86/xwayland/Makefile.am
@@ -6,7 +6,7 @@ AM_CPPFLAGS =   \
-I$(srcdir)/../parser   \
-I$(srcdir)/../modes
 
-libxwayland_la_LTLIBRARIES = libxwayland.la
+noinst_LTLIBRARIES = libxwayland.la
 AM_CFLAGS = \
-DHAVE_XORG_CONFIG_H \
@DIX_CFLAGS@ @XORG_CFLAGS@ @XWAYLAND_CFLAGS@ \
diff --git a/present/Makefile.am b/present/Makefile.am
index 7fea669..1346156 100644
--- a/present/Makefile.am
+++ b/present/Makefile.am
@@ -1,8 +1,9 @@
 noinst_LTLIBRARIES = libpresent.la
-AM_CFLAGS = \
+libpresent_la_CFLAGS = \
-DHAVE_XORG_CONFIG_H \
@DIX_CFLAGS@ @XORG_CFLAGS@
 
+
 libpresent_la_SOURCES = \
present.h \
present.c \
@@ -14,4 +15,25 @@ libpresent_la_SOURCES = \
present_request.c \
present_screen.c
 
+
+if WAYLAND
+noinst_LTLIBRARIES += libpresentwayland.la
+
+libpresentwayland_la_CFLAGS = \
+   -DHAVE_XORG_CONFIG_H \
+   -DPRESENT_WAYLAND\
+   @DIX_CFLAGS@ @XORG_CFLAGS@
+
+libpresentwayland_la_SOURCES = \
+   present.h \
+   present.c \
+   present_event.c \
+   present_fake.c \
+   present_fence.c \
+   present_notify.c \
+   present_priv.h \
+   present_request.c \
+   present_screen.c \
+   present_wayland.c
+endif
 sdk_HEADERS = present.h presentext.h
-- 
1.8.3.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/2] Initial Present Wayland support

[Axel Davy]

Signed-off-by: Axel Davy 
---
 present/present.c |  77 +++
 present/present_priv.h|  37 +++
 present/present_wayland.c | 240 ++
 3 files changed, 333 insertions(+), 21 deletions(-)
 create mode 100644 present/present_wayland.c

diff --git a/present/present.c b/present/present.c
index 30cd3b9..931e8ce 100644
--- a/present/present.c
+++ b/present/present.c
@@ -45,7 +45,7 @@ static struct xorg_list present_flip_queue;
 /*
  * Copies the update region from a pixmap to the target drawable
  */
-static void
+void
 present_copy_region(DrawablePtr drawable,
 PixmapPtr pixmap,
 RegionPtr update,
@@ -167,7 +167,7 @@ present_flip(RRCrtcPtr crtc,
 return (*screen_priv->info->flip) (crtc, event_id, target_msc, pixmap, 
sync_flip);
 }
 
-static void
+void
 present_vblank_notify(present_vblank_ptr vblank, CARD8 kind, CARD8 mode, 
uint64_t ust, uint64_t crtc_msc)
 {
 int n;
@@ -183,7 +183,7 @@ present_vblank_notify(present_vblank_ptr vblank, CARD8 
kind, CARD8 mode, uint64_
 }
 }
 
-static void
+void
 present_pixmap_idle(PixmapPtr pixmap, WindowPtr window, CARD32 serial, struct 
present_fence *present_fence)
 {
 if (present_fence)
@@ -329,7 +329,7 @@ present_set_tree_pixmap_visit(WindowPtr window, pointer 
data)
 return WT_WALKCHILDREN;
 }
 
-static void
+void
 present_set_tree_pixmap(WindowPtr window, PixmapPtr pixmap)
 {
 struct pixmap_visit visit;
@@ -462,7 +462,12 @@ present_check_flip_window (WindowPtr window)
 
 if (screen_priv->unflip_event_id)
 return;
-
+#ifdef PRESENT_WAYLAND
+if (xorgWayland) {
+/* We don't need to do anything */
+return;
+}
+#endif
 if (flip_pending) {
 /*
  * Check pending flip
@@ -663,15 +668,23 @@ present_pixmap(WindowPtr window,
 if (!target_crtc)
 target_crtc = present_get_crtc(window);
 }
+#ifdef PRESENT_WAYLAND
+if (!xorgWayland) {
+#endif
+present_get_ust_msc(window, target_crtc, &ust, &crtc_msc);
 
-present_get_ust_msc(window, target_crtc, &ust, &crtc_msc);
-
-target_msc = present_window_to_crtc_msc(window, target_crtc, window_msc, 
crtc_msc);
-
-/* Stash the current MSC away in case we need it later
- */
-window_priv->msc = crtc_msc;
+target_msc = present_window_to_crtc_msc(window, target_crtc, 
window_msc, crtc_msc);
 
+/* Stash the current MSC away in case we need it later
+ */
+window_priv->msc = crtc_msc;
+#ifdef PRESENT_WAYLAND
+} else {
+/* for now msc is a per-window thing for XWayland */
+crtc_msc = window_priv->msc;
+target_msc = window_msc;
+}
+#endif
 /* Adjust target_msc to match modulus
  */
 if (crtc_msc >= target_msc) {
@@ -686,7 +699,11 @@ present_pixmap(WindowPtr window,
 }
 } else {
 target_msc = crtc_msc;
+#ifdef PRESENT_WAYLAND
+if (!xorgWayland && !(options & PresentOptionAsync))
+#else
 if (!(options & PresentOptionAsync))
+#endif
 target_msc++;
 }
 }
@@ -760,16 +777,25 @@ present_pixmap(WindowPtr window,
 vblank->msc_offset = window_priv->msc_offset;
 vblank->notifies = notifies;
 vblank->num_notifies = num_notifies;
+#ifdef PRESENT_WAYLAND
+if (xorgWayland) {
+if (crtc_msc >= target_msc)
+vblank->flip_allowed = FALSE;
+else
+vblank->flip_allowed = TRUE;
+} else {
+#endif
+if (!screen_priv->info || !(screen_priv->info->capabilities & 
PresentCapabilityAsync))
+vblank->sync_flip = TRUE;
 
-if (!screen_priv->info || !(screen_priv->info->capabilities & 
PresentCapabilityAsync))
-vblank->sync_flip = TRUE;
-
-if (pixmap && present_check_flip (target_crtc, window, pixmap, 
vblank->sync_flip, valid, x_off, y_off)) {
-vblank->flip = TRUE;
-if (vblank->sync_flip)
-target_msc--;
+if (pixmap && present_check_flip (target_crtc, window, pixmap, 
vblank->sync_flip, valid, x_off, y_off)) {
+vblank->flip = TRUE;
+if (vblank->sync_flip)
+target_msc--;
+}
+#ifdef PRESENT_WAYLAND
 }
-
+#endif
 if (wait_fence) {
 vblank->wait_fence = present_fence_create(wait_fence);
 if (!vblank->wait_fence)
@@ -788,8 +814,17 @@ present_pixmap(WindowPtr window,
   vblank->pixmap->drawable.id, vblank->window->drawable.id,
   target_crtc));
 
-xorg_list_add(&vblank->event_queue, &present_exec_queue);
 vblank->queued = TRUE;
+
+#ifdef PRESENT_WAYLAND
+if (xorgWayland) {
+present_wayland_execute(vblank);
+return Success;
+}
+#endif
+
+xorg

[PATCH 4/4 v4] Add XWayland API with Present support in mind.

[Axel Davy]

The API enables to use the frame event and the buffer event.

Signed-off-by: Axel Davy 
---
 hw/xfree86/xwayland/Makefile.am|   1 +
 hw/xfree86/xwayland/xwayland-events.c  | 220 +
 hw/xfree86/xwayland/xwayland-private.h |   9 ++
 hw/xfree86/xwayland/xwayland-window.c  |   6 +
 hw/xfree86/xwayland/xwayland.h |  15 +++
 5 files changed, 251 insertions(+)
 create mode 100644 hw/xfree86/xwayland/xwayland-events.c

diff --git a/hw/xfree86/xwayland/Makefile.am b/hw/xfree86/xwayland/Makefile.am
index 22ab154..cc45444 100644
--- a/hw/xfree86/xwayland/Makefile.am
+++ b/hw/xfree86/xwayland/Makefile.am
@@ -21,6 +21,7 @@ libxwayland_la_SOURCES =  \
xwayland-output.c   \
xwayland-cursor.c   \
xwayland-window.c   \
+   xwayland-events.c   \
xwayland-private.h  \
drm-client-protocol.h   \
drm-protocol.c  \
diff --git a/hw/xfree86/xwayland/xwayland-events.c 
b/hw/xfree86/xwayland/xwayland-events.c
new file mode 100644
index 000..d41b6eb
--- /dev/null
+++ b/hw/xfree86/xwayland/xwayland-events.c
@@ -0,0 +1,220 @@
+/*
+ * Copyright © 2014 Axel Davy
+ *
+ * Permission to use, copy, modify, distribute, and sell this software
+ * and its documentation for any purpose is hereby granted without
+ * fee, provided that the above copyright notice appear in all copies
+ * and that both that copyright notice and this permission notice
+ * appear in supporting documentation, and that the name of the
+ * copyright holders not be used in advertising or publicity
+ * pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no
+ * representations about the suitability of this software for any
+ * purpose.  It is provided "as is" without express or implied
+ * warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+ * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
+ * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+ * SOFTWARE.
+ */
+
+
+#include 
+
+#include 
+#include 
+
+#include 
+#include "xwayland.h"
+#include "xwayland-private.h"
+
+
+/*
+ * Handling of frame events and buffer events.
+ * API to use them
+ */
+
+struct _todo
+{
+union
+{
+   todo_func_frame tff;
+   todo_func_buffer tfb;
+} tocall;
+void *args;
+struct wl_list link;
+struct wl_list link_bis;
+};
+
+static void
+event_todo_free(struct wl_list *todo_list, int is_buffer_todo)
+{
+struct _todo *pos, *tmp;
+wl_list_for_each_safe(pos, tmp, todo_list, link) {
+   wl_list_remove(&pos->link);
+   if (is_buffer_todo)
+   wl_list_remove(&pos->link_bis);
+   free(pos);
+}
+}
+
+static const struct wl_callback_listener frame_listener;
+
+static void
+frame_listener_callback(void *data,
+   struct wl_callback *callback, uint32_t time)
+{
+struct xwl_window *xwl_window = data;
+struct wl_list todo_list;
+struct _todo *todo;
+
+wl_callback_destroy(xwl_window->frame_callback);
+xwl_window->frame_callback = wl_surface_frame(xwl_window->surface);
+wl_callback_add_listener(xwl_window->frame_callback,
+&frame_listener, xwl_window);
+
+if (wl_list_empty(&xwl_window->frame_todo))
+   return;
+
+/* todo funcs are able to ask to be recalled */
+
+wl_list_init(&todo_list);
+wl_list_insert_list(&todo_list, &xwl_window->frame_todo);
+wl_list_init(&xwl_window->frame_todo);
+wl_list_for_each(todo, &todo_list, link)
+   todo->tocall.tff(0, time, todo->args);
+event_todo_free(&todo_list, 0);
+
+/* We need to commit to let the compositor know the new frame callback */
+if (!wl_list_empty(&xwl_window->frame_todo))
+   wl_surface_commit(xwl_window->surface);
+}
+
+
+
+static const struct wl_callback_listener frame_listener = {
+frame_listener_callback
+};
+
+
+static void
+wl_buffer_release_event(void *data, struct wl_buffer *buffer)
+{
+struct xwl_pixmap *xwl_pixmap = data;
+struct wl_list todo_list;
+struct _todo *todo;
+
+if (wl_list_empty(&xwl_pixmap->buffer_todo))
+   return;
+wl_list_init(&todo_list);
+wl_list_insert_list(&todo_list, &xwl_pixmap->buffer_todo);
+wl_list_init(&xwl_pixmap->buffer_todo);
+wl_list_for_each(todo, &todo_list, link)
+   todo->tocall.tfb(0, tod

[PATCH 1/2] XWAYLAND Present support

[Axel Davy]

Hi,

These patches are to enable Present support with XWayland.

While Present has a fallback mode for DDX not implementing
the helper functions for Present, and that this callback
can be used with XWayland, this new implementation (for 
XWayland) is more adapted to Wayland, and is able
to avoid copies if the gl content fills the window (like
standart Present support when the window is fullscreen).

Something that can be improved with this implementation
is the behaviour at swap_interval=0 (no vsync). Right now
it copies the content of the presented pixmap to the window
pixmap, which means tearings. (but with vsync,
you can have flips and avoid tearings).
Something clever can be done, which would remove the tearings
in this situation, but since it's more complicated, I wanted
first to release this implementation.

A difficult thing was to handle correctly the Window destruction
while a flip had been done, and it needed a change to the 
XWayland API change I proposed, that's why I post a new one
that is more adapted.

Don't hesitate to give comments.

Axel Davy (3):
  Add XWayland API with Present support in mind.
  Initial Present Wayland support
  Update configure and Makefile to support Present XWayland

 configure.ac   |  11 +-
 hw/xfree86/xwayland/Makefile.am|   3 +-
 hw/xfree86/xwayland/xwayland-events.c  | 220 ++
 hw/xfree86/xwayland/xwayland-private.h |   9 ++
 hw/xfree86/xwayland/xwayland-window.c  |   6 +
 hw/xfree86/xwayland/xwayland.h |  15 +++
 present/Makefile.am|  24 +++-
 present/present.c  |  77 ---
 present/present_priv.h |  37 +
 present/present_wayland.c  | 240 +
 10 files changed, 617 insertions(+), 25 deletions(-)
 create mode 100644 hw/xfree86/xwayland/xwayland-events.c
 create mode 100644 present/present_wayland.c

-- 
1.8.3.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 4/4 v3] Add XWayland API with Present support in mind.

[Axel Davy]

The API enables to use the frame event and the buffer event.

Signed-off-by: Axel Davy 
---
v3: remove the reversal of the frame_todo list, but instead fill it it
reverse order. The code has been tested with an experimental XWayland
Present support.
v2: fix indentation + move a call from patch 1 to here + add a missing call
 hw/xfree86/xwayland/Makefile.am|   1 +
 hw/xfree86/xwayland/xwayland-events.c  | 208 +
 hw/xfree86/xwayland/xwayland-private.h |   8 ++
 hw/xfree86/xwayland/xwayland-window.c  |   6 +
 hw/xfree86/xwayland/xwayland.h |  14 +++
 5 files changed, 237 insertions(+)
 create mode 100644 hw/xfree86/xwayland/xwayland-events.c

diff --git a/hw/xfree86/xwayland/Makefile.am b/hw/xfree86/xwayland/Makefile.am
index 22ab154..cc45444 100644
--- a/hw/xfree86/xwayland/Makefile.am
+++ b/hw/xfree86/xwayland/Makefile.am
@@ -21,6 +21,7 @@ libxwayland_la_SOURCES =  \
xwayland-output.c   \
xwayland-cursor.c   \
xwayland-window.c   \
+   xwayland-events.c   \
xwayland-private.h  \
drm-client-protocol.h   \
drm-protocol.c  \
diff --git a/hw/xfree86/xwayland/xwayland-events.c 
b/hw/xfree86/xwayland/xwayland-events.c
new file mode 100644
index 000..aa55573
--- /dev/null
+++ b/hw/xfree86/xwayland/xwayland-events.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright © 2014 Axel Davy
+ *
+ * Permission to use, copy, modify, distribute, and sell this software
+ * and its documentation for any purpose is hereby granted without
+ * fee, provided that the above copyright notice appear in all copies
+ * and that both that copyright notice and this permission notice
+ * appear in supporting documentation, and that the name of the
+ * copyright holders not be used in advertising or publicity
+ * pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no
+ * representations about the suitability of this software for any
+ * purpose.  It is provided "as is" without express or implied
+ * warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+ * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
+ * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+ * SOFTWARE.
+ */
+
+
+#include 
+
+#include 
+#include 
+
+#include 
+#include "xwayland.h"
+#include "xwayland-private.h"
+
+
+/*
+ * Handling of frame events and buffer events.
+ * API to use them
+ */
+
+struct _todo
+{
+union
+{
+   todo_func_frame tff;
+   todo_func_buffer tfb;
+} tocall;
+void *args;
+struct wl_list link;
+};
+
+static void
+event_todo_free(struct wl_list *todo_list)
+{
+struct _todo *pos, *tmp;
+wl_list_for_each_safe(pos, tmp, todo_list, link) {
+   wl_list_remove(&pos->link);
+   free(pos);
+}
+}
+
+static const struct wl_callback_listener frame_listener;
+
+static void
+frame_listener_callback(void *data,
+   struct wl_callback *callback, uint32_t time)
+{
+struct xwl_window *xwl_window = data;
+struct wl_list todo_list;
+struct _todo *todo;
+
+wl_callback_destroy(xwl_window->frame_callback);
+xwl_window->frame_callback = wl_surface_frame(xwl_window->surface);
+wl_callback_add_listener(xwl_window->frame_callback,
+&frame_listener, xwl_window);
+
+if (wl_list_empty(&xwl_window->frame_todo))
+   return;
+
+/* todo funcs are able to ask to be recalled */
+
+wl_list_init(&todo_list);
+wl_list_insert_list(&todo_list, &xwl_window->frame_todo);
+wl_list_init(&xwl_window->frame_todo);
+wl_list_for_each(todo, &todo_list, link)
+   todo->tocall.tff(0, time, todo->args);
+event_todo_free(&todo_list);
+
+/* We need to commit to let the compositor know the new frame callback */
+if (!wl_list_empty(&xwl_window->frame_todo))
+   wl_surface_commit(xwl_window->surface);
+}
+
+
+
+static const struct wl_callback_listener frame_listener = {
+frame_listener_callback
+};
+
+
+static void
+wl_buffer_release_event(void *data, struct wl_buffer *buffer)
+{
+struct xwl_pixmap *xwl_pixmap = data;
+struct wl_list todo_list;
+struct _todo *todo;
+
+if (wl_list_empty(&xwl_pixmap->buffer_todo))
+   return;
+wl_list_init(&todo_list);
+wl_list_insert_list(&todo_list, &xwl_pixmap->buffer_todo);
+wl_list_init(&xwl_pixmap-&

[PATCH 3/4 v2] Add function to get new fd of the graphic device

[Axel Davy]

neccessary for dri3

Signed-off-by: Axel Davy 
---
v2: fix indentation
 hw/xfree86/xwayland/xwayland-drm.c | 56 --
 hw/xfree86/xwayland/xwayland.h |  3 ++
 2 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/hw/xfree86/xwayland/xwayland-drm.c 
b/hw/xfree86/xwayland/xwayland-drm.c
index 076fb68..12011bf 100644
--- a/hw/xfree86/xwayland/xwayland-drm.c
+++ b/hw/xfree86/xwayland/xwayland-drm.c
@@ -157,49 +157,63 @@ is_fd_render_node(int fd)
 }
 
 int
-xwl_drm_pre_init(struct xwl_screen *xwl_screen)
+xwl_device_get_fd(struct xwl_screen *xwl_screen)
 {
 uint32_t magic;
+int fd;
 
-xwl_screen->drm_registry = wl_display_get_registry(xwl_screen->display);
-wl_registry_add_listener(xwl_screen->drm_registry, &drm_listener,
-xwl_screen);
-
-/* Ensure drm_handler has seen all the interfaces */
-wl_display_roundtrip(xwl_screen->display);
-/* Ensure the xwl_drm_listener has seen the drm device, if any */
-wl_display_roundtrip(xwl_screen->display);
-
-ErrorF("wayland_drm_screen_init, device name %s\n",
-  xwl_screen->device_name);
-
-xwl_screen->drm_fd = open(xwl_screen->device_name, O_RDWR);
-if (xwl_screen->drm_fd < 0) {
+fd = open(xwl_screen->device_name, O_RDWR);
+if (fd < 0) {
ErrorF("failed to open the drm fd\n");
-   return BadAccess;
+   return -1;
 }
 
-if (!is_fd_render_node(xwl_screen->drm_fd)) {
+if (!is_fd_render_node(fd)) {
 
-   if (drmGetMagic(xwl_screen->drm_fd, &magic)) {
+   if (drmGetMagic(fd, &magic)) {
ErrorF("failed to get drm magic");
-   return BadAccess;
+   close (fd);
+   return -1;
}
 
wl_drm_authenticate(xwl_screen->drm, magic);
 
wl_display_roundtrip(xwl_screen->display);
 
-   ErrorF("opened drm fd: %d\n", xwl_screen->drm_fd);
+   ErrorF("opened drm fd: %d\n", fd);
 
if (!xwl_screen->authenticated) {
ErrorF("Failed to auth drm fd\n");
-   return BadAccess;
+   close (fd);
+   return -1;
}
 } else {
xwl_screen->authenticated = 1;
 }
 
+return fd;
+}
+
+int
+xwl_drm_pre_init(struct xwl_screen *xwl_screen)
+{
+xwl_screen->drm_registry = wl_display_get_registry(xwl_screen->display);
+wl_registry_add_listener(xwl_screen->drm_registry, &drm_listener,
+ xwl_screen);
+
+/* Ensure drm_handler has seen all the interfaces */
+wl_display_roundtrip(xwl_screen->display);
+/* Ensure the xwl_drm_listener has seen the drm device, if any */
+wl_display_roundtrip(xwl_screen->display);
+
+ErrorF("wayland_drm_screen_init, device name %s\n",
+  xwl_screen->device_name);
+
+xwl_screen->drm_fd = xwl_device_get_fd(xwl_screen);
+if (xwl_screen->drm_fd < 0) {
+   return BadAccess;
+}
+
 return Success;
 }
 
diff --git a/hw/xfree86/xwayland/xwayland.h b/hw/xfree86/xwayland/xwayland.h
index 8e484a1..c380618 100644
--- a/hw/xfree86/xwayland/xwayland.h
+++ b/hw/xfree86/xwayland/xwayland.h
@@ -76,6 +76,9 @@ xwl_drm_authenticate(ClientPtr client, struct xwl_screen 
*xwl_screen,
 uint32_t magic);
 
 extern _X_EXPORT int
+xwl_device_get_fd(struct xwl_screen *xwl_screen);
+
+extern _X_EXPORT int
 xwl_create_window_buffer_drm(struct xwl_window *xwl_window,
 PixmapPtr pixmap, uint32_t name);
 
-- 
1.8.3.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/4 v2] Move the wl_buffer from xwl_window to xwl_pixmap

[Axel Davy]

This change enables to change the window pixmap, and have
xwayland send the correct buffer to the Wayland compositor.

Signed-off-by: Axel Davy 
---
v2: fix indentation and remove a call that had to be in patch 4
 hw/xfree86/xwayland/xwayland-drm.c | 10 +++-
 hw/xfree86/xwayland/xwayland-private.h | 10 +++-
 hw/xfree86/xwayland/xwayland-window.c  | 83 +-
 hw/xfree86/xwayland/xwayland.c | 38 ++--
 4 files changed, 113 insertions(+), 28 deletions(-)

diff --git a/hw/xfree86/xwayland/xwayland-drm.c 
b/hw/xfree86/xwayland/xwayland-drm.c
index 5250857..30ec176 100644
--- a/hw/xfree86/xwayland/xwayland-drm.c
+++ b/hw/xfree86/xwayland/xwayland-drm.c
@@ -217,6 +217,7 @@ xwl_create_window_buffer_drm(struct xwl_window *xwl_window,
 VisualID visual;
 WindowPtr window = xwl_window->window;
 ScreenPtr screen = window->drawable.pScreen;
+struct wl_buffer *buffer;
 uint32_t format;
 int i;
 
@@ -238,7 +239,7 @@ xwl_create_window_buffer_drm(struct xwl_window *xwl_window,
 break;
 }
 
-xwl_window->buffer =
+buffer =
   wl_drm_create_buffer(xwl_window->xwl_screen->drm,
   name,
   pixmap->drawable.width,
@@ -246,5 +247,10 @@ xwl_create_window_buffer_drm(struct xwl_window *xwl_window,
   pixmap->devKind,
   format);
 
-return xwl_window->buffer ? Success : BadDrawable;
+if (!buffer)
+   return BadDrawable;
+
+xwl_pixmap_attach_buffer(pixmap, buffer);
+
+return Success;
 }
diff --git a/hw/xfree86/xwayland/xwayland-private.h 
b/hw/xfree86/xwayland/xwayland-private.h
index bdecf8a..853ab3b 100644
--- a/hw/xfree86/xwayland/xwayland-private.h
+++ b/hw/xfree86/xwayland/xwayland-private.h
@@ -29,13 +29,16 @@
 struct xwl_window {
 struct xwl_screen  *xwl_screen;
 struct wl_surface  *surface;
-struct wl_buffer   *buffer;
 WindowPtr   window;
 DamagePtr   damage;
 struct xorg_listlink;
 struct xorg_listlink_damage;
 };
 
+struct xwl_pixmap {
+struct wl_buffer   *buffer;
+};
+
 struct xwl_output;
 
 struct xwl_screen {
@@ -72,6 +75,7 @@ struct xwl_screen {
 RealizeWindowProcPtrRealizeWindow;
 UnrealizeWindowProcPtr  UnrealizeWindow;
 SetWindowPixmapProcPtr  SetWindowPixmap;
+DestroyPixmapProcPtrDestroyPixmap;
 MoveWindowProcPtr   MoveWindow;
 miPointerSpriteFuncPtr  sprite_funcs;
 };
@@ -135,6 +139,10 @@ void xwl_seat_set_cursor(struct xwl_seat *xwl_seat);
 
 void xwl_output_remove(struct xwl_output *output);
 
+void xwl_pixmap_attach_buffer(PixmapPtr pixmap, struct wl_buffer *buffer);
+struct xwl_pixmap *xwl_window_get_buffer(struct xwl_window *xwl_window);
+struct xwl_window *get_xwl_window(WindowPtr window);
+
 extern const struct xserver_listener xwl_server_listener;
 
 #endif /* _XWAYLAND_PRIVATE_H_ */
diff --git a/hw/xfree86/xwayland/xwayland-window.c 
b/hw/xfree86/xwayland/xwayland-window.c
index a2a8206..1e6c09b 100644
--- a/hw/xfree86/xwayland/xwayland-window.c
+++ b/hw/xfree86/xwayland/xwayland-window.c
@@ -41,6 +41,13 @@
 #include "xserver-client-protocol.h"
 
 static DevPrivateKeyRec xwl_window_private_key;
+static DevPrivateKeyRec xwl_pixmap_private_key;
+
+struct xwl_window *
+get_xwl_window(WindowPtr window)
+{
+return dixLookupPrivate(&window->devPrivates, &xwl_window_private_key);
+}
 
 static void
 free_pixmap(void *data, struct wl_callback *callback, uint32_t time)
@@ -56,25 +63,38 @@ static const struct wl_callback_listener 
free_pixmap_listener = {
free_pixmap,
 };
 
+void
+xwl_pixmap_attach_buffer(PixmapPtr pixmap, struct wl_buffer *buffer)
+{
+struct xwl_pixmap *xwl_pixmap = calloc(sizeof *xwl_pixmap, 1);
+if (!xwl_pixmap) {
+   wl_buffer_destroy(buffer);
+   return;
+}
+xwl_pixmap->buffer = buffer;
+dixSetPrivate(&pixmap->devPrivates, &xwl_pixmap_private_key, xwl_pixmap);
+}
+
 static void
 xwl_window_attach(struct xwl_window *xwl_window, PixmapPtr pixmap)
 {
 struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
 struct wl_callback *callback;
+struct xwl_pixmap *xwl_pixmap =
+   dixLookupPrivate(&pixmap->devPrivates, &xwl_pixmap_private_key);
 
-/* We can safely destroy the buffer because we only use one buffer
- * per surface in xwayland model */
-if (xwl_window->buffer)
-wl_buffer_destroy(xwl_window->buffer);
-
-xwl_screen->driver->create_window_buffer(xwl_window, pixmap);
+if (!xwl_pixmap) {
+   xwl_screen->driver->create_window_buffer(xwl_window, pixmap);
+   xwl_pixmap =
+   dixLookupPrivate(&pixmap->devPrivates, &xwl_pixmap_private_key);
 
-if (!xwl_window->buffer) {
-ErrorF("failed 

[PATCH 2/4 v2] Add support to render-nodes.

[Axel Davy]

And allows to create wl_buffers from fds instead of gem names.

Signed-off-by: Axel Davy 
---
v2: fix indentation
 hw/xfree86/xwayland/drm.xml|  45 +-
 hw/xfree86/xwayland/xwayland-drm.c | 108 +
 hw/xfree86/xwayland/xwayland-private.h |   1 +
 hw/xfree86/xwayland/xwayland.h |   7 +++
 4 files changed, 147 insertions(+), 14 deletions(-)

diff --git a/hw/xfree86/xwayland/drm.xml b/hw/xfree86/xwayland/drm.xml
index 89fd8f0..8a3ad69 100644
--- a/hw/xfree86/xwayland/drm.xml
+++ b/hw/xfree86/xwayland/drm.xml
@@ -29,7 +29,7 @@
 
   
-  
+  
 
   
   
@@ -119,6 +119,38 @@
   
 
 
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+
 
 
+
+
+  
+Bitmask of capabilities.
+  
+  
+
+
+
+  
+
   
 
 
diff --git a/hw/xfree86/xwayland/xwayland-drm.c 
b/hw/xfree86/xwayland/xwayland-drm.c
index 30ec176..076fb68 100644
--- a/hw/xfree86/xwayland/xwayland-drm.c
+++ b/hw/xfree86/xwayland/xwayland-drm.c
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -99,11 +100,20 @@ drm_handle_authenticated (void *data, struct wl_drm *drm)
 }
 }
 
+static void
+drm_handle_capabilities(void *data, struct wl_drm *drm, uint32_t value)
+{
+struct xwl_screen *xwl_screen = data;
+
+xwl_screen->drm_capabilities = value;
+}
+
 static const struct wl_drm_listener xwl_drm_listener =
 {
 drm_handle_device,
 drm_handle_format,
-drm_handle_authenticated
+drm_handle_authenticated,
+drm_handle_capabilities
 };
 
 static void
@@ -114,7 +124,7 @@ drm_handler(void *data, struct wl_registry *registry, 
uint32_t id,
 
 if (strcmp (interface, "wl_drm") == 0) {
xwl_screen->drm = wl_registry_bind(xwl_screen->registry, id,
-   &wl_drm_interface, 1);
+   &wl_drm_interface, 2);
wl_drm_add_listener(xwl_screen->drm, &xwl_drm_listener, xwl_screen);
 }
 }
@@ -130,6 +140,22 @@ static const struct wl_registry_listener drm_listener = {
 global_remove
 };
 
+static char
+is_fd_render_node(int fd)
+{
+struct stat render;
+
+if (fstat(fd, &render))
+   return 0;
+
+if (!S_ISCHR(render.st_mode))
+   return 0;
+
+if (render.st_rdev & 0x80)
+   return 1;
+return 0;
+}
+
 int
 xwl_drm_pre_init(struct xwl_screen *xwl_screen)
 {
@@ -137,7 +163,7 @@ xwl_drm_pre_init(struct xwl_screen *xwl_screen)
 
 xwl_screen->drm_registry = wl_display_get_registry(xwl_screen->display);
 wl_registry_add_listener(xwl_screen->drm_registry, &drm_listener,
- xwl_screen);
+xwl_screen);
 
 /* Ensure drm_handler has seen all the interfaces */
 wl_display_roundtrip(xwl_screen->display);
@@ -153,20 +179,25 @@ xwl_drm_pre_init(struct xwl_screen *xwl_screen)
return BadAccess;
 }
 
-if (drmGetMagic(xwl_screen->drm_fd, &magic)) {
-   ErrorF("failed to get drm magic");
-   return BadAccess;
-}
+if (!is_fd_render_node(xwl_screen->drm_fd)) {
 
-wl_drm_authenticate(xwl_screen->drm, magic);
+   if (drmGetMagic(xwl_screen->drm_fd, &magic)) {
+   ErrorF("failed to get drm magic");
+   return BadAccess;
+   }
 
-wl_display_roundtrip(xwl_screen->display);
+   wl_drm_authenticate(xwl_screen->drm, magic);
 
-ErrorF("opened drm fd: %d\n", xwl_screen->drm_fd);
+   wl_display_roundtrip(xwl_screen->display);
 
-if (!xwl_screen->authenticated) {
-   ErrorF("Failed to auth drm fd\n");
-   return BadAccess;
+   ErrorF("opened drm fd: %d\n", xwl_screen->drm_fd);
+
+   if (!xwl_screen->authenticated) {
+   ErrorF("Failed to auth drm fd\n");
+   return BadAccess;
+   }
+} else {
+   xwl_screen->authenticated = 1;
 }
 
 return Success;
@@ -177,6 +208,11 @@ Bool xwl_drm_initialised(struct xwl_screen *xwl_screen)
 return xwl_screen->authenticated;
 }
 
+Bool xwl_drm_prime_able(struct xwl_screen *xwl_screen)
+{
+return xwl_screen->drm_capabilities & WL_DRM_CAPABILITY_PRIME;
+}
+
 int xwl_screen_get_drm_fd(struct xwl_screen *xwl_screen)
 {
 return xwl_screen->drm_fd;
@@ -254,3 +290,49 @@ xwl_create_window_buffer_drm(struct xwl_window *xwl_window,
 
 return Success;
 }
+
+int
+xwl_create_window_buffer_drm_from_fd(struct xwl_window *xwl_window,
+PixmapPtr pixmap, int fd)
+{
+VisualID visual;
+WindowPtr window = xwl_window->window;
+ScreenPtr screen = window->drawable.pScreen;
+struct wl_buffer *buf

[PATCH 4/4 v2] Add XWayland API with Present support in mind.

[Axel Davy]

The API enables to use the frame event and the buffer event.

Signed-off-by: Axel Davy 
---
v2: fix indentation + move a call from patch 1 to here + add a missing call
 hw/xfree86/xwayland/Makefile.am|   1 +
 hw/xfree86/xwayland/xwayland-events.c  | 216 +
 hw/xfree86/xwayland/xwayland-private.h |   8 ++
 hw/xfree86/xwayland/xwayland-window.c  |   6 +
 hw/xfree86/xwayland/xwayland.h |  14 +++
 5 files changed, 245 insertions(+)
 create mode 100644 hw/xfree86/xwayland/xwayland-events.c

diff --git a/hw/xfree86/xwayland/Makefile.am b/hw/xfree86/xwayland/Makefile.am
index 22ab154..cc45444 100644
--- a/hw/xfree86/xwayland/Makefile.am
+++ b/hw/xfree86/xwayland/Makefile.am
@@ -21,6 +21,7 @@ libxwayland_la_SOURCES =  \
xwayland-output.c   \
xwayland-cursor.c   \
xwayland-window.c   \
+   xwayland-events.c   \
xwayland-private.h  \
drm-client-protocol.h   \
drm-protocol.c  \
diff --git a/hw/xfree86/xwayland/xwayland-events.c 
b/hw/xfree86/xwayland/xwayland-events.c
new file mode 100644
index 000..3a986bf
--- /dev/null
+++ b/hw/xfree86/xwayland/xwayland-events.c
@@ -0,0 +1,216 @@
+/*
+ * Copyright © 2014 Axel Davy
+ *
+ * Permission to use, copy, modify, distribute, and sell this software
+ * and its documentation for any purpose is hereby granted without
+ * fee, provided that the above copyright notice appear in all copies
+ * and that both that copyright notice and this permission notice
+ * appear in supporting documentation, and that the name of the
+ * copyright holders not be used in advertising or publicity
+ * pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no
+ * representations about the suitability of this software for any
+ * purpose.  It is provided "as is" without express or implied
+ * warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+ * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
+ * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+ * SOFTWARE.
+ */
+
+
+#include 
+
+#include 
+#include 
+
+#include 
+#include "xwayland.h"
+#include "xwayland-private.h"
+
+
+/*
+ * Handling of frame events and buffer events.
+ * API to use them
+ */
+
+struct _todo
+{
+union
+{
+   todo_func_frame tff;
+   todo_func_buffer tfb;
+} tocall;
+void *args;
+struct wl_list link;
+};
+
+static void
+event_todo_free(struct wl_list *todo_list)
+{
+struct _todo *pos, *tmp;
+wl_list_for_each_safe(pos, tmp, todo_list, link) {
+   wl_list_remove(&pos->link);
+   free(pos);
+}
+}
+
+static const struct wl_callback_listener frame_listener;
+
+static void
+frame_listener_callback(void *data,
+   struct wl_callback *callback, uint32_t time)
+{
+struct xwl_window *xwl_window = data;
+struct wl_list todo_list;
+struct _todo *todo;
+
+wl_callback_destroy(xwl_window->frame_callback);
+xwl_window->frame_callback = wl_surface_frame(xwl_window->surface);
+wl_callback_add_listener(xwl_window->frame_callback,
+&frame_listener, xwl_window);
+
+if (wl_list_empty(&xwl_window->frame_todo))
+   return;
+
+/* todo funcs are able to ask to be recalled */
+
+wl_list_init(&todo_list);
+wl_list_insert_list(&todo_list, &xwl_window->frame_todo);
+wl_list_init(&xwl_window->frame_todo);
+wl_list_for_each(todo, &todo_list, link)
+   todo->tocall.tff(0, time, todo->args);
+event_todo_free(&todo_list);
+
+/* We need to commit to let the compositor know the new frame callback */
+if (!wl_list_empty(&xwl_window->frame_todo)) {
+   /* reverse the list. It is useful to keep the order between two
+* waiting functions that keep adding themselves to the todo list */
+   wl_list_init(&todo_list);
+   wl_list_insert_list(&todo_list, &xwl_window->frame_todo);
+   wl_list_init(&xwl_window->frame_todo);
+   wl_list_for_each(todo, &todo_list, link)
+   wl_list_insert(&xwl_window->frame_todo, &todo->link);
+   wl_surface_commit(xwl_window->surface);
+}
+}
+
+
+
+static const struct wl_callback_listener frame_listener = {
+frame_listener_callback
+};
+
+
+static void
+wl_buffer_release_event(void *data, struct wl_buffer *buffer)
+{
+struct xwl_pix

[PATCH 2/4] Add support to render-nodes.

[Axel Davy]

And allows to create wl_buffers from fds instead of gem names.

Signed-off-by: Axel Davy 
---
 hw/xfree86/xwayland/drm.xml|  45 +-
 hw/xfree86/xwayland/xwayland-drm.c | 106 +
 hw/xfree86/xwayland/xwayland-private.h |   1 +
 hw/xfree86/xwayland/xwayland.h |   7 +++
 4 files changed, 146 insertions(+), 13 deletions(-)

diff --git a/hw/xfree86/xwayland/drm.xml b/hw/xfree86/xwayland/drm.xml
index 89fd8f0..8a3ad69 100644
--- a/hw/xfree86/xwayland/drm.xml
+++ b/hw/xfree86/xwayland/drm.xml
@@ -29,7 +29,7 @@
 
   
-  
+  
 
   
   
@@ -119,6 +119,38 @@
   
 
 
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+
 
 
+
+
+  
+Bitmask of capabilities.
+  
+  
+
+
+
+  
+
   
 
 
diff --git a/hw/xfree86/xwayland/xwayland-drm.c 
b/hw/xfree86/xwayland/xwayland-drm.c
index a52449d..c01fdb3 100644
--- a/hw/xfree86/xwayland/xwayland-drm.c
+++ b/hw/xfree86/xwayland/xwayland-drm.c
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -99,11 +100,20 @@ drm_handle_authenticated (void *data, struct wl_drm *drm)
 }
 }
 
+static void
+drm_handle_capabilities(void *data, struct wl_drm *drm, uint32_t value)
+{
+struct xwl_screen *xwl_screen = data;
+
+xwl_screen->drm_capabilities = value;
+}
+
 static const struct wl_drm_listener xwl_drm_listener =
 {
 drm_handle_device,
 drm_handle_format,
-drm_handle_authenticated
+drm_handle_authenticated,
+drm_handle_capabilities
 };
 
 static void
@@ -114,7 +124,7 @@ drm_handler(void *data, struct wl_registry *registry, 
uint32_t id,
 
 if (strcmp (interface, "wl_drm") == 0) {
xwl_screen->drm = wl_registry_bind(xwl_screen->registry, id,
-   &wl_drm_interface, 1);
+   &wl_drm_interface, 2);
wl_drm_add_listener(xwl_screen->drm, &xwl_drm_listener, xwl_screen);
 }
 }
@@ -130,6 +140,22 @@ static const struct wl_registry_listener drm_listener = {
 global_remove
 };
 
+static char
+is_fd_render_node(int fd)
+{
+struct stat render;
+
+if (fstat(fd, &render))
+   return 0;
+
+if (!S_ISCHR(render.st_mode))
+   return 0;
+
+if (render.st_rdev & 0x80)
+   return 1;
+return 0;
+}
+
 int
 xwl_drm_pre_init(struct xwl_screen *xwl_screen)
 {
@@ -153,20 +179,25 @@ xwl_drm_pre_init(struct xwl_screen *xwl_screen)
return BadAccess;
 }
 
-if (drmGetMagic(xwl_screen->drm_fd, &magic)) {
-   ErrorF("failed to get drm magic");
-   return BadAccess;
-}
+if (!is_fd_render_node(xwl_screen->drm_fd)) {
 
-wl_drm_authenticate(xwl_screen->drm, magic);
+   if (drmGetMagic(xwl_screen->drm_fd, &magic)) {
+   ErrorF("failed to get drm magic");
+   return BadAccess;
+}
 
-wl_display_roundtrip(xwl_screen->display);
+   wl_drm_authenticate(xwl_screen->drm, magic);
 
-ErrorF("opened drm fd: %d\n", xwl_screen->drm_fd);
+   wl_display_roundtrip(xwl_screen->display);
 
-if (!xwl_screen->authenticated) {
-   ErrorF("Failed to auth drm fd\n");
-   return BadAccess;
+   ErrorF("opened drm fd: %d\n", xwl_screen->drm_fd);
+
+   if (!xwl_screen->authenticated) {
+   ErrorF("Failed to auth drm fd\n");
+   return BadAccess;
+}
+} else {
+   xwl_screen->authenticated = 1;
 }
 
 return Success;
@@ -177,6 +208,11 @@ Bool xwl_drm_initialised(struct xwl_screen *xwl_screen)
 return xwl_screen->authenticated;
 }
 
+Bool xwl_drm_prime_able(struct xwl_screen *xwl_screen)
+{
+return xwl_screen->drm_capabilities & WL_DRM_CAPABILITY_PRIME;
+}
+
 int xwl_screen_get_drm_fd(struct xwl_screen *xwl_screen)
 {
 return xwl_screen->drm_fd;
@@ -254,3 +290,49 @@ xwl_create_window_buffer_drm(struct xwl_window *xwl_window,
 
 return Success;
 }
+
+int
+xwl_create_window_buffer_drm_from_fd(struct xwl_window *xwl_window,
+PixmapPtr pixmap, int fd)
+{
+VisualID visual;
+WindowPtr window = xwl_window->window;
+ScreenPtr screen = window->drawable.pScreen;
+struct wl_buffer *buffer;
+uint32_t format;
+int i;
+
+visual = wVisual(window);
+for (i = 0; i < screen->numVisuals; i++)
+   if (screen->visuals[i].vid == visual)
+   break;
+
+switch (screen->visuals[i].nplanes) {
+case 32:
+   format = WL_DRM_FORMAT_ARGB;
+break;
+case 24:
+default:
+   format = WL_DRM_FORMAT_XRGB;
+break;
+case 16:

[PATCH 3/4] Add function to get new fd of the graphic device

[Axel Davy]

neccessary for dri3

Signed-off-by: Axel Davy 
---
 hw/xfree86/xwayland/xwayland-drm.c | 56 --
 hw/xfree86/xwayland/xwayland.h |  3 ++
 2 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/hw/xfree86/xwayland/xwayland-drm.c 
b/hw/xfree86/xwayland/xwayland-drm.c
index c01fdb3..b8d12fd 100644
--- a/hw/xfree86/xwayland/xwayland-drm.c
+++ b/hw/xfree86/xwayland/xwayland-drm.c
@@ -157,49 +157,63 @@ is_fd_render_node(int fd)
 }
 
 int
-xwl_drm_pre_init(struct xwl_screen *xwl_screen)
+xwl_device_get_fd(struct xwl_screen *xwl_screen)
 {
 uint32_t magic;
+int fd;
 
-xwl_screen->drm_registry = wl_display_get_registry(xwl_screen->display);
-wl_registry_add_listener(xwl_screen->drm_registry, &drm_listener,
- xwl_screen);
-
-/* Ensure drm_handler has seen all the interfaces */
-wl_display_roundtrip(xwl_screen->display);
-/* Ensure the xwl_drm_listener has seen the drm device, if any */
-wl_display_roundtrip(xwl_screen->display);
-
-ErrorF("wayland_drm_screen_init, device name %s\n",
-  xwl_screen->device_name);
-
-xwl_screen->drm_fd = open(xwl_screen->device_name, O_RDWR);
-if (xwl_screen->drm_fd < 0) {
+fd = open(xwl_screen->device_name, O_RDWR);
+if (fd < 0) {
ErrorF("failed to open the drm fd\n");
-   return BadAccess;
+   return -1;
 }
 
-if (!is_fd_render_node(xwl_screen->drm_fd)) {
+if (!is_fd_render_node(fd)) {
 
-   if (drmGetMagic(xwl_screen->drm_fd, &magic)) {
+   if (drmGetMagic(fd, &magic)) {
ErrorF("failed to get drm magic");
-   return BadAccess;
+   close (fd);
+   return -1;
 }
 
wl_drm_authenticate(xwl_screen->drm, magic);
 
wl_display_roundtrip(xwl_screen->display);
 
-   ErrorF("opened drm fd: %d\n", xwl_screen->drm_fd);
+   ErrorF("opened drm fd: %d\n", fd);
 
if (!xwl_screen->authenticated) {
ErrorF("Failed to auth drm fd\n");
-   return BadAccess;
+   close (fd);
+   return -1;
 }
 } else {
xwl_screen->authenticated = 1;
 }
 
+return fd;
+}
+
+int
+xwl_drm_pre_init(struct xwl_screen *xwl_screen)
+{
+xwl_screen->drm_registry = wl_display_get_registry(xwl_screen->display);
+wl_registry_add_listener(xwl_screen->drm_registry, &drm_listener,
+ xwl_screen);
+
+/* Ensure drm_handler has seen all the interfaces */
+wl_display_roundtrip(xwl_screen->display);
+/* Ensure the xwl_drm_listener has seen the drm device, if any */
+wl_display_roundtrip(xwl_screen->display);
+
+ErrorF("wayland_drm_screen_init, device name %s\n",
+  xwl_screen->device_name);
+
+xwl_screen->drm_fd = xwl_device_get_fd(xwl_screen);
+if (xwl_screen->drm_fd < 0) {
+   return BadAccess;
+}
+
 return Success;
 }
 
diff --git a/hw/xfree86/xwayland/xwayland.h b/hw/xfree86/xwayland/xwayland.h
index 8e484a1..c380618 100644
--- a/hw/xfree86/xwayland/xwayland.h
+++ b/hw/xfree86/xwayland/xwayland.h
@@ -76,6 +76,9 @@ xwl_drm_authenticate(ClientPtr client, struct xwl_screen 
*xwl_screen,
 uint32_t magic);
 
 extern _X_EXPORT int
+xwl_device_get_fd(struct xwl_screen *xwl_screen);
+
+extern _X_EXPORT int
 xwl_create_window_buffer_drm(struct xwl_window *xwl_window,
 PixmapPtr pixmap, uint32_t name);
 
-- 
1.8.3.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/4] Move the wl_buffer from xwl_window to xwl_pixmap

[Axel Davy]

This change enables to change the window pixmap, and have
xwayland send the correct buffer to the Wayland compositor.

Signed-off-by: Axel Davy 
---
 hw/xfree86/xwayland/xwayland-drm.c | 10 +++-
 hw/xfree86/xwayland/xwayland-private.h | 10 +++-
 hw/xfree86/xwayland/xwayland-window.c  | 87 --
 hw/xfree86/xwayland/xwayland.c | 38 ++-
 4 files changed, 115 insertions(+), 30 deletions(-)

diff --git a/hw/xfree86/xwayland/xwayland-drm.c 
b/hw/xfree86/xwayland/xwayland-drm.c
index 5250857..a52449d 100644
--- a/hw/xfree86/xwayland/xwayland-drm.c
+++ b/hw/xfree86/xwayland/xwayland-drm.c
@@ -217,6 +217,7 @@ xwl_create_window_buffer_drm(struct xwl_window *xwl_window,
 VisualID visual;
 WindowPtr window = xwl_window->window;
 ScreenPtr screen = window->drawable.pScreen;
+struct wl_buffer *buffer;
 uint32_t format;
 int i;
 
@@ -238,7 +239,7 @@ xwl_create_window_buffer_drm(struct xwl_window *xwl_window,
 break;
 }
 
-xwl_window->buffer =
+buffer =
   wl_drm_create_buffer(xwl_window->xwl_screen->drm,
   name,
   pixmap->drawable.width,
@@ -246,5 +247,10 @@ xwl_create_window_buffer_drm(struct xwl_window *xwl_window,
   pixmap->devKind,
   format);
 
-return xwl_window->buffer ? Success : BadDrawable;
+if (!buffer)
+return BadDrawable;
+
+xwl_pixmap_attach_buffer(pixmap, buffer);
+
+return Success;
 }
diff --git a/hw/xfree86/xwayland/xwayland-private.h 
b/hw/xfree86/xwayland/xwayland-private.h
index bdecf8a..853ab3b 100644
--- a/hw/xfree86/xwayland/xwayland-private.h
+++ b/hw/xfree86/xwayland/xwayland-private.h
@@ -29,13 +29,16 @@
 struct xwl_window {
 struct xwl_screen  *xwl_screen;
 struct wl_surface  *surface;
-struct wl_buffer   *buffer;
 WindowPtr   window;
 DamagePtr   damage;
 struct xorg_listlink;
 struct xorg_listlink_damage;
 };
 
+struct xwl_pixmap {
+struct wl_buffer   *buffer;
+};
+
 struct xwl_output;
 
 struct xwl_screen {
@@ -72,6 +75,7 @@ struct xwl_screen {
 RealizeWindowProcPtrRealizeWindow;
 UnrealizeWindowProcPtr  UnrealizeWindow;
 SetWindowPixmapProcPtr  SetWindowPixmap;
+DestroyPixmapProcPtrDestroyPixmap;
 MoveWindowProcPtr   MoveWindow;
 miPointerSpriteFuncPtr  sprite_funcs;
 };
@@ -135,6 +139,10 @@ void xwl_seat_set_cursor(struct xwl_seat *xwl_seat);
 
 void xwl_output_remove(struct xwl_output *output);
 
+void xwl_pixmap_attach_buffer(PixmapPtr pixmap, struct wl_buffer *buffer);
+struct xwl_pixmap *xwl_window_get_buffer(struct xwl_window *xwl_window);
+struct xwl_window *get_xwl_window(WindowPtr window);
+
 extern const struct xserver_listener xwl_server_listener;
 
 #endif /* _XWAYLAND_PRIVATE_H_ */
diff --git a/hw/xfree86/xwayland/xwayland-window.c 
b/hw/xfree86/xwayland/xwayland-window.c
index a2a8206..cd237ab 100644
--- a/hw/xfree86/xwayland/xwayland-window.c
+++ b/hw/xfree86/xwayland/xwayland-window.c
@@ -41,6 +41,13 @@
 #include "xserver-client-protocol.h"
 
 static DevPrivateKeyRec xwl_window_private_key;
+static DevPrivateKeyRec xwl_pixmap_private_key;
+
+struct xwl_window *
+get_xwl_window(WindowPtr window)
+{
+  return dixLookupPrivate(&window->devPrivates, &xwl_window_private_key);
+}
 
 static void
 free_pixmap(void *data, struct wl_callback *callback, uint32_t time)
@@ -56,25 +63,39 @@ static const struct wl_callback_listener 
free_pixmap_listener = {
free_pixmap,
 };
 
+void
+xwl_pixmap_attach_buffer(PixmapPtr pixmap, struct wl_buffer *buffer)
+{
+struct xwl_pixmap *xwl_pixmap = calloc(sizeof *xwl_pixmap, 1);
+if (!xwl_pixmap) {
+wl_buffer_destroy(buffer);
+return;
+}
+xwl_pixmap->buffer = buffer;
+dixSetPrivate(&pixmap->devPrivates,
+  &xwl_pixmap_private_key, xwl_pixmap);
+}
+
 static void
 xwl_window_attach(struct xwl_window *xwl_window, PixmapPtr pixmap)
 {
 struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
 struct wl_callback *callback;
-
-/* We can safely destroy the buffer because we only use one buffer
- * per surface in xwayland model */
-if (xwl_window->buffer)
-wl_buffer_destroy(xwl_window->buffer);
-
-xwl_screen->driver->create_window_buffer(xwl_window, pixmap);
-
-if (!xwl_window->buffer) {
-ErrorF("failed to create buffer\n");
-   return;
+struct xwl_pixmap *xwl_pixmap =
+   dixLookupPrivate(&pixmap->devPrivates, &xwl_pixmap_private_key);
+
+if (!xwl_pixmap) {
+xwl_screen->driver->create_window_buffer(xwl_window, pixmap);
+xwl_pixmap =
+   dixLookupPrivate(&pixmap->devPrivates, &xwl_pixma

[PATCH 0/4][XWayland] New API to support dri3/present

[Axel Davy]

The first patch moves the wl_buffers from being a per-window thing to
a per-pixmap thing. That way if we change the window pixmap, the
window update will attach the new buffer.

The second and third patches are to support dri3 (on render-nodes too).
wlglamor has been updated to drop the DRI2 code (which had the major flaw
that we had to keep the pci_ids, taken from Mesa sources, to get the driver
name for dri2 initialization.), and to implement DRI3.
https://github.com/axeldavy/xf86-video-wlglamor/tree/wlglamor-dri3

The fourth patch is an updated version of my patches I had posted long
ago to improve DRI2 support. Now they are designed to work for Present
support.
The code to support Present for XWayland (using this API) is not finished
yet.

Axel Davy (4):
  Move the wl_buffer from xwl_window to xwl_pixmap
  Add support to render-nodes.
  Add function to get new fd of the graphic device
  Add XWayland API with Present support in mind.

 hw/xfree86/xwayland/Makefile.am|   1 +
 hw/xfree86/xwayland/drm.xml|  45 ++-
 hw/xfree86/xwayland/xwayland-drm.c | 148 +++
 hw/xfree86/xwayland/xwayland-events.c  | 210 +
 hw/xfree86/xwayland/xwayland-private.h |  19 ++-
 hw/xfree86/xwayland/xwayland-window.c  |  92 ---
 hw/xfree86/xwayland/xwayland.c |  38 --
 hw/xfree86/xwayland/xwayland.h |  24 
 8 files changed, 525 insertions(+), 52 deletions(-)
 create mode 100644 hw/xfree86/xwayland/xwayland-events.c

-- 
1.8.3.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 4/4] Add XWayland API with Present support in mind.

[Axel Davy]

The API enables to use the frame event and the buffer event.

Signed-off-by: Axel Davy 
---
 hw/xfree86/xwayland/Makefile.am|   1 +
 hw/xfree86/xwayland/xwayland-events.c  | 210 +
 hw/xfree86/xwayland/xwayland-private.h |   8 ++
 hw/xfree86/xwayland/xwayland-window.c  |   5 +
 hw/xfree86/xwayland/xwayland.h |  14 +++
 5 files changed, 238 insertions(+)
 create mode 100644 hw/xfree86/xwayland/xwayland-events.c

diff --git a/hw/xfree86/xwayland/Makefile.am b/hw/xfree86/xwayland/Makefile.am
index 22ab154..cc45444 100644
--- a/hw/xfree86/xwayland/Makefile.am
+++ b/hw/xfree86/xwayland/Makefile.am
@@ -21,6 +21,7 @@ libxwayland_la_SOURCES =  \
xwayland-output.c   \
xwayland-cursor.c   \
xwayland-window.c   \
+   xwayland-events.c   \
xwayland-private.h  \
drm-client-protocol.h   \
drm-protocol.c  \
diff --git a/hw/xfree86/xwayland/xwayland-events.c 
b/hw/xfree86/xwayland/xwayland-events.c
new file mode 100644
index 000..d756de7
--- /dev/null
+++ b/hw/xfree86/xwayland/xwayland-events.c
@@ -0,0 +1,210 @@
+/*
+ * Copyright © 2014 Axel Davy
+ *
+ * Permission to use, copy, modify, distribute, and sell this software
+ * and its documentation for any purpose is hereby granted without
+ * fee, provided that the above copyright notice appear in all copies
+ * and that both that copyright notice and this permission notice
+ * appear in supporting documentation, and that the name of the
+ * copyright holders not be used in advertising or publicity
+ * pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no
+ * representations about the suitability of this software for any
+ * purpose.  It is provided "as is" without express or implied
+ * warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+ * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
+ * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+ * SOFTWARE.
+ */
+
+
+#include 
+
+#include 
+#include 
+
+#include 
+#include "xwayland.h"
+#include "xwayland-private.h"
+
+
+/*
+ * Handling of frame events and buffer events.
+ * API to use them
+ */
+
+struct _todo {
+union {
+todo_func_frame tff;
+   todo_func_buffer tfb;
+} tocall;
+void *args;
+struct wl_list link;
+};
+
+static void event_todo_free(struct wl_list* todo_list)
+{
+struct _todo* pos,*tmp;
+wl_list_for_each_safe(pos,tmp,todo_list,link) {
+wl_list_remove(&pos->link);
+free (pos);
+}
+}
+
+static const struct wl_callback_listener frame_listener;
+
+static void frame_listener_callback(void *data,
+   struct wl_callback *callback,
+   uint32_t time)
+{
+struct xwl_window *xwl_window = data;
+struct wl_list todo_list;
+struct _todo *todo;
+
+wl_callback_destroy(xwl_window->frame_callback);
+xwl_window->frame_callback = wl_surface_frame(xwl_window->surface);
+wl_callback_add_listener(xwl_window->frame_callback,
+&frame_listener,
+xwl_window);
+
+if (wl_list_empty(&xwl_window->frame_todo))
+return;
+
+/* todo funcs are able to ask to be recalled */
+
+wl_list_init(&todo_list);
+wl_list_insert_list(&todo_list, &xwl_window->frame_todo);
+wl_list_init(&xwl_window->frame_todo);
+wl_list_for_each(todo, &todo_list,link)
+todo->tocall.tff(0, time, todo->args);
+event_todo_free(&todo_list);
+
+/* We need to commit to let the compositor know the new frame callback */
+if (!wl_list_empty(&xwl_window->frame_todo)) {
+/* reverse the list. It is useful to keep the order between two
+ * waiting functions that keep adding themselves to the todo list */
+wl_list_init(&todo_list);
+wl_list_insert_list(&todo_list, &xwl_window->frame_todo);
+wl_list_init(&xwl_window->frame_todo);
+wl_list_for_each(todo, &todo_list,link)
+wl_list_insert(&xwl_window->frame_todo, &todo->link);
+wl_surface_commit(xwl_window->surface);
+}
+}
+
+
+
+static const struct wl_callback_listener frame_listener = {
+frame_listener_callback
+};
+
+
+static void wl_buffer_release_event(void *data, struct wl_buffer *buffer)
+{
+struct xwl_pixm

[PATCH 2/2] Fix XWayland crashes when opening popups

[Axel Davy]

Signed-off-by: Axel Davy 
---
 xwayland/window-manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index d475e36..1bb9825 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -2214,7 +2214,7 @@ xserver_map_shell_surface(struct weston_wm *wm,
  window->x,
  window->y,
  
WL_SHELL_SURFACE_TRANSIENT_INACTIVE);
-   } else if (window->transient_for) {
+   } else if (window->transient_for && window->transient_for->surface) {
parent = window->transient_for;
shell_interface->set_transient(window->shsurf,
   parent->surface,
-- 
1.8.3.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/2] Fix XWayland transient window location.

[Axel Davy]

This fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73517

Signed-off-by: Axel Davy 
---
 xwayland/window-manager.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 70c8cf7..d475e36 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -2218,8 +2218,8 @@ xserver_map_shell_surface(struct weston_wm *wm,
parent = window->transient_for;
shell_interface->set_transient(window->shsurf,
   parent->surface,
-  parent->x - window->x,
-  parent->y - window->y, 0);
+  window->x - parent->x,
+  window->y - parent->y, 0);
} else {
shell_interface->set_toplevel(window->shsurf);
}
-- 
1.8.3.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] compositor: update the transform when attaching a new buffer

[Axel Davy]

On 10/12/2013, Giulio Camuffo wrote :

if a surface has not a buffer yet and a weston_view gets created for
it, the surface's width and height will be 0 and the view's output_mask
will be 0, because the surface's area is 0. Later commits on the surface
with valid buffers will then trigger a surface repaint, which will do
nothing because of the output_mask set to 0. So by calling
weston_update_transform() on the views of the surface at the end of
weston_surface_commit() we update the output_mask of the surface and
of the views, so they will be repainted.
---
  src/compositor.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/compositor.c b/src/compositor.c
index 6beea9c..20d9efb 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -2005,7 +2005,6 @@ weston_surface_commit(struct weston_surface *surface)
surface->pending.buffer = NULL;
surface->pending.sx = 0;
surface->pending.sy = 0;
-   surface->pending.newly_attached = 0;
  
  	/* wl_surface.damage */

pixman_region32_union(&surface->damage, &surface->damage,
@@ -2046,7 +2045,13 @@ weston_surface_commit(struct weston_surface *surface)
  
  	weston_surface_commit_subsurface_order(surface);
  
+	if (surface->pending.newly_attached) {

+   wl_list_for_each(view, &surface->views, surface_link)
+   weston_view_update_transform(view);
+   }
weston_surface_schedule_repaint(surface);
+
+   surface->pending.newly_attached = 0;
  }
  
  static void


Reviewed-by: Axel Davy 

It would probably need similarly to call weston_view_update_transform and 
weston_surface_schedule_repaint in weston_view_create in case a buffer is 
already attached, and the surface had no views previously.

Axel Davy

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Add wl_dmabuf protocol

[Axel Davy]

On 03/12/2013, benjamin.gaign...@linaro.org wrote :

Here are a few comments:

+  
+  


What's the point of creating a new interface, and skipping version 1?
You should have removed too the since="2" you have in some functions.

+
+
+  
+Bitmask of capabilities.
+  
+  
+
+
What's the point of advertising if Prime is available or not? If Prime 
isn't available, then

the extension shouldn't be advertised at all.

+
+   wl_resource_post_event(resource, WL_DMABUF_FORMAT, 
WL_DMABUF_FORMAT_ARGB);
+   wl_resource_post_event(resource, WL_DMABUF_FORMAT, 
WL_DMABUF_FORMAT_XRGB);
+   wl_resource_post_event(resource, WL_DMABUF_FORMAT, 
WL_DMABUF_FORMAT_YUV410);
+   wl_resource_post_event(resource, WL_DMABUF_FORMAT, 
WL_DMABUF_FORMAT_YUV411);
+   wl_resource_post_event(resource, WL_DMABUF_FORMAT, 
WL_DMABUF_FORMAT_YUV420);
+   wl_resource_post_event(resource, WL_DMABUF_FORMAT, 
WL_DMABUF_FORMAT_YUV422);
+   wl_resource_post_event(resource, WL_DMABUF_FORMAT, 
WL_DMABUF_FORMAT_YUV444);
+   wl_resource_post_event(resource, WL_DMABUF_FORMAT, 
WL_DMABUF_FORMAT_NV12);
+   wl_resource_post_event(resource, WL_DMABUF_FORMAT, 
WL_DMABUF_FORMAT_NV16);
+   wl_resource_post_event(resource, WL_DMABUF_FORMAT, 
WL_DMABUF_FORMAT_YUYV);
+
These formats can potentially not be all supported by the server. You 
should find a way to check available formats.



+   capabilities = 0;
+   if (dmabuf->flags & WAYLAND_DMABUF_PRIME)
+   capabilities |= WL_DMABUF_CAPABILITY_PRIME;
+

again, I don't understand why you would advertise PRIME support


If you want a generic interface to share dma-bufs buffers, you should 
make this interface much more generic,

to adapt to what the server can do.
For example you could advertise if the server supports mmap, etc.

Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Flush the wl_display at the end of SwapBuffers

[Axel Davy]

We would like the compositor to receive the commited buffer
as soon as possible, so it has the time to treat it, and 
release old ones. We shouldn't rely on the client
to flush the queue for us.

Signed-off-by: Axel Davy 
---
We flush the wl_display after we flush the drawable.

 src/egl/drivers/dri2/platform_wayland.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 7e3733b..8c3d1f1 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -627,6 +627,8 @@ dri2_swap_buffers_with_damage(_EGLDriver *drv,
   (*dri2_dpy->flush->flush)(dri2_surf->dri_drawable);
(*dri2_dpy->flush->invalidate)(dri2_surf->dri_drawable);
 
+   wl_display_flush(dri2_dpy->wl_dpy);
+
return EGL_TRUE;
 }
 
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH Mesa] Enable throttling in SwapBuffers

[Axel Davy]

flush_with_flags, when available, allows the driver to throttle.
Using this suppress input lag issues that can be observed in heavy
rendering situations on non-intel cards.

Signed-off-by: Axel Davy 
---
We must fight input lag, since we can have situations where
the sent buffer hasn't been touched yet at all by the driver.
In this corner case, there is no lock on the buffer, and Weston
would display the buffer which has not been rendered yet.

 src/egl/drivers/dri2/platform_wayland.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index f9065bb..7e3733b 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -557,6 +557,8 @@ dri2_swap_buffers_with_damage(_EGLDriver *drv,
 {
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
struct dri2_egl_surface *dri2_surf = dri2_egl_surface(draw);
+   _EGLContext *ctx;
+   struct dri2_egl_context *dri2_ctx;
int i, ret = 0;
 
while (dri2_surf->frame_callback && ret != -1)
@@ -612,7 +614,17 @@ dri2_swap_buffers_with_damage(_EGLDriver *drv,
 
wl_surface_commit(dri2_surf->wl_win->surface);
 
-   (*dri2_dpy->flush->flush)(dri2_surf->dri_drawable);
+   if (dri2_dpy->flush->base.version >= 4)
+   {
+  ctx = _eglGetCurrentContext();
+  dri2_ctx = dri2_egl_context(ctx);
+  (*dri2_dpy->flush->flush_with_flags)(dri2_ctx->dri_context,
+   dri2_surf->dri_drawable,
+   __DRI2_FLUSH_DRAWABLE,
+   __DRI2_THROTTLE_SWAPBUFFER);
+   }
+   else
+  (*dri2_dpy->flush->flush)(dri2_surf->dri_drawable);
(*dri2_dpy->flush->invalidate)(dri2_surf->dri_drawable);
 
return EGL_TRUE;
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2] Wayland backend: set the opaque region when starting fullscreen

[Axel Davy]

The opaque region is not set when we start the nested
compositor fullscreen. This patch fixes this.

Signed-off-by: Axel Davy 
---
Jason Ekstrand prefer we use wayland_output_set_fullscreen,
which will -besides other things- set the opaque region.

 src/compositor-wayland.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index ed3923b..7b280b8 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1613,6 +1613,7 @@ backend_init(struct wl_display *display, int *argc, char 
*argv[],
if (!output)
goto err_outputs;
 
+   wayland_output_set_fullscreen(output, 0, 0, NULL);
return &c->base;
}
 
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Wayland backend: set the opaque region when starting fullscreen

[Axel Davy]

The opaque region is not set when we start the nested
compositor fullscreen. This patch fixes this.

Signed-off-by: Axel Davy 
---
 src/compositor-wayland.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index ed3923b..08741d9 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -785,6 +785,7 @@ wayland_output_create(struct wayland_compositor *c, int x, 
int y,
  &shell_surface_listener, output);
 
if (fullscreen) {
+   struct wl_region *region;
wl_shell_surface_set_fullscreen(output->parent.shell_surface,
0, 0, NULL);
wl_display_roundtrip(c->parent.wl_display);
@@ -792,6 +793,11 @@ wayland_output_create(struct wayland_compositor *c, int x, 
int y,
output_width = output->parent.configure_width;
if (!height)
output_height = output->parent.configure_height;
+
+   region = wl_compositor_create_region(c->parent.compositor);
+   wl_region_add(region, 0, 0, output_width, output_height);
+   wl_surface_set_opaque_region(output->parent.surface, region);
+   wl_region_destroy(region);
}
 
output->mode.flags =
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH mesa v5 2/2] wayland: Add support for eglSwapInterval

[Axel Davy]

I'm not sure waiting 10ms when all the buffers aren't released is the 
best solution.


In fact, I experimented a eglSwapInterval(0) behaviour with a simple 
patch to enable it:
having 4 back buffers and using a roundtrip after commiting (that is: a 
bit similar to what you do, but without the poll)


And with glmark2, for all the benchmarks (10 seconds by benchmark) I had 
4-5 egl error messages

because there was no buffer free in get_back_bo (the benchmarks continued).

That makes me think that the poll case might happen more often than you 
think.


I suggest to have a lighter solution: for example poll a first time with 
1ms instead of 10ms,

and then if no buffers are free, try again with a poll of 10ms.
Why not doing directly another roundtrip?

Axel Davy

Le 15/11/2013 14:50, Neil Roberts a écrit :

The Wayland EGL platform now respects the eglSwapInterval value. The value is
clamped to either 0 or 1 because it is difficult (and probably not useful) to
sync to more than 1 redraw.

The main change is that if the swap interval is 0 then Mesa won't install a
frame callback so that eglSwapBuffers can be executed as often as necessary.
Instead it will do a sync request after the swap buffers. It will block for
sync complete event in get_back_bo instead of the frame callback. The
compositor is likely to send a release event while processing the new buffer
attach and this makes sure we will receive that before deciding whether to
allocate a new buffer.

If there are no buffers available then instead of returning with an error,
get_back_bo will now poll the compositor by repeatedly sending sync requests
every 10ms. This is a last resort and in theory this shouldn't happen because
there should be no reason for the compositor to hold on to more than three
buffers. That means whenever we attach the fourth buffer we should always get
an immediate release event which should come in with the notification for the
first sync request that we are throttled to.

When the compositor is directly scanning out from the application's buffer it
may end up holding on to three buffers. These are the one that is is currently
scanning out from, one that has been given to DRM as the next buffer to flip
to, and one that has been attached and will be given to DRM as soon as the
previous flip completes. When we attach a fourth buffer to the compositor it
should replace that third buffer so we should get a release event immediately
after that. This patch therefore also changes the number of buffer slots to 4
so that we can accomodate that situation.

If DRM eventually gets a way to cancel a pending page flip then the compositors
can be changed to only need to hold on to two buffers and this value can be
put back to 3.

This also moves the vblank configuration defines from platform_x11.c to the
common egl_dri2.h header so they can be shared by both platforms.
---
  src/egl/drivers/dri2/egl_dri2.h |  10 +-
  src/egl/drivers/dri2/platform_wayland.c | 199 +++-
  src/egl/drivers/dri2/platform_x11.c |   6 -
  3 files changed, 179 insertions(+), 36 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 8c303d9..d29dd98 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -174,7 +174,7 @@ struct dri2_egl_surface
 struct wl_egl_window  *wl_win;
 intdx;
 intdy;
-   struct wl_callback*frame_callback;
+   struct wl_callback*throttle_callback;
 int  format;
  #endif
  
@@ -194,7 +194,7 @@ struct dri2_egl_surface

  #endif
int locked;
int age;
-   } color_buffers[3], *back, *current;
+   } color_buffers[4], *back, *current;
  #endif
  
  #ifdef HAVE_ANDROID_PLATFORM

@@ -220,6 +220,12 @@ struct dri2_egl_image
 __DRIimage *dri_image;
  };
  
+/* From xmlpool/options.h, user exposed so should be stable */

+#define DRI_CONF_VBLANK_NEVER 0
+#define DRI_CONF_VBLANK_DEF_INTERVAL_0 1
+#define DRI_CONF_VBLANK_DEF_INTERVAL_1 2
+#define DRI_CONF_VBLANK_ALWAYS_SYNC 3
+
  /* standard typecasts */
  _EGL_DRIVER_STANDARD_TYPECASTS(dri2_egl)
  _EGL_DRIVER_TYPECAST(dri2_egl_image, _EGLImage, obj)
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 5ce8981..fca35db 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -34,6 +34,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "egl_dri2.h"
  
@@ -183,8 +184,16 @@ dri2_create_window_surface(_EGLDriver *drv, _EGLDisplay *disp,

   _EGLConfig *conf, EGLNativeWindowType window,
   const EGLint *attrib_list)
  {
-   return dri2_create_surface(drv, disp, EGL_WINDOW_BIT, conf,
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   _EGLSurface *surf;
+
+   s

Re: [PATCH xwayland 2/3] Check for frame being NULL before setting/unsetting flags

[Axel Davy]

I've posted a patch, which prevents wm->focus_window to be a window 
without frame.


This solves the same bug than this patch, but looks better to me.

http://lists.freedesktop.org/archives/wayland-devel/2013-November/012008.html

Axel Davy

Le 15/11/2013 11:25, Axel Davy a écrit :

This patch (Again, I had the same), solves the last bugs for XWayland,
but for this one, I'm not sure it is the correct fix.

In fact it would mean than focus_window would be an unmapped windows,
which looks strange to me.

Axel Davy

Le 15/11/2013 11:01, Dima Ryazanov a écrit :

Fixes a crash in Firefox when clicking an "install plugin" popup.

Signed-off-by: Dima Ryazanov 
---
  src/xwayland/window-manager.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/xwayland/window-manager.c 
b/src/xwayland/window-manager.c

index 5ee9480..6d29026 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -695,12 +695,14 @@ weston_wm_window_activate(struct wl_listener 
*listener, void *data)

  }
if (wm->focus_window) {
-frame_unset_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
+if (wm->focus_window->frame)
+frame_unset_flag(wm->focus_window->frame, 
FRAME_FLAG_ACTIVE);

weston_wm_window_schedule_repaint(wm->focus_window);
  }
  wm->focus_window = window;
  if (wm->focus_window) {
-frame_set_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
+if (wm->focus_window->frame)
+frame_set_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
weston_wm_window_schedule_repaint(wm->focus_window);
  }
  }


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] XWayland: do not set wm->focus_window to a window with no frame

[Axel Davy]

An unmapped window shouldn't be the input focus.
This solves some remaining Weston crashes with XWayland,
because we assume wm->focus_window has a frame.

Signed-off-by: Axel Davy 
---
 src/xwayland/window-manager.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 7783d2c..70244ab 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -671,6 +671,8 @@ weston_wm_window_activate(struct wl_listener *listener, 
void *data)
 
if (surface) {
window = get_wm_window(surface);
+   if (window && !window->frame)
+   window = NULL;
}
 
if (window) {
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland 2/3] Check for frame being NULL before setting/unsetting flags

[Axel Davy]

This patch (Again, I had the same), solves the last bugs for XWayland,
but for this one, I'm not sure it is the correct fix.

In fact it would mean than focus_window would be an unmapped windows,
which looks strange to me.

Axel Davy

Le 15/11/2013 11:01, Dima Ryazanov a écrit :

Fixes a crash in Firefox when clicking an "install plugin" popup.

Signed-off-by: Dima Ryazanov 
---
  src/xwayland/window-manager.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 5ee9480..6d29026 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -695,12 +695,14 @@ weston_wm_window_activate(struct wl_listener *listener, 
void *data)
}
  
  	if (wm->focus_window) {

-   frame_unset_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
+   if (wm->focus_window->frame)
+   frame_unset_flag(wm->focus_window->frame, 
FRAME_FLAG_ACTIVE);
weston_wm_window_schedule_repaint(wm->focus_window);
}
wm->focus_window = window;
if (wm->focus_window) {
-   frame_set_flag(wm->focus_window->frame, FRAME_FLAG_ACTIVE);
+   if (wm->focus_window->frame)
+   frame_set_flag(wm->focus_window->frame, 
FRAME_FLAG_ACTIVE);
weston_wm_window_schedule_repaint(wm->focus_window);
}
  }


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland 3/3] Check if the frame exists before reading its size

[Axel Davy]

You were faster than me!

I was just about sending this very same patch.

The patch is correct as I was explaining in my commit message:
"XWayland: Don't access the frame field for unmapped windows.

There are situations where weston_wm_window_get_frame_size
and weston_wm_window_get_child_position are called on
an unmapped window.
In these cases, the decorations are not yet drawn,
so we must behave as if there was no decoration.
"

Correct the commit message ("I don't know if this correct" shouldn't be in),
and this is
Reviewed-by: Axel Davy 


Axel Davy

On 15/11/2013 , Dima Ryazanov wrote :

This fixes crashes caused by popup windows that don't have override_redirect
(e.g., menus in VLC and KDE apps), though I don't know if this is correct.

Signed-off-by: Dima Ryazanov 
---
  src/xwayland/window-manager.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index 6d29026..eea0349 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -497,7 +497,7 @@ weston_wm_window_get_frame_size(struct weston_wm_window 
*window,
if (window->fullscreen) {
*width = window->width;
*height = window->height;
-   } else if (window->decorate) {
+   } else if (window->decorate && window->frame) {
*width = frame_width(window->frame);
*height = frame_height(window->frame);
} else {
@@ -515,7 +515,7 @@ weston_wm_window_get_child_position(struct weston_wm_window 
*window,
if (window->fullscreen) {
*x = 0;
*y = 0;
-   } else if (window->decorate) {
+   } else if (window->decorate && window->frame) {
frame_interior(window->frame, x, y, NULL, NULL);
} else {
*x = t->margin;


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland] Set the view to NULL when unmapping an X11 window

[Axel Davy]

I've looked deeply in the code to find the remaining xwayland bugs.

I'll publish later a fix for these. The remaining bugs are due to 
accessing to the frame field on

unmapped windows.

Your patch solves all the issues with the view field.

Your patch is tested and
Reviewed-by: Axel Davy 

Axel Davy
Le 15/11/2013 09:44, Axel Davy a écrit :
I have tested your patch, but it doesn't solve all the bugs occuring 
in XWayland because of views (take vlc, go to the menu, crash).


It appears ok to me to set view to NULL at these locations, but 
there's probably something more to do.


Axel Davy

On 15/11/2013, Dima Ryazanov wrote :

Ping :)


On Fri, Nov 1, 2013 at 12:46 AM, Dima Ryazanov <mailto:d...@gmail.com>> wrote:


Fixes a crash caused by accessing a deleted view in
weston_wm_window_schedule_repaint. It can be easily reproduced by
switching between menus in Firefox.

Signed-off-by: Dima Ryazanov mailto:d...@gmail.com>>
---
 src/xwayland/window-manager.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/xwayland/window-manager.c
b/src/xwayland/window-manager.c
index b2776a0..5ee9480 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -902,6 +902,7 @@ weston_wm_handle_unmap_notify(struct
weston_wm *wm, xcb_generic_event_t *event)
wl_list_remove(&window->surface_destroy_listener.link);
window->surface = NULL;
window->shsurf = NULL;
+   window->view = NULL;
xcb_unmap_window(wm->conn, window->frame_id);
 }

@@ -2028,6 +2029,7 @@ surface_destroy(struct wl_listener
*listener, void *data)
Don't try to use it later. */
window->shsurf = NULL;
window->surface = NULL;
+   window->view = NULL;
 }

 static struct weston_wm_window *
--
1.8.3.2




___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel




___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xwayland] Set the view to NULL when unmapping an X11 window

[Axel Davy]

I have tested your patch, but it doesn't solve all the bugs occuring in 
XWayland because of views (take vlc, go to the menu, crash).


It appears ok to me to set view to NULL at these locations, but there's 
probably something more to do.


Axel Davy

On 15/11/2013, Dima Ryazanov wrote :

Ping :)


On Fri, Nov 1, 2013 at 12:46 AM, Dima Ryazanov <mailto:d...@gmail.com>> wrote:


Fixes a crash caused by accessing a deleted view in
weston_wm_window_schedule_repaint. It can be easily reproduced by
switching between menus in Firefox.

Signed-off-by: Dima Ryazanov mailto:d...@gmail.com>>
---
 src/xwayland/window-manager.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/xwayland/window-manager.c
b/src/xwayland/window-manager.c
index b2776a0..5ee9480 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -902,6 +902,7 @@ weston_wm_handle_unmap_notify(struct weston_wm
*wm, xcb_generic_event_t *event)
wl_list_remove(&window->surface_destroy_listener.link);
window->surface = NULL;
window->shsurf = NULL;
+   window->view = NULL;
xcb_unmap_window(wm->conn, window->frame_id);
 }

@@ -2028,6 +2029,7 @@ surface_destroy(struct wl_listener
*listener, void *data)
Don't try to use it later. */
window->shsurf = NULL;
window->surface = NULL;
+   window->view = NULL;
 }

 static struct weston_wm_window *
--
1.8.3.2




___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell - yet another proposal (this time for real).

[Axel Davy]

Hello,

There has been some discussions on IRC about the possible support of
decoration side negociation in xdg_shell.

A client would have to support CSD if it uses xdg_shell.

And I suggested the folowing mechanism:

.when binding to xdg_shell,
the client gets an event telling him the compositors's
preferred mode between CSD and SSD.

. When creating a surface, the client tells which he prefers between
CSD and SSD

. The client gets back an event to tell him what will be the decoration mode
for the surface (the compositor can follow client choice, or enforce CSD 
or SSD).


And I suggest too to be able to change that after creation (ie be able to
send a new request to tell to the compositor the client wants to change 
of mode,

and the client would get the back the same event than before, telling
him what the compositor wants him to use).


Axel Davy

Le 07/11/2013 10:32, Rafael Antognolli a écrit :

Hello all,

Following is the same description as in my previous wrong email, but with the
correct patch attached.

I'm trying to summarize part of the discussion in this new patch, but it's not
the final one.

As far as I understood, the goal is to end up with something like this for
keyboard focus:

W = compositor
A, Z = client surfaces

Viewport change:
W to Z: You are deactivated.
W to A: You are activated.
A to W: Do these things.

So, I added "activated" and "deactivated" events, that the compositor can use
to inform clients what they are. And there's a take_focus request that can be
used by a client to ask for activation, but it's up to the compositor to
decide.

Regarding the surface fullscreen, maximized, etc, I added surface states as
enum's, that can be set/unset, and events from the compositor to request that a
given state should be set/unset.

For those states that take parameters, I added separate requests for setting
the parameters before setting the state. It should all take place after commit
anyway, so that shouldn't matter much. Take a look at the docs and say what you
think.

I didn't change transient/popup surface types yet, but from what has been said
in the ML thread, I think they also should be surface states now. Correct me if
I'm wrong. Otherwise I'm going to send an updated version with those changes
tomorrow.

I also talked to jekstrand (I think) about stacking, will send an updated
version with what I understood from that tomorrow. Should be simple.

Any feedback is appreciated, and thank you guys for the input so far and the
patience.


Rafael Antognolli (1):
   xdg_shell: Add a new shell protocol.

  protocol/Makefile.am |   2 +-
  protocol/xdg-surface.xml | 381 +++
  2 files changed, 382 insertions(+), 1 deletion(-)
  create mode 100644 protocol/xdg-surface.xml



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v.2] Extend wl_surface protocol

[Axel Davy]

On 11/11/2013, Pekka Paalanen wrote :

Hi Axel

On Fri, 08 Nov 2013 23:49:25 +0100
Axel Davy  wrote:


Hello,

I've read carefully your new protocol proposition,
but I think it doesn't meet the requirements to implement
the X Present extension for XWayland.

The problem is that I need to be able to use the frame
request too (I need the frame callback and the presentation time).

Why do you need the frame callback? Is it to know when your one queued
buffer gets into use? That's the idea got from below.

And you specifically do not want to wait so long, that the presentation
timestamp arrives?
I just want the frame callback to count the number of screen refresh, 
and be able to

target one.

Except this problem, I think your protocol proposition is fine.
I suggest to change the spec
to include the fact that queue is a more complete commit,
and will take into account a pending frame request,
and associate it to the wl_buffer we queue.
Since the frame request is linked to a callback, the client
can find to which buffer it is associated when it gets the
frame feedback.

I don't think it makes sense to say, that "When the compositor
applies a buffer from the buffer queue, it will also implicitly commit
all pending frame requests." That's implicit behaviour across two
different interfaces in a rather surprising way, IMHO.

Stepping a bit into the unspecified(?) behaviour of the frame request,
you could submit your wl_buffer via wl_buffer_queue, and then issue the
normal wl_surface.frame with a wl_surface.commit. I believe the current
Weston implementation will trigger the frame callbacks even without a
new buffer, as long as something causes a repaint. Or the other way
around, I'm not sure which order is better for you.
Yes, I think I just need the frame callback to work with a 
wl_surface.commit for XWayland,

so that protocol proposition is ok for it.




Note: to be able to get the presentation time, when the X client
doesn't ask a specific presentation time, I'll have to use a queue
of length one with a requested time of 0. Your spec says it should
behave correctly.

Would you be using the queue length one only so that you know which
wl_buffer corresponds to the frame callback?

If you had frame callbacks tied to a particular submission of a
wl_buffer by some other means, would things be easier for you in
xwayland? Would be able to queue more buffers than just one? If yes,
would it benefit anything?

If it was really useful to know when each wl_buffer enters a
compositor repaint (just like what the frame request offers for
wl_surfaces), we could think about adding such an event to
wl_presentation_time interface (and maybe rename it accordingly).



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v.2] Extend wl_surface protocol

[Axel Davy]

  
  
Hello,
  
  I've read carefully your new protocol proposition, 
  but I think it doesn't meet the requirements to implement 
  the X Present extension for XWayland.
  
  The problem is that I need to be able to use the frame
  request too (I need the frame callback and the presentation time).
  
  Except this problem, I think your protocol proposition is fine.
  I suggest to change the spec
  to include the fact that queue is a more complete commit, 
  and will take into account a pending frame request,
  and associate it to the wl_buffer we queue.
  Since the frame request is linked to a callback, the client
  can find to which buffer it is associated when it gets the
  frame feedback.
  
  Note: to be able to get the presentation time, when the X client 
  doesn't ask a specific presentation time, I'll have to use a queue
  of length one with a requested time of 0. Your spec says it should
  behave correctly.
  
  I'm adding a few comments behind.
  
  Axel Davy
  
  On 08/11/2013,  Frederic Plourde wrote :


  
  Hi, 

I have gathered comments and suggestions from colleagues and
wayland-devel reviewers and here is RFC v.2 of our buffer queue
+ presentation feedback protocol extension.

Notice the following changes :
-
 - it's changed name to make it more general. (comments/ideas on
the protocol and interfaces names are welcome). We believe this
wl_surface extension really is down to adding a timed buffer
queue, hence the wl_buffer_queue interface name.

 - it's been extended to include presentation time feedback
(wl_presentation_time)

 - Extensive comments were added.

please, see the code below:






  
    Copyright © 2012-2013 Collabora, Ltd.

    Permission to use, copy, modify, distribute, and
  sell this
    software and its documentation for any purpose is
  hereby granted
    without fee, provided that the above copyright
  notice appear in
    all copies and that both that copyright notice and
  this permission
    notice appear in supporting documentation, and that
  the name of
    the copyright holders not be used in advertising or
  publicity
    pertaining to distribution of the software without
  specific,
    written prior permission.  The copyright holders
  make no
    representations about the suitability of this
  software for any
    purpose.  It is provided "as is" without express or
  implied
    warranty.

    THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH
  REGARD TO THIS
    SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF
  MERCHANTABILITY AND
    FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE
  LIABLE FOR ANY
    SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY
  DAMAGES
    WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
  PROFITS, WHETHER IN
    AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
  ACTION,
    ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  PERFORMANCE OF
    THIS SOFTWARE.
  

  
    
  The global factory interface exposing timestamped
  buffer queuing composi-
  ting capabilities.

  The aim of presentation timing is to support
  streaming video generally
  coming from videosink clients that typically need
  to queue video buffers
  with presentation timestamps in order to
  accurately synchronize video 
  and audio streams.

  This global interface allows for the creation of
  timestamped buffer 
  queues for wl_surface objects.
    

    
  
    Tell the server that the client will not be
  using this
    protocol object anymore. This does not affect
  any other
    objects, wl_buffer_queue objects included.
  
    

    
  
 summary="the surface already has a
  buffer_queue object/
  associated to it"/>
    

    
  
    Tell the client which clock ID is the
  compositor going to use for time-
    stamps and presentation feedback.

    Compositor sends tha

[PATCH] Do not set output->current_mode in compositor.c

[Axel Davy]

The field is already set - correctly - in the backend switch_mode.
setting output->current_mode to mode in compositor.c leads to bugs,
since mode can be freed by the shell.
For example, the shell allocates it on the stack for
WL_SHELL_SURFACE_FULLSCREEN_METHOD_DRIVER
---
 src/compositor.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/compositor.c b/src/compositor.c
index 36b54b5..6084e6b 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -138,7 +138,6 @@ weston_output_switch_mode(struct weston_output *output, 
struct weston_mode *mode
if (ret < 0)
return ret;
 
-   output->current_mode = mode;
output->current_scale = scale;
break;
case WESTON_MODE_SWITCH_RESTORE_NATIVE:
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Do not release buffer when it is going to be used again.

[Axel Davy]

On Thu, 7 Nov 2013, Ander Conselvan de Oliveira wrote:



We shouldn't have current equals to next in the first place. This can happen 
when the repaint loop starts, but that's what the 'if 
(output->page_flip_pending)' is for. In any other case, that implies we are 
rendering to the front buffer.


Ander



Thanks for having pointing that out.

I've done additional testings and debug, and I found out the patch 
doesn't solve the bug I was hitting (which is strange given it worked

before I posted it).

The root of the bug seems to be the application I tested used
WL_SHELL_SURFACE_FULLSCREEN_METHOD_DRIVER, and it seems to be buggy.

Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Do not set output->current_mode in compositor.c

[Axel Davy]

The field is already set - correctly - in the backend switch_mode.
setting output->current_mode to mode in compositor.c leads to bugs,
since mode can be freed by the shell.
For example, the shell allocates it on the stack for
WL_SHELL_SURFACE_FULLSCREEN_METHOD_DRIVER

Signed-off-by: Axel Davy 
---
 src/compositor.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/compositor.c b/src/compositor.c
index 36b54b5..6084e6b 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -138,7 +138,6 @@ weston_output_switch_mode(struct weston_output *output, 
struct weston_mode *mode
if (ret < 0)
return ret;
 
-   output->current_mode = mode;
output->current_scale = scale;
break;
case WESTON_MODE_SWITCH_RESTORE_NATIVE:
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Do not release buffer when it is going to be used again.

[Axel Davy]

Solve a bug for some fullscreen clients which wouldn't show up.

Signed-off-by: Axel Davy 
---
 src/compositor-drm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 4f015d1..6a2500b 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -711,7 +711,8 @@ vblank_handler(int fd, unsigned int frame, unsigned int 
sec, unsigned int usec,
 
output->vblank_pending = 0;
 
-   drm_output_release_fb(output, s->current);
+   if (s->current != s->next)
+drm_output_release_fb(output, s->current);
s->current = s->next;
s->next = NULL;
 
@@ -735,7 +736,8 @@ page_flip_handler(int fd, unsigned int frame,
 * we just want to page flip to the current buffer to get an accurate
 * timestamp */
if (output->page_flip_pending) {
-   drm_output_release_fb(output, output->current);
+   if (output->current != output->next) 
+drm_output_release_fb(output, output->current);
output->current = output->next;
output->next = NULL;
}
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Extend wl_surface protocol [reminder]

[Axel Davy]

Thanks for this.

I've just realized that using 32 bits ints won't be sufficient.

Is there a way in the protocol to have requests with 64 bits int args, 
and callback with 64 bits int args too?


Axel Davy

Jiergir Ogoerg wrote :
Just a reminder on how clocks differ (on LInux) from one another, 
taken from here:

http://www.spinics.net/lists/linux-man/msg00973.html
Needless to say, gettimeofday() should be avoided.

CLOCK_REALTIME
- can jump
- can slew
- if ntp is running this clock is always kept close to GMT. even if 
hardware is not 100% correct, ntp will correct everything over time.


CLOCK_MONOTONIC
- cannot jump
- can slew !!! (because of ntp)
- it is not kept in sync with GMT. but the "speed" of seconds is kept 
in sync with GMT by varying it constantly by ntp.


CLOCK_MONOTONIC_RAW
- cannot jump
- cannot slew !
- the speed of seconds is not the same as the speed of GMT seconds 
since the hardware timer is never 100% exact and ntp daemon does NOT 
have influence here





/**
*Just one question. Which clock is being used. Ideally a monotony one, or
*even better, a configurable one. We would normally not want these
*timestamps affected by the user changing the system time.
**/


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Extend wl_surface protocol

[Axel Davy]

James Courtier-Dutton wrote :



Just one question. Which clock is being used. Ideally a monotony one, 
or even better, a configurable one. We would normally not want these 
timestamps affected by the user changing the system time.


James





X calculates ust time with the function GetTickCount. I do not know if 
the user can easily change the time given by this function.


Axel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Extend wl_surface protocol

[Axel Davy]

Here is another proposition to extend the protocol
to allow video players to control better the time at 
which frames hit the screen.

Contrary to the original proposition:
http://lists.freedesktop.org/archives/wayland-devel/2013-October/011496.html

I do not separate the new request in another interface.

The first request: presentation_time is only an indication to the compositor,
and the hit request is a similar feedback to the frame request, but the 
notification is when the frame hit the screen. That's why I don't think it 
should be difficult for some compositors to implement it, and don't feel the 
need to separate it in another interface.

The requests were designed to help implement the Present extension for
XWayland. However the Present extension use Microseconds times, instead
of Milliseconds.

Any feedback is appreciated.

I'm not English native, so if you feel some sentence are incorrect,
please help me to correct them.

Axel Davy (1):
  Add presentation_time and hit requests to wl_surface.

 protocol/wayland.xml | 70 +---
 1 file changed, 67 insertions(+), 3 deletions(-)

-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Add presentation_time and hit requests to wl_surface.

[Axel Davy]

These two new requests are designed to help video players
to synchronize what is displayed on the screen and the audio,
and to implement the X Present extension in XWayland.
---
 protocol/wayland.xml | 70 +---
 1 file changed, 67 insertions(+), 3 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index a1df007..553af61 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -959,7 +959,7 @@
 
   
 
-  
+  
 
   A surface is a rectangular area that is displayed on the screen.
   It has a location, size and pixel contents.
@@ -1057,8 +1057,9 @@
 
 
   
-   Request notification when the next frame is displayed. Useful
-   for throttling redrawing operations, and driving animations.
+   Request notification when the next frame is used for the first time
+   by the compositor. Useful for throttling redrawing operations, and
+   driving animations.
The frame request will take effect on the next wl_surface.commit.
The notification will only be posted for one frame unless
requested again.
@@ -1235,6 +1236,69 @@
 

 
+
+
+
+  
+   This request is used to indicate the compositor at which ust time the
+   client wish the frame of next commit to hit the screen.
+
+   The request will take effect on the next wl_surface.commit.
+   The ust time indicated is in Milliseconds.
+
+   If the ust time requested has already happened, then the next commit
+   will be processed as any other commit.
+
+   The client can do another commit request without cancelling
+   a commit associated to a requested presentation time that has not
+   already happened.
+
+   The compositor can choose to ignore the indicated ust time, and for
+   example, if the client has queued too much buffers, it can choose to
+   treat some past commit with a future ust time, as commits with no
+   ust time indicated.
+
+   Calling a second time presentation_time on a wl_surface without doing
+   a commit will replace the last ust time indicated.
+  
+
+  
+
+
+
+  
+   Request notification when the next frame hits a physical screen.
+   This notification, which should happen after the frame notification,
+   can be used to synchronize video and audio better. The time given
+   will be ust time, in Milliseconds.
+
+   If, for any reason, the compositor determines that the frame will
+   never hit the screen, then the callback is called with 0 as argument,
+   instead of the ust time. One possible reason is that the compositor
+   choose to use a newer frame sent by the client.
+
+   The client is not supposed to throttle its drawing to this
+   notification, but to the frame notification.
+
+   If the frame hits multiple physical screens, only the first time it
+   hits a screen triggers the hit callback.
+
+   The hit request will take effect on the next wl_surface.commit.
+   The notification will only be posted for one frame unless
+   requested again.
+
+   A client can request a hit callback even without an attach,
+   damage, or any other state changes, since wl_surface.commit triggers a
+   display update.
+
+   The object returned by this request will be destroyed by the
+   compositor after the callback is fired and as such the client must not
+   attempt to use it after that point.
+  
+
+  
+
+
   
 
   A seat is a group of keyboards, pointer and touch devices. This
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] wl_surface video protocol extension

[Axel Davy]

On 28/10/2013, Daniel Stone wrote :


For programers having to cope with X and Wayland, and to better support the
Present extension, I reiterate my suggestion
to do something similar to the X Present extension.

Anything in particular? I'm well aware of Present, but am not entirely
sure what you're suggesting to do different.

I would like the extension incorporate the use of ust times to target, 
and the feedback contains the ust of when the frame has hit the screen.


About the number of interfaces and the difficulty to implement a 
compositor: Isn't the goal of versioning the ability to add 
functionalities with new version, that compositors with older version 
doesn't need to implement?


Axel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] wl_surface video protocol extension

[Axel Davy]

On 28/10/2013, Frederic Plourde wrote :
I don't know about current/future driver support for this new GSYNC 
technology... but you know what, I definitely agree with Pekka as we 
should get this protocol and basic buffer queuing implementation 
reviewd and working for the general case for now and add HW-specific 
extensions later.




I agree that we must come up with a working protocol soon, but I do not 
agree the one proposed was the best one.


I would prefer the current wl_surface interface to be extended that a 
new one created.
Adding a new interface is not the best performance-wise, and I see no 
reason why we would seperate these features

from wl_surface.

For programers having to cope with X and Wayland, and to better support 
the Present extension, I reiterate my suggestion

to do something similar to the X Present extension.

Axel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] wl_surface video protocol extension

[Axel Davy]

On Mon, 28 Oct 2013, Pekka Paalanen wrote:



The only immediate effect I could see for the protocol proposal is
to replace the frequency field in a "monitor refresh rate changed"
event with a min and max duration, or whatever that could actually
describe how GSYNC affects timings.


I don't understand in which situations you would need to know this 
refresh rate. Again, I advocate to do the same thing than the X present 
extension: the ability to ask the frame to hit the screen at a specific 
ust 'if possible' and get the feedback at which ust it did actually hit 
the screen. If a client wants to estimate the refresh rate, it can.




I also expect video player timing algorithms to need to actually
take GSYNC into account, or they might become unstable as there is
no constant refresh rate. At least they would need to know about
GSYNC to take advantage of it.



The best for video players is the ability to ask the frame to be shown 
at a specific ust and get the feedback at which ust it did hit the 
screen. Then they don't have to care much about refresh rate.



IOW, I'm not sure it's worth to design support for GSYNC at the
moment. I am tempted to say that let's leave it for another
extension (should not be too hard or invasive to add later, as the
only thing changing is the concept of output refresh rate, right?),
and wait for the hardware to be widely adopted. Oh, and also driver
support?


I see no real issue to support GSYNC.


Axel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] clients: add simple-dmabuf

[Axel Davy]

On 22/10/2013 17:23, David Herrmann wrote :

Btw., I got this working with i915 by allowing GEM_OPEN/GEM_FLINK on
the render-node. So if someone else tests this, you might need the
same hacks. I will try to find the code in mesa that requires this.

David


This comes from 'intel_region_alloc_for_handle', which is called in 
'intel_process_dri2_buffer'.


I've just talked with Christopher James Halse Rogers, and he already 
made patches that should solve that.


The patches to support driImage version 7 were posted recently on Mesa,

And his older patches (probably need rebasing):
https://github.com/RAOF/mesa/commit/cc797647eaa0e59929eca09ad1c5936cab74144b
https://github.com/RAOF/mesa/commit/1ff8df28f25f98b2e4a12f7fb3085b7d0adbfdf3
https://github.com/RAOF/mesa/commit/59e6361e9c76bb32c3fe96482ae0b31493dc3b3c

Combined with setting the name field to null (instead of generating a 
name) and setting the fd field to a prime dma-buf when creating a buffer 
(in get_back_bo),
it should avoid using names at all, and use dma-buf in Mesa, thus 
enabling using render-nodes with Mesa.



Axel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] clients: add simple-dmabuf

[Axel Davy]

On 22/10/2013 17:23, David Herrmann wrote :

Btw., I got this working with i915 by allowing GEM_OPEN/GEM_FLINK on
the render-node. So if someone else tests this, you might need the
same hacks. I will try to find the code in mesa that requires this.

David


This comes from 'intel_region_alloc_for_handle', which is called in 
'intel_process_dri2_buffer'.


I understand the will to depreciate GEM_FLINK and GEM_OPEN, but are we 
really ready to forbid using it?


I was rewriting my Prime support patches to use render-nodes, but I 
wasn't able to have anything working due to these restrictions. Mesa 
drivers would need changes to use fd instead of names, as for any other 
project using names instead of fd, and that we would like to run on a 
render-node (glamor, etc, ...).


Since we can't generate a magic number with a render-node, that means 
that every dri2 application won't be able to work under XWayland running 
under Prime -if we use render-nodes-. I would have been happy to have a 
fake magic number generated that would just refuse authentication (but 
XWayland would have said "you are authenticated" to a client if on 
render-node). Instead it would have to wait dri3 to have accelerated 
applications under Prime, and all dri2 applications not ported to dri3 
won't work.


Axel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Buffer release events (was: Add support for eglSwapInterval)

[Axel Davy]

On Wed, 23 Oct 2013, Jason Ekstrand wrote:


There may also be a way that we can sidestep the whole issue.  (I suggested
this to Axel Davy [mannerov] and it worked for him in his wlglamor DDX.)  


The solution is to send a
wl_display.sync request immediately after the commit.  This will force any
queued wl_buffer.release events to get sent out immediately.  The client can
even destroy the returned proxy immediately and completely ignore the
resulting event.  This seems a bit hackish, but this is exactly the kind of
thing the sync request is intended for: flushing the stream.



Well I can give my feedback about it:
I send a dummy sync request after the commit, and I don't have to care 
about it. I don't even test if the sync callback was called.


I don't need to use dummy frame listeners, and using the dummy sync 
request solves the issues in all the cases. When the application is 
fullscreen and the buffers are used as scanout, I don't have any issue 
too with release events.


I'm not sure however this is the best way to solve the issue. As 
mentionned by Jason, this can be used as a fallback for a compositor not 
supporting your new wl_surface extension.___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] wl_surface video protocol extension

[Axel Davy]

I think the simpler is to have a similar functionalities to the X 
Present extension:


git://people.freedesktop.org/~keithp/presentproto master


We can ask a buffer to be shown at a specific ust time, and we get the 
feedback at which ust

time it has hit the screen. And we could queue buffers.

It looks quite sane to me, and doing the same would help writing the 
support to the X Present extension.


It solves the problem you mentions, James Courtier-Dutton, since a Video 
Player that doesn't get their buffers back and know they didn't hit the 
screen, will understand it has to suspend, and will resume when it gets 
the feedbacks.


Axel Davy

Le 21/10/2013 16:33, James Courtier-Dutton a écrit :

Hi,

One last thing to consider, regarding the clock used and the timestamps.
The video frames should pause during system suspend, and continue on 
resume.





___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Fwd: Re: [PATCH 0/2] Add New XWayland API

[Axel Davy]

I suggest putting the XWayland API in a separate library.

There's still many things to fix (handling of the cursor for example),
and if we keep XWayland outside of the Xserver, I believe it's going
to be easier to update the API, and eventually break it when
 it is needed.

I've looked closer at dri3 and Present extension, and I think we
should implement in the XWayland API our own Present extension
implementation. The implementation in the Xserver doesn't seem
to fit well to an XWayland model, but the specifications give me
the hope that we could do an implementation specially designed
for XWayland, that will be easier to deal with than the current one.

I like in the Present extension that the client sets a fence to know
when a buffer is free (it corresponds to our buffer release semantic),
 and the options PresentOptionAsync and PresentOptionCopy,
which allows us to know if the client wants a copy, or if we can
send the buffer directly to the Wayland compositor.


Given that we still need some features to support the Present
extension well (get the time at which buffers hit the screen,
cancel a scheduled pageflip, ask for a buffer to hit the screen
at a specific time, etc), I think we should start with my new API
proposal, and replace it (and dri2 support in the DDX), when
we have the materials Wayland side to implement the Present
extension.

Axel Davy



Given the recent discussion on the xorg-devel mailing list,
I think this new API shouldn't be merged within the X server.

The clear goal of the xorg team is toward dri3, and I was told
no patch enabling AsyncSwap for dri2 would be merged.

To implement the Present extension and composite efficiently,
the XWayland API would have to be rewritten anyway. And since
Present redirection shouldn't make it for X 1.15, but 1.16, it's
probably better waiting X 1.16 for a XWayland API rewrite.

I will include this API proposal with wlglamor, and add options to use
AsyncSwap even when vsync is enabled. (and we'll have the choice to
cap to frame rate or not)

I've tried benchmarking AsyncSwap with the phoronix-test-suite,
and I was surprised to see a regression with Openarena and Xonotic.
According to dri devs, it is because, since I do an exchange, the
application
is fullscreen and then Weston uses the buffer as scanout buffer, when
the buffer is
released and we render again in the buffer, L3 caching is disabled.
I don't know if there's similar issues with other drivers, but I think
this is a problem that should be solved, since the problem will occur
for any fullscreen Wayland applications when bypassing
compositing is enabled.

It makes more sense in this case to have AsyncSwap support only as an
option:
Tearings will go away anyway with it, but for some applications you'll
have a gain, and
some others not. When drivers fix this behaviour, it should always be a
gain.

And since Gnome 3.10 doesn't bypass compositing yet, if I have well
understood, then
for them it'll always be a performance benefit.

Axel Davy



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Fwd: Re: [PATCH 0/2] Add New XWayland API

[Axel Davy]

> On Sat, Oct 19, 2013 at 10:49:04AM +0200, Axel Davy wrote:
>> I've tried benchmarking AsyncSwap with the phoronix-test-suite,
>> and I was surprised to see a regression with Openarena and Xonotic.
>> According to dri devs, it is because, since I do an exchange, the
>> application
>> is fullscreen and then Weston uses the buffer as scanout buffer, when
>> the buffer is
>> released and we render again in the buffer, L3 caching is disabled.
>
> It is simple to demonstrate that hypothesis incorrect by marking all
> colour buffers as uncached.
> -Chirs
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>

Unfortunately, I can't test that with wlglamor, since there is too many
abstraction: I don't have access to the caching of the buffers.

I did many tests, and the only conclusion I've came to is that a buffer we
used for the framebuffer
 is slower to render to after.

I've also compared Bypass compositing + no AsyncSwap vs No Bypass
compositing + AsyncSwap, and
as expected, it performs the same (and in the latter case, we don't get
tearings). (And of course,
it performs better than No Bypass compositing + no AsyncSwap, or Bypass
compositing + AsyncSwap + useless copy)

Axel Davy

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Fwd: Re: [PATCH 0/2] Add New XWayland API

[Axel Davy]

Given the recent discussion on the xorg-devel mailing list,
I think this new API shouldn't be merged within the X server.

The clear goal of the xorg team is toward dri3, and I was told
no patch enabling AsyncSwap for dri2 would be merged.

To implement the Present extension and composite efficiently,
the XWayland API would have to be rewritten anyway. And since
Present redirection shouldn't make it for X 1.15, but 1.16, it's
probably better waiting X 1.16 for a XWayland API rewrite.

I will include this API proposal with wlglamor, and add options to use
AsyncSwap even when vsync is enabled. (and we'll have the choice to
cap to frame rate or not)

I've tried benchmarking AsyncSwap with the phoronix-test-suite,
and I was surprised to see a regression with Openarena and Xonotic.
According to dri devs, it is because, since I do an exchange, the
application
is fullscreen and then Weston uses the buffer as scanout buffer, when
the buffer is
released and we render again in the buffer, L3 caching is disabled.
I don't know if there's similar issues with other drivers, but I think
this is a problem that should be solved, since the problem will occur
for any fullscreen Wayland applications when bypassing
compositing is enabled.

It makes more sense in this case to have AsyncSwap support only as an
option:
Tearings will go away anyway with it, but for some applications you'll
have a gain, and
some others not. When drivers fix this behaviour, it should always be a
gain.

And since Gnome 3.10 doesn't bypass compositing yet, if I have well
understood, then
for them it'll always be a performance benefit.

Axel Davy


The current XWayland API has no functionality to help the DDXs
implement ScheduleSwap. This new API proposal introduces functions
to manipulate the frame event, the release event, and to manipulate
the buffers that the Wayland compositor sees.

The first patch is not linked directly to XWayland,
it is a patch initially written by Chris Wilson, that
enables some useful optimisations DDX side when swap_interval=0
(AsyncSwap).

The new XWayland API enables to do an efficient implementation
of AsyncSwap.

I have implemented ScheduleSwap and AsyncSwap in the wlglamor DDX to
test the API.

For XWayland, applications which benefit from AsyncSwap are applications
with no decoration window, like fullscreen applications.

For example with an intel hd4000, with a fullscreen glmark2(1920x1080),
the terrain benchmark goes from 49 fps to 53 fps, and the ideas benchmark
goes from 397 fps to 645 fps. All this because we avoid a copy. Moreover,
AsyncSwap allows suppress tearings for fullscreen applications because we
can respect the Wayland buffer release semantic.

The new function xwl_add_frame_todo_visible_window allows to implement
ScheduleSwap, and xwl_display_get allows to get the wl_display used by
XWayland.

The API introduces a new object: xwl_buffer, which is use to manipulate
the buffers linked with Wayland and the buffer exposed by the
windows shown to the Wayland compositor.


Axel Davy (2):
   Patch to the Xserver to support AsyncSwap
   Add new XWayland API.

  hw/xfree86/dri2/dri2.c |  36 --
  hw/xfree86/dri2/dri2.h |   8 +-
  hw/xfree86/xwayland/Makefile.am|   2 +
  hw/xfree86/xwayland/xwayland-buffers.c | 114 +
  hw/xfree86/xwayland/xwayland-drm.c |  10 +-
  hw/xfree86/xwayland/xwayland-events.c  | 222 +
  hw/xfree86/xwayland/xwayland-private.h |  20 ++-
  hw/xfree86/xwayland/xwayland-window.c  |  21 ++--
  hw/xfree86/xwayland/xwayland.c |  23 +++-
  hw/xfree86/xwayland/xwayland.h |  68 ++
  10 files changed, 496 insertions(+), 28 deletions(-)
  create mode 100644 hw/xfree86/xwayland/xwayland-buffers.c
  create mode 100644 hw/xfree86/xwayland/xwayland-events.c





___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/2] Patch to the Xserver to support AsyncSwap

[Axel Davy]

I should have add a link to the initial patch:
http://lists.x.org/archives/xorg-devel/2011-June/023102.html 
<http://lists.x.org/archives/xorg-devel/2011-June/023102.html>


Other versions of the patch are:
_http://lists.x.org/archives/xorg-devel/2012-November/034446.html 
<http://lists.x.org/archives/xorg-devel/2012-November/034446.html>

http://lists.x.org/archives/xorg-devel/2013-September/037661.html_

Le 17/10/2013 00:16, Axel Davy a écrit :

The patch is a modified version of a Chris Wilson patch of 2011.
It makes the X server call AsyncSwap, defined by the DDX, when
it does a dri2 swap and swap_interval is 0. It allows the DDX
to avoid the copy if possible, and reduce tearings.

Signed-off-by: Axel Davy 
---
  hw/xfree86/dri2/dri2.c | 36 
  hw/xfree86/dri2/dri2.h |  8 +++-
  2 files changed, 31 insertions(+), 13 deletions(-)

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 483d630..7b06da9 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -118,6 +118,7 @@ typedef struct _DRI2Screen {
  DRI2CreateBufferProcPtr CreateBuffer;
  DRI2DestroyBufferProcPtr DestroyBuffer;
  DRI2CopyRegionProcPtr CopyRegion;
+DRI2AsyncSwapProcPtr AsyncSwap;
  DRI2ScheduleSwapProcPtr ScheduleSwap;
  DRI2GetMSCProcPtr GetMSC;
  DRI2ScheduleWaitMSCProcPtr ScheduleWaitMSC;
@@ -1107,20 +1108,30 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw, 
CARD64 target_msc,
  
  /* Old DDX or no swap interval, just blit */

  if (!ds->ScheduleSwap || !pPriv->swap_interval || pPriv->prime_id) {
-BoxRec box;
-RegionRec region;
-
-box.x1 = 0;
-box.y1 = 0;
-box.x2 = pDraw->width;
-box.y2 = pDraw->height;
-RegionInit(®ion, &box, 0);
-
  pPriv->swapsPending++;
  
-dri2_copy_region(pDraw, ®ion, pDestBuffer, pSrcBuffer);

-DRI2SwapComplete(client, pDraw, target_msc, 0, 0, DRI2_BLIT_COMPLETE,
- func, data);
+if (ds->AsyncSwap)
+{
+(*ds->AsyncSwap)(client, pDraw,
+ pDestBuffer, pSrcBuffer,
+ func, data);
+DRI2InvalidateDrawableAll(pDraw);
+}
+else
+{
+BoxRec box;
+RegionRec region;
+
+box.x1 = 0;
+box.y1 = 0;
+box.x2 = pDraw->width;
+box.y2 = pDraw->height;
+RegionInit(®ion, &box, 0);
+
+dri2_copy_region(pDraw, ®ion, pDestBuffer, pSrcBuffer);
+DRI2SwapComplete(client, pDraw, target_msc, 0, 0,
+ DRI2_BLIT_COMPLETE, func, data);
+}
  return Success;
  }
  
@@ -1463,6 +1474,7 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
  
  if (info->version >= 10) {

  ds->AuthMagic = info->AuthMagic3;
+ds->AsyncSwap = info->AsyncSwap;
  }
  if (info->version >= 8) {
  ds->LegacyAuthMagic2 = info->AuthMagic2;
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index ed67d01..f376e42 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -52,7 +52,12 @@ extern CARD8 dri2_minor;
  typedef DRI2BufferRec DRI2Buffer2Rec, *DRI2Buffer2Ptr;
  typedef void (*DRI2SwapEventPtr) (ClientPtr client, void *data, int type,
CARD64 ust, CARD64 msc, CARD32 sbc);
-
+typedef void (*DRI2AsyncSwapProcPtr)(ClientPtr client,
+ DrawablePtr pDraw,
+ DRI2BufferPtr pDestBuffer,
+ DRI2BufferPtr pSrcBuffer,
+ DRI2SwapEventPtr func,
+ void *data);
  typedef DRI2BufferPtr(*DRI2CreateBuffersProcPtr) (DrawablePtr pDraw,
unsigned int *attachments,
int count);
@@ -257,6 +262,7 @@ typedef struct {
  
  /* added in version 10 */

  DRI2AuthMagic3ProcPtr AuthMagic3;
+DRI2AsyncSwapProcPtr AsyncSwap;
  } DRI2InfoRec, *DRI2InfoPtr;
  
  extern _X_EXPORT Bool DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info);


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 2/2] Add new XWayland API.

[Axel Davy]

The new API:
.Allows to use the frame event.
.Introduces a new object: xwl_buffer, that allow to manipulate
the buffer sent to the Wayland compositor.
.Allows to use the release event.

Signed-off-by: Axel Davy 
---
 hw/xfree86/xwayland/Makefile.am|   2 +
 hw/xfree86/xwayland/xwayland-buffers.c | 114 +
 hw/xfree86/xwayland/xwayland-drm.c |  10 +-
 hw/xfree86/xwayland/xwayland-events.c  | 222 +
 hw/xfree86/xwayland/xwayland-private.h |  20 ++-
 hw/xfree86/xwayland/xwayland-window.c  |  21 ++--
 hw/xfree86/xwayland/xwayland.c |  23 +++-
 hw/xfree86/xwayland/xwayland.h |  68 ++
 8 files changed, 465 insertions(+), 15 deletions(-)
 create mode 100644 hw/xfree86/xwayland/xwayland-buffers.c
 create mode 100644 hw/xfree86/xwayland/xwayland-events.c

diff --git a/hw/xfree86/xwayland/Makefile.am b/hw/xfree86/xwayland/Makefile.am
index 22ab154..43209f4 100644
--- a/hw/xfree86/xwayland/Makefile.am
+++ b/hw/xfree86/xwayland/Makefile.am
@@ -21,6 +21,8 @@ libxwayland_la_SOURCES =  \
xwayland-output.c   \
xwayland-cursor.c   \
xwayland-window.c   \
+   xwayland-buffers.c  \
+   xwayland-events.c   \
xwayland-private.h  \
drm-client-protocol.h   \
drm-protocol.c  \
diff --git a/hw/xfree86/xwayland/xwayland-buffers.c 
b/hw/xfree86/xwayland/xwayland-buffers.c
new file mode 100644
index 000..94361b5
--- /dev/null
+++ b/hw/xfree86/xwayland/xwayland-buffers.c
@@ -0,0 +1,114 @@
+/*
+ * Copyright © 2013 Axel Davy
+ *
+ * Permission to use, copy, modify, distribute, and sell this software
+ * and its documentation for any purpose is hereby granted without
+ * fee, provided that the above copyright notice appear in all copies
+ * and that both that copyright notice and this permission notice
+ * appear in supporting documentation, and that the name of the
+ * copyright holders not be used in advertising or publicity
+ * pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no
+ * representations about the suitability of this software for any
+ * purpose.  It is provided "as is" without express or implied
+ * warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+ * SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+ * FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+ * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
+ * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+ * SOFTWARE.
+ */ 
+
+
+#ifdef HAVE_XORG_CONFIG_H
+#include "xorg-config.h"
+#endif
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xwayland.h"
+#include "xwayland-private.h"
+
+
+/*
+ * Buffer Management API
+ * Exchange buffers,
+ * Create Buffers if needed,
+ * Deleted Buffers
+ * 
+ */
+
+
+
+Bool xwl_is_released_buffer(struct xwl_buffer* xwl_buffer)
+{
+  return !xwl_buffer->busy; 
+}
+
+struct xwl_buffer* xwl_get_xwl_buffer_from_visible_window(WindowPtr window)
+{
+  struct xwl_window* xwl_window = get_xwl_window(window);
+  if (!xwl_window) /* Is not in our 'visible' list */
+return NULL;
+  return xwl_window->buffer;
+}
+
+struct xwl_buffer* 
+xwl_exchange_xwl_buffer_from_visible_window(WindowPtr window,
+   struct xwl_buffer* new_xwl_buffer)
+{
+  struct xwl_window* xwl_window = get_xwl_window(window);
+  struct xwl_buffer* temp;
+  if (!xwl_window || !new_xwl_buffer) /* Is not in our 'visible' list */
+return new_xwl_buffer;
+  temp = xwl_window->buffer;
+  xwl_window->buffer = new_xwl_buffer;
+  return temp;
+}
+
+struct xwl_buffer* 
+xwl_create_new_xwl_buffer_from_pixmap(struct xwl_screen* xwl_screen,
+ WindowPtr window,
+ PixmapPtr pixmap)
+{
+  struct xwl_window *xwl_window = calloc(sizeof *xwl_window, 1);
+  struct xwl_buffer *xwl_buffer = NULL;
+  if(!xwl_window)
+return NULL;
+  xwl_window->xwl_screen = xwl_screen;
+  xwl_window->window = window;
+  xwl_window->buffer = calloc(sizeof (struct xwl_buffer), 1);
+  if(!xwl_window->buffer)
+goto quit;
+  xwl_screen->driver->create_window_buffer(xwl_window, pixmap);
+  if(xwl_window->buffer->buffer)
+xwl_buffer = xwl_window->buffer;
+  else
+free(xwl_window->buffer);
+quit:
+  free(xwl_window);
+  return xwl_buffer;
+}
+
+void xwl_delete_xwl_buffer(s

[PATCH 1/2] Patch to the Xserver to support AsyncSwap

[Axel Davy]

The patch is a modified version of a Chris Wilson patch of 2011.
It makes the X server call AsyncSwap, defined by the DDX, when
it does a dri2 swap and swap_interval is 0. It allows the DDX
to avoid the copy if possible, and reduce tearings.

Signed-off-by: Axel Davy 
---
 hw/xfree86/dri2/dri2.c | 36 
 hw/xfree86/dri2/dri2.h |  8 +++-
 2 files changed, 31 insertions(+), 13 deletions(-)

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 483d630..7b06da9 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -118,6 +118,7 @@ typedef struct _DRI2Screen {
 DRI2CreateBufferProcPtr CreateBuffer;
 DRI2DestroyBufferProcPtr DestroyBuffer;
 DRI2CopyRegionProcPtr CopyRegion;
+DRI2AsyncSwapProcPtr AsyncSwap;
 DRI2ScheduleSwapProcPtr ScheduleSwap;
 DRI2GetMSCProcPtr GetMSC;
 DRI2ScheduleWaitMSCProcPtr ScheduleWaitMSC;
@@ -1107,20 +1108,30 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw, 
CARD64 target_msc,
 
 /* Old DDX or no swap interval, just blit */
 if (!ds->ScheduleSwap || !pPriv->swap_interval || pPriv->prime_id) {
-BoxRec box;
-RegionRec region;
-
-box.x1 = 0;
-box.y1 = 0;
-box.x2 = pDraw->width;
-box.y2 = pDraw->height;
-RegionInit(®ion, &box, 0);
-
 pPriv->swapsPending++;
 
-dri2_copy_region(pDraw, ®ion, pDestBuffer, pSrcBuffer);
-DRI2SwapComplete(client, pDraw, target_msc, 0, 0, DRI2_BLIT_COMPLETE,
- func, data);
+if (ds->AsyncSwap)
+{
+(*ds->AsyncSwap)(client, pDraw,
+ pDestBuffer, pSrcBuffer,
+ func, data);
+DRI2InvalidateDrawableAll(pDraw);
+}
+else
+{
+BoxRec box;
+RegionRec region;
+
+box.x1 = 0;
+box.y1 = 0;
+box.x2 = pDraw->width;
+box.y2 = pDraw->height;
+RegionInit(®ion, &box, 0);
+
+dri2_copy_region(pDraw, ®ion, pDestBuffer, pSrcBuffer);
+DRI2SwapComplete(client, pDraw, target_msc, 0, 0,
+ DRI2_BLIT_COMPLETE, func, data);
+}
 return Success;
 }
 
@@ -1463,6 +1474,7 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
 
 if (info->version >= 10) {
 ds->AuthMagic = info->AuthMagic3;
+ds->AsyncSwap = info->AsyncSwap;
 }
 if (info->version >= 8) {
 ds->LegacyAuthMagic2 = info->AuthMagic2;
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index ed67d01..f376e42 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -52,7 +52,12 @@ extern CARD8 dri2_minor;
 typedef DRI2BufferRec DRI2Buffer2Rec, *DRI2Buffer2Ptr;
 typedef void (*DRI2SwapEventPtr) (ClientPtr client, void *data, int type,
   CARD64 ust, CARD64 msc, CARD32 sbc);
-
+typedef void (*DRI2AsyncSwapProcPtr)(ClientPtr client,
+ DrawablePtr pDraw,
+ DRI2BufferPtr pDestBuffer,
+ DRI2BufferPtr pSrcBuffer,
+ DRI2SwapEventPtr func,
+ void *data);
 typedef DRI2BufferPtr(*DRI2CreateBuffersProcPtr) (DrawablePtr pDraw,
   unsigned int *attachments,
   int count);
@@ -257,6 +262,7 @@ typedef struct {
 
 /* added in version 10 */
 DRI2AuthMagic3ProcPtr AuthMagic3;
+DRI2AsyncSwapProcPtr AsyncSwap;
 } DRI2InfoRec, *DRI2InfoPtr;
 
 extern _X_EXPORT Bool DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info);
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 0/2] Add New XWayland API

[Axel Davy]

The current XWayland API has no functionality to help the DDXs 
implement ScheduleSwap. This new API proposal introduces functions
to manipulate the frame event, the release event, and to manipulate 
the buffers that the Wayland compositor sees.

The first patch is not linked directly to XWayland,
it is a patch initially written by Chris Wilson, that 
enables some useful optimisations DDX side when swap_interval=0
(AsyncSwap).

The new XWayland API enables to do an efficient implementation
of AsyncSwap. 

I have implemented ScheduleSwap and AsyncSwap in the wlglamor DDX to
test the API.

For XWayland, applications which benefit from AsyncSwap are applications 
with no decoration window, like fullscreen applications.

For example with an intel hd4000, with a fullscreen glmark2(1920x1080),
the terrain benchmark goes from 49 fps to 53 fps, and the ideas benchmark
goes from 397 fps to 645 fps. All this because we avoid a copy. Moreover,
AsyncSwap allows suppress tearings for fullscreen applications because we 
can respect the Wayland buffer release semantic.  

The new function xwl_add_frame_todo_visible_window allows to implement
ScheduleSwap, and xwl_display_get allows to get the wl_display used by 
XWayland.

The API introduces a new object: xwl_buffer, which is use to manipulate
the buffers linked with Wayland and the buffer exposed by the 
windows shown to the Wayland compositor.


Axel Davy (2):
  Patch to the Xserver to support AsyncSwap
  Add new XWayland API.

 hw/xfree86/dri2/dri2.c |  36 --
 hw/xfree86/dri2/dri2.h |   8 +-
 hw/xfree86/xwayland/Makefile.am|   2 +
 hw/xfree86/xwayland/xwayland-buffers.c | 114 +
 hw/xfree86/xwayland/xwayland-drm.c |  10 +-
 hw/xfree86/xwayland/xwayland-events.c  | 222 +
 hw/xfree86/xwayland/xwayland-private.h |  20 ++-
 hw/xfree86/xwayland/xwayland-window.c  |  21 ++--
 hw/xfree86/xwayland/xwayland.c |  23 +++-
 hw/xfree86/xwayland/xwayland.h |  68 ++
 10 files changed, 496 insertions(+), 28 deletions(-)
 create mode 100644 hw/xfree86/xwayland/xwayland-buffers.c
 create mode 100644 hw/xfree86/xwayland/xwayland-events.c

-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

A new XWayland Glamor DDX

[Axel Davy]

Hi All,

I've published a new XWayland DDX based on Glamor.

The source code is inspired from the Radeon DDX.

I've tested it on an intel hd4000 and an Amd hd7730m without issues. 
(Need a recent Xserver with XWayland support).


More tests and comments are welcomed.


The source code can be found here:

https://github.com/axeldavy/xf86-video-wlglamor


Axel Davy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 4/9] output gl repaint in clone mode

[Axel Davy]

How does this work if the primary output frequency is more than the
clone output?

I'm afraid the weston log might become very big after a while when
running a such a configuration

Axel Davy

Le 18/09/2013 05:50, Xiong Zhang a écrit :

Only repsone to primary output repaint request; Primary output and
clone output share the same frame buffer, once primary output do page
flip, clone output will do page flip also. When both primary output
and clone output finish the page flip, the fb obj can be released.

Signed-off-by: Xiong Zhang 
---
  src/compositor-drm.c | 101 +++
  src/compositor.c |   9 +
  2 files changed, 110 insertions(+)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 8d16d29..0b9ab45 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -103,6 +103,8 @@ struct drm_compositor {

clockid_t clock;
struct udev_input input;
+
+   uint32_t flip_counter;
  };

  struct drm_mode {
@@ -581,6 +583,12 @@ drm_output_repaint(struct weston_output *output_base,
struct drm_sprite *s;
struct drm_mode *mode;
int ret = 0;
+   struct drm_output *clone_output;
+
+   /*ignore clone output repaint request*/
+   if ((compositor->base.multiscreen_mode == WESTON_MULTISCREEN_CLONE) &&
+   output_base != compositor->base.primary_output)
+   return;

if (!output->next)
drm_output_render(output, damage);
@@ -598,6 +606,22 @@ drm_output_repaint(struct weston_output *output_base,
return;
}
output_base->set_dpms(output_base, WESTON_DPMS_ON);
+   if (compositor->base.multiscreen_mode == 
WESTON_MULTISCREEN_CLONE) {
+   wl_list_for_each(clone_output, 
&compositor->base.output_list, base.link) {
+   if (&clone_output->base != output_base) {
+   mode = 
container_of(clone_output->base.current, struct drm_mode, base);
+   ret = drmModeSetCrtc(compositor->drm.fd, 
clone_output->crtc_id,
+   
output->next->fb_id, 0, 0,
+   
&clone_output->connector_id, 1,
+   
&mode->mode_info);
+   if (ret) {
+   weston_log("set mode failed: 
%m\n");
+   return;
+   }
+   
clone_output->base.set_dpms(&clone_output->base, WESTON_DPMS_ON);
+   }
+   }
+   }
}

if (drmModePageFlip(compositor->drm.fd, output->crtc_id,
@@ -608,6 +632,21 @@ drm_output_repaint(struct weston_output *output_base,
}

output->page_flip_pending = 1;
+   compositor->flip_counter++;
+
+   if (compositor->base.multiscreen_mode == WESTON_MULTISCREEN_CLONE) {
+   wl_list_for_each(clone_output, &compositor->base.output_list, 
base.link) {
+   if (&clone_output->base != output_base) {
+   if (drmModePageFlip(compositor->drm.fd, 
clone_output->crtc_id,
+   
output->next->fb_id,
+   
DRM_MODE_PAGE_FLIP_EVENT, clone_output) < 0) {
+   weston_log("queueing pageflip failed: 
%m\n");
+   return;
+   }
+   compositor->flip_counter++;
+   }
+   }
+   }

drm_output_set_cursor(output);

@@ -666,9 +705,19 @@ drm_output_start_repaint_loop(struct weston_output 
*output_base)
struct drm_compositor *compositor = (struct drm_compositor *)
output_base->compositor;
uint32_t fb_id;
+   struct drm_output *clone_output;

struct timespec ts;

+   /* ignore clone output repaint request */
+   /* clear clone_output->repaint_scheduled, so when clone_output became 
primary */
+   /* output, it can repaint */
+   if ((compositor->base.multiscreen_mode == WESTON_MULTISCREEN_CLONE) &&
+   output_base != compositor->base.primary_output) {
+   output_base->repaint_scheduled = 0;
+   return;
+   }
+
if (!output->current) {
/* We can't page flip if there's no mode

Re: Absolute coordinates using "wl_shell_surface_set_transient"

[Axel Davy]

Yes:
http://cgit.freedesktop.org/wayland/weston/commit/?id=ca43f0942e23356a0a0f3e08e4d20a8a31b4d629

Axel Davy

On Tue, 17 Sep 2013, Tarnyko wrote:

Great ! Do you by chance have the reference of the patch, and know if it's 
applied on the Wayland, Weston, Xorg... repository ? 
Regards 
Axel Davy writes: 
Did you test with git master? There has been a patch recently about this. 
Axel Davy 
Le 17/09/2013 10:37, Tarnyko a écrit :

Hi Giulio, Bill,
We were originally investigating a problem happening when using X/GTK 
applications under XWayland ; most of the menus appeared badly positioned 
when they opened.
For example, under Evolution with XWayland, when opening the "File" menu, 
the menu appears but outside the application's window.
We supposed (but we maybe wrong) that the menu may be a X11 Window, then 
wrapped as a surface by XWayland, as the bug was related to Weston badly 
calculating the new surface coordinates.

(BTW, it would be great if you had an opinion/insight on this matter)
Thanks for all your answers, nice to see some reactivity on this list :-).
Regards,
Tarnyko 
Bill Spitzak writes:


Giulio Camuffo wrote:
No, it's not supposed to work, and if it works it's just by pure chance 
and/or because of how the shell works internally.
There is no way to place a surface to an absolute position from the 
client side, but there may be ways to solve your problem in a different 
way.

What are you trying to achieve?
Loading saved window arrangements from a client's configuration file is 
the likely reason. At the moment this is a problem for migrating our 
software to Wayland. I understand the desire to remove this from Wayland 
but I am somewhat stumped on any other way for Wayland to provide this 
functionality. It appears it is possible for X clients to do this, so I 
think the battle is lost and Wayland should add this for non-X clients.
I agree the supplied code should not work. Attempting to set a loop in 
the surface parents should be an error.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel 



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v3] Restoring alpha after the shell effects.

[Axel Davy]

After the fade or zoom effects, alpha could not have been 1.0, preventing
not redrawing behind opaque windows.

This patch add a reset function in weston_surface_animation to reset
some variables the effects affect.

Signed-off-by: Axel Davy 
---
 src/animation.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/src/animation.c b/src/animation.c
index 0b2fa95..7438111 100644
--- a/src/animation.c
+++ b/src/animation.c
@@ -124,6 +124,7 @@ struct weston_surface_animation {
struct wl_listener listener;
float start, stop;
weston_surface_animation_frame_func_t frame;
+   weston_surface_animation_frame_func_t reset;
weston_surface_animation_done_func_t done;
void *data;
 };
@@ -134,6 +135,8 @@ weston_surface_animation_destroy(struct 
weston_surface_animation *animation)
wl_list_remove(&animation->animation.link);
wl_list_remove(&animation->listener.link);
wl_list_remove(&animation->transform.link);
+   if (animation->reset)
+   animation->reset(animation);
weston_surface_geometry_dirty(animation->surface);
if (animation->done)
animation->done(animation, animation->data);
@@ -179,6 +182,7 @@ static struct weston_surface_animation *
 weston_surface_animation_run(struct weston_surface *surface,
 float start, float stop,
 weston_surface_animation_frame_func_t frame,
+weston_surface_animation_frame_func_t reset,
 weston_surface_animation_done_func_t done,
 void *data)
 {
@@ -190,6 +194,7 @@ weston_surface_animation_run(struct weston_surface *surface,
 
animation->surface = surface;
animation->frame = frame;
+   animation->reset = reset;
animation->done = done;
animation->data = data;
animation->start = start;
@@ -213,6 +218,14 @@ weston_surface_animation_run(struct weston_surface 
*surface,
 }
 
 static void
+reset_alpha(struct weston_surface_animation *animation)
+{
+   struct weston_surface *surface = animation->surface;
+
+   surface->alpha = animation->stop;
+}
+
+static void
 zoom_frame(struct weston_surface_animation *animation)
 {
struct weston_surface *es = animation->surface;
@@ -242,7 +255,8 @@ weston_zoom_run(struct weston_surface *surface, float 
start, float stop,
struct weston_surface_animation *zoom;
 
zoom = weston_surface_animation_run(surface, start, stop,
-   zoom_frame, done, data);
+   zoom_frame, reset_alpha,
+   done, data);
 
weston_spring_init(&zoom->spring, 300.0, start, stop);
zoom->spring.friction = 1400;
@@ -269,8 +283,9 @@ weston_fade_run(struct weston_surface *surface,
 {
struct weston_surface_animation *fade;
 
-   fade = weston_surface_animation_run(surface, 0, 0,
-   fade_frame, done, data);
+   fade = weston_surface_animation_run(surface, 0, end,
+   fade_frame, reset_alpha,
+   done, data);
 
weston_spring_init(&fade->spring, k, start, end);
 
@@ -307,7 +322,8 @@ weston_slide_run(struct weston_surface *surface, float 
start, float stop,
struct weston_surface_animation *animation;
 
animation = weston_surface_animation_run(surface, start, stop,
-slide_frame, done, data);
+slide_frame, NULL, done, 
+data);
if (!animation)
return NULL;
 
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Absolute coordinates using "wl_shell_surface_set_transient"

[Axel Davy]

Did you test with git master? There has been a patch recently about this.

Axel Davy

Le 17/09/2013 10:37, Tarnyko a écrit :

Hi Giulio, Bill,
We were originally investigating a problem happening when using X/GTK 
applications under XWayland ; most of the menus appeared badly 
positioned when they opened.
For example, under Evolution with XWayland, when opening the "File" 
menu, the menu appears but outside the application's window.
We supposed (but we maybe wrong) that the menu may be a X11 Window, 
then wrapped as a surface by XWayland, as the bug was related to 
Weston badly calculating the new surface coordinates.

(BTW, it would be great if you had an opinion/insight on this matter)
Thanks for all your answers, nice to see some reactivity on this list 
:-).

Regards,
Tarnyko

Bill Spitzak writes:



Giulio Camuffo wrote:
No, it's not supposed to work, and if it works it's just by pure 
chance and/or because of how the shell works internally.
There is no way to place a surface to an absolute position from the 
client side, but there may be ways to solve your problem in a 
different way.

What are you trying to achieve?
Loading saved window arrangements from a client's configuration file 
is the likely reason. At the moment this is a problem for migrating 
our software to Wayland. I understand the desire to remove this from 
Wayland but I am somewhat stumped on any other way for Wayland to 
provide this functionality. It appears it is possible for X clients 
to do this, so I think the battle is lost and Wayland should add this 
for non-X clients.
I agree the supplied code should not work. Attempting to set a loop 
in the surface parents should be an error.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] xwm: set the shell_surface's title

[Axel Davy]

It crashes in set_title, when called by one of the functions in 
XWayland window manager. Looks like it try to free something it isn't 
allowed to free (maybe is in use?).


I get the crash with firefox after less than 1 minute playing with the 
menus, and with vlc when looking a video and moving the mouse at the 
same time during a few minutes.


If I remove the two calls to set_title in XWayland (removing only one 
doesn't remove the crash), it fixes the crash.


Axel Davy

On Mon, 16 Sep 2013, Giulio Camuffo wrote:


How does it crash? And when doing what?
Giulio


2013/9/15 Axel Davy 

  This patch makes XWayland often crash for me.

  Axel Davy

  Le 11/09/2013 18:20, Giulio Camuffo a écrit :
add a new function pointer to the
weston_shell_interface struct that
shells will set accordingly.
---
  src/compositor.h              |  2 ++
  src/shell.c                   | 11 +--
  src/xwayland/window-manager.c | 11 +++
  3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/src/compositor.h b/src/compositor.h
index 3c1b643..ead0c91 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -107,6 +107,8 @@ struct weston_shell_interface {
        int (*move)(struct shell_surface *shsurf,
struct weston_seat *ws);
        int (*resize)(struct shell_surface *shsurf,
                      struct weston_seat *ws,
uint32_t edges);
+       void (*set_title)(struct shell_surface
*shsurf,
+                         const char *title);

  };

diff --git a/src/shell.c b/src/shell.c
index dc15bfa..ea4315a 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1595,13 +1595,19 @@ shell_surface_pong(struct
wl_client *client, struct wl_resource *resource,
  }

  static void
+set_title(struct shell_surface *shsurf, const char
*title)
+{
+       free(shsurf->title);
+       shsurf->title = strdup(title);
+}
+
+static void
  shell_surface_set_title(struct wl_client *client,
                        struct wl_resource
*resource, const char *title)
  {
        struct shell_surface *shsurf =
wl_resource_get_user_data(resource);

-       free(shsurf->title);
-       shsurf->title = strdup(title);
+       set_title(shsurf, title);
  }

  static void
@@ -4583,6 +4589,7 @@ module_init(struct
weston_compositor *ec,
        ec->shell_interface.set_xwayland =
set_xwayland;
        ec->shell_interface.move = surface_move;
        ec->shell_interface.resize = surface_resize;
+       ec->shell_interface.set_title = set_title;

        wl_list_init(&shell->input_panel.surfaces);

diff --git a/src/xwayland/window-manager.c
b/src/xwayland/window-manager.c
index f775734..b4f64d3 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -363,6 +363,8 @@ static void
  weston_wm_window_read_properties(struct
weston_wm_window *window)
  {
        struct weston_wm *wm = window->wm;
+       struct weston_shell_interface
*shell_interface =
+              
&wm->server->compositor->shell_interface;

  #define F(field) offsetof(struct weston_wm_window,
field)
        const struct {
@@ -468,6 +470,9 @@
weston_wm_window_read_properties(struct
weston_wm_window *window)
                }
                free(reply);
        }
+
+       if (window->shsurf && window->name)
+              
shell_interface->set_title(window->shsurf,
window->name);
  }

  static void
@@ -1875,6 +1880,9 @@ surface_destroy(struct
wl_listener *listener, void *data)

        wm_log("surface for xid %d destroyed\n",
window->id);

+       /* This should have been freed by the shell.
+       Don't try to use it later. */
+       window->shsurf = NULL;
        window->surface = NULL;
  }

@@ -2029,6 +2037,9 @@
xserver_map_shell_surface(struct west

Re: [PATCH weston v2] xwm: set the shell_surface's title

[Axel Davy]

This patch makes XWayland often crash for me.

Axel Davy

Le 11/09/2013 18:20, Giulio Camuffo a écrit :

add a new function pointer to the weston_shell_interface struct that
shells will set accordingly.
---
  src/compositor.h  |  2 ++
  src/shell.c   | 11 +--
  src/xwayland/window-manager.c | 11 +++
  3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/src/compositor.h b/src/compositor.h
index 3c1b643..ead0c91 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -107,6 +107,8 @@ struct weston_shell_interface {
int (*move)(struct shell_surface *shsurf, struct weston_seat *ws);
int (*resize)(struct shell_surface *shsurf,
  struct weston_seat *ws, uint32_t edges);
+   void (*set_title)(struct shell_surface *shsurf,
+ const char *title);

  };

diff --git a/src/shell.c b/src/shell.c
index dc15bfa..ea4315a 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1595,13 +1595,19 @@ shell_surface_pong(struct wl_client *client, struct 
wl_resource *resource,
  }

  static void
+set_title(struct shell_surface *shsurf, const char *title)
+{
+   free(shsurf->title);
+   shsurf->title = strdup(title);
+}
+
+static void
  shell_surface_set_title(struct wl_client *client,
struct wl_resource *resource, const char *title)
  {
struct shell_surface *shsurf = wl_resource_get_user_data(resource);

-   free(shsurf->title);
-   shsurf->title = strdup(title);
+   set_title(shsurf, title);
  }

  static void
@@ -4583,6 +4589,7 @@ module_init(struct weston_compositor *ec,
ec->shell_interface.set_xwayland = set_xwayland;
ec->shell_interface.move = surface_move;
ec->shell_interface.resize = surface_resize;
+   ec->shell_interface.set_title = set_title;

wl_list_init(&shell->input_panel.surfaces);

diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
index f775734..b4f64d3 100644
--- a/src/xwayland/window-manager.c
+++ b/src/xwayland/window-manager.c
@@ -363,6 +363,8 @@ static void
  weston_wm_window_read_properties(struct weston_wm_window *window)
  {
struct weston_wm *wm = window->wm;
+   struct weston_shell_interface *shell_interface =
+   &wm->server->compositor->shell_interface;

  #define F(field) offsetof(struct weston_wm_window, field)
const struct {
@@ -468,6 +470,9 @@ weston_wm_window_read_properties(struct weston_wm_window 
*window)
}
free(reply);
}
+
+   if (window->shsurf && window->name)
+   shell_interface->set_title(window->shsurf, window->name);
  }

  static void
@@ -1875,6 +1880,9 @@ surface_destroy(struct wl_listener *listener, void *data)

wm_log("surface for xid %d destroyed\n", window->id);

+   /* This should have been freed by the shell.
+   Don't try to use it later. */
+   window->shsurf = NULL;
window->surface = NULL;
  }

@@ -2029,6 +2037,9 @@ xserver_map_shell_surface(struct weston_wm *wm,
  window->surface,
  &shell_client);

+   if (window->name)
+   shell_interface->set_title(window->shsurf, window->name);
+
if (window->fullscreen) {
window->saved_width = window->width;
window->saved_height = window->height;




___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2] Restoring alpha after the shell effects.

[Axel Davy]

You are right, but if we use the slide effect, the target value has no 
meaning for alpha.
The only time we use the fade effect with a target alpha value of 0 is 
the shell_fade effect with the FADE_IN parameter: at the end the surface 
is destroyed anyway.


I think however the first patch was better, but I should add too to set 
surface->alpha to 1.0 for the shell_fade effect and the FADE_OUT parameter.


Kristian, what do you like better?

Axel Davy


Le 12/09/2013 10:27, Giulio Camuffo a écrit :
Shouldn't this set the alpha to the target alpha instead of 1? What if 
i fade from 1 to 0, this will set it back to 1 when it's done.



2013/9/12 Axel Davy mailto:axel.d...@ens.fr>>

After the fade or zoom effects, alpha could not have been 1.0,
preventing
not redrawing behind opaque windows.

Signed-off-by: Axel Davy mailto:axel.d...@ens.fr>>
---
 src/animation.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/animation.c b/src/animation.c
index 0b2fa95..9603115 100644
--- a/src/animation.c
+++ b/src/animation.c
@@ -134,6 +134,7 @@ weston_surface_animation_destroy(struct
weston_surface_animation *animation)
wl_list_remove(&animation->animation.link);
wl_list_remove(&animation->listener.link);
wl_list_remove(&animation->transform.link);
+   animation->surface->alpha = 1.0;
weston_surface_geometry_dirty(animation->surface);
if (animation->done)
animation->done(animation, animation->data);
--
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
<mailto:wayland-devel@lists.freedesktop.org>
http://lists.freedesktop.org/mailman/listinfo/wayland-devel




___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v2] Restoring alpha after the shell effects.

[Axel Davy]

After the fade or zoom effects, alpha could not have been 1.0, preventing
not redrawing behind opaque windows.

Signed-off-by: Axel Davy 
---
 src/animation.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/animation.c b/src/animation.c
index 0b2fa95..9603115 100644
--- a/src/animation.c
+++ b/src/animation.c
@@ -134,6 +134,7 @@ weston_surface_animation_destroy(struct 
weston_surface_animation *animation)
wl_list_remove(&animation->animation.link);
wl_list_remove(&animation->listener.link);
wl_list_remove(&animation->transform.link);
+   animation->surface->alpha = 1.0;
weston_surface_geometry_dirty(animation->surface);
if (animation->done)
animation->done(animation, animation->data);
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/2] wayland: Add support for eglSwapInterval

[Axel Davy]

I think you should too set the number of back buffers to 4 instead of 3.

It looks like if the compositor wants to use the buffers as framebuffers 
and do a pageflip,
it uses 2 buffers at a time (one used for the frame displayed, and one 
used for the pending pageFlip request). The third buffer sent is not 
released and waits for the next frame. If there is only 3 buffers, the 
client will be without free buffers and blocked in eglSwapBuffers.

I may be wrong, but I think the number of back buffers should be set to 4.

Axel Davy



Le 11/09/2013 20:28, Neil Roberts a écrit :

The Wayland EGL platform now respects the eglSwapInterval value. The value is
clamped to either 0 or 1 because it is difficult (and probably not useful) to
sync to more than 1 redraw.

The main change is that if the swap interval is 0 then it simply doesn't
install a frame callback so that the next time eglSwapBuffers is called it
won't delay.

The second change is that in get_back_bo instead of returning with an error if
all three buffers are locked it will now block in a dispatch loop so that it
can receive the buffer release events. The assumption is that the compositor
is unlikely to lock all three buffers so if we find that all the buffers are
locked then we are probably just rendering faster than we are processing the
release events. Therefore the release events should be available very early.

This also moves the vblank configuration defines from platform_x11.c to the
common egl_dri2.h header so they can be shared by both platforms.
---
  src/egl/drivers/dri2/egl_dri2.h |   6 ++
  src/egl/drivers/dri2/platform_wayland.c | 121 ++--
  src/egl/drivers/dri2/platform_x11.c |   6 --
  3 files changed, 107 insertions(+), 26 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index fba5f81..849927b 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -221,6 +221,12 @@ struct dri2_egl_image
 __DRIimage *dri_image;
  };
  
+/* From xmlpool/options.h, user exposed so should be stable */

+#define DRI_CONF_VBLANK_NEVER 0
+#define DRI_CONF_VBLANK_DEF_INTERVAL_0 1
+#define DRI_CONF_VBLANK_DEF_INTERVAL_1 2
+#define DRI_CONF_VBLANK_ALWAYS_SYNC 3
+
  /* standard typecasts */
  _EGL_DRIVER_STANDARD_TYPECASTS(dri2_egl)
  _EGL_DRIVER_TYPECAST(dri2_egl_image, _EGLImage, obj)
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index ffc5959..83e7aab 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -180,8 +180,16 @@ dri2_create_window_surface(_EGLDriver *drv, _EGLDisplay 
*disp,
   _EGLConfig *conf, EGLNativeWindowType window,
   const EGLint *attrib_list)
  {
-   return dri2_create_surface(drv, disp, EGL_WINDOW_BIT, conf,
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   _EGLSurface *surf;
+
+   surf = dri2_create_surface(drv, disp, EGL_WINDOW_BIT, conf,
  window, attrib_list);
+
+   if (surf != NULL)
+  drv->API.SwapInterval(drv, disp, surf, dri2_dpy->default_swap_interval);
+
+   return surf;
  }
  
  /**

@@ -261,24 +269,36 @@ get_back_bo(struct dri2_egl_surface *dri2_surf, 
__DRIbuffer *buffer)
 __DRIimage *image;
 int i, name, pitch;
  
-   /* There might be a buffer release already queued that wasn't processed */

-   wl_display_dispatch_queue_pending(dri2_dpy->wl_dpy, dri2_dpy->wl_queue);
-
 if (dri2_surf->back == NULL) {
-  for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
- /* Get an unlocked buffer, preferrably one with a dri_buffer already
-  * allocated. */
-if (dri2_surf->color_buffers[i].locked)
-continue;
- if (dri2_surf->back == NULL)
-   dri2_surf->back = &dri2_surf->color_buffers[i];
- else if (dri2_surf->back->dri_image == NULL)
-   dri2_surf->back = &dri2_surf->color_buffers[i];
+  /* There might be a buffer release already queued that wasn't processed 
*/
+  wl_display_dispatch_queue_pending(dri2_dpy->wl_dpy, dri2_dpy->wl_queue);
+
+  while (1) {
+ for (i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
+/* Get an unlocked buffer, preferrably one with a dri_buffer 
already
+ * allocated. */
+if (dri2_surf->color_buffers[i].locked)
+   continue;
+if (dri2_surf->back == NULL)
+   dri2_surf->back = &dri2_surf->color_buffers[i];
+else if (dri2_surf->back->dri_image == NULL)
+   dri2_surf->back = &dri2_surf->color_buffers[i];
+ }
+
+ if (dri2_surf->back)
+break;
+
+ /* If we make it here then here then all of the buffers are locked.
+  * It woul

Re: [PATCH] wayland: Add an extension to create wl_buffers from EGLImages

[Axel Davy]

System compositor: set up wl_drm to import buffers on card A

Session compositor: Detects it is on card B and not the card of wl_drm. 
Creates a buffer without tiling and use wl_drm to share it with the 
System compositor.


The session compositor creates a new wl_drm for its clients.
The clients: see they are on card B that is the card of the wl_drm they 
see. They create a buffer with tiling since it is better performance 
wise, and share it with the Session compositor.



Without your extension, the session compositor has to copy the contents 
of the clients (with card B) in its own buffer (readable by card A and 
B) and commit it to the System compositor. Card A only sees a buffer 
without tiling, even if the clients used tiling.


Your extension avoid the copy, and the tiling mode is not changed (it 
would need a copy). Since A doesn't understand the tiling mode of B, the 
buffers will not be displayed correctly.



Prime support isn't implemented in Mesa yet (It'll use render-nodes).

I suggest you design your extension so it can fail if the texture cannot 
be used on the card of the System compositor. When Prime support would 
be ready, it will be needed to check if the card described by wl_drm of 
the System compositor and the Session compositor is the same than the 
one used by the session compositor.
I assume a variable would be added to the dri2_dpy structure to tell if 
it can use tiling or not when creating buffers, and you would just need 
to check it.


Axel Davy

Le 09/09/2013 20:39, Neil Roberts a écrit :

Is this problem specific to the extension or is it a general problem?
Would there not be the same issue if the session compositor wasn't using
the extension but was creating textures from the client surfaces
instead? Presumably if cards A and B don't share a tiling mode then it
won't be possible for card B to make a texture out of buffers created on
card A either.

My assumption was that if you have successfully created an EGLImage out
of the client's surface then it is a valid buffer for that EGL context.
Perhaps this situation should be detected in eglCreateImage rather than
in eglCreateWaylandBufferFromImage.

I apologise in advance if I've misunderstood the problem.

Regards,
- Neil

Axel Davy  writes:


I think there is a problem with tiling handling in your patch.

Thinks of a session compositor running on an other graphic card for example.


Main compositor: card A
session compositor: card B. buffer is shared between A and B and when
creating it, tiling was disabled (because A and B share no tiling mode)
clients in the session compositor: card B. buffer is created on B, when
creating it, tiling was enabled.

In this configuration, your function should fail or do a copy (because A
won't recognize the tiling mode of B)

Axel Davy

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] wayland: Add an extension to create wl_buffers from EGLImages

[Axel Davy]

I want to add the use case that I describe is not with subsurfaces.

What I imagine is having a System compositor on card A (integrated),
and a Session compositor on card A (integrated card/energy saving) or 
card B (dedicated card/max performance).
The Session compositor wouldn't use subsurfaces, and would always give a 
full buffer to the System compositor (as weston running under weston).


The Session compositor window is fullscreen and the System compositor 
optimizes performance by using the Session compositor buffer as a 
scanout buffer.


If a fullscreen application runs inside the Session compositor, with 
your extension,
the Session compositor would not need to copy the content of the window 
application while on card A/energy saving mode.
Thanks to the extension, the fullscreen application will be used as a 
scanout buffer directly by the System compositor.


But if we are on the dedicated card (max performance mode), we need a 
copy because the clients use tiling: your extension should fail (or do a 
copy).


Axel Davy





System compositor: set up wl_drm to import buffers on card A

Session compositor: Detects it is on card B and not the card of 
wl_drm. Creates a buffer without tiling and use wl_drm to share it 
with the System compositor.


The session compositor creates a new wl_drm for its clients.
The clients: see they are on card B that is the card of the wl_drm 
they see. They create a buffer with tiling since it is better 
performance wise, and share it with the Session compositor.



Without your extension, the session compositor has to copy the 
contents of the clients (with card B) in its own buffer (readable by 
card A and B) and commit it to the System compositor. Card A only sees 
a buffer without tiling, even if the clients used tiling.


Your extension avoid the copy, and the tiling mode is not changed (it 
would need a copy). Since A doesn't understand the tiling mode of B, 
the buffers will not be displayed correctly.



Prime support isn't implemented in Mesa yet (It'll use render-nodes).

I suggest you design your extension so it can fail if the texture 
cannot be used on the card of the System compositor. When Prime 
support would be ready, it will be needed to check if the card 
described by wl_drm of the System compositor and the Session 
compositor is the same than the one used by the session compositor.
I assume a variable would be added to the dri2_dpy structure to tell 
if it can use tiling or not when creating buffers, and you would just 
need to check it.


Axel Davy

Le 09/09/2013 20:39, Neil Roberts a écrit :

Is this problem specific to the extension or is it a general problem?
Would there not be the same issue if the session compositor wasn't using
the extension but was creating textures from the client surfaces
instead? Presumably if cards A and B don't share a tiling mode then it
won't be possible for card B to make a texture out of buffers created on
card A either.

My assumption was that if you have successfully created an EGLImage out
of the client's surface then it is a valid buffer for that EGL context.
Perhaps this situation should be detected in eglCreateImage rather than
in eglCreateWaylandBufferFromImage.

I apologise in advance if I've misunderstood the problem.

Regards,
- Neil

Axel Davy  writes:


I think there is a problem with tiling handling in your patch.

Thinks of a session compositor running on an other graphic card for 
example.



Main compositor: card A
session compositor: card B. buffer is shared between A and B and when
creating it, tiling was disabled (because A and B share no tiling mode)
clients in the session compositor: card B. buffer is created on B, when
creating it, tiling was enabled.

In this configuration, your function should fail or do a copy 
(because A

won't recognize the tiling mode of B)

Axel Davy

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel





___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] wayland: Add an extension to create wl_buffers from EGLImages

[Axel Davy]

I think there is a problem with tiling handling in your patch.

Thinks of a session compositor running on an other graphic card for example.


Main compositor: card A
session compositor: card B. buffer is shared between A and B and when
creating it, tiling was disabled (because A and B share no tiling mode)
clients in the session compositor: card B. buffer is created on B, when
creating it, tiling was enabled.

In this configuration, your function should fail or do a copy (because A
won't recognize the tiling mode of B)

Axel Davy
> This adds an extension called EGL_WL_create_wayland_buffer_from_image
> which adds the following single function:
>
> struct wl_buffer *
> eglCreateWaylandBufferFromImageWL(EGLDisplay dpy, EGLImageKHR image);
>
> The function creates a wl_buffer which shares its contents with the given
> EGLImage. The expected use case for this is in a nested Wayland compositor
> which is using subsurfaces to present buffers from its clients. Using this
> extension it can attach the client buffers directly to the subsurface
> without
> having to blit the contents into an intermediate buffer. The compositing
> can
> then be done in the parent compositor.
>
> The extension is only implemented in the Wayland EGL platform because of
> course it wouldn't make sense anywhere else.
> ---
>  .../specs/WL_create_wayland_buffer_from_image.spec | 85
> ++
>  include/EGL/eglmesaext.h   | 10 +++
>  src/egl/drivers/dri2/platform_wayland.c| 71
> ++
>  src/egl/main/eglapi.c  | 25 +++
>  src/egl/main/eglapi.h  |  8 ++
>  src/egl/main/egldisplay.h  |  1 +
>  src/egl/main/eglmisc.c |  1 +
>  7 files changed, 201 insertions(+)
>  create mode 100644 docs/specs/WL_create_wayland_buffer_from_image.spec
>
> diff --git a/docs/specs/WL_create_wayland_buffer_from_image.spec
> b/docs/specs/WL_create_wayland_buffer_from_image.spec
> new file mode 100644
> index 000..7e27695
> --- /dev/null
> +++ b/docs/specs/WL_create_wayland_buffer_from_image.spec
> @@ -0,0 +1,85 @@
> +Name
> +
> +WL_create_wayland_buffer_from_image
> +
> +Name Strings
> +
> +EGL_WL_create_wayland_buffer_from_image
> +
> +Contact
> +
> +Neil Roberts 
> +
> +Status
> +
> +Proposal
> +
> +Version
> +
> +Version 1, September 6, 2013
> +
> +Number
> +
> +EGL Extension #not assigned
> +
> +Dependencies
> +
> +Requires EGL 1.4 or later.  This extension is written against the
> +wording of the EGL 1.4 specification.
> +
> +EGL_KHR_base_image is required.
> +
> +Overview
> +
> +This extension provides an entry point to create a wl_buffer which
> shares
> +its contents with a given EGLImage. The expected use case for this is
> in a
> +nested Wayland compositor which is using subsurfaces to present
> buffers
> +from its clients. Using this extension it can attach the client
> buffers
> +directly to the subsurface without having to blit the contents into
> an
> +intermediate buffer. The compositing can then be done in the parent
> +compositor.
> +
> +The nested compositor can create an EGLImage from a client buffer
> resource
> +using the existing WL_bind_wayland_display extension. It should also
> be
> +possible to create buffers using other types of images although there
> is
> +no expected use case for that.
> +
> +IP Status
> +
> +Open-source; freely implementable.
> +
> +New Procedures and Functions
> +
> +struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy,
> +EGLImageKHR
> image);
> +
> +New Tokens
> +
> +None.
> +
> +Additions to the EGL 1.4 Specification:
> +
> +To create a client-side wl_buffer from an EGLImage call
> +
> +  struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy,
> +  EGLImageKHR
> image);
> +
> +The returned buffer will share the contents with the given EGLImage.
> Any
> +updates to the image will also be updated in the wl_buffer. Typically
> the
> +EGLImage will be generated in a nested Wayland compositor using a
> buffer
> +resource from a client via the EGL_WL_bind_wayland_display extension.
> +
> +If there was an error then the function will return NULL. In
> particular it
> +will generate EGL_BAD_MATCH if the image is not in a format which the
> +implementation can represent in a wl_buffer. It is
> 

[PATCH weston] Restore alpha after fade or zoom effect.

[Axel Davy]

After these effects, alpha could not have been 1.0, preventing
not redrawing behind opaque windows.

Signed-off-by: Axel Davy 
---
 src/shell.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/src/shell.c b/src/shell.c
index cd94aa5..d7e2d1e 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -3485,6 +3485,15 @@ weston_surface_set_initial_position (struct 
weston_surface *surface,
 }
 
 static void
+surface_restore_alpha(struct weston_surface_animation *animation, void *data)
+{
+   struct weston_surface *surface = data;
+
+   surface->alpha = 1.0;
+   weston_surface_geometry_dirty(surface);
+}
+
+static void
 map(struct desktop_shell *shell, struct weston_surface *surface,
 int32_t width, int32_t height, int32_t sx, int32_t sy)
 {
@@ -3576,10 +3585,12 @@ map(struct desktop_shell *shell, struct weston_surface 
*surface,
{
switch (shell->win_animation_type) {
case ANIMATION_FADE:
-   weston_fade_run(surface, 0.0, 1.0, 300.0, NULL, NULL);
+   weston_fade_run(surface, 0.0, 1.0, 300.0,
+   surface_restore_alpha, surface);
break;
case ANIMATION_ZOOM:
-   weston_zoom_run(surface, 0.5, 1.0, NULL, NULL);
+   weston_zoom_run(surface, 0.5, 1.0, 
+   surface_restore_alpha, surface);
break;
default:
break;
-- 
1.8.1.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel