Re: minimized and stick windows
Hello, I thought a bit about it and like to present my ideas. I mainly thought about it from the shell/compositor site when I like to minimize, maximize surfaces from keybindings, like in some window managers. For example the client can still request minimize, maximize, fullsrceen and toplevel actions, but now the compositor responds with an state_update event. The compositor can also send this state_update when the compositor likes change the window on it's own (like some task bar or compositor key bindings). The client can then save the state and act accordingly (like hiding same menus if maximized or fullscreen). diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 3bce022..e0f2c4a 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -811,6 +811,14 @@ + + +Minimize the surface. + +The compositor responds with state_update event. + + + Set a short title for the surface. @@ -867,6 +875,30 @@ + + + + + + + + + + + +Tells the surface which state is has on the output. + +This event is sent in respons to set_maximized, set_minimized or +set_fullscreen request to acknowledge the request. The client can update it +own state if it wants to keep track of it. + +The also compositor sends this event if itt wants the surface minimized or +maximized. For example by clicking on a task list item or compositor key +bindings for fullscreen. + + + + The popup_done event is sent out when a popup grab is broken, I don't know about multiple window applications and maybe missed some other use cases, but I hope this isn't too wrong of an idea. At least this should hopefully not break the protocol too much. Best Regards, Alexander Preisinger 2013/5/14 Kristian Høgsberg > On Tue, May 14, 2013 at 2:30 AM, Pekka Paalanen > wrote: > > On Mon, 13 May 2013 17:26:28 -0500 > > Jason Ekstrand wrote: > > > >> On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli < > antogno...@gmail.com>wrote: > >> > >> > Hi Jason, > >> > > >> > On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand > >> > wrote: > >> > > Hi Rafael, > >> > > > >> > > > >> > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli < > antogno...@gmail.com> > >> > > wrote: > >> > >> > >> > >> Hello, > >> > >> > >> > >> I've been looking the Weston code relative to maximized windows, > and > >> > >> it seems that the respective code for minimized windows wouldn't be > >> > >> hard to implement. > >> > >> > >> > >> The questions are: are there any plans to add it? Is there someone > >> > >> already working on it? If not, would it be OK if I start submitting > >> > >> patches to try to add support for this? > >> > > > >> > > > >> > > A month or two ago, Scott Morreau was working on it. However, his > work > >> > > never made into weston for a variety of reasons. Personally, I'm > glad to > >> > > see someone interested in working on it again because it's > something that > >> > > wayland will need eventually. > >> > > > >> > > The place to start on it is probably with the following e-mail and > the > >> > long > >> > > string of replies: > >> > > > >> > > > >> > > http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html > >> > > > >> > > There was quite a bit of discussion about how to handle it from a > >> > protocol > >> > > level, but Scott never made an actual version 2. I'd suggest you > start > >> > by > >> > > reading the chain of e-mails (it goes into April, not just March). > There > >> > > were quite a few suggestions in there that could be incorporated. > >> > > Hopefully, you can pick through the e-mail discussion and figure > out what > >> > > the consensus was. It'd be good to have a pair of fresh eyes look > at it. > >> > > >> > Thanks for pointing that out. I just went through the chain of > >> > e-mails, but I don't think there was a consensus there. > >> > > >> > It also seems that the minimize implementation is a little more > >> > complex than just hiding surfaces and marking some flags. Which ma
Re: minimized and stick windows
2013/5/15 Pekka Paalanen > On Wed, 15 May 2013 14:20:21 +0200 > Alexander Preisinger wrote: > > > Hello, > > > > I thought a bit about it and like to present my ideas. > > I mainly thought about it from the shell/compositor site when I like to > > minimize, maximize surfaces from keybindings, like in some window > managers. > > > > For example the client can still request minimize, maximize, fullsrceen > and > > toplevel actions, but now the compositor responds with an state_update > > event. > > The compositor can also send this state_update when the compositor likes > > change the window on it's own (like some task bar or compositor key > > bindings). > > The client can then save the state and act accordingly (like hiding same > > menus if maximized or fullscreen). > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 3bce022..e0f2c4a 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -811,6 +811,14 @@ > > > allow-null="true"/> > > > > > > + > > + > > +Minimize the surface. > > + > > +The compositor responds with state_update event. > > + > > + > > + > > > > > > Set a short title for the surface. > > @@ -867,6 +875,30 @@ > > > > > > > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > +Tells the surface which state is has on the output. > > + > > +This event is sent in respons to set_maximized, set_minimized or > > +set_fullscreen request to acknowledge the request. The client can > > update it > > +own state if it wants to keep track of it. > > + > > +The also compositor sends this event if itt wants the surface > > minimized or > > +maximized. For example by clicking on a task list item or compositor > > key > > +bindings for fullscreen. > > + > > + > > + > > + > > > > > > The popup_done event is sent out when a popup grab is broken, > > > > > > I don't know about multiple window applications and maybe missed some > other > > use cases, but I hope this isn't too wrong of an idea. At least this > should > > hopefully not break the protocol too much. > > If I understood right, here you have the client asking the compositor > for permission, and then the compositor orders the client to be in a > certain state and will compose it as such, regardless of what the client > actually draws. > > This won't work, fixing the races it causes will complicate the > protocol and cause roundtrips. > > The client draws its window, hence the client is in charge of how it > looks, and the compositor cannot force that. > > Hence, it must be compositor proposing to the client that it should > e.g. maximize. It the client does that at some point, perhaps first > sending a few new frames since it was animating, the client will tell > the compositor it will now go maximized, and then the very next frame > it draws will be maximized. This avoids flicker. > > Yes that seems logical. So the update_state should then be a request/suggest_state event? It seems I am tainted by using tiling window managers, where they sometimes forces the size. > Minimize is a little special, since the client does not need to react > specially for it to look right. For everything else it will need to. > Actually, if you think about a multi-window application, minimize needs > to work the same way, so that application can hide all relevant > windows (but maybe not *all* windows). > > My Idea is that the client gets notified per shell surface and the client can hide all windows (for example we want to minimize the main window) or just the requested/proposed window. I will try get some basic implementation done, maybe I can reuse soreaus code for this. > > Deja vu, > pq > Thank you for your time Best Regards. Alexander Preisinger ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] wl_shell: Add surface state changed event
Nice! 2013/5/15 Mikko Levonmaa > This allows the shell to inform the surface that it has changed > state, current supported states are default, minimized, maximized > and fullscreen. The shell implementation is free to interpret the > meaning for the state, i.e. the minimized might not always mean > that the surface is fully hidden for example. > > Signed-off-by: Mikko Levonmaa > --- > protocol/wayland.xml | 15 +++ > 1 files changed, 15 insertions(+), 0 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 3bce022..ee7d32d 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -874,6 +874,21 @@ > to the client owning the popup surface. > > > + > + > + > + > + > + > Are these supposed to be flags? Like that it can send multiple states in one request? I think the client should keep track of the previous state itself and the compositor only sends the state he wants the client to have. > + > + > + > + > +The compositor or the user has taken action that has resulted in > +this surface to change state. > + > + > + > > > > -- > 1.7.4.1 > > ___ > 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: Wayland and Blender
Hi, Using Desktop OpenGL on wayland is possible. I wrote the EGL backend for the mpv video player which also uses Full OpenGL. The only problem is when you want to have a system without any X11 libraries. Best Regards, Alexander 2013/6/19 Wander Lairson Costa > Hi, > > I am starting to add support for Wayland in Blender. From mailing list > archives I see Campbell Barton has already discussed this possibility > here a long time ago. > > As far as I understood, Weston uses OpenGL ES because libGL depends on > GLX, which depends on X11 libraries. What I don't understand is if > this affects full OpenGL clients in runtime. By "affect in runtime" I > mean the application not running. I believe that this problem will be > fixed sooner or later, but I would like to know how can I test my > implementation in the mean time. > > As I am using EGL, I think that I can run Weston under X. > > Forgive me if this question is too newbie, but I am a starter with Wayland. > > -- > Best Regards, > Wander Lairson Costa > ___ > 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: How to check if OpenGL is supported?
Hi, You could use pkg-config to check for wayland-egl and egl. Best Regards, Alexander Preisinger 2013/9/10 Campbell Barton > Hi, I'm interested to get Blender (OpenGL 3d graphics application) > running with wayland/weston. > > However I cant tell if my configuration can even run simple OpenGL > applications (the more recent weston for arch-linux 1.2.2 has no > "weston-gears"). > > Whats a good way to see if loading opengl/egl applications is supported? > > Some more info in case it helps. > > > A while back I managed to run weston but no opengl applications would > work (weston-gears for example didn't start but weston-smoke did, It > gave some error about not being able to setup EGL). > I spent some time trying to get this running but I think it simply > wasn't supported by proprietary-nvidia & mesa configuration. > > More recently I tried again with a newer weston but now I cant find > weston-gears so not sure how to test. > > There is a git repo that Wander Costa has been working on, but its > crashing on my system (opengl context fails to initialize). > https://github.com/walac/blender-wayland > > So I want to know if this is a bug in the code or just a limitation > with my configuration. > > -- > - Campbell > ___ > 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: Stabilizing wl_scaler protocol extension
Hi pq, I use it in my wayland-next branch (for unstable wayland stuff) of the mpv player: http://mpv.io/ In this commit: https://github.com/mpv-player/mpv/commit/77cc885b44a9e95e5c3c9ae4961b9958ff5cf643 I only just now realized that I should just use set_destination for my use case. So setting the destination separately is definitely a use case and I think the set request is redundant. So far I really like the scaler extensions. But the scaling quality has lots of room for improvement. I thought about improving the scaling quality, but didn't had the opportunity to look into it. That's all from me. Best Regards, Alexander 2014-09-16 11:09 GMT+02:00 Pekka Paalanen : > Hi, > > wl_scaler has been sitting in Weston for quite some time now: > http://cgit.freedesktop.org/wayland/weston/tree/protocol/scaler.xml > > I would like to collect comments and opinions on the protocol extension: > - Is it ready? > - Are the interfaces ok? As in, have a wl_viewport created for a > wl_surface, instead of having wl_surface argument on a global request. > - Are the names ok? > - Should wl_viewport.set be removed as completely redundant? > - Do we care about maintaining compatibility with the current wl_scaler > protocol, when moving it into Wayland? > > Obviously, if we change anything, it won't be compatible with the > current version. > > My goal is to move wl_scaler or equivalent into the Wayland repository. > That effort is now tracked at: > https://bugs.freedesktop.org/show_bug.cgi?id=83918 > > (Also that I wouldn't forget again, as I already did. :-p) > > I don't know how widely or little it has been used so far, so simply > pointing out projects that already use it would be nice, too. > > Originally, I was waiting for the Presentation queueing to mature a bit > before declaring wl_scaler as stable, because queueing seemed to > require a split in the scaler state. That split is there now, and while > I haven't really worked on Presentation for a long time, I do not see > further changes needed. And even this split was introduced in a > backwards compatible manner. > > I don't have a deadline for this, but now would be a good time to bring > out all your critique about the wl_scaler/wl_viewport extension on the > record. :-) > > > Thanks, > pq > ___ > 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: Stabilizing wl_scaler protocol extension
2014-09-16 13:51 GMT+02:00 Pekka Paalanen : > On Tue, 16 Sep 2014 13:26:12 +0200 > Alexander Preisinger wrote: > > > Hi pq, > > > > I use it in my wayland-next branch (for unstable wayland stuff) of the > mpv > > player: http://mpv.io/ > > In this commit: > > > https://github.com/mpv-player/mpv/commit/77cc885b44a9e95e5c3c9ae4961b9958ff5cf643 > > Good to know, thanks. > > > I only just now realized that I should just use set_destination for my > use > > case. > > So setting the destination separately is definitely a use case and I > think > > the set request is redundant. > > True, but I'm worried how many upset people there will be if I break > the protocol during the migration by removing or renaming something. :-) > There should be no-one as it's all experimental still, but... > > I was just voicing my opinion for this question: > - Should wl_viewport.set be removed as completely redundant? Maybe I understood it wrong? Best Regards, Alexander ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Incompatible pointer type in dnd.c
Here is the patch for it. My very first patch ever :). 2010/11/30 Christoph Frieben : > dnd.c: In function ‘drop_io_func’: > dnd.c:362:2: warning: passing argument 4 of ‘g_io_channel_read_chars’ > from incompatible pointer type > /usr/include/glib-2.0/glib/giochannel.h:247:11: note: expected ‘gsize > *’ but argument is of type ‘unsigned int *’ > > Issued by GCC 4.5.1. > ~C > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > diff --git a/clients/dnd.c b/clients/dnd.c index dedf353..82c95da 100644 --- a/clients/dnd.c +++ b/clients/dnd.c @@ -356,7 +356,7 @@ drop_io_func(GIOChannel *source, GIOCondition condition, gpointer data) struct dnd_offer *dnd_offer = data; char buffer[256]; int fd; - unsigned int len; + gsize len; GError *err = NULL; g_io_channel_read_chars(source, buffer, sizeof buffer, &len, &err); ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Add minimum size for terminal
At the moment the terminal can a negativ size and resizing it can create some artifacts. --- clients/terminal.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/clients/terminal.c b/clients/terminal.c index 4308875..7e1c741 100644 --- a/clients/terminal.c +++ b/clients/terminal.c @@ -772,6 +772,12 @@ resize_handler(struct widget *widget, struct terminal *terminal = data; int32_t columns, rows, m; +if (width < 200) +width = 200; + +if (height < 50) +height = 50; + m = 2 * terminal->margin; columns = (width - m) / (int32_t) terminal->extents.max_x_advance; rows = (height - m) / (int32_t) terminal->extents.height; -- 1.7.10.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC] Add wayland support for MPlayer2
This patch series will enable support for wayland via EGL. Input and output works correctly. But there is no window decoration. Please have look and tell what should be changed or improved. This patch series also goes to wayland-devel@lists.freedesktop.org. Regards, Alexander Preisinger ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/3] Add wayland support
Implements shared routines for initialising wayland and keyboard/pointer input.
Indepentend from the video output.
---
libvo/wl_common.c | 634 ++
libvo/wl_common.h | 131 +++
2 files changed, 765 insertions(+)
create mode 100644 libvo/wl_common.c
create mode 100644 libvo/wl_common.h
diff --git a/libvo/wl_common.c b/libvo/wl_common.c
new file mode 100644
index 000..e271e5d
--- /dev/null
+++ b/libvo/wl_common.c
@@ -0,0 +1,634 @@
+/*
+ * This file is part of MPlayer.
+ *
+ * MPlayer is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * MPlayer is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with MPlayer; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "config.h"
+#include "bstr.h"
+#include "options.h"
+#include "mp_msg.h"
+#include "mp_fifo.h"
+#include "libavutil/common.h"
+#include "talloc.h"
+
+#include "wl_common.h"
+
+#include "video_out.h"
+#include "aspect.h"
+#include "geometry.h"
+#include "osdep/timer.h"
+
+#include "subopt-helper.h"
+
+#include "input/input.h"
+#include "input/keycodes.h"
+
+#ifdef CONFIG_GL_WAYLAND
+#include
+#endif
+
+static void create_display (struct wl_priv *wl);
+static void create_window (struct wl_priv *wl, int width, int height);
+
+/* SHELL SURFACE LISTENER */
+static void ssurface_handle_ping (void *data,
+struct wl_shell_surface *shell_surface, uint32_t serial)
+{
+wl_shell_surface_pong(shell_surface, serial);
+}
+
+static void ssurface_handle_configure (void *data,
+struct wl_shell_surface *shell_surface,
+uint32_t edges, int32_t width, int32_t height)
+{
+}
+
+static void ssurface_handle_popup_done (void *data,
+struct wl_shell_surface *shell_surface)
+{
+}
+
+const struct wl_shell_surface_listener shell_surface_listener = {
+ssurface_handle_ping,
+ssurface_handle_configure,
+ssurface_handle_popup_done
+};
+
+/* OUTPUT LISTENER */
+static void output_handle_geometry (void *data, struct wl_output *wl_output,
+int32_t x, int32_t y, int32_t physical_width, int32_t physical_height,
+int32_t subpixel, const char *make, const char *model,
+int32_t transform)
+{
+struct vo_wl_display *d = data;
+
+d->pos_x = x;
+d->pos_y = y;
+}
+
+static void output_handle_mode (void *data, struct wl_output *wl_output,
+uint32_t flags, int32_t width, int32_t height, int32_t refresh)
+{
+struct vo_wl_display *d = data;
+
+d->output_height = height;
+d->output_width = width;
+d->mode_received = 1;
+}
+
+const struct wl_output_listener output_listener = {
+output_handle_geometry,
+output_handle_mode
+};
+
+/* KEY LOOKUP */
+static const struct mp_keymap keymap[] = {
+// special keys
+{XKB_KEY_Pause, KEY_PAUSE}, {XKB_KEY_Escape, KEY_ESC},
+{XKB_KEY_BackSpace, KEY_BS}, {XKB_KEY_Tab, KEY_TAB},
+{XKB_KEY_Return, KEY_ENTER}, {XKB_KEY_Menu, KEY_MENU},
+{XKB_KEY_Print, KEY_PRINT},
+
+// cursor keys
+{XKB_KEY_Left, KEY_LEFT}, {XKB_KEY_Right, KEY_RIGHT},
+{XKB_KEY_Up, KEY_UP}, {XKB_KEY_Down, KEY_DOWN},
+
+// navigation block
+{XKB_KEY_Insert, KEY_INSERT}, {XKB_KEY_Delete, KEY_DELETE},
+{XKB_KEY_Home, KEY_HOME}, {XKB_KEY_End, KEY_END},
+{XKB_KEY_Page_Up, KEY_PAGE_UP}, {XKB_KEY_Page_Down, KEY_PAGE_DOWN},
+
+// F-keys
+{XKB_KEY_F1, KEY_F+1}, {XKB_KEY_F2, KEY_F+2}, {XKB_KEY_F3, KEY_F+3},
+{XKB_KEY_F4, KEY_F+4}, {XKB_KEY_F5, KEY_F+5}, {XKB_KEY_F6, KEY_F+6},
+{XKB_KEY_F7, KEY_F+7}, {XKB_KEY_F8, KEY_F+8}, {XKB_KEY_F9, KEY_F+9},
+{XKB_KEY_F10, KEY_F+10}, {XKB_KEY_F11, KEY_F+11}, {XKB_KEY_F12, KEY_F+12},
+
+// numpad independent of numlock
+{XKB_KEY_KP_Subtract, '-'}, {XKB_KEY_KP_Add, '+'},
+{XKB_KEY_KP_Multiply, '*'}, {XKB_KEY_KP_Divide, '/'},
+{XKB_KEY_KP_Enter, KEY_KPENTER},
+
+// numpad with numlock
+{XKB_KEY_KP_0, KEY_KP0}, {XKB_KEY_KP_1, KEY_KP1}, {XKB_KEY_KP_2, KEY_KP2},
+{XKB_KEY_KP_3, KEY_KP3}, {XKB_KEY_KP_4, KEY_KP4}, {XKB_KEY_KP_5, KEY_KP5},
+{XKB_KEY_KP_6, KEY_KP6}, {XKB_KEY_KP_7, KEY_KP7}, {XKB_KEY_KP_8, KEY_KP8},
+{XKB_KEY_KP_9, KEY_KP9}, {XKB_KEY_KP_Decimal, KEY_KPDEC},
+{XKB_KEY_KP_Separator, KEY_KPDEC},
+
+// numpad without numlock
+{XKB_KEY_KP_Insert, KEY_KPINS}, {XKB_KEY_KP_End, KEY_KP1},
+{XKB_KEY_KP_Down, KEY_KP2}, {XKB_KEY_KP_Page_Down, KEY_KP3}
[PATCH 2/3] Add wayland egl support for vo_gl
---
libvo/gl_common.c | 199 ++
libvo/gl_common.h | 9 +++
2 files changed, 208 insertions(+)
diff --git a/libvo/gl_common.c b/libvo/gl_common.c
index 3b72349..d916db7 100644
--- a/libvo/gl_common.c
+++ b/libvo/gl_common.c
@@ -1971,6 +1971,182 @@ static void swapGlBuffers_x11(MPGLContext *ctx)
}
#endif
+#ifdef CONFIG_GL_WAYLAND
+#include
+#include "wl_common.h"
+
+static struct wl_priv wl = {NULL, NULL, NULL, NULL};
+/* New wl_common requires to preset it
+to zero, but that is a bit too hackish for my taste.
+Maybe there is another way to get around the fact that mplayer calls
+vo_init two times. */
+
+struct vo_wl_private {
+EGLSurface egl_surface;
+
+struct {
+EGLDisplay dpy;
+EGLContext ctx;
+EGLConfig conf;
+} egl;
+};
+
+static void appendstr(char **dst, const char *str)
+{
+int newsize;
+char *newstr;
+if (!str)
+return;
+newsize = strlen(*dst) + 1 + strlen(str) + 1;
+newstr = realloc(*dst, newsize);
+if (!newstr)
+return;
+*dst = newstr;
+strcat(*dst, " ");
+strcat(*dst, str);
+}
+
+static int init_wayland(struct vo *vo)
+{
+wl.vo = vo;
+return vo_wl_priv_init(&wl);
+}
+
+static int create_window_wayland(struct MPGLContext *ctx, uint32_t d_width,
+ uint32_t d_height, uint32_t flags)
+{
+wl.window->width = d_width;
+wl.window->height = d_height;
+
+if (!wl.window)
+return 0;
+
+if (!wl.window->private) {
+wl.window->private = malloc(sizeof(struct vo_wl_private));
+
+wl.window->private->egl.dpy = eglGetDisplay(wl.display->display);
+assert(wl.window->private->egl.dpy);
+
+wl.window->egl_window = wl_egl_window_create(wl.window->surface,
+wl.window->width, wl.window->height);
+
+wl.window->x = wl.display->pos_x;
+wl.window->y = wl.display->pos_y;
+}
+
+return 1;
+}
+
+static int setGlWindow_wayland(MPGLContext *ctx)
+{
+GL *gl = ctx->gl;
+void *(*getProcAddress)(const GLubyte *);
+const char *(*eglExtStr)(EGLDisplay *, int);
+char *eglstr = strdup("");
+
+EGLint config_attribs[] = {
+EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
+EGL_RED_SIZE, 1,
+EGL_GREEN_SIZE, 1,
+EGL_BLUE_SIZE, 1,
+EGL_ALPHA_SIZE, 0,
+EGL_DEPTH_SIZE, 1,
+EGL_RENDERABLE_TYPE, EGL_OPENGL_BIT,
+EGL_NONE
+};
+
+EGLint major, minor, n;
+EGLBoolean ret;
+
+ret = eglInitialize(wl.window->private->egl.dpy, &major, &minor);
+assert(ret == EGL_TRUE);
+
+ret = eglBindAPI(EGL_OPENGL_API);
+assert(ret == EGL_TRUE);
+
+ret = eglChooseConfig(wl.window->private->egl.dpy, config_attribs,
+ &wl.window->private->egl.conf, 1, &n);
+assert(ret && n == 1);
+
+wl.window->private->egl.ctx = eglCreateContext(
+wl.window->private->egl.dpy,
+wl.window->private->egl.conf,
+EGL_NO_CONTEXT, NULL);
+assert(wl.window->private->egl.ctx);
+
+wl.window->private->egl_surface = eglCreateWindowSurface(
+wl.window->private->egl.dpy, wl.window->private->egl.conf,
+wl.window->egl_window, NULL);
+
+ret = eglMakeCurrent(wl.window->private->egl.dpy,
+wl.window->private->egl_surface,
+wl.window->private->egl_surface,
+wl.window->private->egl.ctx);
+
+assert(ret == EGL_TRUE);
+
+getProcAddress = getdladdr("eglGetProcAddress");
+if (!getProcAddress)
+mp_msg(MSGT_VO, MSGL_WARN, "[egl] No eglGetProcAdress");
+
+eglExtStr = getdladdr("eglQueryString");
+if (eglExtStr)
+appendstr(&eglstr,
+eglExtStr(wl.window->private->egl.dpy, EGL_EXTENSIONS));
+
+getFunctions(gl, (void *(*)(const GLubyte*))eglGetProcAddress, eglstr);
+if (!gl->BindProgram)
+getFunctions(gl, NULL, eglstr);
+
+wl_display_roundtrip(wl.display->display);
+
+return SET_WINDOW_OK;
+}
+
+static void update_xinerama_info_wayland(struct vo * vo)
+{
+struct MPOpts *opts = vo->opts;
+
+vo_wl_priv_init(&wl);
+
+while (!wl.display->mode_received)
+wl_display_roundtrip(wl.display->display);
+
+opts->vo_screenwidth = wl.display->output_width;
+opts->vo_screenheight = wl.display->output_height;
+
+aspect_save_screenres(vo, opts->vo_screenwidth, opts->vo_screenheight);
+}
+
+static void releaseGlContext_wayland(MPGLContext *ctx)
+{
+GL *gl = ctx->gl;
+gl->Finish();
+eglMakeCurrent(wl.window->private->egl.dpy, NULL, NULL, EGL_NO_CONTEXT);
+eglDestroyContext(wl.window->private->egl.dpy,
+wl.window->private->egl.ctx);
+eglTerminate(wl.window->private->egl.dpy);
+}
+
+static void swapGlBuffers_wayland(MPGLContext *ctx)
+{
+eglSwapBuffers(wl.window->private->egl.dpy,
+wl.window->private->egl_surface);
+wl_display_flush(wl.display->display)
[PATCH 3/3] Enable build for wayland egl
This uses 2 defines
* CONFIG_WAYLAND
* CONFIG_GL_WAYLAND
CONFIG_WAYLAND is not used at the moment
---
Makefile | 1 +
configure | 48 +++-
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index d1ce8dd..035606c 100644
--- a/Makefile
+++ b/Makefile
@@ -453,6 +453,7 @@ SRCS_MPLAYER-$(GL) += libvo/gl_common.c
libvo/vo_gl.c \
SRCS_MPLAYER-$(GL_SDL) += libvo/sdl_common.c
SRCS_MPLAYER-$(GL_WIN32) += libvo/w32_common.c
SRCS_MPLAYER-$(GL_X11) += libvo/x11_common.c
+SRCS_MPLAYER-$(GL_WAYLAND) += libvo/wl_common.c
SRCS_MPLAYER-$(IVTV) += libao2/ao_ivtv.c libvo/vo_ivtv.c
SRCS_MPLAYER-$(JACK) += libao2/ao_jack.c
diff --git a/configure b/configure
index 5c1e288..d698031 100755
--- a/configure
+++ b/configure
@@ -416,6 +416,7 @@ Video output:
--enable-vm enable XF86VidMode support [autodetect]
--enable-xineramaenable Xinerama support [autodetect]
--enable-x11 enable X11 video output [autodetect]
+ --enable-wayland enable Wayland video output [autodetect]
--enable-xshape enable XShape support [autodetect]
--disable-xssdisable screensaver support via xss [autodetect]
--enable-fbdev enable FBDev video output [autodetect]
@@ -560,6 +561,7 @@ ffmpeg=auto
ffmpeg_internals=no
_mplayer=yes
_x11=auto
+_wayland=auto
_xshape=auto
_xss=auto
_dga1=auto
@@ -839,6 +841,8 @@ for ac_option do
--disable-cross-compile) _cross_compile=no ;;
--enable-mplayer) _mplayer=yes;;
--disable-mplayer)_mplayer=no ;;
+ --enable-wayland) _wayland=yes;;
+ --disable-wayland)_wayland=no ;;
--enable-x11) _x11=yes;;
--disable-x11)_x11=no ;;
--enable-xshape) _xshape=yes ;;
@@ -3833,6 +3837,34 @@ depends_on_application_services(){
fi #if darwin
+echocheck "Wayland headers presence"
+ _wayland_headers="no"
+ res_comment="check if the dev(el) packages are installed"
+ for I in $(echo $extra_cflags | sed s/-I//g) /usr/include ; do
+if test -f "$I/wayland-client.h" ; then
+ _wayland_headers="yes"
+ res_comment=""
+ break
+fi
+ done
+echores "$_wayland_headers"
+
+echocheck "Wayland"
+if test "$_wayland" = auto && test "$_wayland_headers" = yes ; then
+ pkg_config_add "wayland-client" && _wayland="yes"
+fi
+if test "$_wayland" = yes ; then
+ def_wayland='#define CONFIG_WAYLAND'
+ vomodules="wayland $vomodules"
+ libs_mplayer="$libs_mplayer -lwayland-client -lxkbcommon"
+ #pkg_config_add doesn't work
+else
+ _wayland="no"
+ def_wayland="#undef CONFIG_WAYLAND"
+ novomodules="wayland $novomodules"
+ res_comment="check if the dev(el) packages are installed"
+fi
+echores "$_wayland"
echocheck "X11 headers presence"
_x11_headers="no"
@@ -4475,7 +4507,7 @@ echores "$_sdl"
# conflicts between -lGL and -framework OpenGL
echocheck "OpenGL"
#Note: this test is run even with --enable-gl since we autodetect linker flags
-if (test "$_x11" = yes || test "$_sdl" = yes || test "$_cocoa" = yes || win32)
&& test "$_gl" != no ; then
+if (test "$_x11" = yes || test "$_wayland" = yes || test "$_sdl" = yes || test
"$_cocoa" = yes || win32) && test "$_gl" != no ; then
cat > $TMPC << EOF
#ifdef GL_WIN32
#include
@@ -4520,6 +4552,11 @@ EOF
fi
done
fi
+ if test "$_wayland" = yes ; then
+_gl=yes
+_gl_wayland=yes
+libs_mplayer="$libs_mplayer -lGL -lEGL -lwayland-egl"
+ fi
if win32 && cc_check -DGL_WIN32 -lopengl32 ; then
_gl=yes
_gl_win32=yes
@@ -4560,6 +4597,10 @@ if test "$_gl" = yes ; then
def_gl_x11='#define CONFIG_GL_X11 1'
res_comment="$res_comment x11"
fi
+ if test "$_gl_wayland" = yes ; then
+def_gl_wayland='#define CONFIG_GL_WAYLAND'
+res_comment="$res_comment wayland"
+ fi
if test "$_gl_sdl" = yes ; then
def_gl_sdl='#define CONFIG_GL_SDL 1'
res_comment="$res_comment sdl"
@@ -4570,6 +4611,7 @@ else
def_gl_cocoa='#undef CONFIG_GL_COCOA'
def_gl_win32='#undef CONFIG_GL_WIN32'
def_gl_x11='#undef CONFIG_GL_X11'
+ def_gl_wayland='#undef CONFIG_GL_WAYLAND'
def_gl_sdl='#undef CONFIG_GL_SDL'
novomodules="opengl $novomodules"
fi
@@ -6305,6 +6347,7 @@ GL = $_gl
GL_COCOA = $_gl_cocoa
GL_WIN32 = $_gl_win32
GL_X11 = $_gl_x11
+GL_WAYLAND = $_gl_wayland
GL_SDL = $_gl_sdl
HAVE_POSIX_SELECT = $_posix_select
HAVE_SYS_MMAN_H = $_mman
@@ -6380,6 +6423,7 @@ WIN32DLL = $_win32dll
WIN32WAVEOUT = $_win32waveout
WIN32_EMULATION = $_win32_emulation
X11 = $_x11
+WAYLAND = $_wayland
XANIM_CODECS = $_xanim
XMGA = $_xmga
XMMS_PLUGINS = $_xmms
@@ -6699,6 +6743,7 @@ $def_gl
$def_gl_cocoa
$def_gl_win32
$def_gl_x11
+$def_gl_wayland
$def_gl_sdl
$def_ivtv
$def_jpeg
@@ -6720,6 +6765,7 @@ $def_vesa
$def_vm
$def_wii
$def_x11
+$def_wayland
$def_xdpms
$def_xf86keysym
$def_xinerama
--
1.7.12
Re: [PATCH 1/3] Add wayland support
Sorry I didn't send it to the mailing list.
2012/8/24 Pekka Paalanen :
> On Fri, 24 Aug 2012 08:08:22 +0200
> Alexander Preisinger wrote:
>
>> Implements shared routines for initialising wayland and keyboard/pointer
>> input.
>> Indepentend from the video output.
>
> Hi,
>
> I have some wayland protocol related comments below, inline.
>
>> +static void create_display (struct wl_priv *wl);
>> +static void create_window (struct wl_priv *wl, int width, int height);
>> +
>> +/* SHELL SURFACE LISTENER */
>> +static void ssurface_handle_ping (void *data,
>> +struct wl_shell_surface *shell_surface, uint32_t serial)
>> +{
>> +wl_shell_surface_pong(shell_surface, serial);
>> +}
>> +
>> +static void ssurface_handle_configure (void *data,
>> +struct wl_shell_surface *shell_surface,
>> +uint32_t edges, int32_t width, int32_t height)
>> +{
>> +}
>> +
>> +static void ssurface_handle_popup_done (void *data,
>> +struct wl_shell_surface *shell_surface)
>> +{
>> +}
>> +
>> +const struct wl_shell_surface_listener shell_surface_listener = {
>> +ssurface_handle_ping,
>> +ssurface_handle_configure,
>> +ssurface_handle_popup_done
>> +};
>> +
>> +/* OUTPUT LISTENER */
>> +static void output_handle_geometry (void *data, struct wl_output *wl_output,
>> +int32_t x, int32_t y, int32_t physical_width, int32_t
>> physical_height,
>> +int32_t subpixel, const char *make, const char *model,
>> +int32_t transform)
>> +{
>> +struct vo_wl_display *d = data;
>> +
>> +d->pos_x = x;
>> +d->pos_y = y;
>
> What are these x and y used for? They are leftovers from the global
> coordinate system removal, and I don't think they should be used at all.
>
> Doesn't mplayer use the physical dimensions for anything?
>
> Later you would also want to take care of the transform, so that for a
> rotated output, you can render a rotated image so that Weston is not
> forced to rotate it. That would be especially useful for fullscreen
> output, where weston might be able to scan out your image without
> compositing it first.
>
>> +}
>> +
>> +static void output_handle_mode (void *data, struct wl_output *wl_output,
>> +uint32_t flags, int32_t width, int32_t height, int32_t refresh)
>> +{
>> +struct vo_wl_display *d = data;
>> +
>> +d->output_height = height;
>> +d->output_width = width;
>> +d->mode_received = 1;
>
> You will get a mode event for every possible video mode an output *may*
> have. If you want the current mode, you need to pick the one which has
> "current" flag set. Note, that the x11 backend of Weston does not
> advertise more than one mode, but the DRM backend does.
>
> I think this event is also sent, when the output mode is changed... or
> at least when the default mode is changed, not sure if it is emitted
> for fullscreen switches.
>
>> +}
>> +
>> +const struct wl_output_listener output_listener = {
>> +output_handle_geometry,
>> +output_handle_mode
>> +};
>
>> +/* POINTER LISTENER */
>> +static void pointer_handle_enter(void *data, struct wl_pointer *pointer,
>> +uint32_t serial, struct wl_surface *surface,
>> +wl_fixed_t sx_w, wl_fixed_t sy_w)
>> +{
>
> I think you should set a cursor here, or set a NULL cursor if you want
> to hide it. Otherwise you probably get whatever cursor another client
> set earlier.
>
>> +}
>> +
>> +static void pointer_handle_leave(void *data, struct wl_pointer *pointer,
>> +uint32_t serial, struct wl_surface *surface)
>> +{
>> +}
>> +
>> +static void pointer_handle_motion(void *data, struct wl_pointer *pointer,
>> +uint32_t time, wl_fixed_t sx_w, wl_fixed_t sy_w)
>> +{
>> +}
>> +
>> +static void pointer_handle_button(void *data, struct wl_pointer *pointer,
>> +uint32_t serial, uint32_t time, uint32_t button, uint32_t state)
>> +{
>> +struct wl_priv *wl = data;
>> +
>> +mplayer_put_key(wl->vo->key_fifo, MOUSE_BTN0 + (button - BTN_LEFT) |
>> +((state == WL_POINTER_BUTTON_STATE_PRESSED) ? MP_KEY_DOWN : 0));
>> +}
>> +
>> +static void pointer_handle_axis(void *data, struct wl_pointer *pointer,
>> +uint32_t time, uint32_t axis, wl_fixed_t value)
>> +{
>> +struct wl_priv *wl = data;
>> +
>> +if (axis == WL_POINTER_AXIS_VERTICAL_SCROLL) {
>> +
Re: [RFC] Add wayland support for MPlayer2
Sorry for the late answer.
2012/8/24 Uoti Urpala :
> On Fri, 2012-08-24 at 08:08 +0200, Alexander Preisinger wrote:
>> This patch series will enable support for wayland via EGL.
>> Input and output works correctly. But there is no window decoration.
>>
>> Please have look and tell what should be changed or improved.
>
> This was already very briefly discussed on IRC, but I'll write a reply
> here now in a bit more detail.
>
> The first main issue is that I can't easily test Wayland code, and I
> haven't heard of others using it either. Adding code like this in
> gl_common.c will cause some problems if there's nobody who's doing
> player development/testing otherwise and would compile/run it. What are
> the actual benefits? Which users would benefit and how?
The actual benefit is that we have a native media player. I wanted to know
how hard or easy it is to port a program to wayland and I choose
mplayer2, because I use it daily.
>
>
> Here are some issues about the patch I noticed (but it's probably not
> worth spending too much time on the particulars now, if it's not clear
> if it'd be applied anyway):
>
> Having a separate configure check for "Wayland headers presence" seems
> completely pointless. Its result isn't used for anything separate.
>
> Does Wayland presence somehow guarantee libxkb presence? Should that not
> be tested separately?
>
> You have "pkg_config_add" but then a comment "#pkg_config_add doesn't
> work" and add some libs manually. What does the .pc file on your system
> add then?
I screwed up the configure check that's why pkg_config_add didn't work.
I also added xkbcommmon to the check and removed the separate check.
>
> Adding "wayland" to the "vomodules" configure variable is wrong, as
> there is no vo_wayland; it's only a backend for vo_gl.
>
I accidentally left it there, because for testing I added another vo module
with shm buffers.
> res_comment="check if the dev(el) packages are installed" shouldn't be
> there; that'd apply equally to almost any library, and Wayland is
> currently one of the things most people don't need to check even if not
> enabled.
>
> +static struct wl_priv wl = {NULL, NULL, NULL, NULL};
> +/* New wl_common requires to preset it
> +to zero, but that is a bit too hackish for my taste.
>
> I'm not sure what that comment is about; does it refer to the "NULL"
> initialization above? That initialization does not actually do anything;
> the variable would be zero-initialized by default anyway. Adding a
> static variable to gl_common is quite ugly.
>
> You add a second copy of the appendstr() function.
>
> wm_common.c is compiled if GL_WAYLAND is enabled, but still pointlessly
> tests for "#ifdef CONFIG_GL_WAYLAND".
>
I left it there because it is possible to use different rendering backends
with wayland aside from EGL. But I think it is better to remove the #ifdef
because the GL output will be the only one worth using.
> The vo_wl_check_events() function seems to be unused; instead
> vo_wl_priv_check_events() is called.
>
> What's the deal with the repeat.timer_fd stuff? Does wayland input not
> have native key repeat, so you emulate that manually with one
> arbitrarily picked repeat rate?
>
> Handling of window resize events seems to be missing.
>
>
> I didn't look at most of the actual Wayland code.
>
Thanks for your input. I will try to fix the patches according to your
comments. As for the timer_fd stuff, it was used in weston toytoolkit and
I found no other way to implement repeating keys. I should take more time
to look into xkbcommon. Maybe there is already some native way of doing this.
But as of now xkbcommon, had no official release.
Thanks,
Alexander Preisinger
>
> ___
> mplayer2-dev mailing list
> mplayer2-...@mplayer2.org
> http://lists.mplayer2.org/mailman/listinfo/mplayer2-dev
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
