Re: [PATCH weston 0/3] Pointer locking revisited
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
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
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 ja...@jlekstrand.net mailto:ja...@jlekstrand.net On Fri, Feb 21, 2014 at 7:46 AM, Pekka Paalanen ppaala...@gmail.com mailto:ppaala...@gmail.com wrote: From: Pekka Paalanen pekka.paala...@collabora.co.uk 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 pekka.paala...@collabora.co.uk mailto:pekka.paala...@collabora.co.uk Cc: Axel Davy axel.d...@ens.fr mailto:axel.d...@ens.fr Cc: Jason Ekstrand ja...@jlekstrand.net 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 request name=frame - description summary=request repaint feedback - Request notification when the next frame is displayed. Useful - for throttling redrawing operations, and driving animations. + description summary=request a frame throttling hint + 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
Re: [PATCH] xwayland: Destroy wl_buffers only after they are released
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 ppaala...@gmail.com 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); @@ -74,6 +72,8 @@ xwl_window_attach(struct xwl_window *xwl_window, PixmapPtr pixmap) return; } +_buffer_init(xwl_window-buffer
Re: Core protocol change; [RFC v2] Wayland presentation extension
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
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
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=waylandid=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)
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 P0t(1/2)P0+(1/2)P1 then you take the pageflip at P0 if (1/2)P0+(1/2)P1tP1 then you take the pageflip at P1 That 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!
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=Waylandcomponent=westonversion=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=optimized out, 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
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 1/2] XWAYLAND Present support
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 1/2] Initial Present Wayland support
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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_list_add(vblank-event_queue, present_exec_queue);
+
if (target_msc = crtc_msc) {
ret = present_queue_vblank(screen, target_crtc, vblank-event_id,
target_msc);
if (ret != Success) {
diff
[PATCH 2/2] Update configure and Makefile to support Present XWayland
Signed-off-by: Axel Davy axel.d...@ens.fr --- 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 4/4 v3] Add XWayland API with Present support in mind.
The API enables to use the frame event and the buffer event.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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 unistd.h
+
+#include wayland-util.h
+#include wayland-client.h
+
+#include xf86Crtc.h
+#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-buffer_todo);
+wl_list_for_each(todo, todo_list, link)
+ todo-tocall.tfb(0, todo-args
[PATCH 2/4 v2] Add support to render-nodes.
And allows to create wl_buffers from fds instead of gem names.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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 @@
!-- drm support. This object is created by the server and published
using the display's global event. --
- interface name=wl_drm version=1
+ interface name=wl_drm version=2
enum name=error
entry name=authenticate_fail value=0/
entry name=invalid_format value=1/
@@ -119,6 +119,38 @@
arg name=format type=uint/
/request
+!-- Create a wayland buffer for the named DRM buffer. The DRM
+ surface must have a name using the flink ioctl --
+request name=create_planar_buffer
+ arg name=id type=new_id interface=wl_buffer/
+ arg name=name type=uint/
+ arg name=width type=int/
+ arg name=height type=int/
+ arg name=format type=uint/
+ arg name=offset0 type=int/
+ arg name=stride0 type=int/
+ arg name=offset1 type=int/
+ arg name=stride1 type=int/
+ arg name=offset2 type=int/
+ arg name=stride2 type=int/
+/request
+
+!-- Create a wayland buffer for the prime fd. Use for regular and planar
+ buffers. Pass 0 for offset and stride for unused planes. --
+request name=create_prime_buffer since=2
+ arg name=id type=new_id interface=wl_buffer/
+ arg name=name type=fd/
+ arg name=width type=int/
+ arg name=height type=int/
+ arg name=format type=uint/
+ arg name=offset0 type=int/
+ arg name=stride0 type=int/
+ arg name=offset1 type=int/
+ arg name=stride1 type=int/
+ arg name=offset2 type=int/
+ arg name=stride2 type=int/
+/request
+
!-- Notification of the path of the drm device which is used by
the server. The client should use this device for creating
local buffers. Only buffers created from this device should
@@ -134,6 +166,17 @@
!-- Raised if the authenticate request succeeded --
event name=authenticated/
+
+enum name=capability since=2
+ description summary=wl_drm capability bitmask
+Bitmask of capabilities.
+ /description
+ entry name=prime value=1 summary=wl_drm prime available/
+/enum
+
+event name=capabilities
+ arg name=value type=uint/
+/event
/interface
/protocol
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 unistd.h
#include fcntl.h
+#include sys/stat.h
#include xf86drm.h
#include wayland-util.h
@@ -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
[PATCH 4/4 v2] Add XWayland API with Present support in mind.
The API enables to use the frame event and the buffer event.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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 unistd.h
+
+#include wayland-util.h
+#include wayland-client.h
+
+#include xf86Crtc.h
+#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_pixmap *xwl_pixmap = data;
+struct wl_list todo_list;
+struct _todo *todo;
+
+if (wl_list_empty(xwl_pixmap
[PATCH 1/4 v2] Move the wl_buffer from xwl_window to xwl_pixmap
This change enables to change the window pixmap, and have
xwayland send the correct buffer to the Wayland compositor.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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 to create buffer\n);
- return;
+ if (!xwl_pixmap) {
+ ErrorF(failed to create buffer\n);
+ return
[PATCH 3/4 v2] Add function to get new fd of the graphic device
neccessary for dri3
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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 0/4][XWayland] New API to support dri3/present
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.
The API enables to use the frame event and the buffer event.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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 unistd.h
+
+#include wayland-util.h
+#include wayland-client.h
+
+#include xf86Crtc.h
+#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_pixmap *xwl_pixmap = data;
+struct wl_list todo_list;
+struct _todo *todo;
+
+if (wl_list_empty(xwl_pixmap
[PATCH 1/4] Move the wl_buffer from xwl_window to xwl_pixmap
This change enables to change the window pixmap, and have
xwayland send the correct buffer to the Wayland compositor.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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_pixmap_private_key);
+
+if (!xwl_pixmap) {
+ErrorF(failed to create buffer\n);
+return
[PATCH 3/4] Add function to get new fd of the graphic device
neccessary for dri3
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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 2/4] Add support to render-nodes.
And allows to create wl_buffers from fds instead of gem names.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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 @@
!-- drm support. This object is created by the server and published
using the display's global event. --
- interface name=wl_drm version=1
+ interface name=wl_drm version=2
enum name=error
entry name=authenticate_fail value=0/
entry name=invalid_format value=1/
@@ -119,6 +119,38 @@
arg name=format type=uint/
/request
+!-- Create a wayland buffer for the named DRM buffer. The DRM
+ surface must have a name using the flink ioctl --
+request name=create_planar_buffer
+ arg name=id type=new_id interface=wl_buffer/
+ arg name=name type=uint/
+ arg name=width type=int/
+ arg name=height type=int/
+ arg name=format type=uint/
+ arg name=offset0 type=int/
+ arg name=stride0 type=int/
+ arg name=offset1 type=int/
+ arg name=stride1 type=int/
+ arg name=offset2 type=int/
+ arg name=stride2 type=int/
+/request
+
+!-- Create a wayland buffer for the prime fd. Use for regular and planar
+ buffers. Pass 0 for offset and stride for unused planes. --
+request name=create_prime_buffer since=2
+ arg name=id type=new_id interface=wl_buffer/
+ arg name=name type=fd/
+ arg name=width type=int/
+ arg name=height type=int/
+ arg name=format type=uint/
+ arg name=offset0 type=int/
+ arg name=stride0 type=int/
+ arg name=offset1 type=int/
+ arg name=stride1 type=int/
+ arg name=offset2 type=int/
+ arg name=stride2 type=int/
+/request
+
!-- Notification of the path of the drm device which is used by
the server. The client should use this device for creating
local buffers. Only buffers created from this device should
@@ -134,6 +166,17 @@
!-- Raised if the authenticate request succeeded --
event name=authenticated/
+
+enum name=capability since=2
+ description summary=wl_drm capability bitmask
+Bitmask of capabilities.
+ /description
+ entry name=prime value=1 summary=wl_drm prime available/
+/enum
+
+event name=capabilities
+ arg name=value type=uint/
+/event
/interface
/protocol
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 unistd.h
#include fcntl.h
+#include sys/stat.h
#include xf86drm.h
#include wayland-util.h
@@ -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
[PATCH 1/2] Fix XWayland transient window location.
This fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73517
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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
[PATCH 2/2] Fix XWayland crashes when opening popups
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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
Re: [PATCH weston] compositor: update the transform when attaching a new buffer
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 axel.d...@ens.fr
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
[PATCH Mesa] Enable throttling in SwapBuffers
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 axel.d...@ens.fr
---
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] Flush the wl_display at the end of SwapBuffers
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 axel.d...@ens.fr --- 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
Re: [PATCH] Add wl_dmabuf protocol
On 03/12/2013, benjamin.gaign...@linaro.org wrote : Here are a few comments: + !-- dmabuf support. This object is created by the server and published + using the display's global event. -- + interface name=wl_dmabuf version=2 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. + +enum name=capability since=2 + description summary=wl_dmabuf capability bitmask +Bitmask of capabilities. + /description + entry name=prime value=1 summary=wl_dmabuf prime available/ +/enum + 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] Wayland backend: set the opaque region when starting fullscreen
The opaque region is not set when we start the nested
compositor fullscreen. This patch fixes this.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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 xwayland] Set the view to NULL when unmapping an X11 window
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 d...@gmail.com 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 d...@gmail.com 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 xwayland] Set the view to NULL when unmapping an X11 window
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.d...@ens.fr 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 d...@gmail.com 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 d...@gmail.com 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 3/3] Check if the frame exists before reading its size
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.d...@ens.fr
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 d...@gmail.com
---
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 2/3] Check for frame being NULL before setting/unsetting flags
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 d...@gmail.com
---
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
[PATCH] XWayland: do not set wm-focus_window to a window with no frame
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 axel.d...@ens.fr
---
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
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 d...@gmail.com
---
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
Re: [PATCH mesa v5 2/2] wayland: Add support for eglSwapInterval
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 unistd.h
#include fcntl.h
#include xf86drm.h
+#include poll.h
#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;
+
+ surf
Re: [PATCH] xdg-shell - yet another proposal (this time for real).
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
[PATCH] Do not set output-current_mode in compositor.c
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 axel.d...@ens.fr --- 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.
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
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: [RFC v.2] Extend wl_surface protocol
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: ?xml version="1.0" encoding="UTF-8"? protocol name="presentation_timing" copyright 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. /copyright interface name="wl_presentation" version="1" description summary="buffer queues with presentation timing information/ for surfaces" 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. /description request name="destroy" type="destructor" description summary="unbind from the wl_presentation interface" 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. /description /request enum name="error" entry name="buffer_queue_exists" value="0" summary="the
[PATCH] Do not release buffer when it is going to be used again.
Solve a bug for some fullscreen clients which wouldn't show up.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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
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
Re: [PATCH] Extend wl_surface protocol [reminder]
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
[PATCH] Add presentation_time and hit requests to wl_surface.
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 @@ /event /interface - interface name=wl_surface version=3 + interface name=wl_surface version=4 description summary=an onscreen surface 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 name=frame description summary=request repaint feedback - 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 @@ /request /interface +!-- Version 4 additions -- + +request name=presentation_time since=4 + description summary=request the frame of next commit to hit the screen at a specific time + 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. + /description + + arg name=ust type=uint/ +/request + +request name=hit since=4 + description summary=request hit feedback + 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. + /description + + arg name=callback type=new_id interface=wl_callback/ +/request + interface name=wl_seat version=3 description summary=group of input devices 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
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] wl_surface video protocol extension
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] clients: add simple-dmabuf
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: [RFC] clients: add simple-dmabuf
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: Buffer release events (was: Add support for eglSwapInterval)
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
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
Fwd: Re: [PATCH 0/2] Add New XWayland API
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: Fwd: Re: [PATCH 0/2] Add New XWayland API
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
Re: Fwd: Re: [PATCH 0/2] Add New XWayland API
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
[PATCH 0/2] Add New XWayland API
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
[PATCH 1/2] Patch to the Xserver to support AsyncSwap
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 axel.d...@ens.fr
---
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(region, box, 0);
-
pPriv-swapsPending++;
-dri2_copy_region(pDraw, region, 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(region, box, 0);
+
+dri2_copy_region(pDraw, region, 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 2/2] Add new XWayland API.
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 axel.d...@ens.fr
---
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 unistd.h
+#include fcntl.h
+
+#include xf86drm.h
+#include wayland-util.h
+#include wayland-client.h
+#include drm-client-protocol.h
+
+#include xf86Xinput.h
+#include xf86Crtc.h
+#include xf86str.h
+#include windowstr.h
+#include input.h
+#include inputstr.h
+#include exevents.h
+
+#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
Re: [PATCH 1/2] Patch to the Xserver to support AsyncSwap
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 axel.d...@ens.fr
---
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(region, box, 0);
-
pPriv-swapsPending++;
-dri2_copy_region(pDraw, region, 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(region, box, 0);
+
+dri2_copy_region(pDraw, region, 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
A new XWayland Glamor DDX
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
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 xiong.y.zh...@intel.com
---
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 set */
uint32_t msec;
@@ -686,6 +735,21 @@ drm_output_start_repaint_loop(struct weston_output
*output_base)
weston_log(queueing pageflip failed: %m\n);
return
Re: Absolute coordinates using wl_shell_surface_set_transient
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
[PATCH v3] Restoring alpha after the shell effects.
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 axel.d...@ens.fr
---
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
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
Re: [PATCH weston v2] xwm: set the shell_surface's title
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 d...@clipper.ens.fr
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
Re: [PATCH weston v2] xwm: set the shell_surface's title
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
[PATCH v2] Restoring alpha after the shell effects.
After the fade or zoom effects, alpha could not have been 1.0, preventing not redrawing behind opaque windows. Signed-off-by: Axel Davy 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 http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] Restoring alpha after the shell effects.
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 axel.d...@ens.fr 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 axel.d...@ens.fr 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
Re: [PATCH] wayland: Add an extension to create wl_buffers from EGLImages
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 axel.d...@ens.fr 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
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 axel.d...@ens.fr 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 1/2] wayland: Add support for eglSwapInterval
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 wouldn't make sense for the compositor to keep all three
+ * buffers so it must mean that we are rendering too fast without
+ * getting a chance
Re: [PATCH] wayland: Add an extension to create wl_buffers from EGLImages
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 neil.s.robe...@intel.com + +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 implementation-defined +what formats and types of EGLImage will be successfully converted to a +wl_buffer without error. + +Issues + +None. + +Revision History + +Version 1, September 6, 2013 +Initial draft (Neil Roberts) diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h index e0eae28..0a65cb8 100644 --- a/include/EGL/eglmesaext.h +++ b/include/EGL/eglmesaext.h @@ -132,6 +132,16 @@ typedef EGLBoolean (EGLAPIENTRYP
[PATCH weston] Restore alpha after fade or zoom effect.
After these effects, alpha could not have been 1.0, preventing
not redrawing behind opaque windows.
Signed-off-by: Axel Davy axel.d...@ens.fr
---
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
