Re: [PATCH weston] gl-renderer: allow EGL_NATIVE_VISUAL_ID to be 0 in configs

[Manuel Bachmann]

Hi Derek, and thanks for your answer,

You are right, maybe we could search a config with matching visual_id, and
if one does not exist, then fallback to a "0" config.

I can rework the patch to do this ; but if you already started working on a
new one, I will wait and be happy to test it :).

PS : it is Mesa 10.3.7.



Regards,

*Manuel Bachmann, Graphics Engineer www.iot.bzh <http://iot.bzh> *


2015-11-04 21:45 GMT+01:00 Derek Foreman <der...@osg.samsung.com>:

> On 04/11/15 01:44 PM, Bryce Harrington wrote:
> > On Wed, Nov 04, 2015 at 02:57:11PM +0100, Manuel Bachmann wrote:
> >> Accept 0 as a valid value for the EGL_NATIVE_VISUAL_ID
> >> attribute in EGL configurations, just as we did before
> >> commit e76f185.
> >>
> >> (fixes running Weston with DRM backend and gl-renderer
> >> on Lenovo ThinkPad with i915 driver)
> >>
> >> Signed-off-by: Manuel Bachmann <manuel.bachm...@iot.bzh>
> >
> > Confirmed; the code prior to that refactor was allowing id == 0 through.
> >
> > Reviewed-by: Bryce Harrington <br...@osg.samsung.com>
> > Cc: Derek Foreman <der...@osg.samsung.com>
> >
> >> ---
> >>  src/gl-renderer.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/src/gl-renderer.c b/src/gl-renderer.c
> >> index d7231f4..85c69f3 100644
> >> --- a/src/gl-renderer.c
> >> +++ b/src/gl-renderer.c
> >> @@ -2194,7 +2194,7 @@ match_config_to_visual(EGLDisplay egl_display,
> >>  ))
> >>  continue;
> >>
> >> -if (id == visual_id)
> >> +if (id == 0 || id == visual_id)
>
> I think this could potentially pick the wrong id on some systems?
>
> Seems like it's theoretically possible for visuals with a native id of 0
> to be tested before the ones with legitimate ids...  I think we should
> always prefer a visual with a matching id if at all possible.
>
> Just out of curiosity, what version of Mesa are you using?
>
> I'll post an alternative patch shortly - I can't reproduce your bug, so
> it'd be great if you could try it...
>
> >>  return i;
> >>  }
> >>
> >> --
> >> 1.8.3.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

[PATCH weston] gl-renderer: allow EGL_NATIVE_VISUAL_ID to be 0 in configs

[Manuel Bachmann]

Accept 0 as a valid value for the EGL_NATIVE_VISUAL_ID
attribute in EGL configurations, just as we did before
commit e76f185.

(fixes running Weston with DRM backend and gl-renderer
on Lenovo ThinkPad with i915 driver)

Signed-off-by: Manuel Bachmann <manuel.bachm...@iot.bzh>
---
 src/gl-renderer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index d7231f4..85c69f3 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -2194,7 +2194,7 @@ match_config_to_visual(EGLDisplay egl_display,
))
continue;
 
-   if (id == visual_id)
+   if (id == 0 || id == visual_id)
return i;
}
 
-- 
1.8.3.1

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

[PATCH][weston] build: Require dbus for systemd-login

[Manuel Bachmann]

systemd-login support requires dbus (see "dbus.h" header in
"launcher-logind.c") but the configure script was only
checking libsystemd-login availability to define the
HAVE_SYSTEMD_LOGIN macro, which results in undefined
symbols in launcher-unit.

Put the systemd-login checks after the dbus ones, and only
run the checks if it is present. Also mention dbus in the
error message if "--enable-systemd-login" was forced.

Signed-off-by: Manuel Bachmann <manuel.bachm...@iot.bzh>
---
 configure.ac | 66 +++-
 1 file changed, 34 insertions(+), 32 deletions(-)

diff --git a/configure.ac b/configure.ac
index e5afbc0..9e29098 100644
--- a/configure.ac
+++ b/configure.ac
@@ -380,38 +380,6 @@ AC_ARG_ENABLE(resize-optimization,
 AS_IF([test "x$enable_resize_optimization" = "xyes"],
   [AC_DEFINE([USE_RESIZE_POOL], [1], [Use resize memory pool as a 
performance optimization])])
 
-AC_ARG_ENABLE(systemd-login,
-  AS_HELP_STRING([--enable-systemd-login],
- [Enable logind support]),,
-  enable_systemd_login=auto)
-if test x$enable_systemd_login != xno; then
-  PKG_CHECK_MODULES(SYSTEMD_LOGIN,
-[libsystemd >= 209],
-[have_systemd_login_209=yes;have_systemd_login=yes],
-[have_systemd_login_209=no;have_systemd_login=no])
-
-  # Older versions of systemd package systemd-login separately. Fall back on 
that
-  AS_IF([test x$have_systemd_login != xyes],[
-PKG_CHECK_MODULES(SYSTEMD_LOGIN,
-  [libsystemd-login >= 198],
-  [have_systemd_login=yes],
-  [have_systemd_login=no])
-])
-else
-  have_systemd_login=no
-fi
-
-if test "x$have_systemd_login" = "xno" -a "x$enable_systemd_login" = "xyes"; 
then
-  AC_MSG_ERROR([systemd-login support explicitly enabled, but can't find 
libsystemd>=209 or libsystemd-login])
-fi
-
-AS_IF([test "x$have_systemd_login" = "xyes"],
-  [AC_DEFINE([HAVE_SYSTEMD_LOGIN], [1], [Have systemd-login])])
-AM_CONDITIONAL(HAVE_SYSTEMD_LOGIN, test "x$have_systemd_login" = "xyes")
-
-AS_IF([test "x$have_systemd_login_209" = "xyes"],
-  [AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 209])])
-
 AC_ARG_ENABLE(weston-launch, [  --enable-weston-launch],, 
enable_weston_launch=yes)
 AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch == xyes)
 if test x$enable_weston_launch == xyes; then
@@ -484,6 +452,40 @@ if test "x$enable_dbus" != "xno"; then
 fi
 AM_CONDITIONAL(ENABLE_DBUS, test "x$enable_dbus" = "xyes")
 
+# systemd-login support
+AC_ARG_ENABLE(systemd-login,
+  AS_HELP_STRING([--enable-systemd-login],
+ [Enable logind support]),,
+  enable_systemd_login=auto)
+if test x$enable_systemd_login != xno -a x$have_dbus != xno; then
+  PKG_CHECK_MODULES(SYSTEMD_LOGIN,
+[libsystemd >= 209],
+[have_systemd_login_209=yes;have_systemd_login=yes],
+[have_systemd_login_209=no;have_systemd_login=no])
+
+  # Older versions of systemd package systemd-login separately. Fall back on 
that
+  AS_IF([test x$have_systemd_login != xyes],[
+PKG_CHECK_MODULES(SYSTEMD_LOGIN,
+  [libsystemd-login >= 198],
+  [have_systemd_login=yes],
+  [have_systemd_login=no])
+])
+else
+  have_systemd_login=no
+fi
+
+if test "x$have_systemd_login" = "xno" -a "x$enable_systemd_login" = "xyes"; 
then
+  AC_MSG_ERROR([systemd-login support explicitly enabled, but can't find 
libsystemd>=209, libsystemd-login or dbus])
+fi
+
+AS_IF([test "x$have_systemd_login" = "xyes"],
+  [AC_DEFINE([HAVE_SYSTEMD_LOGIN], [1], [Have systemd-login])])
+AM_CONDITIONAL(HAVE_SYSTEMD_LOGIN, test "x$have_systemd_login" = "xyes")
+
+AS_IF([test "x$have_systemd_login_209" = "xyes"],
+  [AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 209])])
+
+
 # Note that other features might want libxml2, or this feature might use
 # alternative xml libraries at some point. Therefore the feature and
 # pre-requisite concepts are split.
-- 
1.8.3.1

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

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

[Manuel Bachmann]

Hi Jonas, Daniel, Derek, Bill,

My apologizes for the late answer, I initiallty wanted to come back Monday
with a new test case, and missed some answers.

* Jonas, good point, I forgot to bump the protocol here. I really think it
fits into xdg-shell ; what are you thinking of when you are referring to an
extension ? An additional .xml ? If it can be done without breaking
anything, I would be happy to push it for review.

Regarding the core of the topic - and the usefulness of these requests - my
point is that  :
- it is useful to desktop software (messaging IRC clients, text editors,
browsers, etc..) ;
- embedded-oriented distributions, such as AGL, will definitely need it as
it is a common usecase for their Wayland backends.

 I wanted to showcase a heavy client such as Empathy implementing this, it
unfortunately got delayed, but I'll try to have it ASAP.

* Daniels, I totally agree with you that "raise()" is a bad choice of
wording, it offers false expectations, and we agreed with Jasper that
present() is a lot better (plus, it resembles a "present()" function
present in popular toolkits such as GTK+) ;

* Bill, Derek, about having a single request which always takes a serial
argument : I initially thought the same because it seems a lot cleaner,
but as no consensus was reached, and Wayland wants to position itself as a
stable protocol, I think we better have the double request model for now.

Thanks a lot for your time and patience.





Regards,

*Manuel Bachmann, Graphics Engineer www.iot.bzh <http://iot.bzh> *


2015-10-02 4:07 GMT+02:00 Jonas Ådahl <jad...@gmail.com>:

> On Thu, Apr 09, 2015 at 06:22:53PM +0200, Manuel Bachmann wrote:
> > xdg_surface_present() and xdg_surface_present_from_event()
> > are new requests supposed to be called on an existing
> > xdg_surface. They tell the compositor that the surface
> > has new content which may be of interest to the user.
> > The compositor may then choose to notify the user.
> >
> > xdg_surface_present_from_event() takes a serial coming
> > from an input (wl_keyboard, wl_pointer, wl_touch) event as
> > an argument. If the serial is valid and sufficiently recent,
> > we can suppose the new content has been issued at the user's
> > request ; the compositor may then choose to raise the
> > surface directly. Otherwise, it just behaves like present().
> >
> > Signed-off-by: Manuel Bachmann <manuel.bachm...@open.eurogiciel.org>
> > ---
> >  desktop-shell/shell.c  | 15 +++
> >  protocol/xdg-shell.xml | 20 
> >  2 files changed, 35 insertions(+)
> >
> > diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> > index f7c928e..d1d3f3c 100644
> > --- a/desktop-shell/shell.c
> > +++ b/desktop-shell/shell.c
> > @@ -3923,6 +3923,19 @@ xdg_surface_set_minimized(struct wl_client
> *client,
> >   set_minimized(shsurf->surface);
> >  }
> >
> > +static void
> > +xdg_surface_present(struct wl_client *client,
> > + struct wl_resource *resource)
> > +{
> > +}
> > +
> > +static void
> > +xdg_surface_present_from_event(struct wl_client *client,
> > +struct wl_resource *resource,
> > +uint32_t serial)
> > +{
> > +}
> > +
> >  static const struct xdg_surface_interface xdg_surface_implementation = {
> >   xdg_surface_destroy,
> >   xdg_surface_set_parent,
> > @@ -3938,6 +3951,8 @@ static const struct xdg_surface_interface
> xdg_surface_implementation = {
> >   xdg_surface_set_fullscreen,
> >   xdg_surface_unset_fullscreen,
> >   xdg_surface_set_minimized,
> > + xdg_surface_present,
> > + xdg_surface_present_from_event,
> >  };
> >
> >  static void
> > diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
> > index 68cf469..10f82c5 100644
> > --- a/protocol/xdg-shell.xml
> > +++ b/protocol/xdg-shell.xml
> > @@ -396,6 +396,26 @@
> >
> >  
> >
> > +
> > +  
> > + The surface has new content and would like the compositor
> > + to notify the user.
> > +  
> > +
> > +
> > +
> > +  
> > + The surface has new content and would like the compositor
> > + to notify the user.
> > +
> > + If a valid and sufficiently recent serial coming from an
> > + input (keyboard, pointer, touch) event is passed as an
> > + argument, the compositor may want to raise the surface.
> > + Otherwise, the request just behaves like the "present" one.
> > +  
> > +

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

[Manuel Bachmann]

Hi Derek, and thanks a lot for your feedback,

I think it makes sense if you consider the compositor can know if a past
input event could have happened "not long ago" or "a very long time ago"
(if the event happened not long ago, raise the window, otherwise blink). It
is really a matter of policy, but the idea was to let the shell know some
details on user interactions, so it can decide what to do. What do you
think of this ?

PS : I  rebased the patches on top of Weston 1.9 *. I am also preparing a
demonstration using well-known applications with external toolkits, but it
takes some time.

* : https://github.com/Tarnyko/weston-xdg_surface_present

Regards,

*Manuel Bachmann, Graphics Engineer www.iot.bzh <http://iot.bzh> *


2015-09-28 22:41 GMT+02:00 Derek Foreman <der...@osg.samsung.com>:

> On 09/04/15 11:22 AM, Manuel Bachmann wrote:
> > xdg_surface_present() and xdg_surface_present_from_event()
> > are new requests supposed to be called on an existing
> > xdg_surface. They tell the compositor that the surface
> > has new content which may be of interest to the user.
> > The compositor may then choose to notify the user.
> >
> > xdg_surface_present_from_event() takes a serial coming
> > from an input (wl_keyboard, wl_pointer, wl_touch) event as
> > an argument. If the serial is valid and sufficiently recent,
> > we can suppose the new content has been issued at the user's
> > request ; the compositor may then choose to raise the
> > surface directly. Otherwise, it just behaves like present().
>
> I'm having a hard time thinking of a use case for
> xdg_surface_present_from_event()...  Picking an arbitrary motion event
> from the past seems odd - the compositor probably won't keep track of
> input serials in any way that makes this useful?
>
> > Signed-off-by: Manuel Bachmann <manuel.bachm...@open.eurogiciel.org>
> > ---
> >  desktop-shell/shell.c  | 15 +++
> >  protocol/xdg-shell.xml | 20 
> >  2 files changed, 35 insertions(+)
> >
> > diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> > index f7c928e..d1d3f3c 100644
> > --- a/desktop-shell/shell.c
> > +++ b/desktop-shell/shell.c
> > @@ -3923,6 +3923,19 @@ xdg_surface_set_minimized(struct wl_client
> *client,
> >   set_minimized(shsurf->surface);
> >  }
> >
> > +static void
> > +xdg_surface_present(struct wl_client *client,
> > + struct wl_resource *resource)
> > +{
> > +}
> > +
> > +static void
> > +xdg_surface_present_from_event(struct wl_client *client,
> > +struct wl_resource *resource,
> > +uint32_t serial)
> > +{
> > +}
> > +
> >  static const struct xdg_surface_interface xdg_surface_implementation = {
> >   xdg_surface_destroy,
> >   xdg_surface_set_parent,
> > @@ -3938,6 +3951,8 @@ static const struct xdg_surface_interface
> xdg_surface_implementation = {
> >   xdg_surface_set_fullscreen,
> >   xdg_surface_unset_fullscreen,
> >   xdg_surface_set_minimized,
> > + xdg_surface_present,
> > + xdg_surface_present_from_event,
> >  };
> >
> >  static void
> > diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
> > index 68cf469..10f82c5 100644
> > --- a/protocol/xdg-shell.xml
> > +++ b/protocol/xdg-shell.xml
> > @@ -396,6 +396,26 @@
> >
> >  
> >
> > +
> > +  
> > + The surface has new content and would like the compositor
> > + to notify the user.
> > +  
> > +
> > +
> > +
> > +  
> > + The surface has new content and would like the compositor
> > + to notify the user.
> > +
> > + If a valid and sufficiently recent serial coming from an
> > + input (keyboard, pointer, touch) event is passed as an
> > + argument, the compositor may want to raise the surface.
> > + Otherwise, the request just behaves like the "present" one.
> > +  
> > +  
> > +
> > +
> >  
> >
> >  The close event is sent by the compositor when the user
> >
>
> ___
> 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] terminal: allow copy-paste when selection is scrolled out

[Manuel Bachmann]

Hi Bryce, and thanks a lot for the review !

Of course I have tested it :) ; the steps are the following :
Copy some text in weston-terminal, scroll it out (by pressing [Enter]
repeatedly e.g.), try to paste.
It does work with the patch only.


2015-09-23 2:10 GMT+02:00 Bryce Harrington <br...@osg.samsung.com>:

> On Sat, Sep 19, 2015 at 01:51:05PM +0200, Manuel Bachmann wrote:
> > We could not paste text when its source went outside the
> > visible part of the buffer ; this is because we were
> > incorrectly assuming that our iterator should start at
> > row 0, while it could very well be negative.
> >
> > Signed-off-by: Manuel Bachmann <manuel.bachm...@iot.bzh>
>
> Interesting find.  I assume this patch has been tested to verify it
> fixes the problem?
>
> Reviewed-by: Bryce Harrington <br...@osg.samsung.com>
>
> > ---
> >  clients/terminal.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/clients/terminal.c b/clients/terminal.c
> > index c5d5d60..7406f50 100644
> > --- a/clients/terminal.c
> > +++ b/clients/terminal.c
> > @@ -942,7 +942,7 @@ terminal_send_selection(struct terminal *terminal,
> int fd)
> >   close(fd);
> >   return;
> >   }
> > - for (row = 0; row < terminal->height; row++) {
> > + for (row = terminal->selection_start_row; row < terminal->height;
> row++) {
> >   p_row = terminal_get_row(terminal, row);
> >   for (col = 0; col < terminal->width; col++) {
> >   if (p_row[col].ch == 0x200B) /* space glyph */
> > --
> > 1.8.3.1
> >
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
Regards,

*Manuel Bachmann, Graphics Engineer www.iot.bzh <http://iot.bzh> *
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH][weston] desktop-shell: fix minimization of fullscreen surfaces

[Manuel Bachmann]

Hi folks,

Any news on this one ? (https://patchwork.freedesktop.org/patch/46001/)

Just tried, the problem still shows in latest master (if you fullscreen
weston-terminal with [F11], and then minimize wih right-click ->
"Minimize", the screen stays black).

If the implementation not seeming optimal is the root cause, I really think
it is the best we can achieve with a few lines and while keeping the
existing model. I am totally open to suggestions, though.

-
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f7c928e..073f187 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2667,6 +2667,11 @@  set_minimized(struct weston_surface *surface)
 weston_layer_entry_remove(>layer_link);
 weston_layer_entry_insert(>shell->minimized_layer.view_list,
>layer_link);

+/* if this surface if fullscreen, we temporarily disable fullscreen
+ * mode and reposition it to its previous x,y coordinates */
+if (shsurf->state.fullscreen)
+unset_fullscreen(shsurf);
+
 drop_focus_state(shsurf->shell, current_ws, view->surface);
 wl_list_for_each(seat, >shell->compositor->seat_list, link) {
 if (!seat->keyboard)
@@ -6016,8 +6021,14 @@  switcher_next(struct switcher *switcher)
 view->alpha = 1.0;

 shsurf = get_shell_surface(switcher->current);
-if (shsurf && shsurf->state.fullscreen)
-shsurf->fullscreen.black_view->alpha = 1.0;
+if (shsurf && shsurf->state.fullscreen) {
+/* A fullscreen surface may not be centered anymore
+ * if unset_fullscreen() was called on it, e.g.
+ * when minimizing it. Make sure it is again. */
+center_on_output(shsurf->view, shsurf->fullscreen_output);
+if (shsurf->fullscreen.black_view)
+shsurf->fullscreen.black_view->alpha = 1.0;
+}
 }

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

[PATCH][weston] terminal: allow copy-paste when selection is scrolled out

[Manuel Bachmann]

We could not paste text when its source went outside the
visible part of the buffer ; this is because we were
incorrectly assuming that our iterator should start at
row 0, while it could very well be negative.

Signed-off-by: Manuel Bachmann <manuel.bachm...@iot.bzh>
---
 clients/terminal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clients/terminal.c b/clients/terminal.c
index c5d5d60..7406f50 100644
--- a/clients/terminal.c
+++ b/clients/terminal.c
@@ -942,7 +942,7 @@ terminal_send_selection(struct terminal *terminal, int fd)
close(fd);
return;
}
-   for (row = 0; row < terminal->height; row++) {
+   for (row = terminal->selection_start_row; row < terminal->height; 
row++) {
p_row = terminal_get_row(terminal, row);
for (col = 0; col < terminal->width; col++) {
if (p_row[col].ch == 0x200B) /* space glyph */
-- 
1.8.3.1

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

Re: How to match versions of wayland/weston/freerdp?

[Manuel Bachmann]

Hi Marko,

You might have found that information in older threads, but FreeRDP commit
2604ff20bd12e810cfeed735b80dbe90020d781c works well for us starting from
Weston 1.5.0 (on x86/x86_64 at least, some people reported problems with
ARM).

Regards,
Manuel

2015-03-13 21:54 GMT+01:00 Marko Moberg marko.s.mob...@gmail.com:

 Hello there,

 I have a little question regarding Wayland/Weston and their compatibility
 with freeRdp.

 I am working on a fairly old Yocto branch (dylan) but I need to enable
 support for Wayland/Weston with RDP. According to the info on the web, RDP
 support should be available from Wayland/Weston 1.1 onwards.

 I can get the v1.1 Wayland/Weston from dora branch but it seems that
 Yocto dora comes with a incompatible version of freeRDP (it contains
 freeRdp v1.0.2 whereas Weston seems to require 1.1.0 or newer). Problems in
 Weston compilation occur immediately when rdp protocol is enabled.

 Well, I also tried to update the freeRDP 1.1 to my environment but the
 rdp_compositor.c of Weston is still not matching the freeRDP
 implementation. However, I noticed that Weston 1.2 seems to have some
 changes that match with the rdp protocol api of FreeRdp 1.1 (changes like
 context_size - ContextSize, stream_free - Stream_Free etc.).

 Does anybody know which version are compatible with each other?

 There are some complex dependencies in our distro which makes it quite
 hard to work with the most up-to-date SW at this point so that's why I am
 trying to find the minimum set of changes to get the Weston + freeRDP
 running on old dylan based distro.

 regards,
 Marko

 marko.s.mob...@gmail.com

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




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC : xdg_surface_present() - take 2

[Manuel Bachmann]

Hi everybody again,

As there does not seem to be a great motivation to annotate the protocol,
I suppose the right way to go is to have the 2 requests.

I prepared the patches in this sense, and am going to push them for review
right now.

Regards,
Manuel

2015-03-27 6:54 GMT+01:00 Manuel Bachmann 
manuel.bachm...@open.eurogiciel.org:

 Hi Jasper, Jonas, Pekka, Jason,

 Just a little update regarding the present() request. As the serial thing
 seems to be our main concern, aside from the minor protocol change and new
 functionality we mostly seem to agree on, here are the 2 ways we could do
 it :

 1) modify the protocol, which means :
 - in the XML, adding : A serial of 0 cannot be returned by the compositor
 ; thus in requests, passing 0 as a serial parameter actually means no
 specific serial is needed nor provided.
 - modify wayland-server to reflect the description (thanks to Jonas for
 reminding me).

 2) have 2 requests instead of 1 :
 xdg_surface_present(struct xdg_surface *surface);
 xdg_surface_present_from_event(struct xdg_surface *surface, uint32_t
 serial);

 What should be our preferred way ? Doing 2) is still satisfying is we
 cannot do 1). Looking for a consensus here.

 Regards,
 Manuel


 2015-03-09 6:17 GMT+01:00 Manuel Bachmann 
 manuel.bachm...@open.eurogiciel.org:

 Hi Jasper,

 This is not an I need attention request. Perhaps our documentation is
 poor.
 You are right, just as I answered to Jonas, I mixed present() with the
 desktop-launcher-focus-stealing feature we were discussing in the previous
 thread. Sorry for the confusion.

 2015-03-09 3:25 GMT+01:00 Jasper St. Pierre jstpie...@mecheye.net:



 On Sun, Mar 8, 2015 at 6:57 PM, Jonas Ådahl jad...@gmail.com wrote:

 On Fri, Feb 27, 2015 at 11:14:19AM +0100, Manuel Bachmann wrote:
  Hello fellow developers,
 
  I just wanted to continue a discussion which occured some time ago,
 about
  the eventuality of adding a xdg_surface_present() request to
 XDG-Shell.
 
  (For reference, former discussion entry points are here :
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-July/016078.html
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-July/016224.html
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-August/016269.html
 )
 
  To summarize : the idea behing xdg_surface_present() is that there
 are
  some cases where a surface wants to advertise the fact that it has
 been
  updated and the user may want to take a look (think of an IRC chat
 window
  which gets new messages containing the user's nickname). There are
 even
  some corner cases where the surface may want to be raised and focused
  directly ; but we do not want to request to be abused this way, a
 client
  must be prevented from stealing the focus repeatedly. At last, the
  compositor's shell should have the last word.

 I have some comments I thought I'd share. See the inline replies:

 
  Here are some of the points that were discussed and the outcomes :
 
  - Pekka Paalanen pointed out the request name was unclear and
 suggested to
  use xdg_surface_needs/wants_attention() instead. Jasper St. Pierre
  pointed out that _NET_WM_STATE_DEMANDS_ATTENTION already existed in
 X11
  and does not do the same thing. We discussed that again yesterday and
  thought that present() fitted nicely ;

 There is also the The Present Extension in X11, so is present really
 that much better? If the use case is a client wants attention because
 some reason (be it IRC highlight, new message, task finished or
 whatever), shouldn't the request name contain that information some how?
 Isn't what is discussed here even quite similar to
 _NET_WM_STATE_DEMANDS_ATTENTION?


 No. It's equivalent to the _NET_ACTIVATE_WINDOW ClientMessage.

 IRC highlights, new messages, task finished, etc. are use cases for
 notifications. The use case here is user double-clicked on a file and I
 want my existing gedit window to be raised in response. Basically, places
 where you want to show the window immediately if the stars are aligned
 correctly (the serial is correct).


 
  - We want to implement focus stealing prevention : if the user is
 starting
  a slow app (browser...), gets back to typing a mail while it starts,
 and at
  last the browser window appears, the focus should stay in the mail
 window
  without his keyboard presses going elsewhere ;

 This rather sound like something startup notification protocol related
 than an I need attention request, and I think that problem needs to be
 tackled separately.


 This is not an I need attention request. Perhaps our documentation is
 poor.


 
  - Implementing focus stealing prevention between different clients
 may be
  easy : just count the delay between the client has been started and
 its
  shell surface actually gets mapped, and if it has been too long and
 the
  focus is elsewhere, show the surface without focusing it (but with a
  notification). The notion of the client has been started is vague,
 but at
  worst, we

[PATCH weston 5/6] toytoolkit: implement a window_present() helper function

[Manuel Bachmann]

window_present() is a little helper function calling
xdg_surface_present() on a toytoolkit shell surface.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 clients/window.c | 9 +
 clients/window.h | 3 +++
 2 files changed, 12 insertions(+)

diff --git a/clients/window.c b/clients/window.c
index 81e007b..cfa0451 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -4337,6 +4337,15 @@ window_set_minimized(struct window *window)
 }
 
 void
+window_present(struct window *window)
+{
+   if (!window-xdg_surface)
+   return;
+
+   xdg_surface_present(window-xdg_surface);
+}
+
+void
 window_set_user_data(struct window *window, void *data)
 {
window-user_data = data;
diff --git a/clients/window.h b/clients/window.h
index 0686c3f..b2d6f9c 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -395,6 +395,9 @@ void
 window_set_minimized(struct window *window);
 
 void
+window_present(struct window *window);
+
+void
 window_set_user_data(struct window *window, void *data);
 
 void *
-- 
1.8.3.1

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

[PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

[Manuel Bachmann]

xdg_surface_present() and xdg_surface_present_from_event()
are new requests supposed to be called on an existing
xdg_surface. They tell the compositor that the surface
has new content which may be of interest to the user.
The compositor may then choose to notify the user.

xdg_surface_present_from_event() takes a serial coming
from an input (wl_keyboard, wl_pointer, wl_touch) event as
an argument. If the serial is valid and sufficiently recent,
we can suppose the new content has been issued at the user's
request ; the compositor may then choose to raise the
surface directly. Otherwise, it just behaves like present().

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 desktop-shell/shell.c  | 15 +++
 protocol/xdg-shell.xml | 20 
 2 files changed, 35 insertions(+)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f7c928e..d1d3f3c 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -3923,6 +3923,19 @@ xdg_surface_set_minimized(struct wl_client *client,
set_minimized(shsurf-surface);
 }
 
+static void
+xdg_surface_present(struct wl_client *client,
+   struct wl_resource *resource)
+{
+}
+
+static void
+xdg_surface_present_from_event(struct wl_client *client,
+  struct wl_resource *resource,
+  uint32_t serial)
+{
+}
+
 static const struct xdg_surface_interface xdg_surface_implementation = {
xdg_surface_destroy,
xdg_surface_set_parent,
@@ -3938,6 +3951,8 @@ static const struct xdg_surface_interface 
xdg_surface_implementation = {
xdg_surface_set_fullscreen,
xdg_surface_unset_fullscreen,
xdg_surface_set_minimized,
+   xdg_surface_present,
+   xdg_surface_present_from_event,
 };
 
 static void
diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
index 68cf469..10f82c5 100644
--- a/protocol/xdg-shell.xml
+++ b/protocol/xdg-shell.xml
@@ -396,6 +396,26 @@
   /description
 /request
 
+request name=present
+  description summary=the window wants attention from the user
+   The surface has new content and would like the compositor
+   to notify the user.
+  /description
+/request
+
+request name=present_from_event
+  description summary=the window needs attention from the user
+   The surface has new content and would like the compositor
+   to notify the user.
+
+   If a valid and sufficiently recent serial coming from an
+   input (keyboard, pointer, touch) event is passed as an
+   argument, the compositor may want to raise the surface.
+   Otherwise, the request just behaves like the present one.
+  /description
+  arg name=serial type=uint summary=serial of an input event/
+/request
+
 event name=close
   description summary=surface wants to be closed
 The close event is sent by the compositor when the user
-- 
1.8.3.1

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

[PATCH weston 6/6] stacking: manage stacking lists, implement present()

[Manuel Bachmann]

Due to the absence of a clever close handler, closing one
window among multiple ones used to quit the application.
We now keep track of our children windows, and close only
these ones.

If the user tries to create a new window and we already
have a child, present() the child instead. The user will
then be able to raise and find the child by interacting
with the notification.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 clients/stacking.c | 81 ++
 1 file changed, 70 insertions(+), 11 deletions(-)

diff --git a/clients/stacking.c b/clients/stacking.c
index ea6101d..c9e38d3 100644
--- a/clients/stacking.c
+++ b/clients/stacking.c
@@ -33,9 +33,15 @@
 
 #include window.h
 
+struct stacked_window {
+   struct window *window;
+   struct stacked_window *child_window;
+   struct stacking *stacking;
+};
+
 struct stacking {
struct display *display;
-   struct window *root_window;
+   struct stacked_window *root_window;
 };
 
 static void
@@ -55,17 +61,33 @@ static void
 fullscreen_handler(struct window *window, void *data);
 static void
 redraw_handler(struct widget *widget, void *data);
+static void
+close_handler(void *data);
 
 /* Iff parent_window is set, the new window will be transient. */
 static struct window *
 new_window(struct stacking *stacking, struct window *parent_window)
 {
+   struct stacked_window *current_window;
struct window *new_window;
struct widget *new_widget;
 
new_window = window_create(stacking-display);
window_set_parent(new_window, parent_window);
 
+   /* iterate through stackings, and stop once we find
+* the last window */
+   current_window = stacking-root_window;
+   while (current_window-child_window) {
+   current_window = current_window-child_window;
+   }
+   /* we create the new child */
+   current_window-child_window = xzalloc(sizeof *current_window);
+   current_window = current_window-child_window;
+   current_window-stacking = stacking;
+   current_window-window = new_window;
+   current_window-child_window = NULL;
+
new_widget = window_frame_create(new_window, new_window);
 
window_set_title(new_window, Stacking Test);
@@ -74,7 +96,8 @@ new_window(struct stacking *stacking, struct window 
*parent_window)
window_set_fullscreen_handler(new_window, fullscreen_handler);
widget_set_button_handler(new_widget, button_handler);
widget_set_redraw_handler(new_widget, redraw_handler);
-   window_set_user_data(new_window, stacking);
+   window_set_close_handler(new_window, close_handler);
+   window_set_user_data(new_window, current_window);
 
window_schedule_resize(new_window, 300, 300);
 
@@ -108,12 +131,12 @@ button_handler(struct widget *widget,
uint32_t button,
enum wl_pointer_button_state state, void *data)
 {
-   struct stacking *stacking = data;
+   struct stacked_window *current_window = data;
 
switch (button) {
case BTN_RIGHT:
if (state == WL_POINTER_BUTTON_STATE_PRESSED)
-   show_popup(stacking, input, time,
+   show_popup(current_window-stacking, input, time,
   widget_get_user_data(widget));
break;
 
@@ -129,7 +152,7 @@ key_handler(struct window *window,
 uint32_t key, uint32_t sym, enum wl_keyboard_key_state state,
 void *data)
 {
-   struct stacking *stacking = data;
+   struct stacked_window *current_window = data;
 
if (state != WL_KEYBOARD_KEY_STATE_PRESSED)
return;
@@ -144,12 +167,16 @@ key_handler(struct window *window,
break;
 
case XKB_KEY_n:
-   /* New top-level window. */
-   new_window(stacking, NULL);
+   /* If this window has no child, create a new top-level one.
+* Otherwise, present the existing child to the user. */
+   if (!current_window-child_window)
+   new_window(current_window-stacking, NULL);
+   else
+   window_present(current_window-child_window-window);
break;
 
case XKB_KEY_p:
-   show_popup(stacking, input, time, window);
+   show_popup(current_window-stacking, input, time, window);
break;
 
case XKB_KEY_q:
@@ -158,7 +185,7 @@ key_handler(struct window *window,
 
case XKB_KEY_t:
/* New transient window. */
-   new_window(stacking, window);
+   new_window(current_window-stacking, window);
break;
 
default:
@@ -281,6 +308,34 @@ redraw_handler(struct widget *widget, void *data)
cairo_destroy(cr);
 }
 
+static void
+close_handler(void *data)
+{
+   struct stacked_window

[PATCH weston 2/6] desktop-shell: define a managed_surface interface

[Manuel Bachmann]

The new xdg-shell present/present_from_event() requests
specify that the compositor may notify the user. Thus,
we need a way to pass requests and events between the
compositor-side shell plugin and the shell client
(which does the drawing).

Define a managed_surface interface, which will keep track
of server-side shell surfaces, and is able to send requests
and receive events.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 clients/desktop-shell.c| 37 ++-
 desktop-shell/shell.c  | 18 
 protocol/desktop-shell.xml | 54 ++
 3 files changed, 108 insertions(+), 1 deletion(-)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index ac2928f..c5baf52 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -942,6 +942,32 @@ unlock_dialog_finish(struct task *task, uint32_t events)
 }
 
 static void
+managed_surface_presented(void *data,
+ struct managed_surface *managed_surface)
+{
+}
+
+static void
+managed_surface_title_changed(void *data,
+ struct managed_surface *managed_surface,
+ const char *title)
+{
+}
+
+static void
+managed_surface_removed(void *data,
+   struct managed_surface *managed_surface)
+{
+   managed_surface_destroy(managed_surface);
+}
+
+static const struct managed_surface_listener managed_surface_listener = {
+   managed_surface_presented,
+   managed_surface_title_changed,
+   managed_surface_removed
+};
+
+static void
 desktop_shell_configure(void *data,
struct desktop_shell *desktop_shell,
uint32_t edges,
@@ -1018,10 +1044,19 @@ desktop_shell_grab_cursor(void *data,
}
 }
 
+static void
+desktop_shell_add_managed_surface(void *data,
+ struct desktop_shell *desktop_shell,
+ struct managed_surface *managed_surface,
+ const char *title)
+{
+}
+
 static const struct desktop_shell_listener listener = {
desktop_shell_configure,
desktop_shell_prepare_lock_surface,
-   desktop_shell_grab_cursor
+   desktop_shell_grab_cursor,
+   desktop_shell_add_managed_surface
 };
 
 static void
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index d1d3f3c..e48d63d 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -3509,6 +3509,24 @@ static const struct wl_shell_surface_interface 
shell_surface_implementation = {
 };
 
 static void
+managed_surface_activate(struct wl_client *client,
+struct wl_resource *resource)
+{
+}
+
+static void
+managed_surface_destroy(struct wl_client *client,
+   struct wl_resource *resource)
+{
+   wl_resource_destroy(resource);
+}
+
+static const struct managed_surface_interface managed_surface_implementation = 
{
+   managed_surface_activate,
+   managed_surface_destroy
+};
+
+static void
 destroy_shell_surface(struct shell_surface *shsurf)
 {
struct shell_surface *child, *next;
diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml
index fb0b748..7fc2307 100644
--- a/protocol/desktop-shell.xml
+++ b/protocol/desktop-shell.xml
@@ -117,6 +117,60 @@
   /description
 /request
 
+!-- Version 4 additions --
+
+event name=add_managed_surface since=4
+  description summary=manage a new surface
+Tell the shell to create a new managed_surface object.
+  /description
+  arg name=id type=new_id interface=managed_surface/
+  arg name=title type=string allow-null=true/
+/event
+
+  /interface
+
+  interface name=managed_surface version=1
+description summary=interface for handling shell surfaces
+  A managed surface is an abstraction for a shell surface,
+  susceptible to send events requiring shell feedback, and
+  also to which the shell might want to send requests back.
+/description
+
+request name=activate
+  description summary=activate a managed surface
+Tell the server that the shell wants to activate a
+managed surface.
+  /description
+/request
+
+request name=destroy type=destructor/
+
+event name=presented
+  description summary=a managed surface needs attention
+This event will be sent immediately after a present
+request has been issued on the corresponding shell surface.
+
+The shell will draw a tooltip specifying the title of the
+surface. If the user clicks on this tooltip, the shell will
+send an activate request back to the server.
+  /description
+/event
+
+event name=title_changed
+  description summary=a managed surface has a new title
+This event will be sent immediately after the title of the
+corresponding shell surface has been modified.
+  /description

[PATCH weston 3/6] xdg-shell: implement the present() basic logic

[Manuel Bachmann]

Whenever a shell surface is created, a corresponding
managed_surface object will be created and tracked down
down at the shell client level.

Every valid call to xdg_surface_set_title(),
xdg_surface_present() or xdg_surface_present_from_event()
will now fire the corresponding events ; managed_surface
_activate() is also implemented but unused for now.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 clients/desktop-shell.c | 33 +
 desktop-shell/shell.c   | 39 +++
 2 files changed, 72 insertions(+)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index c5baf52..3c63c28 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -56,6 +56,7 @@ struct desktop {
struct unlock_dialog *unlock_dialog;
struct task unlock_task;
struct wl_list outputs;
+   struct wl_list managed_surfaces;
 
struct window *grab_window;
struct widget *grab_widget;
@@ -68,6 +69,12 @@ struct desktop {
int painted;
 };
 
+struct desktop_managed_surface {
+   struct managed_surface *managed_surface;
+   char *title;
+   struct wl_list link;
+};
+
 struct surface {
void (*configure)(void *data,
  struct desktop_shell *desktop_shell,
@@ -952,12 +959,25 @@ managed_surface_title_changed(void *data,
  struct managed_surface *managed_surface,
  const char *title)
 {
+   struct desktop_managed_surface *mgsurf = data;
+
+   if (mgsurf-title)
+   free(mgsurf-title);
+
+   mgsurf-title = (title) ? xstrdup(title) : NULL;
 }
 
 static void
 managed_surface_removed(void *data,
struct managed_surface *managed_surface)
 {
+   struct desktop_managed_surface *mgsurf = data;
+
+   if (mgsurf-title)
+   free(mgsurf-title);
+   wl_list_remove(mgsurf-link);
+   free(mgsurf);
+
managed_surface_destroy(managed_surface);
 }
 
@@ -1050,6 +1070,18 @@ desktop_shell_add_managed_surface(void *data,
  struct managed_surface *managed_surface,
  const char *title)
 {
+   struct desktop *desktop = data;
+   struct desktop_managed_surface *mgsurf;
+
+   mgsurf = xzalloc(sizeof *mgsurf);
+   mgsurf-managed_surface = managed_surface;
+   mgsurf-title = (title) ? xstrdup(title) : NULL;
+
+   wl_list_insert(desktop-managed_surfaces.prev, mgsurf-link);
+
+   managed_surface_add_listener(managed_surface,
+managed_surface_listener,
+mgsurf);
 }
 
 static const struct desktop_shell_listener listener = {
@@ -1367,6 +1399,7 @@ int main(int argc, char *argv[])
 
desktop.unlock_task.run = unlock_dialog_finish;
wl_list_init(desktop.outputs);
+   wl_list_init(desktop.managed_surfaces);
 
config_file = weston_config_get_name_from_env();
desktop.config = weston_config_parse(config_file);
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index e48d63d..7263044 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -105,6 +105,7 @@ struct shell_client;
 
 struct shell_surface {
struct wl_resource *resource;
+   struct wl_resource *managed_surface;
struct wl_signal destroy_signal;
struct shell_client *owner;
 
@@ -2249,6 +2250,8 @@ set_title(struct shell_surface *shsurf, const char *title)
free(shsurf-title);
shsurf-title = strdup(title);
shsurf-surface-timeline.force_refresh = 1;
+
+   managed_surface_send_title_changed(shsurf-managed_surface, title);
 }
 
 static void
@@ -2681,6 +2684,16 @@ set_minimized(struct weston_surface *surface)
 }
 
 static void
+present(struct shell_surface *shsurf,
+   bool from_event, uint32_t serial)
+{
+   if (shsurf-type == SHELL_SURFACE_TOPLEVEL)
+   managed_surface_send_presented(shsurf-managed_surface);
+
+   /* TODO: handle the from_event()-with-serial case */
+}
+
+static void
 shell_surface_set_maximized(struct wl_client *client,
 struct wl_resource *resource,
 struct wl_resource *output_resource)
@@ -3512,6 +3525,13 @@ static void
 managed_surface_activate(struct wl_client *client,
 struct wl_resource *resource)
 {
+   struct shell_surface *shsurf = wl_resource_get_user_data(resource);
+   struct desktop_shell *shell = shell_surface_get_shell(shsurf);
+   struct weston_compositor *compositor = shell-compositor;
+   struct weston_seat *seat;   
+
+   wl_list_for_each(seat, compositor-seat_list, link)
+   activate(shell, shsurf-surface, seat, true);
 }
 
 static void
@@ -3533,6 +3553,8 @@ destroy_shell_surface(struct shell_surface *shsurf)
 
wl_signal_emit(shsurf-destroy_signal, shsurf

[PATCH weston 4/6] desktop-shell: implement the presented() GUI notifier

[Manuel Bachmann]

Each time a managed_surface receives a presented
event, a red tooltip will be created on the panel and
stacked on the right side (near the clock).

The user can click on the tooltip to make the shell
send an activate request, and raise the surface
to the foreground of its current workspace.

The tooltip is destroyed after having been clicked,
or whenever the corresponding shell surface gets
destroyed by any means.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 clients/desktop-shell.c | 207 ++--
 1 file changed, 203 insertions(+), 6 deletions(-)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index 3c63c28..5c5a1aa 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -72,6 +72,7 @@ struct desktop {
 struct desktop_managed_surface {
struct managed_surface *managed_surface;
char *title;
+   struct desktop *desktop;
struct wl_list link;
 };
 
@@ -87,6 +88,7 @@ struct panel {
struct window *window;
struct widget *widget;
struct wl_list launcher_list;
+   struct wl_list notifier_list;
struct panel_clock *clock;
int painted;
uint32_t color;
@@ -123,6 +125,13 @@ struct panel_launcher {
struct wl_array argv;
 };
 
+struct panel_notifier {
+   struct widget *widget;
+   struct panel *panel;
+   struct desktop_managed_surface *mgsurf;
+   struct wl_list link;
+};
+
 struct panel_clock {
struct widget *widget;
struct panel *panel;
@@ -172,6 +181,16 @@ show_menu(struct panel *panel, struct input *input, 
uint32_t time)
 x - 10, y - 10, menu_func, entries, 4);
 }
 
+static void
+update_window(struct window *window)
+{
+   struct rectangle allocation;
+
+   window_get_allocation(window, allocation);
+   window_schedule_resize(window, allocation.width,
+  allocation.height);
+}
+
 static int
 is_desktop_painted(struct desktop *desktop)
 {
@@ -204,6 +223,25 @@ check_desktop_ready(struct window *window)
}
 }
 
+static struct panel_notifier *
+managed_surface_get_notifier(struct output *output,
+ struct desktop_managed_surface *mgsurf)
+{
+   struct panel *panel;
+   struct panel_notifier *notifier;
+
+   panel = output-panel;
+   if (!panel)
+   return NULL;
+
+   wl_list_for_each(notifier, panel-notifier_list, link) {
+   if (notifier-mgsurf == mgsurf)
+   return notifier;
+   }
+
+   return NULL;
+}
+
 static void
 panel_launcher_activate(struct panel_launcher *widget)
 {
@@ -358,6 +396,112 @@ panel_launcher_touch_up_handler(struct widget *widget, 
struct input *input,
 }
 
 static void
+panel_destroy_notifier(struct panel_notifier *notifier)
+{
+   wl_list_remove(notifier-link);
+   update_window(notifier-panel-window);
+
+   widget_destroy(notifier-widget);
+   notifier-mgsurf = NULL;
+   free(notifier);
+}
+
+static void
+panel_notifier_activate(struct panel_notifier *notifier)
+{
+   if (notifier-mgsurf)
+   managed_surface_activate(notifier-mgsurf-managed_surface);
+
+   panel_destroy_notifier(notifier);
+}
+
+static void
+panel_notifier_touch_up_handler(struct widget *widget, struct input *input,
+   uint32_t serial, uint32_t time, int32_t id,
+   void *data)
+{
+   struct panel_notifier *notifier;
+
+   notifier = widget_get_user_data(widget);
+   widget_schedule_redraw(widget);
+   panel_notifier_activate(notifier);
+}
+
+static void
+panel_notifier_button_handler(struct widget *widget, struct input *input,
+ uint32_t time, uint32_t button,
+ enum wl_pointer_button_state state,
+ void *data)
+{
+   struct panel_notifier *notifier;
+
+   notifier = widget_get_user_data(widget);
+   widget_schedule_redraw(widget);
+   if (state == WL_POINTER_BUTTON_STATE_RELEASED)
+   panel_notifier_activate(notifier);
+}
+
+static void
+panel_notifier_redraw_handler(struct widget *widget, void *data)
+{
+   struct panel_notifier *notifier = data;
+   struct rectangle allocation;
+   char *title;
+   cairo_text_extents_t extents;
+   cairo_t *cr;
+
+   widget_get_allocation(widget, allocation);
+   if (allocation.width == 0 || !notifier-mgsurf)
+   return;
+
+   cr = widget_cairo_create(notifier-panel-widget);
+
+   rounded_rect(cr, allocation.x, allocation.y,
+allocation.x + allocation.width + 3,
+allocation.y + allocation.height + 3, 3);
+   cairo_set_operator(cr, CAIRO_OPERATOR_OVER);
+   cairo_set_source_rgba(cr, 0.8, 0.0, 0.0, 0.8);
+   cairo_fill(cr);
+
+   cairo_set_source_rgb(cr, 1.0, 1.0, 1.0

Re: [PATCH weston 1/3] gl-renderer: fix EGL initialization steps

[Manuel Bachmann]

Looks good to me !

2015-04-08 16:02 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:

 From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

 Some DRI drivers, including VMware vmwgfx, do not support
 calling eglQueryString() with a EGL_NO_DISPLAY parameter.
 Just as we do in gl_renderer_supports(), which returns 0
 but does not fail in this case, do not fail in
 gl_renderer_setup_egl_extensions().

 Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
 [Pekka: split the patch]
 Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk
 ---
  src/gl-renderer.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/gl-renderer.c b/src/gl-renderer.c
 index b3b2364..5a2ed9f 100644
 --- a/src/gl-renderer.c
 +++ b/src/gl-renderer.c
 @@ -2136,7 +2136,7 @@ gl_renderer_setup_egl_extensions(struct
 weston_compositor *ec)
 (const char *) eglQueryString(EGL_NO_DISPLAY,
 EGL_EXTENSIONS);
 if (!extensions) {
 weston_log(Retrieving EGL client extension string
 failed.\n);
 -   return -1;
 +   return 0;
 }

 if (strstr(extensions, EGL_EXT_platform_base))
 --
 2.0.5




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/3] gl-renderer: check EGL_EXT_platform_base in supports()

[Manuel Bachmann]

Looks good to me !

2015-04-08 16:02 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:

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

 An EGL implementation may support client extensions without supporting
 EGL_EXT_platform_base. In such a case, we should return 0 to fall back
 to the old eglGetDisplay() way.

 Cc: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
 Signed-off-by: Pekka Paalanen pekka.paala...@collabora.co.uk
 ---
  src/gl-renderer.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

 diff --git a/src/gl-renderer.c b/src/gl-renderer.c
 index 5a2ed9f..35cd7e7 100644
 --- a/src/gl-renderer.c
 +++ b/src/gl-renderer.c
 @@ -2213,6 +2213,9 @@ gl_renderer_supports(struct weston_compositor *ec,
extensions);
 }

 +   if (!strstr(extensions, EGL_EXT_platform_base))
 +   return 0;
 +
 snprintf(s, sizeof s, EGL_KHR_platform_%s, extension_suffix);
 if (strstr(extensions, s))
 return 1;
 @@ -2225,8 +2228,8 @@ gl_renderer_supports(struct weston_compositor *ec,
 if (strstr(extensions, s))
 return 1;

 -   /* at this point we definitely have some client extensions but
 -* haven't found the supplied client extension, so chances are it's
 +   /* at this point we definitely have some platform extensions but
 +* haven't found the supplied platform, so chances are it's
  * not supported. */

 return -1;
 --
 2.0.5




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

FreeGLUT has now a Wayland backend

[Manuel Bachmann]

Hello fellow developers,

Just a little message to let you know that the well-known FreeGLUT (1)
library (open-source fork of the legacy GLUT (2) library) can now use
Wayland natively.

The particular commit enables it :
https://github.com/dcnieho/FreeGLUT/commit/9b30564b6d9c9f106c7d079d6cf9207363a49111

And here is a video demonstrating the backend :
https://www.youtube.com/watch?v=FQvRIoALQyg

Thanks to the wonderful maintainers (most notably, John Tsiombikas and
Diederick C. Niehorster), for having made this possible !

(1) http://freeglut.sourceforge.net/
(2) https://www.opengl.org/resources/libraries/glut/
-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] gl-renderer: fix EGL initialization steps

[Manuel Bachmann]

Agreed !

I am going send the patch again, same name (gl-renderer: fix EGL
initialization steps) but modified in this sense and with another commit
message,

Regards,
Manuel

2015-04-02 11:51 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:

 On Mon, 30 Mar 2015 21:48:32 +0200
 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:

  OK. Found it, thanks to your hint, Daniel.
 
  This version of Mesa (10.1.3) does not feature these extensions.
 
  They were added here :
 
 http://cgit.freedesktop.org/mesa/mesa/commit/src/egl/main/eglglobals.c?id=468cc866b4b308cee40470f06b31002c6c56da96
 
  Considering that recent distributions, such as Ubuntu 14.04 LTS (Debian,
  RHEL.. are even older) may not package a sufficiently recent version of
  Mesa, maybe it is wise to ignore the test if extensions is only
  EGL_EXT_client_extensions (which should not happen with recent Mesa,
  because at least one platform should be supported there) ?

 Hi,

 I think the correct test is to check if the string contains
 EGL_EXT_platform_base. If the client extensions string cannot be
 queried or does not contain EGL_EXT_platform_base, then supports()
 should return 0 to indicate maybe, which means we fall back to the old
 way.


 Thanks,
 pq

  2015-03-30 21:38 GMT+02:00 Manuel Bachmann 
  manuel.bachm...@open.eurogiciel.org:
 
   Hi Daniel, and thanks,
  
   What is the complete client extension string on that platform?
  
   It is simply EGL_EXT_client_extensions.
  
   Here are the details : kernel 3.13.0 - Mesa 10.1.3 (built with
   with-egl-platforms=wayland,x11,drm) - kernel module is i915 - EGL
 is :
   1.4 (DRI2) - GL vendor is : Intel Open Source Technology Center - GL
   renderer is : Mesa DRI Intel(R) Ivybridge Model.
   GPU seems to be : Intel HP Graphics 4000 (core i7 CPU)
  
   2015-03-30 20:52 GMT+02:00 Daniel Stone dan...@fooishbar.org:
  
   Hi,
  
   On 30 March 2015 at 17:38, Manuel Bachmann
   manuel.bachm...@open.eurogiciel.org wrote:
You removed the early return here...
...which means this check may be accessing NULL extensions, no?
   
You are right ! Sorry for that, did not even look at the #ifdef,
 will
   rework
this part.
  
   Apart from the configless_context damage, the rest (don't make lack of
   client extensions query fatal) is very much correct. I think that got
   lost in review. :\
  
You do want to keep the -1 return as fatal here.
 gl_renderer_supports()
should already return 0 meaning maybe if client extensions cannot
 be
queried. The supports function is very nicely documented.
   
Well, I have here a pratical case of a Ubuntu 14.04 laptop (Intel
 GPU,
   i915
driver, will let you know the hardware, Mesa and libs versions soon
   when I
get my hands on it), where the supports() function is able to find
 an
*extensions strings, but then fails to locate these precise
   extensions,
and thus returns -1. It prevents the X11 and DRM compositors to run,
   but it
works nicely when removing this check. Does it make sense to you ?
(regarding the purpose of the function, is that when building EGL
 with
   X11
support, it will always report X11 as a supported platform ? Maybe
   there are
versions of Mesa which do not honor this. Will check.)
  
   Weird - the only way I can see that happening is if Mesa advertises
   support for platform_base, but not for platform_{x11,gbm}, which seems
   very odd indeed. Ever since the addition of platform_base support[0],
   Mesa has supported EXT variants of x11 and wayland, and a MESA variant
   of gbm. So given the (fairly exhaustive) checks in
   gl_renderer_supports, I can't see how we'd end up in this situation.
   What is the complete client extension string on that platform?
  
   Cheers,
   Daniel
  
   [0]:
  
 http://cgit.freedesktop.org/mesa/mesa/commit/src/egl/main/eglglobals.c?id=468cc866b4b308cee40470f06b31002c6c56da96
  
2015-03-30 14:40 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:
   
On Sun, 29 Mar 2015 05:03:09 +0200
Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:
   
 From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

 We should not prevent gl-renderer to initalize if client
 extensions were not found. Practically, this prevented
 Weston from running with GL on i915 DRI platforms.

 Some DRI drivers, including VMware vmwgfx, do not support
 calling eglQueryString() with a EGL_NO_DISPLAY parameter.
 Just as we do in gl_renderer_supports(), which returns 0
 but does not fail in this case, do not fail in
 gl_renderer_setup_egl_extensions().
 ---
  src/gl-renderer.c | 18 +++---
  1 file changed, 7 insertions(+), 11 deletions(-)

 diff --git a/src/gl-renderer.c b/src/gl-renderer.c
 index b3b2364..28ecc63 100644
 --- a/src/gl-renderer.c
 +++ b/src/gl-renderer.c
 @@ -2136,15 +2136,14 @@ gl_renderer_setup_egl_extensions(struct
 weston_compositor *ec

[PATCH weston] gl-renderer: fix EGL initialization steps

[Manuel Bachmann]

From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

Some DRI drivers, including VMware vmwgfx, do not support
calling eglQueryString() with a EGL_NO_DISPLAY parameter.
Just as we do in gl_renderer_supports(), which returns 0
but does not fail in this case, do not fail in
gl_renderer_setup_egl_extensions().

With some versions of Mesa, EGL client extensions may
very well be defined without the corresponding platform
extensions (EGL_EXT_platform_x11/wayland/gbm). Do not
fail in this case, but report lack of information.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 src/gl-renderer.c | 33 ++---
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index b3b2364..d9b6a66 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -2136,7 +2136,7 @@ gl_renderer_setup_egl_extensions(struct weston_compositor 
*ec)
(const char *) eglQueryString(EGL_NO_DISPLAY, EGL_EXTENSIONS);
if (!extensions) {
weston_log(Retrieving EGL client extension string failed.\n);
-   return -1;
+   return 0;
}
 
if (strstr(extensions, EGL_EXT_platform_base))
@@ -2213,23 +2213,26 @@ gl_renderer_supports(struct weston_compositor *ec,
   extensions);
}
 
-   snprintf(s, sizeof s, EGL_KHR_platform_%s, extension_suffix);
-   if (strstr(extensions, s))
-   return 1;
+   if (strstr(extensions, EGL_EXT_client_extensions)) {
+   snprintf(s, sizeof s, EGL_KHR_platform_%s, extension_suffix);
+   if (strstr(extensions, s))
+   return 1;
 
-   snprintf(s, sizeof s, EGL_EXT_platform_%s, extension_suffix);
-   if (strstr(extensions, s))
-   return 1;
+   snprintf(s, sizeof s, EGL_EXT_platform_%s, extension_suffix);
+   if (strstr(extensions, s))
+   return 1;
 
-   snprintf(s, sizeof s, EGL_MESA_platform_%s, extension_suffix);
-   if (strstr(extensions, s))
-   return 1;
+   snprintf(s, sizeof s, EGL_MESA_platform_%s, extension_suffix);
+   if (strstr(extensions, s))
+   return 1;
 
-   /* at this point we definitely have some client extensions but
-* haven't found the supplied client extension, so chances are it's
-* not supported. */
-
-   return -1;
+   /* at this point we definitely have some client extensions but
+* haven't found the supplied client extension, so it may be
+* supported or not. */
+   return 0;
+   } else {
+   return -1;
+   }
 }
 
 static const char *
-- 
1.8.3.1

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

Re: [PATCH weston] gl-renderer: fix EGL initialization steps

[Manuel Bachmann]

You removed the early return here...
...which means this check may be accessing NULL extensions, no?

You are right ! Sorry for that, did not even look at the #ifdef, will
rework this part.

You do want to keep the -1 return as fatal here. gl_renderer_supports()
should already return 0 meaning maybe if client extensions cannot be
queried. The supports function is very nicely documented.

Well, I have here a pratical case of a Ubuntu 14.04 laptop (Intel GPU, i915
driver, will let you know the hardware, Mesa and libs versions soon when I
get my hands on it), where the supports() function is able to find an
*extensions strings, but then fails to locate these precise extensions,
and thus returns -1. It prevents the X11 and DRM compositors to run, but it
works nicely when removing this check. Does it make sense to you ?
(regarding the purpose of the function, is that when building EGL with X11
support, it will always report X11 as a supported platform ? Maybe there
are versions of Mesa which do not honor this. Will check.)

2015-03-30 14:40 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:

 On Sun, 29 Mar 2015 05:03:09 +0200
 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:

  From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
 
  We should not prevent gl-renderer to initalize if client
  extensions were not found. Practically, this prevented
  Weston from running with GL on i915 DRI platforms.
 
  Some DRI drivers, including VMware vmwgfx, do not support
  calling eglQueryString() with a EGL_NO_DISPLAY parameter.
  Just as we do in gl_renderer_supports(), which returns 0
  but does not fail in this case, do not fail in
  gl_renderer_setup_egl_extensions().
  ---
   src/gl-renderer.c | 18 +++---
   1 file changed, 7 insertions(+), 11 deletions(-)
 
  diff --git a/src/gl-renderer.c b/src/gl-renderer.c
  index b3b2364..28ecc63 100644
  --- a/src/gl-renderer.c
  +++ b/src/gl-renderer.c
  @@ -2136,15 +2136,14 @@ gl_renderer_setup_egl_extensions(struct
 weston_compositor *ec)
(const char *) eglQueryString(EGL_NO_DISPLAY,
 EGL_EXTENSIONS);
if (!extensions) {
weston_log(Retrieving EGL client extension string
 failed.\n);
  - return -1;
  + } else {
  + if (strstr(extensions, EGL_EXT_platform_base))
  + gr-create_platform_window =
  + (void *)
 eglGetProcAddress(eglCreatePlatformWindowSurfaceEXT);
  + else
  + weston_log(warning: EGL_EXT_platform_base not
 supported.\n);
}

 You removed the early return here...

 
  - if (strstr(extensions, EGL_EXT_platform_base))
  - gr-create_platform_window =
  - (void *)
 eglGetProcAddress(eglCreatePlatformWindowSurfaceEXT);
  - else
  - weston_log(warning: EGL_EXT_platform_base not
 supported.\n);
  -
   #ifdef EGL_MESA_configless_context
if (strstr(extensions, EGL_MESA_configless_context))
gr-has_configless_context = 1;

 ...which means this check may be accessing NULL extensions, no?

 Hmm, I wonder if the configless context check is looking at the right
 extensions string here.

  @@ -2256,12 +2255,9 @@ gl_renderer_create(struct weston_compositor *ec,
 EGLenum platform,
EGLint major, minor;
int supports = 0;
 
  - if (platform) {
  + if (platform)
supports = gl_renderer_supports(
ec, platform_to_extension(platform));
  - if (supports  0)
  - return -1;
  - }

 Just make sure that if EXT_platform_base exists, but the specific
 platform we are looking for does not, we fail this function.

 You do want to keep the -1 return as fatal here. gl_renderer_supports()
 should already return 0 meaning maybe if client extensions cannot be
 queried. The supports function is very nicely documented.

 
gr = zalloc(sizeof *gr);
if (gr == NULL)


 Thanks,
 pq




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] desktop-shell: fix minimization of fullscreen surfaces, pointer focus

[Manuel Bachmann]

Hi Pekka,

It is the wrong way to fix it.

Not wl_pointer nor wl_keyboard foci are interchangeable with the concept of
active. It simply just happens that an active window will usually have
the kbd focus if a kbd exists, because users expect that. From a purely
protocol-mechanical point of view there is no connection. Giving keyboard
focus to an active window is compositor internal policy.

This makes sense, thank you. I am thus going to remove the call to
pointer_set_focus(.. 0, 0). By the way, I have a WIP patch which will
allow focus to switch when you minimize a surface, just as when one gets
destroyed currently. This seems to be what most of the other window
managers do, and is likely to address this problem in a better way :-).

Hmm, I'm not sure if that's clever or abuse... it's certainly unexpected
and requires effort to see in the code, which calls a for a big comment to
explain what is happening.

Practically, it works just nice ; but I agree, I will add a multi-line
comment on top of this, to explain why this is required.

Regards,
Manuel

2015-03-30 8:59 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:

 On Sat, 28 Mar 2015 07:29:48 +0100
 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:

  Hi Pekka, thanks a lot for getting this on the rails !
 
  I'm not so sure about the pointer_set_focus here. Shuffling surfaces is
  supposed to trigger a repick, which will reassign the pointer focus.
  However, it seems something is off.
 
  The pointer_set_focus(... 0, 0) thing was added for a client (Chromium)
  whch privilegies pointer focus over keyboard focus, It considers itself
  still focused when minimized ; mostly because it disregards keyboard
 focus
  and, last time I looked in desktop-shell, even xdg-shell activate()
 events
  were mostly linked to keyboard focus. So adding this call for
 pointer_leave
  fixed it. What is your opinon on this ?

 It is the wrong way to fix it.

 Not wl_pointer nor wl_keyboard foci are interchangeable with the
 concept of active. It simply just happens that an active window will
 usually have the kbd focus if a kbd exists, because users expect that.
 From a purely protocol-mechanical point of view there is no connection.
 Giving keyboard focus to an active window is compositor internal policy.

 The app must be fixed to honour the activate events if it uses
 xdg_shell. In xdg_shell, window activeness is notified via configure
 events' flags. The spec says:
   entry name=activated value=4
 Client window decorations should be painted as if the window is
 active. Do not assume this means that the window actually has
 keyboard or pointer focus.
   /entry

 If it uses wl_shell, then you have to rely on kbd focus, because
 wl_shell doesn't have anything better. This means that in a
 keyboard-less system, wl_shell cannot even communicate activeness. Maybe
 that's the reason why someone might abuse pointer focus as window
 activation? But when he does that, the window will switch to an
 inactive look by just a pointer leave, while the user could still be
 typing into the window. That would be confusing.

 If this is some tablet use case, then you wouldn't have either
 wl_pointer not wl_keyboard, you'd only have wl_touch. And touch focus
 disappears the moment the last finger goes up. Note, that virtual
 keyboards do not communicate via wl_keyboard. So in a tablet case, the
 window activeness is completely separated from any foci.

 Pointer focus is good for highlighting the widget under the pointer
 kind of things, but neither pointer not keyboard foci are meant to
 signify activeness.

  assume the first wl_pointer.leave(nil) is for the popup surface, so
  that's ok. The enter for nil looks very suspicious though. Maybe that
  is caused by this patch?
 
  It clearly is ; I interpret this as the pointer leaving the main terminal
  surface when it minimizes, which seems logical, but maybe I'm misleaded
  (btw, how do you get all these logs ?).

 You can get them with WAYLAND_DEBUG=client env var, when running the
 client.

 Entering a NULL surface makes no sense to a client, it can only ignore
 it. It already received a leave, which means that wl_pointer is not on
 any of its own surfaces. Saying the pointer is still not on any of
 your surfaces is redundant.

 These NULL arguments should happen only in race conditions. For
 instance, the compositor assigned pointer focus to a surface, that the
 client has already destroyed but the compositor has not processed the
 destruction yet. If the compositor *has* processed the destruction,
 there is no reason to send enter for NULL.

  Just curious, how can the surface go off-center? Some output
  hot-unplugging involved?
 
  The call to unset_fullscreen() will reposition the surface at its
 former
  non-fullscreen position (old_x, old_y), which is good. When the surface
  gets focused again later, fullscreen state gets triggered again because
 the
  hint is stll too, which is good, too

Re: [PATCH weston] gl-renderer: fix EGL initialization steps

[Manuel Bachmann]

Hi Daniel, and thanks,

What is the complete client extension string on that platform?

It is simply EGL_EXT_client_extensions.

Here are the details : kernel 3.13.0 - Mesa 10.1.3 (built with
with-egl-platforms=wayland,x11,drm) - kernel module is i915 - EGL is :
1.4 (DRI2) - GL vendor is : Intel Open Source Technology Center - GL
renderer is : Mesa DRI Intel(R) Ivybridge Model.
GPU seems to be : Intel HP Graphics 4000 (core i7 CPU)

2015-03-30 20:52 GMT+02:00 Daniel Stone dan...@fooishbar.org:

 Hi,

 On 30 March 2015 at 17:38, Manuel Bachmann
 manuel.bachm...@open.eurogiciel.org wrote:
  You removed the early return here...
  ...which means this check may be accessing NULL extensions, no?
 
  You are right ! Sorry for that, did not even look at the #ifdef, will
 rework
  this part.

 Apart from the configless_context damage, the rest (don't make lack of
 client extensions query fatal) is very much correct. I think that got
 lost in review. :\

  You do want to keep the -1 return as fatal here. gl_renderer_supports()
  should already return 0 meaning maybe if client extensions cannot be
  queried. The supports function is very nicely documented.
 
  Well, I have here a pratical case of a Ubuntu 14.04 laptop (Intel GPU,
 i915
  driver, will let you know the hardware, Mesa and libs versions soon when
 I
  get my hands on it), where the supports() function is able to find an
  *extensions strings, but then fails to locate these precise extensions,
  and thus returns -1. It prevents the X11 and DRM compositors to run, but
 it
  works nicely when removing this check. Does it make sense to you ?
  (regarding the purpose of the function, is that when building EGL with
 X11
  support, it will always report X11 as a supported platform ? Maybe there
 are
  versions of Mesa which do not honor this. Will check.)

 Weird - the only way I can see that happening is if Mesa advertises
 support for platform_base, but not for platform_{x11,gbm}, which seems
 very odd indeed. Ever since the addition of platform_base support[0],
 Mesa has supported EXT variants of x11 and wayland, and a MESA variant
 of gbm. So given the (fairly exhaustive) checks in
 gl_renderer_supports, I can't see how we'd end up in this situation.
 What is the complete client extension string on that platform?

 Cheers,
 Daniel

 [0]:
 http://cgit.freedesktop.org/mesa/mesa/commit/src/egl/main/eglglobals.c?id=468cc866b4b308cee40470f06b31002c6c56da96

  2015-03-30 14:40 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:
 
  On Sun, 29 Mar 2015 05:03:09 +0200
  Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:
 
   From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
  
   We should not prevent gl-renderer to initalize if client
   extensions were not found. Practically, this prevented
   Weston from running with GL on i915 DRI platforms.
  
   Some DRI drivers, including VMware vmwgfx, do not support
   calling eglQueryString() with a EGL_NO_DISPLAY parameter.
   Just as we do in gl_renderer_supports(), which returns 0
   but does not fail in this case, do not fail in
   gl_renderer_setup_egl_extensions().
   ---
src/gl-renderer.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
  
   diff --git a/src/gl-renderer.c b/src/gl-renderer.c
   index b3b2364..28ecc63 100644
   --- a/src/gl-renderer.c
   +++ b/src/gl-renderer.c
   @@ -2136,15 +2136,14 @@ gl_renderer_setup_egl_extensions(struct
   weston_compositor *ec)
 (const char *) eglQueryString(EGL_NO_DISPLAY,
   EGL_EXTENSIONS);
 if (!extensions) {
 weston_log(Retrieving EGL client extension string
   failed.\n);
   - return -1;
   + } else {
   + if (strstr(extensions, EGL_EXT_platform_base))
   + gr-create_platform_window =
   + (void *)
   eglGetProcAddress(eglCreatePlatformWindowSurfaceEXT);
   + else
   + weston_log(warning: EGL_EXT_platform_base not
   supported.\n);
 }
 
  You removed the early return here...
 
  
   - if (strstr(extensions, EGL_EXT_platform_base))
   - gr-create_platform_window =
   - (void *)
   eglGetProcAddress(eglCreatePlatformWindowSurfaceEXT);
   - else
   - weston_log(warning: EGL_EXT_platform_base not
   supported.\n);
   -
#ifdef EGL_MESA_configless_context
 if (strstr(extensions, EGL_MESA_configless_context))
 gr-has_configless_context = 1;
 
  ...which means this check may be accessing NULL extensions, no?
 
  Hmm, I wonder if the configless context check is looking at the right
  extensions string here.
 
   @@ -2256,12 +2255,9 @@ gl_renderer_create(struct weston_compositor
 *ec,
   EGLenum platform,
 EGLint major, minor;
 int supports = 0;
  
   - if (platform) {
   + if (platform)
 supports = gl_renderer_supports(
 ec

Re: [PATCH weston] gl-renderer: fix EGL initialization steps

[Manuel Bachmann]

OK. Found it, thanks to your hint, Daniel.

This version of Mesa (10.1.3) does not feature these extensions.

They were added here :
http://cgit.freedesktop.org/mesa/mesa/commit/src/egl/main/eglglobals.c?id=468cc866b4b308cee40470f06b31002c6c56da96

Considering that recent distributions, such as Ubuntu 14.04 LTS (Debian,
RHEL.. are even older) may not package a sufficiently recent version of
Mesa, maybe it is wise to ignore the test if extensions is only
EGL_EXT_client_extensions (which should not happen with recent Mesa,
because at least one platform should be supported there) ?

2015-03-30 21:38 GMT+02:00 Manuel Bachmann 
manuel.bachm...@open.eurogiciel.org:

 Hi Daniel, and thanks,

 What is the complete client extension string on that platform?

 It is simply EGL_EXT_client_extensions.

 Here are the details : kernel 3.13.0 - Mesa 10.1.3 (built with
 with-egl-platforms=wayland,x11,drm) - kernel module is i915 - EGL is :
 1.4 (DRI2) - GL vendor is : Intel Open Source Technology Center - GL
 renderer is : Mesa DRI Intel(R) Ivybridge Model.
 GPU seems to be : Intel HP Graphics 4000 (core i7 CPU)

 2015-03-30 20:52 GMT+02:00 Daniel Stone dan...@fooishbar.org:

 Hi,

 On 30 March 2015 at 17:38, Manuel Bachmann
 manuel.bachm...@open.eurogiciel.org wrote:
  You removed the early return here...
  ...which means this check may be accessing NULL extensions, no?
 
  You are right ! Sorry for that, did not even look at the #ifdef, will
 rework
  this part.

 Apart from the configless_context damage, the rest (don't make lack of
 client extensions query fatal) is very much correct. I think that got
 lost in review. :\

  You do want to keep the -1 return as fatal here. gl_renderer_supports()
  should already return 0 meaning maybe if client extensions cannot be
  queried. The supports function is very nicely documented.
 
  Well, I have here a pratical case of a Ubuntu 14.04 laptop (Intel GPU,
 i915
  driver, will let you know the hardware, Mesa and libs versions soon
 when I
  get my hands on it), where the supports() function is able to find an
  *extensions strings, but then fails to locate these precise
 extensions,
  and thus returns -1. It prevents the X11 and DRM compositors to run,
 but it
  works nicely when removing this check. Does it make sense to you ?
  (regarding the purpose of the function, is that when building EGL with
 X11
  support, it will always report X11 as a supported platform ? Maybe
 there are
  versions of Mesa which do not honor this. Will check.)

 Weird - the only way I can see that happening is if Mesa advertises
 support for platform_base, but not for platform_{x11,gbm}, which seems
 very odd indeed. Ever since the addition of platform_base support[0],
 Mesa has supported EXT variants of x11 and wayland, and a MESA variant
 of gbm. So given the (fairly exhaustive) checks in
 gl_renderer_supports, I can't see how we'd end up in this situation.
 What is the complete client extension string on that platform?

 Cheers,
 Daniel

 [0]:
 http://cgit.freedesktop.org/mesa/mesa/commit/src/egl/main/eglglobals.c?id=468cc866b4b308cee40470f06b31002c6c56da96

  2015-03-30 14:40 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:
 
  On Sun, 29 Mar 2015 05:03:09 +0200
  Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:
 
   From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
  
   We should not prevent gl-renderer to initalize if client
   extensions were not found. Practically, this prevented
   Weston from running with GL on i915 DRI platforms.
  
   Some DRI drivers, including VMware vmwgfx, do not support
   calling eglQueryString() with a EGL_NO_DISPLAY parameter.
   Just as we do in gl_renderer_supports(), which returns 0
   but does not fail in this case, do not fail in
   gl_renderer_setup_egl_extensions().
   ---
src/gl-renderer.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
  
   diff --git a/src/gl-renderer.c b/src/gl-renderer.c
   index b3b2364..28ecc63 100644
   --- a/src/gl-renderer.c
   +++ b/src/gl-renderer.c
   @@ -2136,15 +2136,14 @@ gl_renderer_setup_egl_extensions(struct
   weston_compositor *ec)
 (const char *) eglQueryString(EGL_NO_DISPLAY,
   EGL_EXTENSIONS);
 if (!extensions) {
 weston_log(Retrieving EGL client extension string
   failed.\n);
   - return -1;
   + } else {
   + if (strstr(extensions, EGL_EXT_platform_base))
   + gr-create_platform_window =
   + (void *)
   eglGetProcAddress(eglCreatePlatformWindowSurfaceEXT);
   + else
   + weston_log(warning: EGL_EXT_platform_base not
   supported.\n);
 }
 
  You removed the early return here...
 
  
   - if (strstr(extensions, EGL_EXT_platform_base))
   - gr-create_platform_window =
   - (void *)
   eglGetProcAddress(eglCreatePlatformWindowSurfaceEXT);
   - else

Re: [PATCH weston 2/2] desktop-shell: fix minimization of fullscreen surfaces, pointer focus

[Manuel Bachmann]

Now re-sending this patch, modified, under the new name desktop-shell: fix
minimization of fullscreen surfaces.

2015-03-30 18:26 GMT+02:00 Manuel Bachmann 
manuel.bachm...@open.eurogiciel.org:

 Hi Pekka,

 It is the wrong way to fix it.

 Not wl_pointer nor wl_keyboard foci are interchangeable with the concept
 of active. It simply just happens that an active window will usually have
 the kbd focus if a kbd exists, because users expect that. From a purely
 protocol-mechanical point of view there is no connection. Giving keyboard
 focus to an active window is compositor internal policy.

 This makes sense, thank you. I am thus going to remove the call to
 pointer_set_focus(.. 0, 0). By the way, I have a WIP patch which will
 allow focus to switch when you minimize a surface, just as when one gets
 destroyed currently. This seems to be what most of the other window
 managers do, and is likely to address this problem in a better way :-).

 Hmm, I'm not sure if that's clever or abuse... it's certainly unexpected
 and requires effort to see in the code, which calls a for a big comment to
 explain what is happening.

 Practically, it works just nice ; but I agree, I will add a multi-line
 comment on top of this, to explain why this is required.

 Regards,
 Manuel

 2015-03-30 8:59 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:

 On Sat, 28 Mar 2015 07:29:48 +0100
 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:

  Hi Pekka, thanks a lot for getting this on the rails !
 
  I'm not so sure about the pointer_set_focus here. Shuffling surfaces is
  supposed to trigger a repick, which will reassign the pointer focus.
  However, it seems something is off.
 
  The pointer_set_focus(... 0, 0) thing was added for a client
 (Chromium)
  whch privilegies pointer focus over keyboard focus, It considers itself
  still focused when minimized ; mostly because it disregards keyboard
 focus
  and, last time I looked in desktop-shell, even xdg-shell activate()
 events
  were mostly linked to keyboard focus. So adding this call for
 pointer_leave
  fixed it. What is your opinon on this ?

 It is the wrong way to fix it.

 Not wl_pointer nor wl_keyboard foci are interchangeable with the
 concept of active. It simply just happens that an active window will
 usually have the kbd focus if a kbd exists, because users expect that.
 From a purely protocol-mechanical point of view there is no connection.
 Giving keyboard focus to an active window is compositor internal policy.

 The app must be fixed to honour the activate events if it uses
 xdg_shell. In xdg_shell, window activeness is notified via configure
 events' flags. The spec says:
   entry name=activated value=4
 Client window decorations should be painted as if the window is
 active. Do not assume this means that the window actually has
 keyboard or pointer focus.
   /entry

 If it uses wl_shell, then you have to rely on kbd focus, because
 wl_shell doesn't have anything better. This means that in a
 keyboard-less system, wl_shell cannot even communicate activeness. Maybe
 that's the reason why someone might abuse pointer focus as window
 activation? But when he does that, the window will switch to an
 inactive look by just a pointer leave, while the user could still be
 typing into the window. That would be confusing.

 If this is some tablet use case, then you wouldn't have either
 wl_pointer not wl_keyboard, you'd only have wl_touch. And touch focus
 disappears the moment the last finger goes up. Note, that virtual
 keyboards do not communicate via wl_keyboard. So in a tablet case, the
 window activeness is completely separated from any foci.

 Pointer focus is good for highlighting the widget under the pointer
 kind of things, but neither pointer not keyboard foci are meant to
 signify activeness.

  assume the first wl_pointer.leave(nil) is for the popup surface, so
  that's ok. The enter for nil looks very suspicious though. Maybe that
  is caused by this patch?
 
  It clearly is ; I interpret this as the pointer leaving the main
 terminal
  surface when it minimizes, which seems logical, but maybe I'm misleaded
  (btw, how do you get all these logs ?).

 You can get them with WAYLAND_DEBUG=client env var, when running the
 client.

 Entering a NULL surface makes no sense to a client, it can only ignore
 it. It already received a leave, which means that wl_pointer is not on
 any of its own surfaces. Saying the pointer is still not on any of
 your surfaces is redundant.

 These NULL arguments should happen only in race conditions. For
 instance, the compositor assigned pointer focus to a surface, that the
 client has already destroyed but the compositor has not processed the
 destruction yet. If the compositor *has* processed the destruction,
 there is no reason to send enter for NULL.

  Just curious, how can the surface go off-center? Some output
  hot-unplugging involved?
 
  The call to unset_fullscreen() will reposition

[PATCH weston] desktop-shell: fix minimization of fullscreen surfaces

[Manuel Bachmann]

From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

If a fullscreen surface was minimized, the shell would keep
its fullscreen mode activated, and only a black background
would be visible.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 desktop-shell/shell.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f7c928e..073f187 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2667,6 +2667,11 @@ set_minimized(struct weston_surface *surface)
weston_layer_entry_remove(view-layer_link);
weston_layer_entry_insert(shsurf-shell-minimized_layer.view_list, 
view-layer_link);
 
+   /* if this surface if fullscreen, we temporarily disable fullscreen
+* mode and reposition it to its previous x,y coordinates */
+   if (shsurf-state.fullscreen)
+   unset_fullscreen(shsurf);
+
drop_focus_state(shsurf-shell, current_ws, view-surface);
wl_list_for_each(seat, shsurf-shell-compositor-seat_list, link) {
if (!seat-keyboard)
@@ -6016,8 +6021,14 @@ switcher_next(struct switcher *switcher)
view-alpha = 1.0;
 
shsurf = get_shell_surface(switcher-current);
-   if (shsurf  shsurf-state.fullscreen)
-   shsurf-fullscreen.black_view-alpha = 1.0;
+   if (shsurf  shsurf-state.fullscreen) {
+   /* A fullscreen surface may not be centered anymore
+ * if unset_fullscreen() was called on it, e.g.
+ * when minimizing it. Make sure it is again. */
+   center_on_output(shsurf-view, shsurf-fullscreen_output);
+   if (shsurf-fullscreen.black_view)
+   shsurf-fullscreen.black_view-alpha = 1.0;
+   }
 }
 
 static void
-- 
1.8.3.1

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

[PATCH weston] toytoolkit: fix EGL surface creation for lazy drivers

[Manuel Bachmann]

From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

Some DRI drivers, including VMware vmwgfx, do not support
calling eglQueryString() with a EGL_NO_DISPLAY parameter.

Allow toytoolkit to create EGL surfaces with them, by
falling back to the old creation method.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 shared/platform.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/shared/platform.h b/shared/platform.h
index ff640b5..364ce5a 100644
--- a/shared/platform.h
+++ b/shared/platform.h
@@ -55,8 +55,9 @@ weston_platform_get_egl_proc_address(const char *address)
 {
const char *extensions = eglQueryString(EGL_NO_DISPLAY, EGL_EXTENSIONS);
 
-   if (strstr(extensions, EGL_EXT_platform_wayland)
-   || strstr(extensions, EGL_KHR_platform_wayland)) {
+   if (extensions
+(strstr(extensions, EGL_EXT_platform_wayland)
+   || strstr(extensions, EGL_KHR_platform_wayland))) {
return (void *) eglGetProcAddress(address);
}
 
-- 
1.8.3.1

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

[PATCH weston] editor: implement Cut,Copy,Paste

[Manuel Bachmann]

From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

weston-editor is the only stock client spawning the virtual
keyboard ; which means it may be the only client able to
obtain some special characters (depending on the user's
keyboard layout).

If we implement Cut, Copy and Paste, the user has now a way
to copy such characters to other useful clients (such as
weston-terminal). Plus, it demonstrates text data exchange
between two clients of different nature.

Functionality is implemented in a right-click menu and the
Ctrl+Shift+X/C/V bindings, just as in weston-terminal.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 clients/editor.c | 169 ++-
 1 file changed, 166 insertions(+), 3 deletions(-)

diff --git a/clients/editor.c b/clients/editor.c
index 9299a05..29cab34 100644
--- a/clients/editor.c
+++ b/clients/editor.c
@@ -28,6 +28,7 @@
 #include stdlib.h
 #include string.h
 #include stdbool.h
+#include unistd.h
 
 #include linux/input.h
 #include cairo.h
@@ -76,6 +77,8 @@ struct text_entry {
 
 struct editor {
struct wl_text_input_manager *text_input_manager;
+   struct wl_data_source *selection;
+   char *selected_text;
struct display *display;
struct window *window;
struct widget *widget;
@@ -554,6 +557,128 @@ static const struct wl_text_input_listener 
text_input_listener = {
text_input_text_direction
 };
 
+static void
+data_source_target(void *data,
+  struct wl_data_source *source, const char *mime_type)
+{
+}
+
+static void
+data_source_send(void *data,
+struct wl_data_source *source,
+const char *mime_type, int32_t fd)
+{
+   struct editor *editor = data;
+
+   write(fd, editor-selected_text, strlen(editor-selected_text) + 1);
+}
+
+static void
+data_source_cancelled(void *data, struct wl_data_source *source)
+{
+   wl_data_source_destroy(source);
+}
+
+static const struct wl_data_source_listener data_source_listener = {
+   data_source_target,
+   data_source_send,
+   data_source_cancelled
+};
+
+static void
+paste_func(void *buffer, size_t len,
+  int32_t x, int32_t y, void *data)
+{
+   struct editor *editor = data;
+   struct text_entry *entry = editor-active_entry;
+   char *pasted_text;
+
+   if (!entry)
+   return;
+
+   pasted_text = malloc(len + 1);
+   strncpy(pasted_text, buffer, len);
+   pasted_text[len] = '\0';
+
+   text_entry_insert_at_cursor(entry, pasted_text, 0, 0);
+
+   free(pasted_text);
+}
+
+static void
+editor_copy_cut(struct editor *editor, struct input *input, bool cut)
+{
+   struct text_entry *entry = editor-active_entry;
+
+   if (!entry)
+   return;
+   
+   if (entry-cursor != entry-anchor) {
+   int start_index = MIN(entry-cursor, entry-anchor);
+   int end_index = MAX(entry-cursor, entry-anchor);
+   int len = end_index - start_index;
+
+   editor-selected_text = realloc(editor-selected_text, len + 1);
+   strncpy(editor-selected_text, entry-text[start_index], len);
+   editor-selected_text[len] = '\0';
+
+   if (cut)
+   text_entry_delete_text(entry, start_index, len);
+
+   editor-selection =
+   display_create_data_source(editor-display);
+   wl_data_source_offer(editor-selection,
+text/plain;charset=utf-8);
+   wl_data_source_add_listener(editor-selection,
+   data_source_listener, editor);
+   input_set_selection(input, editor-selection,
+   display_get_serial(editor-display));
+   }
+}
+
+static void
+editor_paste(struct editor *editor, struct input *input)
+{
+   input_receive_selection_data(input,
+text/plain;charset=utf-8,
+paste_func, editor);
+}
+
+static void
+menu_func(void *data, struct input *input, int index)
+{
+   struct window *window = data;
+   struct editor *editor = window_get_user_data(window);
+
+   fprintf(stderr, picked entry %d\n, index);
+
+   switch (index) {
+   case 0:
+   editor_copy_cut(editor, input, true);
+   break;
+   case 1:
+   editor_copy_cut(editor, input, false);
+   break;
+   case 2:
+   editor_paste(editor, input);
+   break;
+   }
+}
+
+static void
+show_menu(struct editor *editor, struct input *input, uint32_t time)
+{
+   int32_t x, y;
+   static const char *entries[] = {
+   Cut, Copy, Paste
+   };
+
+   input_get_position(input, x, y);
+   window_show_menu(editor-display, input, time, editor-window,
+x + 10, y + 20

[PATCH weston] gl-renderer: fix EGL initialization steps

[Manuel Bachmann]

From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

We should not prevent gl-renderer to initalize if client
extensions were not found. Practically, this prevented
Weston from running with GL on i915 DRI platforms.

Some DRI drivers, including VMware vmwgfx, do not support
calling eglQueryString() with a EGL_NO_DISPLAY parameter.
Just as we do in gl_renderer_supports(), which returns 0
but does not fail in this case, do not fail in
gl_renderer_setup_egl_extensions().
---
 src/gl-renderer.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index b3b2364..28ecc63 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -2136,15 +2136,14 @@ gl_renderer_setup_egl_extensions(struct 
weston_compositor *ec)
(const char *) eglQueryString(EGL_NO_DISPLAY, EGL_EXTENSIONS);
if (!extensions) {
weston_log(Retrieving EGL client extension string failed.\n);
-   return -1;
+   } else {
+   if (strstr(extensions, EGL_EXT_platform_base))
+   gr-create_platform_window =
+   (void *) 
eglGetProcAddress(eglCreatePlatformWindowSurfaceEXT);
+   else
+   weston_log(warning: EGL_EXT_platform_base not 
supported.\n);
}
 
-   if (strstr(extensions, EGL_EXT_platform_base))
-   gr-create_platform_window =
-   (void *) 
eglGetProcAddress(eglCreatePlatformWindowSurfaceEXT);
-   else
-   weston_log(warning: EGL_EXT_platform_base not supported.\n);
-
 #ifdef EGL_MESA_configless_context
if (strstr(extensions, EGL_MESA_configless_context))
gr-has_configless_context = 1;
@@ -2256,12 +2255,9 @@ gl_renderer_create(struct weston_compositor *ec, EGLenum 
platform,
EGLint major, minor;
int supports = 0;
 
-   if (platform) {
+   if (platform)
supports = gl_renderer_supports(
ec, platform_to_extension(platform));
-   if (supports  0)
-   return -1;
-   }
 
gr = zalloc(sizeof *gr);
if (gr == NULL)
-- 
1.8.3.1

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

[PATCH weston] nested-client: fix typo

[Manuel Bachmann]

From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

Should be client instead of nclient.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 clients/nested-client.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clients/nested-client.c b/clients/nested-client.c
index 615f589..27dc54f 100644
--- a/clients/nested-client.c
+++ b/clients/nested-client.c
@@ -310,7 +310,7 @@ nested_client_create(void)
  client-width, client-height);
 
client-egl_surface = 
weston_platform_create_egl_surface(client-egl_display,
-
nclient-egl_config,
+
client-egl_config,
 
client-native, NULL);
 
eglMakeCurrent(client-egl_display, client-egl_surface,
-- 
1.8.3.1

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

[PATCH weston] toytoolkit: fix new EGL extensions fallback typedefs

[Manuel Bachmann]

From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

The dummy typedefs for get_platform_display() and
create_platform_window() were badly defined, which
prevented building Weston on older systems.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 shared/platform.h | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/shared/platform.h b/shared/platform.h
index c099188..ff640b5 100644
--- a/shared/platform.h
+++ b/shared/platform.h
@@ -41,8 +41,13 @@ extern C {
 #ifdef ENABLE_EGL
 
 #ifndef EGL_EXT_platform_base
-typedef void (*PFNEGLGETPLATFORMDISPLAYEXTPROC) (void);
-typedef void (*PFNEGLCREATEPLATFORMWINDOWSURFACEEXTPROC) (void);
+typedef EGLDisplay (*PFNEGLGETPLATFORMDISPLAYEXTPROC) (EGLenum platform,
+  void *native_display,
+  const EGLint 
*attrib_list);
+typedef EGLSurface (*PFNEGLCREATEPLATFORMWINDOWSURFACEEXTPROC) (EGLDisplay dpy,
+   EGLConfig 
config,
+   void 
*native_window,
+   const EGLint 
*attrib_list);
 #endif
 
 static inline void *
-- 
1.8.3.1

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

Re: [PATCH weston 2/2] desktop-shell: fix minimization of fullscreen surfaces, pointer focus

[Manuel Bachmann]

Hi Pekka, thanks a lot for getting this on the rails !

I'm not so sure about the pointer_set_focus here. Shuffling surfaces is
supposed to trigger a repick, which will reassign the pointer focus.
However, it seems something is off.

The pointer_set_focus(... 0, 0) thing was added for a client (Chromium)
whch privilegies pointer focus over keyboard focus, It considers itself
still focused when minimized ; mostly because it disregards keyboard focus
and, last time I looked in desktop-shell, even xdg-shell activate() events
were mostly linked to keyboard focus. So adding this call for pointer_leave
fixed it. What is your opinon on this ?

assume the first wl_pointer.leave(nil) is for the popup surface, so
that's ok. The enter for nil looks very suspicious though. Maybe that
is caused by this patch?

It clearly is ; I interpret this as the pointer leaving the main terminal
surface when it minimizes, which seems logical, but maybe I'm misleaded
(btw, how do you get all these logs ?).

Just curious, how can the surface go off-center? Some output
hot-unplugging involved?

The call to unset_fullscreen() will reposition the surface at its former
non-fullscreen position (old_x, old_y), which is good. When the surface
gets focused again later, fullscreen state gets triggered again because the
hint is stll too, which is good, too ; but the x,y is now old_x, old_y, so
off-center.

When wouldn't there be a black_view?

When you refocus a minimized surface, black_view has been destroyed by
unset_fullscreen(). It gets created later again, but after this part,
where it is NULL and thus crashes.
---
(btw, as you pushed master, you'll want to take a look at my 2 no-brainer
patches which fix building it :
http://lists.freedesktop.org/archives/wayland-devel/2015-March/020920.html
- http://lists.freedesktop.org/archives/wayland-devel/2015-March/020921.html
)

Regards,

2015-03-27 15:22 GMT+01:00 Pekka Paalanen ppaala...@gmail.com:

 On Mon, 16 Feb 2015 11:52:47 +0100
 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:

  From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
 
  2 things were wrong with the minimization code :
  - if the minimized surface was fullscreen, the shell would keep
its fullscreen mode on and only display a black background ;
  - keyboard focus was unset, but pointer focus was not.
 
  On the other hand, make sure a fullscreen surface gets centered
  again when refocused with Mod+Tab.
 
  Author: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
  Author: Nicolas Guyomard nicolas.guyom...@open.eurogiciel.org
  Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
  ---
   desktop-shell/shell.c |   16 +---
   1 file changed, 13 insertions(+), 3 deletions(-)
 
  diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
  index 5900c4d..830c25d 100644
  --- a/desktop-shell/shell.c
  +++ b/desktop-shell/shell.c
  @@ -2657,13 +2657,20 @@ set_minimized(struct weston_surface *surface)
weston_layer_entry_remove(view-layer_link);
 
  weston_layer_entry_insert(shsurf-shell-minimized_layer.view_list,
 view-layer_link);
 
  + if (shsurf-state.fullscreen)
  + unset_fullscreen(shsurf);
  +
drop_focus_state(shsurf-shell, current_ws, view-surface);
wl_list_for_each(seat, shsurf-shell-compositor-seat_list,
 link) {
if (!seat-keyboard)
continue;
focus =
 weston_surface_get_main_surface(seat-keyboard-focus);
  - if (focus == view-surface)
  + if (focus == view-surface) {
weston_keyboard_set_focus(seat-keyboard, NULL);
  + weston_pointer_set_focus(seat-pointer, NULL,
  +  wl_fixed_from_int(0),
  +  wl_fixed_from_int(0));
  + }
}

 Hi,

 I'm not so sure about the pointer_set_focus here. Shuffling surfaces is
 supposed to trigger a repick, which will reassign the pointer focus.
 However, it seems something is off. The keyboards focus is different to
 pointer focus, because keyboard focus is sticky and needs to be
 explicitly managed. Pointer focus generally follows picking unless the
 pointer is grabbed.

 With this patch applied:

 [2030091.702]  - xdg_surface@15.set_minimized()
 [2030091.737]  - xdg_popup@21.destroy()
 [2030091.768]  - wl_surface@25.destroy()
 [2030091.805]  - wl_buffer@29.destroy()
 [2030091.892]  - wl_shm_pool@28.destroy()
 [2030092.413] wl_display@1.delete_id(21)
 [2030092.469] wl_display@1.delete_id(25)
 [2030092.503] wl_display@1.delete_id(29)
 [2030092.537] wl_display@1.delete_id(28)
 [2030092.570] wl_keyboard@16.leave(315, wl_surface@14)
 [2030092.633] xdg_surface@15.configure(1024, 600, array, 316)
 [2030092.722]  - xdg_surface@15.ack_configure(316)
 [2030092.762]  - xdg_surface@15.set_title(pq@erebos:~/git/weston)
 [2030092.798] wl_pointer@17.leave(317, nil)
 [2030092.853] wl_keyboard

Re: [RFC : xdg_surface_present() - take 2

[Manuel Bachmann]

Hi Jasper, Jonas, Pekka, Jason,

Just a little update regarding the present() request. As the serial thing
seems to be our main concern, aside from the minor protocol change and new
functionality we mostly seem to agree on, here are the 2 ways we could do
it :

1) modify the protocol, which means :
- in the XML, adding : A serial of 0 cannot be returned by the compositor
; thus in requests, passing 0 as a serial parameter actually means no
specific serial is needed nor provided.
- modify wayland-server to reflect the description (thanks to Jonas for
reminding me).

2) have 2 requests instead of 1 :
xdg_surface_present(struct xdg_surface *surface);
xdg_surface_present_from_event(struct xdg_surface *surface, uint32_t
serial);

What should be our preferred way ? Doing 2) is still satisfying is we
cannot do 1). Looking for a consensus here.

Regards,
Manuel

2015-03-09 6:17 GMT+01:00 Manuel Bachmann 
manuel.bachm...@open.eurogiciel.org:

 Hi Jasper,

 This is not an I need attention request. Perhaps our documentation is
 poor.
 You are right, just as I answered to Jonas, I mixed present() with the
 desktop-launcher-focus-stealing feature we were discussing in the previous
 thread. Sorry for the confusion.

 2015-03-09 3:25 GMT+01:00 Jasper St. Pierre jstpie...@mecheye.net:



 On Sun, Mar 8, 2015 at 6:57 PM, Jonas Ådahl jad...@gmail.com wrote:

 On Fri, Feb 27, 2015 at 11:14:19AM +0100, Manuel Bachmann wrote:
  Hello fellow developers,
 
  I just wanted to continue a discussion which occured some time ago,
 about
  the eventuality of adding a xdg_surface_present() request to
 XDG-Shell.
 
  (For reference, former discussion entry points are here :
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-July/016078.html
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-July/016224.html
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-August/016269.html
 )
 
  To summarize : the idea behing xdg_surface_present() is that there
 are
  some cases where a surface wants to advertise the fact that it has been
  updated and the user may want to take a look (think of an IRC chat
 window
  which gets new messages containing the user's nickname). There are even
  some corner cases where the surface may want to be raised and focused
  directly ; but we do not want to request to be abused this way, a
 client
  must be prevented from stealing the focus repeatedly. At last, the
  compositor's shell should have the last word.

 I have some comments I thought I'd share. See the inline replies:

 
  Here are some of the points that were discussed and the outcomes :
 
  - Pekka Paalanen pointed out the request name was unclear and
 suggested to
  use xdg_surface_needs/wants_attention() instead. Jasper St. Pierre
  pointed out that _NET_WM_STATE_DEMANDS_ATTENTION already existed in
 X11
  and does not do the same thing. We discussed that again yesterday and
  thought that present() fitted nicely ;

 There is also the The Present Extension in X11, so is present really
 that much better? If the use case is a client wants attention because
 some reason (be it IRC highlight, new message, task finished or
 whatever), shouldn't the request name contain that information some how?
 Isn't what is discussed here even quite similar to
 _NET_WM_STATE_DEMANDS_ATTENTION?


 No. It's equivalent to the _NET_ACTIVATE_WINDOW ClientMessage.

 IRC highlights, new messages, task finished, etc. are use cases for
 notifications. The use case here is user double-clicked on a file and I
 want my existing gedit window to be raised in response. Basically, places
 where you want to show the window immediately if the stars are aligned
 correctly (the serial is correct).


 
  - We want to implement focus stealing prevention : if the user is
 starting
  a slow app (browser...), gets back to typing a mail while it starts,
 and at
  last the browser window appears, the focus should stay in the mail
 window
  without his keyboard presses going elsewhere ;

 This rather sound like something startup notification protocol related
 than an I need attention request, and I think that problem needs to be
 tackled separately.


 This is not an I need attention request. Perhaps our documentation is
 poor.


 
  - Implementing focus stealing prevention between different clients may
 be
  easy : just count the delay between the client has been started and its
  shell surface actually gets mapped, and if it has been too long and the
  focus is elsewhere, show the surface without focusing it (but with a
  notification). The notion of the client has been started is vague,
 but at
  worst, we can use the time when the client did its initial connection
 to
  the compositor ;

 As Bill mentioned, clients that happens to do a lot of things before
 connecting will have a very short time from that the connection is
 established to that a surface is to be mapped. It can even be trivially
 abused to steal focus at unexpected times.

 
  - Within a same client

Re: [RFC] Implementing Wayland Security Module

[Manuel Bachmann]

Hi Jasper,

Why are fullscreen and resolution change privileged operations?

Personally, I think fullscreen should be allowed by default, but could be
disallowed on a per-application-basis ; because a few ones could abuse it
by re-triggering repeatedly (it made a great testcase for the demo,
however).

Regarding resolution change, I'm not even sure it's in WSM ;-), but that's
direct access to the hardware modes ; what about an app changing modes
every 5 seconds while minimized so you cannot easily kill it ? You can
imagine the compositor's default UI would be authorized, but a third-party
app (like a video game) would at least need to ask the first time.

I will not implement support for WSMs in mutter. I have given my opinion
on why I think technical solutions to security problems and security
policies are bogus before. I won't bother to repeat it here.

We discussed that on IRC, I can understand your position.

Regards,
Manuel

2015-03-09 21:41 GMT+01:00 Jasper St. Pierre jstpie...@mecheye.net:

 On Mon, Mar 9, 2015 at 12:52 PM, Manuel Bachmann 
 manuel.bachm...@open.eurogiciel.org wrote:

 Hi Matthias,

 I don't think it makes sense to develop a specific solution just for
 the portion of application sandboxing that happens to overlap with
 wayland protocol requests. The same questions need to be answered when
 a third-party application e.g. wants to open a file or send an email.

 While it is true that the general security policy concern is a huge
 topic, and that WSM may seem to be a too-specific solution in an ecosystem
 where several Linux Security Modules have already been implemented, I
 think, however, that there is a valid use case for it.

 We happen to have a more-than-20-years-old ecosystem of GUI applications
 which were using the X11 protocol. For all these years, they were allowed
 to exploit this protocol in various ways, which gave us the cool features
 we could not imagine living without today.

 Then comes Wayland. It is more secure, but the cool features aren't
 there. Sure, each compositor can do the way it wants, but application
 developers are embarrassed . This potentially cripples the user experience
 and slows down Wayland adoption.

 WSM is interesting because it only tries to cover GUI applications,
 which, basically, all have the same needs :
 - screenshooting, screen recording, color picking
 - critical actions on the outputs : fullscreen, resolution change...


 Why are fullscreen and resolution change privileged operations?


 - access to a central clipboard ;

 - replacing a vital part of the compositor  (virtual keyboard, panel,
 systray...)
 - 

 A Linux Security Module goes too far, has too many implications, hence
 why it is rarely deployed excepted on server systems. But WSM is only about
 GUI apps ; it precisely knows what it wants to be and which problems it
 tries to address. I think, personally, that WSM has a chance of success
 because it is pragmatic and has the privilegied timeframe for this.


 I will not implement support for WSMs in mutter. I have given my opinion
 on why I think technical solutions to security problems and security
 policies are bogus before. I won't bother to repeat it here.


 Regards,
 Manuel

 2015-03-09 14:30 GMT+01:00 Matthias Clasen matthias.cla...@gmail.com:

 On Mon, Mar 9, 2015 at 1:38 AM, Manuel Bachmann
 manuel.bachm...@open.eurogiciel.org wrote:

  Any comments on this ?
 

 I don't think it makes sense to develop a specific solution just for
 the portion of application sandboxing that happens to overlap with
 wayland protocol requests. The same questions need to be answered when
 a third-party application e.g. wants to open a file or send an email.




 --
 Regards,



 *Manuel BACHMANN Tizen Project VANNES-FR*

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




 --
   Jasper




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] Implementing Wayland Security Module

[Manuel Bachmann]

Hi Matthias,

I don't think it makes sense to develop a specific solution just for
the portion of application sandboxing that happens to overlap with
wayland protocol requests. The same questions need to be answered when
a third-party application e.g. wants to open a file or send an email.

While it is true that the general security policy concern is a huge topic,
and that WSM may seem to be a too-specific solution in an ecosystem where
several Linux Security Modules have already been implemented, I think,
however, that there is a valid use case for it.

We happen to have a more-than-20-years-old ecosystem of GUI applications
which were using the X11 protocol. For all these years, they were allowed
to exploit this protocol in various ways, which gave us the cool features
we could not imagine living without today.

Then comes Wayland. It is more secure, but the cool features aren't there.
Sure, each compositor can do the way it wants, but application developers
are embarrassed . This potentially cripples the user experience and slows
down Wayland adoption.

WSM is interesting because it only tries to cover GUI applications, which,
basically, all have the same needs :
- screenshooting, screen recording, color picking
- critical actions on the outputs : fullscreen, resolution change...
- access to a central clipboard ;
- replacing a vital part of the compositor  (virtual keyboard, panel,
systray...)
- 

A Linux Security Module goes too far, has too many implications, hence why
it is rarely deployed excepted on server systems. But WSM is only about GUI
apps ; it precisely knows what it wants to be and which problems it tries
to address. I think, personally, that WSM has a chance of success because
it is pragmatic and has the privilegied timeframe for this.

Regards,
Manuel

2015-03-09 14:30 GMT+01:00 Matthias Clasen matthias.cla...@gmail.com:

 On Mon, Mar 9, 2015 at 1:38 AM, Manuel Bachmann
 manuel.bachm...@open.eurogiciel.org wrote:

  Any comments on this ?
 

 I don't think it makes sense to develop a specific solution just for
 the portion of application sandboxing that happens to overlap with
 wayland protocol requests. The same questions need to be answered when
 a third-party application e.g. wants to open a file or send an email.




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC : xdg_surface_present() - take 2

[Manuel Bachmann]

 will have to remember very few serials.
 Rather than per-surface I think it would be per-seat. And there would be no
 timeout, instead it would remember the last N button or key presses (N
 quite possibley is 1).


 Yes, per-seat is most likely what we want.  How many serials do we want to
 hold on to?  I think that's kind of depends on how badly we want to pass
 serials across clients.  Within a client, one is probably sufficient.  If
 we're going to pass it between clients, we probably want to hold on to more
 and have a timeout.  We probably also want to do something such as clearing
 all serials when the user raises a window.  However, that falls under the
 category of heuristics, not protocol.




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC : xdg_surface_present() - take 2

[Manuel Bachmann]

I have some comments I thought I'd share. See the inline replies:

Hi Jonas, and thanks a lot for your time,

This rather sound like something startup notification protocol related
than an I need attention request, and I think that problem needs to be
tackled separately.

You're right :  it has nothing to do with the present() request in itself .
I mentioned it mostly because the former discussion mentioned possible ways
to cross-use present() with shell environment variables (like X11 does, to
improve the global user experience). But this is probably going too early
too far, and I should not have mentioned it in my first mail.

As Bill mentioned, clients that happens to do a lot of things before
connecting will have a very short time from that the connection is
established to that a surface is to be mapped. It can even be trivially
abused to steal focus at unexpected times.

In fact, at least in the current implementation, I think  it cannot be
abused because the surface will be shown and focused if it did not exist
before (that's what already happens), and if it did, it won't raise because
the client will not be able to use a serial coming from another client
(cross-client serials are not implemented nor wanted yet, contrary to what
my former paragraph could let guess ; the compositor stores serials
per-client, should also be per-seat as Bill mentioned).

I don't think it's a good idea to pass serials between clients and assume
they have any effect, and the server should probably not allow such focus
switching between clients.

Agreed ; let's just forget this for now.

If 0-is-invalid its not formalized, it should not be relied upon IMO,
but I think it is useful to have a non-valid serial.

Agreed ; this is really the biggest caveat, and it would be nice to agree
on a way to formalize it.
From an implementation POV : I know that Weston never reuses 0 ; Mutter
probably won't because Jasper most likely agrees :-) ; and regarding
Enlightenment, we're following it closely and regulary pushing patches for
it.

Regards.


2015-03-09 2:57 GMT+01:00 Jonas Ådahl jad...@gmail.com:

 On Fri, Feb 27, 2015 at 11:14:19AM +0100, Manuel Bachmann wrote:
  Hello fellow developers,
 
  I just wanted to continue a discussion which occured some time ago, about
  the eventuality of adding a xdg_surface_present() request to XDG-Shell.
 
  (For reference, former discussion entry points are here :
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-July/016078.html
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-July/016224.html
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-August/016269.html
 )
 
  To summarize : the idea behing xdg_surface_present() is that there are
  some cases where a surface wants to advertise the fact that it has been
  updated and the user may want to take a look (think of an IRC chat window
  which gets new messages containing the user's nickname). There are even
  some corner cases where the surface may want to be raised and focused
  directly ; but we do not want to request to be abused this way, a client
  must be prevented from stealing the focus repeatedly. At last, the
  compositor's shell should have the last word.

 I have some comments I thought I'd share. See the inline replies:

 
  Here are some of the points that were discussed and the outcomes :
 
  - Pekka Paalanen pointed out the request name was unclear and suggested
 to
  use xdg_surface_needs/wants_attention() instead. Jasper St. Pierre
  pointed out that _NET_WM_STATE_DEMANDS_ATTENTION already existed in X11
  and does not do the same thing. We discussed that again yesterday and
  thought that present() fitted nicely ;

 There is also the The Present Extension in X11, so is present really
 that much better? If the use case is a client wants attention because
 some reason (be it IRC highlight, new message, task finished or
 whatever), shouldn't the request name contain that information some how?
 Isn't what is discussed here even quite similar to
 _NET_WM_STATE_DEMANDS_ATTENTION?

 
  - We want to implement focus stealing prevention : if the user is
 starting
  a slow app (browser...), gets back to typing a mail while it starts, and
 at
  last the browser window appears, the focus should stay in the mail window
  without his keyboard presses going elsewhere ;

 This rather sound like something startup notification protocol related
 than an I need attention request, and I think that problem needs to be
 tackled separately.

 
  - Implementing focus stealing prevention between different clients may be
  easy : just count the delay between the client has been started and its
  shell surface actually gets mapped, and if it has been too long and the
  focus is elsewhere, show the surface without focusing it (but with a
  notification). The notion of the client has been started is vague, but
 at
  worst, we can use the time when the client did its initial connection to
  the compositor ;

 As Bill

[RFC] Implementing Wayland Security Module

[Manuel Bachmann]

Hi fellow developers,

Some time ago, there has been some discussion on this mailing list about
libwsm (alias lib Wayland Security Module).

Here is the previous thread :
http://lists.freedesktop.org/archives/wayland-devel/2014-February/013359.html

Libwsm has been developed by Martin Peres and Steve Dodier-Lazaro ; it
tries to address the issues about unprivilegied clients wanting access to
privilegies interfaces. For instance,

- a legitimate third-party app wanting to take screenshots and record the
screen at the user's request ;
- a rogue app trying to take screenshots of the users' bank account number ;
- a legitimate app installed as an alternate virtual keyboard (instead of,
say, weston-keyboard)
- a rogue app (virus) trying to permanently switch fullscreen to display
ads and threats.

We know all this was possible with X11 due to protocol flaws. Wayland is a
lot more secure, but there are still legitimate third-party clients wanting
access to these privliegied features (such as the Pick a color from the
screen tool of GIMP) !
 Unfortunately, Wayland Compositors have no generic way to validate them.
So, how do we allow GIMP, for instance, to work ? libwsm lives in the
compositor (eventually in a plugin) and is able to takes decisions based on
various configurable policies. Policies can be shared among compositors.

Here's a demo with fullscreen limitation policies :

The current code :
https://github.com/Tarnyko/weston-wayland_security_module/commits/master

and the video :
https://www.youtube.com/watch?v=pDg-eUARW5c

(here we try to make weston-terminal fullscreen ; first with allow
policy -it works-, then with deny -it fails with an explanative
notification- and finally with soft allow -it works when the user
interacts with the notification to explicitly authorize the app)

Any comments on this ?

-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC : xdg_surface_present() - take 2

[Manuel Bachmann]

Hi Jasper,

This is not an I need attention request. Perhaps our documentation is
poor.
You are right, just as I answered to Jonas, I mixed present() with the
desktop-launcher-focus-stealing feature we were discussing in the previous
thread. Sorry for the confusion.

2015-03-09 3:25 GMT+01:00 Jasper St. Pierre jstpie...@mecheye.net:



 On Sun, Mar 8, 2015 at 6:57 PM, Jonas Ådahl jad...@gmail.com wrote:

 On Fri, Feb 27, 2015 at 11:14:19AM +0100, Manuel Bachmann wrote:
  Hello fellow developers,
 
  I just wanted to continue a discussion which occured some time ago,
 about
  the eventuality of adding a xdg_surface_present() request to
 XDG-Shell.
 
  (For reference, former discussion entry points are here :
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-July/016078.html
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-July/016224.html
 
 http://lists.freedesktop.org/archives/wayland-devel/2014-August/016269.html
 )
 
  To summarize : the idea behing xdg_surface_present() is that there are
  some cases where a surface wants to advertise the fact that it has been
  updated and the user may want to take a look (think of an IRC chat
 window
  which gets new messages containing the user's nickname). There are even
  some corner cases where the surface may want to be raised and focused
  directly ; but we do not want to request to be abused this way, a client
  must be prevented from stealing the focus repeatedly. At last, the
  compositor's shell should have the last word.

 I have some comments I thought I'd share. See the inline replies:

 
  Here are some of the points that were discussed and the outcomes :
 
  - Pekka Paalanen pointed out the request name was unclear and suggested
 to
  use xdg_surface_needs/wants_attention() instead. Jasper St. Pierre
  pointed out that _NET_WM_STATE_DEMANDS_ATTENTION already existed in
 X11
  and does not do the same thing. We discussed that again yesterday and
  thought that present() fitted nicely ;

 There is also the The Present Extension in X11, so is present really
 that much better? If the use case is a client wants attention because
 some reason (be it IRC highlight, new message, task finished or
 whatever), shouldn't the request name contain that information some how?
 Isn't what is discussed here even quite similar to
 _NET_WM_STATE_DEMANDS_ATTENTION?


 No. It's equivalent to the _NET_ACTIVATE_WINDOW ClientMessage.

 IRC highlights, new messages, task finished, etc. are use cases for
 notifications. The use case here is user double-clicked on a file and I
 want my existing gedit window to be raised in response. Basically, places
 where you want to show the window immediately if the stars are aligned
 correctly (the serial is correct).


 
  - We want to implement focus stealing prevention : if the user is
 starting
  a slow app (browser...), gets back to typing a mail while it starts,
 and at
  last the browser window appears, the focus should stay in the mail
 window
  without his keyboard presses going elsewhere ;

 This rather sound like something startup notification protocol related
 than an I need attention request, and I think that problem needs to be
 tackled separately.


 This is not an I need attention request. Perhaps our documentation is
 poor.


 
  - Implementing focus stealing prevention between different clients may
 be
  easy : just count the delay between the client has been started and its
  shell surface actually gets mapped, and if it has been too long and the
  focus is elsewhere, show the surface without focusing it (but with a
  notification). The notion of the client has been started is vague,
 but at
  worst, we can use the time when the client did its initial connection to
  the compositor ;

 As Bill mentioned, clients that happens to do a lot of things before
 connecting will have a very short time from that the connection is
 established to that a surface is to be mapped. It can even be trivially
 abused to steal focus at unexpected times.

 
  - Within a same client application, however, it is harder. Think of a
  browser where you click new window but lots of time pass before it
  appears. The starting point is the pointer click event. So the idea
 would
  be to pass the Wayland serial corresponding to this event :
  xdg_surface_present (surface, SERIAL). It the serial has been issued
  too long ago, do focus stealing prevention.

 Serials are quite easy to guess, but for intra-client focus switching it
 might work. I don't think it's a good idea to pass serials between
 clients and assume they have any effect, and the server should probably
 not allow such focus switching between clients.

 
  This raises the question : how do we say We have no serial to pass,
 for
  the standard case ? We repeatedly suggested 0 (xdg_surface_present
  (surface, 0)) because serials are incrementing globals, so 0 to be
  issued would be very-very unlikely. Should we formalize that somewhere
 in
  the protocol ?

 If 0

Re: [RFC : xdg_surface_present() - take 2

[Manuel Bachmann]

Hi Bill, and thanks a lot for your comments,

What about raise?

I think the issue with raise was the same that with set_unminimized or
activate ; it gives the false impression that the surface will
consistently be brought to the foreground (whereas it depends on many
things, and will in fact be rare).

I suspect that initial connection is going to be far too late. It will be
after all the dynamic linking and static object initialization and script
interpretation (imagine if the wayland api is written in the interpreted
language, it will not open the display until quite a lot of interpretation
is done), all of which are the real reason modern apps take forever to
start up.
I would put the serial somewhere that the app can get it, perhaps in an
environment variable, so it can send it with it's first raise request.

You have a good point here. Ideally we would catch the very moment the user
clicks on the application icon, or starts it in a command line ; Jasper
pointed out a X11-specific variable named DESKTOP_STARTUP_ID (1) which
seems to do this very thing.

This kind of variable could be filled by the launcher, caught by the shell,
and then seamlessly passed to the client  (I personally wanted to avoid
over-engineering things in preliminary patches).

'0' is useful but should force the the serial is too old behavior.
Anybody who wants a real raise will have to get an actual serial.

Yes this is also a good point ; good you're mentioning that in that simple
way !

Rather than per-surface I think it would be per-seat.

The current patch implementation makes it per-client, but in the end you're
right. We would only need to remember a few of the latest serials issued by
each input interface(keyboard/pointer/touch).

(1) :
http://lists.freedesktop.org/archives/wayland-devel/2014-August/016279.html

2015-03-03 22:15 GMT+01:00 Bill Spitzak spit...@gmail.com:


  - Pekka Paalanen pointed out the request name was unclear and suggested
 to use xdg_surface_needs/wants_attention() instead. Jasper St. Pierre
 pointed out that _NET_WM_STATE_DEMANDS_ATTENTION already existed in
 X11 and does not do the same thing. We discussed that again yesterday
 and thought that present() fitted nicely ;


 What about raise?

  - Implementing focus stealing prevention between different clients may
 be easy : just count the delay between the client has been started and
 its shell surface actually gets mapped, and if it has been too long and
 the focus is elsewhere, show the surface without focusing it (but with a
 notification). The notion of the client has been started is vague, but
 at worst, we can use the time when the client did its initial connection
 to the compositor ;


 I suspect that initial connection is going to be far too late. It will be
 after all the dynamic linking and static object initialization and script
 interpretation (imagine if the wayland api is written in the interpreted
 language, it will not open the display until quite a lot of interpretation
 is done), all of which are the real reason modern apps take forever to
 start up.

 I would put the serial somewhere that the app can get it, perhaps in an
 environment variable, so it can send it with it's first raise request.

  - Within a same client application, however, it is harder.


 Actually it is impossible without a serial. The serial is the correct
 solution which makes within the same client easier that between clients.

  This raises the question : how do we say We have no serial to pass,
 for the standard case ? We repeatedly suggested 0 (xdg_surface_present
 (surface, 0)) because serials are incrementing globals, so 0 to be
 issued would be very-very unlikely. Should we formalize that somewhere
 in the protocol ?


 '0' is useful but should force the the serial is too old behavior.
 Anybody who wants a real raise will have to get an actual serial.

  We also want to secure the request from garbage random serials ; the
 implementation behavior is that there is only one serial valid for a few
 seconds, if the surface has not been focused for some time, it will not
 be able to raise itself even if it random()ly finds the formerly good
 serial.


 It seems to me the compositor will have to remember very few serials.
 Rather than per-surface I think it would be per-seat. And there would be no
 timeout, instead it would remember the last N button or key presses (N
 quite possibley is 1).




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[RFC : xdg_surface_present() - take 2

[Manuel Bachmann]

Hello fellow developers,

I just wanted to continue a discussion which occured some time ago, about
the eventuality of adding a xdg_surface_present() request to XDG-Shell.

(For reference, former discussion entry points are here :
http://lists.freedesktop.org/archives/wayland-devel/2014-July/016078.html
http://lists.freedesktop.org/archives/wayland-devel/2014-July/016224.html
http://lists.freedesktop.org/archives/wayland-devel/2014-August/016269.html)

To summarize : the idea behing xdg_surface_present() is that there are
some cases where a surface wants to advertise the fact that it has been
updated and the user may want to take a look (think of an IRC chat window
which gets new messages containing the user's nickname). There are even
some corner cases where the surface may want to be raised and focused
directly ; but we do not want to request to be abused this way, a client
must be prevented from stealing the focus repeatedly. At last, the
compositor's shell should have the last word.

Here are some of the points that were discussed and the outcomes :

- Pekka Paalanen pointed out the request name was unclear and suggested to
use xdg_surface_needs/wants_attention() instead. Jasper St. Pierre
pointed out that _NET_WM_STATE_DEMANDS_ATTENTION already existed in X11
and does not do the same thing. We discussed that again yesterday and
thought that present() fitted nicely ;

- We want to implement focus stealing prevention : if the user is starting
a slow app (browser...), gets back to typing a mail while it starts, and at
last the browser window appears, the focus should stay in the mail window
without his keyboard presses going elsewhere ;

- Implementing focus stealing prevention between different clients may be
easy : just count the delay between the client has been started and its
shell surface actually gets mapped, and if it has been too long and the
focus is elsewhere, show the surface without focusing it (but with a
notification). The notion of the client has been started is vague, but at
worst, we can use the time when the client did its initial connection to
the compositor ;

- Within a same client application, however, it is harder. Think of a
browser where you click new window but lots of time pass before it
appears. The starting point is the pointer click event. So the idea would
be to pass the Wayland serial corresponding to this event :
xdg_surface_present (surface, SERIAL). It the serial has been issued
too long ago, do focus stealing prevention.

This raises the question : how do we say We have no serial to pass, for
the standard case ? We repeatedly suggested 0 (xdg_surface_present
(surface, 0)) because serials are incrementing globals, so 0 to be
issued would be very-very unlikely. Should we formalize that somewhere in
the protocol ?

(Having 2 requests, one with serial and one without, has been suggested by
krh on IRC ; I personally prefer only one request because they would serve
the same purpose, but why not ? It would get the need for formalization out
of the way)

We also want to secure the request from garbage random serials ; the
implementation behavior is that there is only one serial valid for a few
seconds, if the surface has not been focused for some time, it will not be
able to raise itself even if it random()ly finds the formerly good serial.

-
Now the demos ! Here is the latest code :

https://github.com/Tarnyko/weston-xdg_surface_present/commits/test

A video for the generic focus stealing prevention case (delayed start,
focus stays in old surface) between different clients :

https://www.youtube.com/watch?v=gifjXyPV3X4

and within the same client :

https://www.youtube.com/watch?v=Xiq1p5AOf1U
-

Any thoughts on this ?

-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Wayland1.5]Question about wl_shell_get_shell_surface

[Manuel Bachmann]

Hi Andy, Pekka,

I think the question is more about the ICO Homescreen
(ico-uxf-homescreen package under Tizen IVI) which is an extension for
the Weston ivi-shell. ICO itself is outside of the scope of the Wayland
project.


Here is what I know (I am not an ICO developer, so if you are, feel free to
correct me) :

ICO was developed at a time where IVI-Shell was not finalized nor
upstreamed, and there was litlle support for it in Wayland client
applications. Instead, these apps supported the standard wl_shell
inteface.

So, in order to display these apps on screen, it had a hack which
reimplemented some of the wl_shell  calls they used.

Here is a ICO source file which contains reference to wl_shell, e.g.
https://review.tizen.org/git/?p=profile/ivi/ico-uxf-weston-plugin.git;a=blob;f=src/ico_window_mgr.c


About the reasons why it may be slow, or other problems, I don't have a
clue though

Hope it helps.

Regards,
Manuel Bachmann


2015-02-26 11:50 GMT+01:00 Pekka Paalanen ppaala...@gmail.com:

 On Thu, 26 Feb 2015 09:04:25 +
 Yang Andy williamyan...@hotmail.com wrote:

  Hi everyone
 
  I have a question about wl_shell_get_shell_surface.
 
  【ＮＧ Issue】When system launch QT-Application from ICO-HOME screen,it
 takes 4 seconds before application is rendered.
 
  [Reference Module]ICO-HOMEMurphyweston-ivi-shellweston/waylandQTWayland
  【TizenIVI Version】
  tizen-3.0.m14.3-ivi_20141028.3
 
  【Investigation】
   I analyze the ivi_shell.log and find that
 method[wl_shell_get_shell_surface] is called before it takes 3 seconds.
 
  Why it takes 3 seconds until method[wl_shell_get_shell_surface] is
 called?
 
  who will call
 wl_shell_get_shell_surface?Compositor-wayland.c?Multi-resource.c?Window.c?
  (I search the application/QTWayland source code,there is not caller)

 I have no idea what you are doing, but ivi-shell does not implement
 wl_shell at all. There is no global advertised with the name
 wl_shell, which you can see with e.g. weston-info. Therefore a call to
 wl_shell_get_shell_surface() should lead to a crash, abort, or a fatal
 protocol error.

 wl_shell protocol does not make sense in an IVI environment.


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




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: weston rdp crash on arm

[Manuel Bachmann]

Hi Raphael,

You are using a rather old version of Weston (1.7.0 was just released).
Considered upgrading the software ?

Anyways, I remember pretty well that when 1.5.0 was around, latest FreeRDP
master did not work.
Here is the git commit that we were using in Tizen back then :

2604ff20bd12e810cfeed735b80dbe90020d781c

I hope it helps.

2015-02-16 17:55 GMT+01:00 Raphael Cotty r.co...@cascade-technologies.com:

  I am trying to run the rdp backend on a proprietary board (arm / zynq).
 I am using yocto build system, wayland 1.5.0, freerdp (latest master).

 weston crashes just after the connection (using remmina from a Ubuntu PC).

 [20:08:40.921] weston 1.5.0
http://wayland.freedesktop.org/
Bug reports to:
 https://bugs.freedesktop.org/enter_bug.cgi?product=Waylandcomponent=westonversion=1.5.0
Build: 1.4.93 configure.ac: Bump version 1.4.93
 (2014-05-12 12:51:52 -0700)
 [20:08:40.922] OS: Linux, 3.6.0-xilinx-00014-gc78d9cf, #56 SMP PREEMPT Fri
 Mar 28 18:09:55 GMT 2014, armv7l
 [20:08:40.923] Starting with no config file.
 [20:08:40.923] Loading module '/usr/lib/weston/rdp-backend.so'
 [20:08:40.957] using FreeRDP version 1.2.1
 [20:08:40:141] [2444:-1224888320] [INFO][com.freerdp.core.listener] -
 Listening on 0.0.0.0:3389
 [20:08:40:143] [2444:-1224888320] [ERROR][com.freerdp.core.listener] -
 socket
 [20:08:40.964] Loading module '/usr/lib/weston/desktop-shell.so'
 [20:08:40.965] Compositor capabilities:
arbitrary surface rotation: yes
screen capture uses y-flip: yes
 [20:08:40.981] launching '/usr/lib/weston/weston-desktop-shell'
 [154264.319]  - wl_display@1.get_registry(new id wl_registry@2)
 [154264.868] wl_display@1.get_registry(new id wl_registry@2)
 ...
 [154458.246] wl_display@1.delete_id(16)
 [154458.492] wl_display@1.delete_id(24)
 [154458.624] wl_display@1.delete_id(20)
 [154458.776] wl_display@1.delete_id(23)
 [154458.908] wl_display@1.delete_id(19)
 [154459.040] wl_surface@13.enter(wl_output@11)
 [154459.286] wl_surface@14.enter(wl_output@11)
 [154459.418] wl_callb...@23.done(2396746158)
 [154459.607] wl_callb...@19.done(2396746158)
 [20:08:47.702] caught signal: 11
 [160979.659]  - wl_surface@15.destroy()
 [160979.791]  - wl_surface@14.destroy()
 [160979.848]  - wl_buffer@22.destroy()
 Trace/breakpoint trap
 root@cascade-zynq7:~# [160982.305]  - wl_shm_pool@21.destroy()
 [160982.494]  - wl_surface@13.destroy()
 [160982.588]  - wl_buffer@18.destroy()
 [160982.872]  - wl_shm_pool@17.destroy()
 [160983.061]  - wl_shm_pool@10.destroy()
 [160983.250]  - wl_subcompositor@4.destroy()

 Is there a way to enable the freerdp logs?



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




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 1/2] desktop-shell: remove dead unminimization code

[Manuel Bachmann]

From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

The set_minimized(surface, 0) function call was never
used anywhere, and not really respecting naming
conventions.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 desktop-shell/shell.c |   33 ++---
 1 file changed, 10 insertions(+), 23 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index f28fc10..5900c4d 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2637,7 +2637,7 @@ unset_maximized(struct shell_surface *shsurf)
 }
 
 static void
-set_minimized(struct weston_surface *surface, uint32_t is_true)
+set_minimized(struct weston_surface *surface)
 {
struct shell_surface *shsurf;
struct workspace *current_ws;
@@ -2655,31 +2655,18 @@ set_minimized(struct weston_surface *surface, uint32_t 
is_true)
current_ws = get_current_workspace(shsurf-shell);
 
weston_layer_entry_remove(view-layer_link);
-/* hide or show, depending on the state */
-   if (is_true) {
-   
weston_layer_entry_insert(shsurf-shell-minimized_layer.view_list, 
view-layer_link);
-
-   drop_focus_state(shsurf-shell, current_ws, view-surface);
-   wl_list_for_each(seat, shsurf-shell-compositor-seat_list, 
link) {
-   if (!seat-keyboard)
-   continue;
-   focus = 
weston_surface_get_main_surface(seat-keyboard-focus);
-   if (focus == view-surface)
-   weston_keyboard_set_focus(seat-keyboard, NULL);
-   }
-   }
-   else {
-   weston_layer_entry_insert(current_ws-layer.view_list, 
view-layer_link);
+   weston_layer_entry_insert(shsurf-shell-minimized_layer.view_list, 
view-layer_link);
 
-   wl_list_for_each(seat, shsurf-shell-compositor-seat_list, 
link) {
-   if (!seat-keyboard)
-   continue;
-   activate(shsurf-shell, view-surface, seat, true);
-   }
+   drop_focus_state(shsurf-shell, current_ws, view-surface);
+   wl_list_for_each(seat, shsurf-shell-compositor-seat_list, link) {
+   if (!seat-keyboard)
+   continue;
+   focus = weston_surface_get_main_surface(seat-keyboard-focus);
+   if (focus == view-surface)
+   weston_keyboard_set_focus(seat-keyboard, NULL);
}
 
shell_surface_update_child_surface_layers(shsurf);
-
weston_view_damage_below(view);
 }
 
@@ -3876,7 +3863,7 @@ xdg_surface_set_minimized(struct wl_client *client,
return;
 
 /* apply compositor's own minimization logic (hide) */
-   set_minimized(shsurf-surface, 1);
+   set_minimized(shsurf-surface);
 }
 
 static const struct xdg_surface_interface xdg_surface_implementation = {
-- 
1.7.10.4

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

[PATCH weston 2/2] desktop-shell: fix minimization of fullscreen surfaces, pointer focus

[Manuel Bachmann]

From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

2 things were wrong with the minimization code :
- if the minimized surface was fullscreen, the shell would keep
  its fullscreen mode on and only display a black background ;
- keyboard focus was unset, but pointer focus was not.

On the other hand, make sure a fullscreen surface gets centered
again when refocused with Mod+Tab.

Author: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
Author: Nicolas Guyomard nicolas.guyom...@open.eurogiciel.org
Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 desktop-shell/shell.c |   16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 5900c4d..830c25d 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2657,13 +2657,20 @@ set_minimized(struct weston_surface *surface)
weston_layer_entry_remove(view-layer_link);
weston_layer_entry_insert(shsurf-shell-minimized_layer.view_list, 
view-layer_link);
 
+   if (shsurf-state.fullscreen)
+   unset_fullscreen(shsurf);
+
drop_focus_state(shsurf-shell, current_ws, view-surface);
wl_list_for_each(seat, shsurf-shell-compositor-seat_list, link) {
if (!seat-keyboard)
continue;
focus = weston_surface_get_main_surface(seat-keyboard-focus);
-   if (focus == view-surface)
+   if (focus == view-surface) {
weston_keyboard_set_focus(seat-keyboard, NULL);
+   weston_pointer_set_focus(seat-pointer, NULL,
+wl_fixed_from_int(0),
+wl_fixed_from_int(0));
+   }
}
 
shell_surface_update_child_surface_layers(shsurf);
@@ -5937,8 +5944,11 @@ switcher_next(struct switcher *switcher)
view-alpha = 1.0;
 
shsurf = get_shell_surface(switcher-current);
-   if (shsurf  shsurf-state.fullscreen)
-   shsurf-fullscreen.black_view-alpha = 1.0;
+   if (shsurf  shsurf-state.fullscreen) {
+   center_on_output(shsurf-view, shsurf-fullscreen_output);
+   if (shsurf-fullscreen.black_view)
+   shsurf-fullscreen.black_view-alpha = 1.0;
+   }
 }
 
 static void
-- 
1.7.10.4

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

[PATCH] build: do not install ivi-shell png files with --disable-ivi-shell

[Manuel Bachmann]

From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org

Some of the .png files are specific to ivi-shell. Avoid installing
them to $prefix/share/weston if ivi-shell has explicitly been
disabled at configure time.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 Makefile.am |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 1864b70..32e8b0b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -688,7 +688,10 @@ dist_westondata_DATA = \
data/icon_window.png\
data/sign_close.png \
data/sign_maximize.png  \
-   data/sign_minimize.png  \
+   data/sign_minimize.png
+
+if ENABLE_IVI_SHELL
+dist_westondata_DATA +=\
data/background.png \
data/tiling.png \
data/fullscreen.png \
@@ -701,6 +704,7 @@ dist_westondata_DATA =  \
data/icon_ivi_simple-egl.png\
data/icon_ivi_simple-shm.png\
data/icon_ivi_smoke.png
+endif
 
 
 if BUILD_WCAP_TOOLS
-- 
1.7.10.4

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

Re: [PATCH weston] shell: fix various interactions with the minimized state

[Manuel Bachmann]

Hi Giulio,

Sorry for the late answer, I happen to be very busy lately.

 How do you test that? Did you have to craft an ad-hoc client?

Yes ;  you will find the client I use at this URL :
http://www.tarnyko.net/repo/wayland-9b-xdg_shell_150.zip (run ./build.sh
to compile).
If you then start the client, go fullscreen with the last upper-right
square (black) and then minimize with the upper-left square (light gray),
you will notice the client disappears and screen goes totally black. The
patch fixes that (in a good manner, hopefully).

 There seems to be a bug still. If I mod+tab away from a fullscreen client
into a windowed one and release the mod key, then pressing
mod+tab again doesn't go back to the fullscreen client, i have to  press
tab two times.

Oops ; I definitely have to try this. Thanks for letting me know !

Regards,
Manuel


2014-09-03 20:45 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com:

 2014-07-31 16:36 GMT+03:00 Manuel Bachmann
 manuel.bachm...@open.eurogiciel.org:
  This fixes the following :
  - if a surface was set fullscreen, and then minimized,
  the fullscreen compositor state would stay on and display
  a black screen ;

 How do you test that? Did you have to craft an ad-hoc client?

  - if a surface was set fullscreen, and we would then
  cycle between surfaces (with Mod+Tab e.g.), the fullscreen
  compositor state would stay on, and the fullscreen layer
  would sometimes hide surfaces positioned behind it ;

 There seems to be a bug still. If I mod+tab away from a fullscreen
 client into a windowed one and release the mod key, then pressing
 mod+tab again doesn't go back to the fullscreen client, i have to
 press tab two times.

  - style and functional polishing, remove dead code.

 The rest looks good to me.


 --
 Giulio


 
  Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
  ---
   desktop-shell/shell.c |   67
 -
   1 file changed, 38 insertions(+), 29 deletions(-)
 
  diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
  index 3c3649c..60639cc 100644
  --- a/desktop-shell/shell.c
  +++ b/desktop-shell/shell.c
  @@ -2510,13 +2510,14 @@ unset_maximized(struct shell_surface *shsurf)
   }
 
   static void
  -set_minimized(struct weston_surface *surface, uint32_t is_true)
  +set_minimized(struct weston_surface *surface)
   {
  +   struct weston_view *view;
  struct shell_surface *shsurf;
  -   struct workspace *current_ws;
  +   struct workspace *ws;
  struct weston_seat *seat;
  struct weston_surface *focus;
  -   struct weston_view *view;
  +   float x,y;
 
  view = get_default_view(surface);
  if (!view)
  @@ -2525,34 +2526,31 @@ set_minimized(struct weston_surface *surface,
 uint32_t is_true)
  assert(weston_surface_get_main_surface(view-surface) ==
 view-surface);
 
  shsurf = get_shell_surface(surface);
  -   current_ws = get_current_workspace(shsurf-shell);
  +   ws = get_current_workspace(shsurf-shell);
 
  -   weston_layer_entry_remove(view-layer_link);
  -/* hide or show, depending on the state */
  -   if (is_true) {
  -
  weston_layer_entry_insert(shsurf-shell-minimized_layer.view_list,
 view-layer_link);
  -
  -   drop_focus_state(shsurf-shell, current_ws,
 view-surface);
  -   wl_list_for_each(seat,
 shsurf-shell-compositor-seat_list, link) {
  -   if (!seat-keyboard)
  -   continue;
  -   focus =
 weston_surface_get_main_surface(seat-keyboard-focus);
  -   if (focus == view-surface)
  -
  weston_keyboard_set_focus(seat-keyboard, NULL);
  -   }
  +   /* if the surface is fullscreen, unset the global fullscreen
 state,
  +* but keep the surface centered on its previous output.
  +*/
  +   if (shsurf-state.fullscreen) {
  +   x = shsurf-view-geometry.x;
  +   y = shsurf-view-geometry.y;
  +   unset_fullscreen(shsurf);
  +   weston_view_set_position(shsurf-view, x, y);
  }
  -   else {
  -   weston_layer_entry_insert(current_ws-layer.view_list,
 view-layer_link);
 
  -   wl_list_for_each(seat,
 shsurf-shell-compositor-seat_list, link) {
  -   if (!seat-keyboard)
  -   continue;
  -   activate(shsurf-shell, view-surface, seat,
 true);
  -   }
  +   weston_layer_entry_remove(view-layer_link);
  +
  weston_layer_entry_insert(shsurf-shell-minimized_layer.view_list,
 view-layer_link);
  +
  +   drop_focus_state(shsurf-shell, ws, view-surface);
  +   wl_list_for_each(seat, shsurf-shell-compositor-seat_list,
 link) {
  +   if (!seat-keyboard)
  +   continue;
  +   focus =
 weston_surface_get_main_surface(seat-keyboard-focus

Re: [PATCH 1/1] build: handle special characters when building from git

[Manuel Bachmann]

Hi Pekka and thanks for the review,

Hmm strange, wasn't what I observed when I submitted the patch, will look
at that and let you know.


2014-08-15 15:33 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:

 On Wed, 30 Jul 2014 00:28:52 +0200
 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:

  When building from a git repository, in Makefile.am, the
  macro creating the src/git-version.h file will fail
  if the last commit subject contains a special character
  such as . Escape characters so that the output string
  is, at worst, empty.
 
  Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
  ---
   Makefile.am |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/Makefile.am b/Makefile.am
  index 191dcc9..68f4d18 100644
  --- a/Makefile.am
  +++ b/Makefile.am
  @@ -112,7 +112,7 @@ endif
 
   if HAVE_GIT_REPO
   src/git-version.h : $(top_srcdir)/.git/logs/HEAD
  - $(AM_V_GEN)echo #define BUILD_ID \$(shell git
 --git-dir=$(top_srcdir)/.git describe --always --dirty) $(shell git
 --git-dir=$(top_srcdir)/.git log -1 --format='%s (%ci)')\  $@
  + $(AM_V_GEN)echo #define BUILD_ID \${(shell git
 --git-dir=$(top_srcdir)/.git describe --always --dirty)} ${(shell git
 --git-dir=$(top_srcdir)/.git log -1 --format='%s (%ci)')}\  $@
   else
   src/git-version.h :
$(AM_V_GEN)echo #define BUILD_ID \unknown (not built from git or
 tarball)\  $@

 For me, this just makes the BUILD_ID always empty, even without any
 funny characters.


 Thanks,
 pq




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [LookForHelp]A10S/ARM Weston-launch failed‏

[Manuel Bachmann]

Hi Andy,

It looks like Weston is trying to use its DRM backend (which is the
default) to initialize the GPU, but is not finding the device or driver.
You can verify this by doing $ ls /dev/dri/. If the folder is empty, or
does not exist, it means you do not have a DRM driver for your GPU.

If your GPU has framebuffer support, you can try this as root :
$ weston --backend=fbdev-backend.so

More generally, ARM boards support is tricky, because their GPUs have
specific and sometimes closed drivers. Raspberry PI is a notable exception
(for the support).

Regards.


2014-08-08 9:56 GMT+02:00 Yang Andy williamyan...@hotmail.com:

 Hi everyone

 I have some questions for help.

 When i run weston-launch command in TizeIVI,it echo below error
 information.

 I investigation weston source code and find that it seems to fail to find
 gup device.

 1.In order to setup wayland/weston in arm device,is there any necessary
 thing to be done?

 2.Is there any requirement for Hardware / Drivers?

 3.Is DRM  must for weston(compositor),how to setup DRM?

 4.In order to run weston-launch,do i have to use gpu?

 [Error Information]
 Aug 07 12:19:26 ivi_box weston-launch[264]: [12:19:26.243] Using config
 file '/etc/xdg/weston/weston.ini'
 Aug 07 12:19:26 ivi_box weston-launch[264]: [12:19:26.243] Loading module
 '/usr/lib/weston/drm-backend.so'
 Aug 07 12:19:26 ivi_box weston-launch[264]: [12:19:26.244] initializing
 drm backend
 Aug 07 12:19:26 ivi_box weston-launch[264]: [12:19:26.244] no drm device
 found

 [target device]
 A10S ARM


 Best regards.

 Andy

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




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Question] Z-order management in Wayland

[Manuel Bachmann]

Yan,

gl comes from the mesa package, but has been disabled in the pure wayland
profile (libGL.so pulls libX11.so). My guess is that your gbs'
build.conf is not correct or up-to-date, as gl only appears if the %with
x macro is defined, while it is not in recent config files.  So you likely
have the good repo but a bad config file.

As this discussion is more Tizen-specific than Wayland-specific, would you
mind that we go further with private email, or -better- in the Tizen-IVI
maling list (i...@lists.tizen.org) ?

Regards,


2014-08-01 4:59 GMT+02:00 yan.w...@linux.intel.com:

 Sure. We Tizen IVI tried 20140704.2 image and found this macro is enabled.
 But when we tried to build efl by GBS, we get the following error:

 efl:
   nothing provides pkgconfig(gl)

 We are looking for the cause.

 Yan Wang


  Hi Yan,
 
  And I am not sure whether USE_XDG_SHELL macro is enabled in current
  Tizen upstream.
 
  It is enabled by default. If you download a sufficiently recent snapshot
  of
  Tizen Common or IVI (I recommend from 2014/06/20 so you can have Weston
  1.5.0), and click on the Minimize button of a random EFL application,
 it
  will in fact minimize the window with xdg_surface_set_minimized(). It
 is
  a good way to check if this macro was enabled.
 
  Regards,
 
 
  2014-07-31 10:57 GMT+02:00 yan.w...@linux.intel.com:
 
  Hi, Carsten,
Thanks for your comments.
I check efl code and I found
  _ecore_wl_window_cb_xdg_surface_active/deactivate is empty.
As your comments, we should add code into them and pop related Ecore
  event out. Is it right?
I could also find ecore_wl_window_raise() in ecore_wl_window.c. It
  shouldn't be used?
And I am not sure whether USE_XDG_SHELL macro is enabled in current
  Tizen upstream.
 
  Yan Wang
 
   On Thu, 31 Jul 2014 01:02:33 -0700 (PDT) yan.w...@linux.intel.com
  said:
  
   E.g. When we start a new application on mobile platform, previous
  running
   application could be hidden and paused to reduce power consuming and
  improve response speed. If we could adjust and get z-order status, we
   could callback application to sleep. And when user restart this
  application, we could just make this slept app waked up.
  
   you do NOT want to do this by raise/lower. even doing this in x11 is
  just
   WRONG. in fact a good mobile wm setup would refuse to allow this.
  there
  is
   a
   netwm request netwm activate. this requests the window is activated.
  this MAY
   raise the window. it may switch desktop. it may de-iconify a window.
  it
  may
   also place focus on the window... unless the wm decides that this is a
  bad
   idea
   right now.
  
   you do NOT want a raise/lower etc. in wayland. you want xdg shell and
  an
  activate request. the compositor after that decides what is best to do.
  
   Yan Wang
There is currently no way to influence the stacking order of
  top-level
surfaces. Why do you need this?
On Jul 31, 2014 9:28 AM, yan.w...@linux.intel.com wrote:
   
Hi, All,
   I found X provides raise/lower APIs to manger window Z-order.
  But
there
isn't related APIs in Wayland/Weston.
   May it should be one design idea of Wayland in fact or I could
achieve
this  by current Wayland protocol?
   Thanks.
   
Yan Wang
___
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
  
  
   --
   - Codito, ergo sum - I code, therefore I am
  --
  The Rasterman (Carsten Haitzler)ras...@rasterman.com
  
  
 
 
 
  ___
  wayland-devel mailing list
  wayland-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/wayland-devel
 
 
 
 
  --
  Regards,
 
 
 
  *Manuel BACHMANN Tizen Project VANNES-FR*
 




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: RFC : xdg_surface_present() look-and-feel and implementation

[Manuel Bachmann]

Hello everybody,

I just updated the repo today (
https://github.com/Tarnyko/weston-xdg_surface_present/commit/0aca29d4b6dbe10d5237aaf5f35f72d25db3ac30).
The xdg_surface_present() request not accepts a timestamp (uint32_t type)
as an additional parameter.

If different of 0, and it is the first time the surface should be shown,
the shell will check if a significant amount of time passed between this
timestamp and the actual present() request, and it it did, will show a
notification instead of directly mapping the surface.

You can see a demo here (1st case immediate, 2nd case delayed) :
https://www.youtube.com/watch?v=IDa2W_xMg10

The implementation is still pretty naive, but I will improve it with the
following considerations :
- if any of the application surfaces focused, or not ;
- are we on the same workspace ;
- etc.

Interested in your feedback on the protocol definition especially.


2014-07-30 0:00 GMT+02:00 Manuel Bachmann 
manuel.bachm...@open.eurogiciel.org:

 Hi Jasper, Jason,

 Agreed. Especially if you start an application, but it's slow to start,
 and you have typed into the current window or have navigated away from it
 since, you should get a popup instead of the window immediately mapped.
 This is known as focus stealing prevention.

 Good point. I will work on this.
 Unfortunately, the protocol as Manuel mocked up doesn't have the event
 timestamp. This is required so we can track when the surface was intended
 to be presented.

 Have to get familiar with timestamps, looking for some useful code right
 now.

 Another question for Manuel: Does present() interact with the surface
 commit? Should it?

 Not in a way that I know of. From a compositor point of view, present()
 (when the user interacts to show) does only change the surface worskpace,
 stacking order, and focus. I doesn't trigger a commit, or at least it's
 unwanted. I think it can be compared to what happens when you cycle through
 windows with Mod-Tab and choose one.


 2014-07-29 23:11 GMT+02:00 Jason Ekstrand ja...@jlekstrand.net:




 On Tue, Jul 29, 2014 at 12:16 PM, Bill Spitzak spit...@gmail.com wrote:

 On 07/29/2014 11:40 AM, Manuel Bachmann wrote:

  When creating a xdg_surface, the surface will not be mapped (i.e. shown)
 by desktop-shell anymore. It will only be if xdg_surface_present() has
 been called once.


 There seems to be a design goal in Wayland to prevent clients from
 making surfaces that they never map. So it would be better if creation +
 commit of a surface did the same thing as present. Also this does not break
 existing clients.


 That's the way it has worked in the past.  There's nothing requiring this
 behavior in xdg_shell as we haven't stabilized it fully yet.  Really, it
 doesn't matter whether the client has to call an additional request beyond
 just creating the xdg_surface.

 Another question for Manuel: Does present() interact with the surface
 commit?  Should it?



 There is nothing special about the first time the surface wants
 attention (other than historical legacy). The desktop should be allowed to
 turn this into a notification just like it would on subsequent calls.


 True.  We shouldn't claim to guarantee any window showing up behavior
 on the first or subsequent calls.



  If called twice, or more, the request will send an event to
 desktop-shell, so it can display a notification.


 This is not controlled by a count, but by whether a window is already
 visible or already in the notification state. Clients should be able to
 send a lot of these in a row. They cannot reliably test if they are
 invisible and send the request only then, as there is a race condition.


 Yes, talking about it in terms of a count is a bad plan.


 I also think the term present is not a great idea. This should be
 exactly the same as raise or show or activate or any number of other
 terms, but I have never seen the word present used before. I would reuse
 an existing term. One reason is to prevent somebody else from adding a
 redundant api for that term, because they did not realize present is the
 thing they are looking for.


 We also discussed the name attention.  The reason why we didn't go with
 raise or show is that it implies a specific action on the part of the
 compositor, namely showing the user the window.  The term activate is
 used for something else in xdg_shell so that one's out too.

 --Jason Ekstrand


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




 --
 Regards,



 *Manuel BACHMANN Tizen Project VANNES-FR*




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] shell: fix various interactions with the minimized state

[Manuel Bachmann]

This fixes the following :
- if a surface was set fullscreen, and then minimized,
the fullscreen compositor state would stay on and display
a black screen ;
- if a surface was set fullscreen, and we would then
cycle between surfaces (with Mod+Tab e.g.), the fullscreen
compositor state would stay on, and the fullscreen layer
would sometimes hide surfaces positioned behind it ;
- style and functional polishing, remove dead code.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 desktop-shell/shell.c |   67 -
 1 file changed, 38 insertions(+), 29 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 3c3649c..60639cc 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2510,13 +2510,14 @@ unset_maximized(struct shell_surface *shsurf)
 }
 
 static void
-set_minimized(struct weston_surface *surface, uint32_t is_true)
+set_minimized(struct weston_surface *surface)
 {
+   struct weston_view *view;
struct shell_surface *shsurf;
-   struct workspace *current_ws;
+   struct workspace *ws;
struct weston_seat *seat;
struct weston_surface *focus;
-   struct weston_view *view;
+   float x,y;
 
view = get_default_view(surface);
if (!view)
@@ -2525,34 +2526,31 @@ set_minimized(struct weston_surface *surface, uint32_t 
is_true)
assert(weston_surface_get_main_surface(view-surface) == view-surface);
 
shsurf = get_shell_surface(surface);
-   current_ws = get_current_workspace(shsurf-shell);
+   ws = get_current_workspace(shsurf-shell);
 
-   weston_layer_entry_remove(view-layer_link);
-/* hide or show, depending on the state */
-   if (is_true) {
-   
weston_layer_entry_insert(shsurf-shell-minimized_layer.view_list, 
view-layer_link);
-
-   drop_focus_state(shsurf-shell, current_ws, view-surface);
-   wl_list_for_each(seat, shsurf-shell-compositor-seat_list, 
link) {
-   if (!seat-keyboard)
-   continue;
-   focus = 
weston_surface_get_main_surface(seat-keyboard-focus);
-   if (focus == view-surface)
-   weston_keyboard_set_focus(seat-keyboard, NULL);
-   }
+   /* if the surface is fullscreen, unset the global fullscreen state,
+* but keep the surface centered on its previous output.
+*/
+   if (shsurf-state.fullscreen) {
+   x = shsurf-view-geometry.x;
+   y = shsurf-view-geometry.y;
+   unset_fullscreen(shsurf);
+   weston_view_set_position(shsurf-view, x, y);
}
-   else {
-   weston_layer_entry_insert(current_ws-layer.view_list, 
view-layer_link);
 
-   wl_list_for_each(seat, shsurf-shell-compositor-seat_list, 
link) {
-   if (!seat-keyboard)
-   continue;
-   activate(shsurf-shell, view-surface, seat, true);
-   }
+   weston_layer_entry_remove(view-layer_link);
+   weston_layer_entry_insert(shsurf-shell-minimized_layer.view_list, 
view-layer_link);
+
+   drop_focus_state(shsurf-shell, ws, view-surface);
+   wl_list_for_each(seat, shsurf-shell-compositor-seat_list, link) {
+   if (!seat-keyboard)
+   continue;
+   focus = weston_surface_get_main_surface(seat-keyboard-focus);
+   if (focus == view-surface)
+   weston_keyboard_set_focus(seat-keyboard, NULL);
}
 
shell_surface_update_child_surface_layers(shsurf);
-
weston_view_damage_below(view);
 }
 
@@ -3534,8 +3532,7 @@ xdg_surface_set_minimized(struct wl_client *client,
if (shsurf-type != SHELL_SURFACE_TOPLEVEL)
return;
 
-/* apply compositor's own minimization logic (hide) */
-   set_minimized(shsurf-surface, 1);
+   set_minimized(shsurf-surface);
 }
 
 static const struct xdg_surface_interface xdg_surface_implementation = {
@@ -5444,12 +5441,24 @@ struct switcher {
 static void
 switcher_next(struct switcher *switcher)
 {
+   struct focus_state *state;
+   struct weston_surface *surface;
struct weston_view *view;
struct weston_surface *first = NULL, *prev = NULL, *next = NULL;
struct shell_surface *shsurf;
struct workspace *ws = get_current_workspace(switcher-shell);
 
-/* temporary re-display minimized surfaces */
+   /* if the focused surface is fullscreen, minimize it */
+   wl_list_for_each(state, ws-focus_list, link) {
+   if (state-keyboard_focus) {
+   surface = 
weston_surface_get_main_surface(state-keyboard_focus);
+   shsurf = get_shell_surface(surface);
+   if (shsurf-state.fullscreen

RFC : xdg_surface_present() look-and-feel and implementation

[Manuel Bachmann]

Hi folks,

(This post follows a discussion which I will link at the end of the mail :
*)

I have been working on an implementation of xdg_surface_present() for some
time now ; here is a proposal with working code.

When creating a xdg_surface, the surface will not be mapped (i.e. shown) by
desktop-shell anymore. It will only be if xdg_surface_present() has been
called once.

If called twice, or more, the request will send an event to desktop-shell,
so it can display a notification. A red tooltip with the title of the
xdg_surface (xdg_surface_set_title()) will then appear on the right side of
the top panel. (Tooltips will stack from right to left. They won't hide the
launchers, although invisible tooltips really exist and will appear if
they get sufficient space).

When clicked, the tooltip will disappear, and the corresponding xdg_surface
is moved to the current workspace + put in foreground. (the tooltip also
ceases to exist if the shell surface is destroyed by any means).

Here is a video : http://www.youtube.com/watch?v=eI4Stmx9B54

The code can be found at
https://github.com/Tarnyko/weston-xdg_surface_present. The test branch
has the modifications to weston-simple-damage which will lead you the test
case (run weston-simple-damage --verbose).

Would like some feedback on both the look-and-feel and the implementation
**. Thanks !


* :
http://lists.freedesktop.org/archives/wayland-devel/2014-July/016078.html

** main changes : new desktop_shell_add_managed_surface event and
managed_surface interface in desktop-shell.xml, new panel_notifier
widget, helper functions.
-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: RFC : xdg_surface_present() look-and-feel and implementation

[Manuel Bachmann]

Hi Bill,

This is not controlled by a count, but by whether a window is already
visible or already in the notification state. Clients should be able to
send a lot of these in a row. They cannot reliably test if they are
invisible and send the request only then, as there is a race condition.

Thanks a lot for that ; your remark made me find a bug in my
implementation, effectively when a surface was shown via a notification
(i.e. tooltip), subsequent present() request would not re-create the
notification. This is bad.

Now fixed here :
https://github.com/Tarnyko/weston-xdg_surface_present/commit/4265ab36f644d2663bf14d4b0d42fb8bcb6ca6f7

Regards,


2014-07-29 21:16 GMT+02:00 Bill Spitzak spit...@gmail.com:

 On 07/29/2014 11:40 AM, Manuel Bachmann wrote:

  When creating a xdg_surface, the surface will not be mapped (i.e. shown)
 by desktop-shell anymore. It will only be if xdg_surface_present() has
 been called once.


 There seems to be a design goal in Wayland to prevent clients from making
 surfaces that they never map. So it would be better if creation + commit of
 a surface did the same thing as present. Also this does not break existing
 clients.

 There is nothing special about the first time the surface wants attention
 (other than historical legacy). The desktop should be allowed to turn this
 into a notification just like it would on subsequent calls.


  If called twice, or more, the request will send an event to
 desktop-shell, so it can display a notification.


 This is not controlled by a count, but by whether a window is already
 visible or already in the notification state. Clients should be able to
 send a lot of these in a row. They cannot reliably test if they are
 invisible and send the request only then, as there is a race condition.

 I also think the term present is not a great idea. This should be
 exactly the same as raise or show or activate or any number of other
 terms, but I have never seen the word present used before. I would reuse
 an existing term. One reason is to prevent somebody else from adding a
 redundant api for that term, because they did not realize present is the
 thing they are looking for.
 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: RFC : xdg_surface_present() look-and-feel and implementation

[Manuel Bachmann]

Hi Jasper, Jason,

Agreed. Especially if you start an application, but it's slow to start,
and you have typed into the current window or have navigated away from it
since, you should get a popup instead of the window immediately mapped.
This is known as focus stealing prevention.

Good point. I will work on this.
Unfortunately, the protocol as Manuel mocked up doesn't have the event
timestamp. This is required so we can track when the surface was intended
to be presented.

Have to get familiar with timestamps, looking for some useful code right
now.

Another question for Manuel: Does present() interact with the surface
commit? Should it?

Not in a way that I know of. From a compositor point of view, present()
(when the user interacts to show) does only change the surface worskpace,
stacking order, and focus. I doesn't trigger a commit, or at least it's
unwanted. I think it can be compared to what happens when you cycle through
windows with Mod-Tab and choose one.


2014-07-29 23:11 GMT+02:00 Jason Ekstrand ja...@jlekstrand.net:




 On Tue, Jul 29, 2014 at 12:16 PM, Bill Spitzak spit...@gmail.com wrote:

 On 07/29/2014 11:40 AM, Manuel Bachmann wrote:

  When creating a xdg_surface, the surface will not be mapped (i.e. shown)
 by desktop-shell anymore. It will only be if xdg_surface_present() has
 been called once.


 There seems to be a design goal in Wayland to prevent clients from making
 surfaces that they never map. So it would be better if creation + commit of
 a surface did the same thing as present. Also this does not break existing
 clients.


 That's the way it has worked in the past.  There's nothing requiring this
 behavior in xdg_shell as we haven't stabilized it fully yet.  Really, it
 doesn't matter whether the client has to call an additional request beyond
 just creating the xdg_surface.

 Another question for Manuel: Does present() interact with the surface
 commit?  Should it?



 There is nothing special about the first time the surface wants attention
 (other than historical legacy). The desktop should be allowed to turn this
 into a notification just like it would on subsequent calls.


 True.  We shouldn't claim to guarantee any window showing up behavior on
 the first or subsequent calls.



  If called twice, or more, the request will send an event to
 desktop-shell, so it can display a notification.


 This is not controlled by a count, but by whether a window is already
 visible or already in the notification state. Clients should be able to
 send a lot of these in a row. They cannot reliably test if they are
 invisible and send the request only then, as there is a race condition.


 Yes, talking about it in terms of a count is a bad plan.


 I also think the term present is not a great idea. This should be
 exactly the same as raise or show or activate or any number of other
 terms, but I have never seen the word present used before. I would reuse
 an existing term. One reason is to prevent somebody else from adding a
 redundant api for that term, because they did not realize present is the
 thing they are looking for.


 We also discussed the name attention.  The reason why we didn't go with
 raise or show is that it implies a specific action on the part of the
 compositor, namely showing the user the window.  The term activate is
 used for something else in xdg_shell so that one's out too.

 --Jason Ekstrand


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




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/1] build: handle special characters when building from git

[Manuel Bachmann]

When building from a git repository, in Makefile.am, the
macro creating the src/git-version.h file will fail
if the last commit subject contains a special character
such as . Escape characters so that the output string
is, at worst, empty.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 Makefile.am |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 191dcc9..68f4d18 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -112,7 +112,7 @@ endif
 
 if HAVE_GIT_REPO
 src/git-version.h : $(top_srcdir)/.git/logs/HEAD
-   $(AM_V_GEN)echo #define BUILD_ID \$(shell git 
--git-dir=$(top_srcdir)/.git describe --always --dirty) $(shell git 
--git-dir=$(top_srcdir)/.git log -1 --format='%s (%ci)')\  $@
+   $(AM_V_GEN)echo #define BUILD_ID \${(shell git 
--git-dir=$(top_srcdir)/.git describe --always --dirty)} ${(shell git 
--git-dir=$(top_srcdir)/.git log -1 --format='%s (%ci)')}\  $@
 else
 src/git-version.h :
$(AM_V_GEN)echo #define BUILD_ID \unknown (not built from git or 
tarball)\  $@
-- 
1.7.10.4

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

Re: Fwd: [PATCH weston] xdg-shell: Make stable

[Manuel Bachmann]

Hi everybody, and thanks Phillippe for reacting to this topic,

Yes, we under Tizen are using xdg-shell for some of the great features it
has, and doing the integration in applications and toolkits such
Ozone-Wayland, Qt, EFL...

We were recently challenged by a feature needed in the Web runtime, which
is resuming an application by making it visible again.
Currently, we use xdg_shell_set_minimized() to hide it. There is no
corresponding reverse function though, so we have been hacking by
destroying and recreating xdg_surfaces, but it is at best

Having a xdg_surface_unset_minimized() request would really solve this
issue.

I'm attaching the WIP patch implementing this. And here is a video of a
client-side implementation, here switching apps :
https://www.youtube.com/watch?v=Kn7mxUUD2B0

Looking forward for your feedback, Jasper and everyone interested !




2014-07-18 13:33 GMT+02:00 Philippe Coval 
philippe.co...@open.eurogiciel.org:


 We've gone through enough churn of xdg-shell that we're now feeling
 confident enough to commit to this much. Let's do it.


 Ok good news, I guess you're want to gather some feedback
 before it lands into next release

 As a qtwayland developer it seems ok for us
 (note current master branch is aligned to latest release wl-1.5)
 may giucam confirm too,
 I'll probably upgrade to 1.6 soon or later...


 But as mentionned in

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

 We at Tizen feels the unset_minimized request is missing
 (may it be part of the states enum too ?)


 If we compare to maximize both are there :

request name=set_maximized /
request name=unset_maximized /


 While there is only :

request name=set_minimized /


 Would it make sense to add this one :

request name=unset_minimized /


 I supose it's not there because there is no real need,
 but it wasnt intentional please confirm ?

 We can share some patches if it maters.

 To be tracked here and at  :

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


 Regards


 --
  mailto:philippe.co...@eurogiciel.fr  --  gpg:0x467094BC
  xmpp:philippe.coval@gmail.com
  https://dockr.eurogiciel.fr/blogs/embedded/author/pcl/
.




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
From 20f6daf2bc40bbd9f8d2271a7840fd0bc4d2f658 Mon Sep 17 00:00:00 2001
From: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
Date: Wed, 16 Jul 2014 03:29:50 +0200
Subject: [PATCH] shell: support a new xdg_shell_unset_minimized() function

Clients can now unminimize themselves. They will be shown in the
foreground when doing so.

Change-Id: I5b42f2f179d8efeb198bfc5a58a9119b0cc25253
Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 desktop-shell/shell.c  | 16 +++-
 protocol/xdg-shell.xml |  8 +++-
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 4eef849..9b44c62 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -3515,6 +3515,19 @@ xdg_surface_set_minimized(struct wl_client *client,
 	set_minimized(shsurf-surface, 1);
 }
 
+static void
+xdg_surface_unset_minimized(struct wl_client *client,
+struct wl_resource *resource)
+{
+struct shell_surface *shsurf = wl_resource_get_user_data(resource);
+
+if (shsurf-type != SHELL_SURFACE_TOPLEVEL)
+return;
+
+ /* apply compositor's own unminimization logic (unhide) */
+set_minimized(shsurf-surface, 0);
+}
+
 static const struct xdg_surface_interface xdg_surface_implementation = {
 	xdg_surface_destroy,
 	xdg_surface_set_transient_for,
@@ -3526,7 +3539,8 @@ static const struct xdg_surface_interface xdg_surface_implementation = {
 	xdg_surface_set_output,
 	xdg_surface_request_change_state,
 	xdg_surface_ack_change_state,
-	xdg_surface_set_minimized
+	xdg_surface_set_minimized,
+	xdg_surface_unset_minimized
 };
 
 static void
diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
index 79a2831..741d458 100644
--- a/protocol/xdg-shell.xml
+++ b/protocol/xdg-shell.xml
@@ -357,11 +357,17 @@
 /request
 
 request name=set_minimized
-  description summary=minimize the surface
+  description summary=set the surface state as minimized
 Minimize the surface.
   /description
 /request
 
+request name=unset_minimized
+  description summary=unset the surface state as minimized
+Unminimize the surface.
+  /description
+/request
+
 event name=activated
   description summary=surface was activated
 	The activated_set event is sent when this surface has been
-- 
1.8.1.4

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

Weston IVI-Shell GitHub repo

[Manuel Bachmann]

Hi folks,

This is about the IVI-Shell patches, which are provided and frequently
updated by TANIBATA Nabuhiko, the main developer and maintainer of the
IVI-Shell project.

Just to act as a reminder, IVI-Shell is providing a Weston shell interface,
linked to the GENIVI API which targets In-Vehicle Infotainment systems
(1)..

And as a reminder too, here is a previous patch set (2).
--
I have setup a GitHub repo, which is basically a copy of the weston repo,
but with the IVI patches applied :
https://github.com/Tarnyko/weston-ivi-shell .

There is only one branch currently (weston150_ivi-shell, which is 1.5.0
release) but I will create a master_ivi-shell which will follow master
with the latest updates.

So with this repo, testing the latest IVI-Shell code will only be a matter
of fetching and rebuilding.

(here is what it looks like currently : (3))

Hope it helps !

(1) : http://www.genivi.org/
(2) :
http://lists.freedesktop.org/archives/wayland-devel/2014-June/015617.html
(3) : http://www.tarnyko.net/repo/weston-ivi-shell.png
-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston IVI-Shell GitHub repo

[Manuel Bachmann]

You are very welcome, Nabuhiko !

So, regarding the GitHub repo, looks like I managed to do it as promised.

Here is what has just been done :

- the homepage (https://github.com/Tarnyko/weston-ivi-shell/) now displays
an introduction, screenshot, and quick installation procedure ;

- the latest IVI-Shell v6 patches have been merged in a new branch
(weston150_ivi-shell_v6) which is now the default ;

- the v6 patches have been rebased for latest master in a new branch
(master_ivi-shell_v6). Beware, I needed to adapt the last 9/9 slightly
(look at 
https://github.com/Tarnyko/weston-ivi-shell/commit/b7fc0e251129a245da7a176aebdb106ef65c5940#diff-f75861e3924903672183c98007852192R370;,
the fullscreen part). Plus, it doesn't build, but vanilla master does not
build either, so I guess we are not guilty.

Regards,


2014-07-09 11:41 GMT+02:00 Tanibata, Nobuhiko (ADITJ/SWG) 
ntanib...@jp.adit-jv.com:

 Hi Manuel,



 Thank you very much for supporting!



 (3) : http://www.tarnyko.net/repo/weston-ivi-shell.png


 http://lists.freedesktop.org/archives/wayland-devel/attachments/20140625/abbfc064/attachment-0001.png



 The above png might be helpful for what it looks like currently.



 BR,

 ntanibata



 *From:* wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org]
 *On Behalf Of *Manuel Bachmann
 *Sent:* Wednesday, July 09, 2014 4:47 PM
 *To:* wayland-devel@lists.freedesktop.org
 *Subject:* Weston IVI-Shell GitHub repo



 Hi folks,

 This is about the IVI-Shell patches, which are provided and frequently
 updated by TANIBATA Nabuhiko, the main developer and maintainer of the
 IVI-Shell project.

 Just to act as a reminder, IVI-Shell is providing a Weston shell
 interface, linked to the GENIVI API which targets In-Vehicle Infotainment
 systems  (1)..


 And as a reminder too, here is a previous patch set (2).
 --

 I have setup a GitHub repo, which is basically a copy of the weston repo,
 but with the IVI patches applied :
 https://github.com/Tarnyko/weston-ivi-shell .

 There is only one branch currently (weston150_ivi-shell, which is 1.5.0
 release) but I will create a master_ivi-shell which will follow master
 with the latest updates.

 So with this repo, testing the latest IVI-Shell code will only be a matter
 of fetching and rebuilding.



 (here is what it looks like currently : (3))

 Hope it helps !


 (1) : http://www.genivi.org/
 (2) :
 http://lists.freedesktop.org/archives/wayland-devel/2014-June/015617.html
 (3) : http://www.tarnyko.net/repo/weston-ivi-shell.png
 --

 Regards,

 *Manuel BACHMANN*

 *Tizen ProjectVANNES-FR*




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: DE-components (Re: Window placement)

[Manuel Bachmann]

 The second point is not related to this topic, so we can probably
   think of
 it later.



   
This reminds me of a something similar[1] that comes with the Wacom
drivers on Windows and Mac. Its not a normal application that you
would open, interact with, (possibly switch away from temporarily),
and close. Rather, the application sits in the background and waits
for some button/mouse/hotkey to be pressed before spawning a window
under the mouse that you interact with for only a moment before
returning to your original task.
  
   Right, though on a quick glimpse on that video without really
   understanding what's going on there, the circular menu seems more like
   belonging to the image processing application.
  
   Fabrice's example OTOH is obviously a DE component, as it is a
   launcher, window control, and stuff.
  
I do not mean to put words into Pekka's mouth, but I believe what he
means when saying that things like this are a DE-component he's
speaking conceptually more than anything else. Alternative menu
systems like this and desklets essentially exist to augment the
desktop itself. Just because they can be written in a DE-agnostic
manner and run on GNOME, KDE, or TWM (all hail xeyes?) doesn't change
that. They have fundamentally different needs than the average
application, and -- at least as far as I understand Wayland -- it
makes sense to leave some of these things up to the desktops to
define.
  
   Quite right. Defining a generic protocol (designed from above, a
   little like the core Wayland protocol has been done) for adding DE
   components like pagers, task bars, launcher systems, window management
   thingies, desklets, etc. is so far an explicit non-goal.
  
   On Wayland, desktop environments are intended to be much more tightly
   integrated than on X11. We are not planning to intentionally design
   support for custom desktop environment arrangements where you pick the
   window manager from here, pager from there, a 3rd party task bar, and
   then a few desklets all from different other DEs. Yes, you can say it
 is
   a loss for the people who like to build their own DE from various
   pieces (I'm one of them, but mostly just because I can't bother
   learning anything else). However, it should be a great win in
   freedom of design, stability and usablity for the seriously developed
   DEs used by the masses.
  
   Every DE has its own thing for DE components already. Inventing yet
   another way that doesn't really fit well for any DE and forcing
   everyone to support that is not a good plan. Some components in some
   DEs could be not programs but plugins, some may talk via dbus rather
   than the display protocol, and so on.
  
   Instead, we are trying to allow DEs to define their own interfaces for
   these DE components, and if there actually emerges some common
   interfaces that could be standardised, then we can look into it.
   One hope is, that one DE starts to use a public interface for some DE
   components, some other DE finds it good and starts using it too, and so
   it slowly becomes a standard. Note, that nothing requires the
   standard protocol to be part of the display (Wayland) protocol.
  
   Unfortunately such organic, cooperative protocol design does not really
   work for the core protocol that all applications will depend on, and
   that's why we have and are centrally designing the Wayland core
   protocols and xdg_shell. We cannot really test much without a stable
   core protocol, and we cannot be sure the core protocol is good until it
   is put into serious use; we also have already been bitten by this
   chicken-and-egg problem.
  
  
   Thanks,
   pq
  
[1]: https://www.youtube.com/watch?v=McJMnMJydes
   
Jason
  
 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston-ivi-shell v5 7/9] data: add reference image files for weston-ivi-shell-user-interface

[Manuel Bachmann]

Hello Tanibata-San,

I think your forget to include the changes to Makefile.am in this series.
What is more, as Weston has now a unique Makefile.am in the root directory

I modified the patch this way :

--- a/Makefile.am
+++ b/Makefile.am
@@ -638,7 +638,19 @@ dist_westondata_DATA = \
data/icon_window.png\
data/sign_close.png \
data/sign_maximize.png  \
-   data/sign_minimize.png
+   data/sign_minimize.png  \
+   data/background.png \
+   data/tiling.png \
+   data/fullscreen.png \
+   data/panel.png  \
+   data/random.png \
+   data/sidebyside.png \
+   data/home.png   \
+   data/icon_ivi_clickdot.png  \
+   data/icon_ivi_flower.png\
+   data/icon_ivi_simple-egl.png\
+   data/icon_ivi_simple-shm.png\
+   data/icon_ivi_smoke.png

Hope this helps !

Regards,


2014-05-20 6:35 GMT+02:00 Nobuhiko Tanibata 
nobuhiko_tanib...@xddp.denso.co.jp:

 Hi,

 I removed binary from patch as review comment.
 Image files can be downloaded from,
 https://github.com/ntanibata/weston-ivi-shell/tree/weston-
 ivi-shell-1.4.93-v3/data

 BR,
 Nobuhiko

 2014-05-20 13:30 に Nobuhiko Tanibata さんは書きました:

  Signed-off-by: Nobuhiko Tanibata nobuhiko_tanib...@xddp.denso.co.jp
 ---

 Changes for v2:
  - squash Makefile to this patch

 Changes for v3, v4, and v5:
  - nothing. Version number aligned to the first patch

  data/Makefile.am |  14 +-
  data/background.png  | Bin 0 - 245579 bytes
  data/fullscreen.png  | Bin 0 - 3406 bytes
  data/home.png| Bin 0 - 4629 bytes
  data/icon_ivi_clickdot.png   | Bin 0 - 39523 bytes
  data/icon_ivi_flower.png | Bin 0 - 24475 bytes
  data/icon_ivi_simple-egl.png | Bin 0 - 29316 bytes
  data/icon_ivi_simple-shm.png | Bin 0 - 71120 bytes
  data/icon_ivi_smoke.png  | Bin 0 - 46577 bytes
  data/panel.png   | Bin 0 - 41955 bytes
  data/random.png  | Bin 0 - 4891 bytes
  data/sidebyside.png  | Bin 0 - 3929 bytes
  data/tiling.png  | Bin 0 - 5620 bytes
  13 files changed, 13 insertions(+), 1 deletion(-)
  create mode 100644 data/background.png
  create mode 100644 data/fullscreen.png
  create mode 100644 data/home.png
  create mode 100644 data/icon_ivi_clickdot.png
  create mode 100644 data/icon_ivi_flower.png
  create mode 100644 data/icon_ivi_simple-egl.png
  create mode 100644 data/icon_ivi_simple-shm.png
  create mode 100644 data/icon_ivi_smoke.png
  create mode 100644 data/panel.png
  create mode 100644 data/random.png
  create mode 100644 data/sidebyside.png
  create mode 100644 data/tiling.png

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




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] screen-share: Allow fullscreen shell command to be configured

[Manuel Bachmann]

-share]
 +command=@bindir@/weston --backend=rdp-backend.so
 --shell=fullscreen-shell.so --no-clients-resize
 --
 1.9.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




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] editor: react on Enter, Tab, and Up-Down arrow keys

[Manuel Bachmann]

Hi Bill,

 It looks like the text actually has the bytes Enter at the newlines,
rather than, say, a '\n'?

In fact, it is '\r' (carriage return) rather than '\n' (new line). In
renders correctly with Pango, though, and would paste gracefully to other
clients such as weston-terminal.

The only problem would be if we made weston-terminal save its text buffer
directly to a file, in which case most text editors would display an
uninterpreted special character. Note that we do not do that yet, though.

Regards,
Manuel




2014-04-21 21:49 GMT+02:00 Bill Spitzak spit...@gmail.com:

  It looks like the text actually has the bytes Enter at the newlines,
 rather than, say, a '\n'?


 On 04/18/2014 03:52 AM, Manuel Bachmann wrote:

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

  Regards,
 Manuel


 2014-04-18 12:50 GMT+02:00 Manuel Bachmann 
 manuel.bachm...@open.eurogiciel.org:

 The editor will now insert new lines and tabulations when
 pressing the corresponding keys on the virtual keyboard.

 The Up and Down arrows can be used to navigate through
 lines.

 Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
 ---
  clients/editor.c |   97
 --
  1 file changed, 87 insertions(+), 10 deletions(-)

 diff --git a/clients/editor.c b/clients/editor.c
 index 76e2346..4c5c427 100644
 --- a/clients/editor.c
 +++ b/clients/editor.c
 @@ -110,6 +110,47 @@ utf8_next_char(const char *p)
 return NULL;
  }

 +static void
 +move_up(const char *p, uint32_t *cursor)
 +{
 +   const char *posr, *posr_i;
 +   char text[16];
 +
 +   xkb_keysym_to_utf8(XKB_KEY_Return, text, sizeof(text));
 +
 +   posr = strstr(p, text);
 +   while (posr) {
 +   if (*cursor  (unsigned)(posr-p)) {
 +   posr_i = strstr(posr+1, text);
 +   if (!posr_i || !(*cursor  (unsigned)(posr_i-p)))
 {
 +   *cursor = posr-p;
 +   break;
 +   }
 +   posr = posr_i;
 +   } else {
 +   break;
 +   }
 +   }
 +}
 +
 +static void
 +move_down(const char *p, uint32_t *cursor)
 +{
 +   const char *posr;
 +   char text[16];
 +
 +   xkb_keysym_to_utf8(XKB_KEY_Return, text, sizeof(text));
 +
 +   posr = strstr(p, text);
 +   while (posr) {
 +   if (*cursor = (unsigned)(posr-p)) {
 +   *cursor = posr-p + 1;
 +   break;
 +   }
 +   posr = strstr(posr+1, text);
 +   }
 +}
 +
  static void text_entry_redraw_handler(struct widget *widget, void *data);
  static void text_entry_button_handler(struct widget *widget,
   struct input *input, uint32_t time,
 @@ -374,6 +415,23 @@ text_input_keysym(void *data,
 return;
 }

 +   if (key == XKB_KEY_Up ||
 +   key == XKB_KEY_Down) {
 +   if (state != WL_KEYBOARD_KEY_STATE_RELEASED)
 +   return;
 +
 +   if (key == XKB_KEY_Up)
 +   move_up(entry-text, entry-cursor);
 +   else
 +   move_down(entry-text, entry-cursor);
 +
 +   if (!(modifiers  entry-keysym.shift_mask))
 +   entry-anchor = entry-cursor;
 +   widget_schedule_redraw(entry-widget);
 +
 +   return;
 +   }
 +
 if (key == XKB_KEY_BackSpace) {
 const char *start, *end;

 @@ -395,17 +453,20 @@ text_input_keysym(void *data,
 return;
 }

 -   switch (key) {
 -   case XKB_KEY_Tab:
 -   key_label = Tab;
 -   break;
 -   case XKB_KEY_KP_Enter:
 -   case XKB_KEY_Return:
 -   key_label = Enter;
 -   break;
 -   }
 +   if (key == XKB_KEY_Tab ||
 +   key == XKB_KEY_KP_Enter ||
 +   key == XKB_KEY_Return) {
 +   char text[16];
 +
 +   if (state != WL_KEYBOARD_KEY_STATE_RELEASED)
 +   return;
 +
 +   xkb_keysym_to_utf8(key, text, sizeof(text));

 -   fprintf(stderr, %s key was %s.\n, key_label, state_label);
 +   text_entry_insert_at_cursor(entry, text, 0, 0);
 +
 +   return;
 +   }
  }

  static void
 @@ -1208,6 +1269,22 @@ key_handler(struct window *window,
 widget_schedule_redraw(entry-widget);
 }
 break;
 +   case XKB_KEY_Up:
 +   text_entry_commit_and_reset(entry);
 +
 +   move_up(entry-text, entry-cursor);
 +   if (!(input_get_modifiers(input) 
 MOD_SHIFT_MASK))
 +   entry-anchor = entry-cursor

[PATCH] editor: react on Enter, Tab, and Up-Down arrow keys

[Manuel Bachmann]

The editor will now insert new lines and tabulations when
pressing the corresponding keys on the virtual keyboard.

The Up and Down arrows can be used to navigate through
lines.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 clients/editor.c |   97 --
 1 file changed, 87 insertions(+), 10 deletions(-)

diff --git a/clients/editor.c b/clients/editor.c
index 76e2346..4c5c427 100644
--- a/clients/editor.c
+++ b/clients/editor.c
@@ -110,6 +110,47 @@ utf8_next_char(const char *p)
return NULL;
 }
 
+static void
+move_up(const char *p, uint32_t *cursor)
+{
+   const char *posr, *posr_i;
+   char text[16];
+
+   xkb_keysym_to_utf8(XKB_KEY_Return, text, sizeof(text));
+
+   posr = strstr(p, text);
+   while (posr) {
+   if (*cursor  (unsigned)(posr-p)) {
+   posr_i = strstr(posr+1, text);
+   if (!posr_i || !(*cursor  (unsigned)(posr_i-p))) {
+   *cursor = posr-p;
+   break;
+   }
+   posr = posr_i;
+   } else {
+   break;  
+   }
+   }
+}
+
+static void
+move_down(const char *p, uint32_t *cursor)
+{
+   const char *posr;
+   char text[16];
+
+   xkb_keysym_to_utf8(XKB_KEY_Return, text, sizeof(text));
+
+   posr = strstr(p, text);
+   while (posr) {
+   if (*cursor = (unsigned)(posr-p)) {
+   *cursor = posr-p + 1;
+   break;
+   }
+   posr = strstr(posr+1, text);
+   }
+}
+
 static void text_entry_redraw_handler(struct widget *widget, void *data);
 static void text_entry_button_handler(struct widget *widget,
  struct input *input, uint32_t time,
@@ -374,6 +415,23 @@ text_input_keysym(void *data,
return;
}
 
+   if (key == XKB_KEY_Up ||
+   key == XKB_KEY_Down) {
+   if (state != WL_KEYBOARD_KEY_STATE_RELEASED)
+   return;
+
+   if (key == XKB_KEY_Up)
+   move_up(entry-text, entry-cursor);
+   else
+   move_down(entry-text, entry-cursor);
+
+   if (!(modifiers  entry-keysym.shift_mask))
+   entry-anchor = entry-cursor;
+   widget_schedule_redraw(entry-widget);
+
+   return;
+   }
+
if (key == XKB_KEY_BackSpace) {
const char *start, *end;
 
@@ -395,17 +453,20 @@ text_input_keysym(void *data,
return;
}
 
-   switch (key) {
-   case XKB_KEY_Tab:
-   key_label = Tab;
-   break;
-   case XKB_KEY_KP_Enter:
-   case XKB_KEY_Return:
-   key_label = Enter;
-   break;
-   }
+   if (key == XKB_KEY_Tab ||
+   key == XKB_KEY_KP_Enter ||
+   key == XKB_KEY_Return) {
+   char text[16];
+
+   if (state != WL_KEYBOARD_KEY_STATE_RELEASED)
+   return;
+
+   xkb_keysym_to_utf8(key, text, sizeof(text));
 
-   fprintf(stderr, %s key was %s.\n, key_label, state_label);
+   text_entry_insert_at_cursor(entry, text, 0, 0);
+
+   return;
+   }
 }
 
 static void
@@ -1208,6 +1269,22 @@ key_handler(struct window *window,
widget_schedule_redraw(entry-widget);
}
break;
+   case XKB_KEY_Up:
+   text_entry_commit_and_reset(entry);
+
+   move_up(entry-text, entry-cursor);
+   if (!(input_get_modifiers(input)  MOD_SHIFT_MASK))
+   entry-anchor = entry-cursor;
+   widget_schedule_redraw(entry-widget);
+   break;
+   case XKB_KEY_Down:
+   text_entry_commit_and_reset(entry);
+
+   move_down(entry-text, entry-cursor);
+   if (!(input_get_modifiers(input)  MOD_SHIFT_MASK))
+   entry-anchor = entry-cursor;
+   widget_schedule_redraw(entry-widget);
+   break;
case XKB_KEY_Escape:
break;
default:
-- 
1.7.10.4

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

Re: [PATCH] editor: react on Enter, Tab, and Up-Down arrow keys

[Manuel Bachmann]

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

Regards,
Manuel


2014-04-18 12:50 GMT+02:00 Manuel Bachmann 
manuel.bachm...@open.eurogiciel.org:

 The editor will now insert new lines and tabulations when
 pressing the corresponding keys on the virtual keyboard.

 The Up and Down arrows can be used to navigate through
 lines.

 Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
 ---
  clients/editor.c |   97
 --
  1 file changed, 87 insertions(+), 10 deletions(-)

 diff --git a/clients/editor.c b/clients/editor.c
 index 76e2346..4c5c427 100644
 --- a/clients/editor.c
 +++ b/clients/editor.c
 @@ -110,6 +110,47 @@ utf8_next_char(const char *p)
 return NULL;
  }

 +static void
 +move_up(const char *p, uint32_t *cursor)
 +{
 +   const char *posr, *posr_i;
 +   char text[16];
 +
 +   xkb_keysym_to_utf8(XKB_KEY_Return, text, sizeof(text));
 +
 +   posr = strstr(p, text);
 +   while (posr) {
 +   if (*cursor  (unsigned)(posr-p)) {
 +   posr_i = strstr(posr+1, text);
 +   if (!posr_i || !(*cursor  (unsigned)(posr_i-p))) {
 +   *cursor = posr-p;
 +   break;
 +   }
 +   posr = posr_i;
 +   } else {
 +   break;
 +   }
 +   }
 +}
 +
 +static void
 +move_down(const char *p, uint32_t *cursor)
 +{
 +   const char *posr;
 +   char text[16];
 +
 +   xkb_keysym_to_utf8(XKB_KEY_Return, text, sizeof(text));
 +
 +   posr = strstr(p, text);
 +   while (posr) {
 +   if (*cursor = (unsigned)(posr-p)) {
 +   *cursor = posr-p + 1;
 +   break;
 +   }
 +   posr = strstr(posr+1, text);
 +   }
 +}
 +
  static void text_entry_redraw_handler(struct widget *widget, void *data);
  static void text_entry_button_handler(struct widget *widget,
   struct input *input, uint32_t time,
 @@ -374,6 +415,23 @@ text_input_keysym(void *data,
 return;
 }

 +   if (key == XKB_KEY_Up ||
 +   key == XKB_KEY_Down) {
 +   if (state != WL_KEYBOARD_KEY_STATE_RELEASED)
 +   return;
 +
 +   if (key == XKB_KEY_Up)
 +   move_up(entry-text, entry-cursor);
 +   else
 +   move_down(entry-text, entry-cursor);
 +
 +   if (!(modifiers  entry-keysym.shift_mask))
 +   entry-anchor = entry-cursor;
 +   widget_schedule_redraw(entry-widget);
 +
 +   return;
 +   }
 +
 if (key == XKB_KEY_BackSpace) {
 const char *start, *end;

 @@ -395,17 +453,20 @@ text_input_keysym(void *data,
 return;
 }

 -   switch (key) {
 -   case XKB_KEY_Tab:
 -   key_label = Tab;
 -   break;
 -   case XKB_KEY_KP_Enter:
 -   case XKB_KEY_Return:
 -   key_label = Enter;
 -   break;
 -   }
 +   if (key == XKB_KEY_Tab ||
 +   key == XKB_KEY_KP_Enter ||
 +   key == XKB_KEY_Return) {
 +   char text[16];
 +
 +   if (state != WL_KEYBOARD_KEY_STATE_RELEASED)
 +   return;
 +
 +   xkb_keysym_to_utf8(key, text, sizeof(text));

 -   fprintf(stderr, %s key was %s.\n, key_label, state_label);
 +   text_entry_insert_at_cursor(entry, text, 0, 0);
 +
 +   return;
 +   }
  }

  static void
 @@ -1208,6 +1269,22 @@ key_handler(struct window *window,
 widget_schedule_redraw(entry-widget);
 }
 break;
 +   case XKB_KEY_Up:
 +   text_entry_commit_and_reset(entry);
 +
 +   move_up(entry-text, entry-cursor);
 +   if (!(input_get_modifiers(input)  MOD_SHIFT_MASK))
 +   entry-anchor = entry-cursor;
 +   widget_schedule_redraw(entry-widget);
 +   break;
 +   case XKB_KEY_Down:
 +   text_entry_commit_and_reset(entry);
 +
 +   move_down(entry-text, entry-cursor);
 +   if (!(input_get_modifiers(input)  MOD_SHIFT_MASK))
 +   entry-anchor = entry-cursor;
 +   widget_schedule_redraw(entry-widget);
 +   break;
 case XKB_KEY_Escape:
 break;
 default:
 --
 1.7.10.4




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel

[PATCH] shell: display the input panel on the active output

[Manuel Bachmann]

We now dynamically move the input panel (i.e. virtual
keyboard) surface to the output containing the currently
focused surface.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 desktop-shell/input-panel.c |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/desktop-shell/input-panel.c b/desktop-shell/input-panel.c
index 12fe686..d5e7d71 100644
--- a/desktop-shell/input-panel.c
+++ b/desktop-shell/input-panel.c
@@ -54,6 +54,9 @@ show_input_panels(struct wl_listener *listener, void *data)
container_of(listener, struct desktop_shell,
 show_input_panel_listener);
struct input_panel_surface *ipsurf, *next;
+   struct weston_seat *seat;
+   struct weston_surface *focus;
+   float x, y;
 
shell-text_input.surface = (struct weston_surface*)data;
 
@@ -70,6 +73,17 @@ show_input_panels(struct wl_listener *listener, void *data)
  shell-input_panel.surfaces, link) {
if (ipsurf-surface-width == 0)
continue;
+
+   wl_list_for_each(seat, shell-compositor-seat_list, link) {
+   if (!seat-keyboard)
+   continue;
+   focus = 
weston_surface_get_main_surface(seat-keyboard-focus);
+   ipsurf-output = focus-output;
+   x = ipsurf-output-x + (ipsurf-output-width - 
ipsurf-surface-width) / 2;
+   y = ipsurf-output-y + ipsurf-output-height - 
ipsurf-surface-height;
+   weston_view_set_position(ipsurf-view, x, y);
+   }
+
wl_list_insert(shell-input_panel_layer.view_list,
   ipsurf-view-layer_link);
weston_view_geometry_dirty(ipsurf-view);
-- 
1.7.10.4

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

Re: [PATCH] shell: display the input panel on the active output

[Manuel Bachmann]

This patch fixes :

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

Regards,
Manuel


2014-04-17 14:04 GMT+02:00 Manuel Bachmann 
manuel.bachm...@open.eurogiciel.org:

 We now dynamically move the input panel (i.e. virtual
 keyboard) surface to the output containing the currently
 focused surface.

 Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
 ---
  desktop-shell/input-panel.c |   14 ++
  1 file changed, 14 insertions(+)

 diff --git a/desktop-shell/input-panel.c b/desktop-shell/input-panel.c
 index 12fe686..d5e7d71 100644
 --- a/desktop-shell/input-panel.c
 +++ b/desktop-shell/input-panel.c
 @@ -54,6 +54,9 @@ show_input_panels(struct wl_listener *listener, void
 *data)
 container_of(listener, struct desktop_shell,
  show_input_panel_listener);
 struct input_panel_surface *ipsurf, *next;
 +   struct weston_seat *seat;
 +   struct weston_surface *focus;
 +   float x, y;

 shell-text_input.surface = (struct weston_surface*)data;

 @@ -70,6 +73,17 @@ show_input_panels(struct wl_listener *listener, void
 *data)
   shell-input_panel.surfaces, link) {
 if (ipsurf-surface-width == 0)
 continue;
 +
 +   wl_list_for_each(seat, shell-compositor-seat_list,
 link) {
 +   if (!seat-keyboard)
 +   continue;
 +   focus =
 weston_surface_get_main_surface(seat-keyboard-focus);
 +   ipsurf-output = focus-output;
 +   x = ipsurf-output-x + (ipsurf-output-width -
 ipsurf-surface-width) / 2;
 +   y = ipsurf-output-y + ipsurf-output-height -
 ipsurf-surface-height;
 +   weston_view_set_position(ipsurf-view, x, y);
 +   }
 +
 wl_list_insert(shell-input_panel_layer.view_list,
ipsurf-view-layer_link);
 weston_view_geometry_dirty(ipsurf-view);
 --
 1.7.10.4




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] keyboard: add the missing symbols layout, fix arabic layout

[Manuel Bachmann]

The symbols modifier key of weston-keyboard is no longer
inactive, but will provide an additionnal layout with
numerals and special characters.

Fix the Arabic keyboard, which was rendering out of the
bounds, and now use the Arabic IBM PC keyboard as a
reference for its standard and new symbols layouts.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 clients/keyboard.c |  280 +---
 1 file changed, 159 insertions(+), 121 deletions(-)

diff --git a/clients/keyboard.c b/clients/keyboard.c
index 11fe21d..cd1ad58 100644
--- a/clients/keyboard.c
+++ b/clients/keyboard.c
@@ -75,7 +75,8 @@ struct key {
enum key_type key_type;
 
char *label;
-   char *alt;
+   char *uppercase;
+   char *symbol;
 
unsigned int width;
 };
@@ -92,120 +93,119 @@ struct layout {
 };
 
 static const struct key normal_keys[] = {
-   { keytype_default, q, Q, 1},
-   { keytype_default, w, W, 1},
-   { keytype_default, e, E, 1},
-   { keytype_default, r, R, 1},
-   { keytype_default, t, T, 1},
-   { keytype_default, y, Y, 1},
-   { keytype_default, u, U, 1},
-   { keytype_default, i, I, 1},
-   { keytype_default, o, O, 1},
-   { keytype_default, p, P, 1},
-   { keytype_backspace, --, --, 2},
-
-   { keytype_tab, -|, -|, 1},
-   { keytype_default, a, A, 1},
-   { keytype_default, s, S, 1},
-   { keytype_default, d, D, 1},
-   { keytype_default, f, F, 1},
-   { keytype_default, g, G, 1},
-   { keytype_default, h, H, 1},
-   { keytype_default, j, J, 1},
-   { keytype_default, k, K, 1},
-   { keytype_default, l, L, 1},
-   { keytype_enter, Enter, Enter, 2},
-
-   { keytype_switch, ABC, abc, 2},
-   { keytype_default, z, Z, 1},
-   { keytype_default, x, X, 1},
-   { keytype_default, c, C, 1},
-   { keytype_default, v, V, 1},
-   { keytype_default, b, B, 1},
-   { keytype_default, n, N, 1},
-   { keytype_default, m, M, 1},
-   { keytype_default, ,, ,, 1},
-   { keytype_default, ., ., 1},
-   { keytype_switch, ABC, abc, 1},
-
-   { keytype_symbols, ?123, ?123, 1},
-   { keytype_space, , , 5},
-   { keytype_arrow_up, /\\, /\\, 1},
-   { keytype_arrow_left, , , 1},
-   { keytype_arrow_right, , , 1},
-   { keytype_arrow_down, \\/, \\/, 1},
-   { keytype_style, , , 2}
+   { keytype_default, q, Q, 1, 1},
+   { keytype_default, w, W, 2, 1},
+   { keytype_default, e, E, 3, 1},
+   { keytype_default, r, R, 4, 1},
+   { keytype_default, t, T, 5, 1},
+   { keytype_default, y, Y, 6, 1},
+   { keytype_default, u, U, 7, 1},
+   { keytype_default, i, I, 8, 1},
+   { keytype_default, o, O, 9, 1},
+   { keytype_default, p, P, 0, 1},
+   { keytype_backspace, --, --, --, 2},
+
+   { keytype_tab, -|, -|, -|, 1},
+   { keytype_default, a, A, -, 1},
+   { keytype_default, s, S, @, 1},
+   { keytype_default, d, D, *, 1},
+   { keytype_default, f, F, ^, 1},
+   { keytype_default, g, G, :, 1},
+   { keytype_default, h, H, ;, 1},
+   { keytype_default, j, J, (, 1},
+   { keytype_default, k, K, ), 1},
+   { keytype_default, l, L, ~, 1},
+   { keytype_enter, Enter, Enter, Enter, 2},
+
+   { keytype_switch, ABC, abc, ABC, 2},
+   { keytype_default, z, Z, /, 1},
+   { keytype_default, x, X, \', 1},
+   { keytype_default, c, C, \, 1},
+   { keytype_default, v, V, +, 1},
+   { keytype_default, b, B, =, 1},
+   { keytype_default, n, N, ?, 1},
+   { keytype_default, m, M, !, 1},
+   { keytype_default, ,, ,, \\, 1},
+   { keytype_default, ., ., |, 1},
+   { keytype_switch, ABC, abc, ABC, 1},
+
+   { keytype_symbols, ?123, ?123, abc, 1},
+   { keytype_space, , , , 5},
+   { keytype_arrow_up, /\\, /\\, /\\, 1},
+   { keytype_arrow_left, , , , 1},
+   { keytype_arrow_right, , , , 1},
+   { keytype_arrow_down, \\/, \\/, \\/, 1},
+   { keytype_style, , , , 2}
 };
 
 static const struct key numeric_keys[] = {
-   { keytype_default, 1, 1, 1},
-   { keytype_default, 2, 2, 1},
-   { keytype_default, 3, 3, 1},
-   { keytype_default, 4, 4, 1},
-   { keytype_default, 5, 5, 1},
-   { keytype_default, 6, 6, 1},
-   { keytype_default, 7, 7, 1},
-   { keytype_default, 8, 8, 1},
-   { keytype_default, 9, 9, 1},
-   { keytype_default, 0, 0, 1},
-   { keytype_backspace, --, --, 2},
-
-   { keytype_space, , , 4},
-   { keytype_enter, Enter, Enter, 2},
-   { keytype_arrow_up, /\\, /\\, 1},
-   { keytype_arrow_left, , , 1},
-   { keytype_arrow_right, , , 1},
-   { keytype_arrow_down, \\/, \\/, 1},
-   { keytype_style, , , 2}
+   { keytype_default, 1, 1, 1, 1},
+   { keytype_default, 2, 2, 2, 1},
+   { keytype_default, 3, 3, 3, 1},
+   { keytype_default, 4, 4, 4, 1},
+   { keytype_default, 5

[PATCH] Fix on-the-fly transparency changes in pixman-renderer

[Manuel Bachmann]

This fixes :
- leaking the mask used to simulate transparency ;
- code style (definitions moved up, use of brackets) ;
- applying an opaque region when transparency is
 wanted (shound not happen).

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 src/pixman-renderer.c |   19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/src/pixman-renderer.c b/src/pixman-renderer.c
index eff7201..4ac4693 100644
--- a/src/pixman-renderer.c
+++ b/src/pixman-renderer.c
@@ -181,6 +181,8 @@ repaint_region(struct weston_view *ev, struct weston_output 
*output,
float view_x, view_y;
pixman_transform_t transform;
pixman_fixed_t fw, fh;
+   pixman_image_t *mask_image;
+   pixman_color_t mask;
 
/* The final region to be painted is the intersection of
 * 'region' and 'surf_region'. However, 'region' is in the global
@@ -340,12 +342,12 @@ repaint_region(struct weston_view *ev, struct 
weston_output *output,
if (ps-buffer_ref.buffer)
wl_shm_buffer_begin_access(ps-buffer_ref.buffer-shm_buffer);
 
-   pixman_image_t *mask_image;
if (ev-alpha  1.0) {
-   pixman_color_t mask = { 0x, 0x, 0x, 
0x*ev-alpha };
+   mask.alpha = 0x*ev-alpha;
mask_image = pixman_image_create_solid_fill(mask);
-   } else
+   } else {
mask_image = NULL;
+   }
 
pixman_image_composite32(pixman_op,
 ps-image, /* src */
@@ -357,6 +359,9 @@ repaint_region(struct weston_view *ev, struct weston_output 
*output,
 pixman_image_get_width (po-shadow_image), /* 
width */
 pixman_image_get_height (po-shadow_image) /* 
height */);
 
+   if (mask_image)
+   pixman_image_unref(mask_image);
+
if (ps-buffer_ref.buffer)
wl_shm_buffer_end_access(ps-buffer_ref.buffer-shm_buffer);
 
@@ -408,12 +413,14 @@ draw_view(struct weston_view *ev, struct weston_output 
*output,
ev-transform.matrix.type != WESTON_MATRIX_TRANSFORM_TRANSLATE) {
repaint_region(ev, output, repaint, NULL, PIXMAN_OP_OVER);
} else {
-   /* blended region is whole surface minus opaque region: */
+   /* blended region is whole surface minus opaque region, if not 
transparent: */
pixman_region32_init_rect(surface_blend, 0, 0,
  ev-surface-width, 
ev-surface-height);
-   pixman_region32_subtract(surface_blend, surface_blend, 
ev-surface-opaque);
+   if (ev-alpha == 1.0) {
+   pixman_region32_subtract(surface_blend, 
surface_blend, ev-surface-opaque);
+   }
 
-   if (pixman_region32_not_empty(ev-surface-opaque)) {
+   if ((ev-alpha == 1.0)  
pixman_region32_not_empty(ev-surface-opaque)) {
repaint_region(ev, output, repaint, 
ev-surface-opaque, PIXMAN_OP_SRC);
}
 
-- 
1.7.10.4

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

Re: [PATCH] Support on-the-fly transparency changes in pixman renderer

[Manuel Bachmann]

Hi Kristian,

Thanks a lot for your review !
You're totally right, I was leaking the mask (shame on me :-( ) and wasn't
totally consistent on the code style part.
I just submitted another patch, which should address most of our concerns :

http://lists.freedesktop.org/archives/wayland-devel/2014-April/014080.html

This fixes :
- the leak ;
- code style (added brackets, put definitions on top) ;

Additionally, this fixes the case of clients using an opaque surface
(weston-terminal e.g.) ; the surface was still computed when using
transparency, which would make them render an ugly black rectangle. The
patch now totally disables the opaque surface in this case.

For the window fade out animation, you're right, it doesn't happen ; I
think I saw the shell fade out and considered it should work everywhere.
Will address that.

Regards,
Manuel


2014-04-07 7:59 GMT+02:00 Kristian Høgsberg hoegsb...@gmail.com:

 On Sat, Apr 05, 2014 at 05:31:37AM +0200, Manuel Bachmann wrote:
  When the alpha channel of a surface is changed and the surface
  refreshed, pixman renderer will now apply a mask corresponding
  to the alpha channel value.
 
  This allows visual effects like shell fade in, shell fade out,
  window switching, to work when using pixman renderer.
 
  Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
  ---
   src/pixman-renderer.c |9 -
   1 file changed, 8 insertions(+), 1 deletion(-)
 
  diff --git a/src/pixman-renderer.c b/src/pixman-renderer.c
  index b999343..eff7201 100644
  --- a/src/pixman-renderer.c
  +++ b/src/pixman-renderer.c
  @@ -340,9 +340,16 @@ repaint_region(struct weston_view *ev, struct
 weston_output *output,
if (ps-buffer_ref.buffer)
 
 wl_shm_buffer_begin_access(ps-buffer_ref.buffer-shm_buffer);
 
  + pixman_image_t *mask_image;
  + if (ev-alpha  1.0) {
  + pixman_color_t mask = { 0x, 0x, 0x,
 0x*ev-alpha };
  + mask_image = pixman_image_create_solid_fill(mask);
  + } else
  + mask_image = NULL;

 I like this but it doesn't quite look right, it looks like the surface
 also fades
 from black.  I also doesn't see it trigger on the close window fade
 anmation.
 And stylistically, please don't mix code and declarations (move mask_image
 declartion up) and use braces for both branches (the rule is both or none).

pixman_image_composite32(pixman_op,
 ps-image, /* src */
  -  NULL /* mask */,
  +  mask_image, /* mask */
 po-shadow_image, /* dest */
 0, 0, /* src_x, src_y */
 0, 0, /* mask_x, mask_y */

 We're leaking mask_image.

 Kristian

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




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Fix on-the-fly transparency changes in pixman-renderer

[Manuel Bachmann]

Awesome ! Thank you both once again.

Regards,
Manuel


2014-04-07 18:46 GMT+02:00 Kristian Høgsberg hoegsb...@gmail.com:

 On Mon, Apr 07, 2014 at 04:02:11PM +0300, Pekka Paalanen wrote:
  On Mon,  7 Apr 2014 11:58:45 +0200
  Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:
 
   This fixes :
   - leaking the mask used to simulate transparency ;
   - code style (definitions moved up, use of brackets) ;
   - applying an opaque region when transparency is
wanted (shound not happen).
  
   Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
   ---
src/pixman-renderer.c |   19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
  
   diff --git a/src/pixman-renderer.c b/src/pixman-renderer.c
   index eff7201..4ac4693 100644
   --- a/src/pixman-renderer.c
   +++ b/src/pixman-renderer.c
   @@ -181,6 +181,8 @@ repaint_region(struct weston_view *ev, struct
 weston_output *output,
   float view_x, view_y;
   pixman_transform_t transform;
   pixman_fixed_t fw, fh;
   +   pixman_image_t *mask_image;
   +   pixman_color_t mask;
  
   /* The final region to be painted is the intersection of
* 'region' and 'surf_region'. However, 'region' is in the global
   @@ -340,12 +342,12 @@ repaint_region(struct weston_view *ev, struct
 weston_output *output,
   if (ps-buffer_ref.buffer)
  
 wl_shm_buffer_begin_access(ps-buffer_ref.buffer-shm_buffer);
  
   -   pixman_image_t *mask_image;
   if (ev-alpha  1.0) {
   -   pixman_color_t mask = { 0x, 0x, 0x,
 0x*ev-alpha };
   +   mask.alpha = 0x*ev-alpha;
 
  Hi,
 
  doesn't this now leave red, green and blue of 'mask' undefined?

 It does, but for the mask argument, pixman only uses the alpha component.
 Regardless, I added an initializer for mask to set it to zero.  Mainly to
 make sure valgrind won't complain about.

   mask_image = pixman_image_create_solid_fill(mask);
   -   } else
   +   } else {
   mask_image = NULL;
   +   }
  
   pixman_image_composite32(pixman_op,
ps-image, /* src */
   @@ -357,6 +359,9 @@ repaint_region(struct weston_view *ev, struct
 weston_output *output,
pixman_image_get_width
 (po-shadow_image), /* width */
pixman_image_get_height
 (po-shadow_image) /* height */);
  
   +   if (mask_image)
   +   pixman_image_unref(mask_image);
   +
   if (ps-buffer_ref.buffer)
  
 wl_shm_buffer_end_access(ps-buffer_ref.buffer-shm_buffer);
  
   @@ -408,12 +413,14 @@ draw_view(struct weston_view *ev, struct
 weston_output *output,
   ev-transform.matrix.type !=
 WESTON_MATRIX_TRANSFORM_TRANSLATE) {
   repaint_region(ev, output, repaint, NULL, PIXMAN_OP_OVER);
   } else {
   -   /* blended region is whole surface minus opaque region: */
   +   /* blended region is whole surface minus opaque region, if
 not transparent: */
   pixman_region32_init_rect(surface_blend, 0, 0,
 ev-surface-width,
 ev-surface-height);
   -   pixman_region32_subtract(surface_blend, surface_blend,
 ev-surface-opaque);
   +   if (ev-alpha == 1.0) {
   +   pixman_region32_subtract(surface_blend,
 surface_blend, ev-surface-opaque);
   +   }
  
   -   if (pixman_region32_not_empty(ev-surface-opaque)) {
   +   if ((ev-alpha == 1.0) 
 pixman_region32_not_empty(ev-surface-opaque)) {
   repaint_region(ev, output, repaint,
 ev-surface-opaque, PIXMAN_OP_SRC);
   }
  
 
  You could merge the two if-statements. If the region is empty, the
  subtraction won't have an effect anyway.
 
  I wonder if the condition alpha == 1.0 is really the opposite of alpha
   1.0 in weston... maybe it should be written as alpha = 1.0 or
  even !(alpha  1.0) to exactly reflect the earlier test.

 We cap the alpha at 1 in the animation code.  I changed the tests above to
 just:

 if (ev-alpha != 1.0 ||
 (ev-transform.enabled 
  ev-transform.matrix.type !=
 WESTON_MATRIX_TRANSFORM_TRANSLATE)) {
 repaint_region(ev, output, repaint, NULL, PIXMAN_OP_OVER);

 and left the else case unchanged.

  This looks ok, but I suppose it will have the same problem with
  Xwayland that the gl-renderer is working around.

 Yeah, I guess it would.  I think we can create an XRGB pixman image for the
 same data and use that as source when we renderthe opaque regions.

  Kristian, now on the new era of Xwayland DDX and possibly glamor,
  does Xwayland still produce garbage alpha channels sometimes, or could
  we drop that hack?

 We'll fix it but currently we still get undefined alpha.  Before the new
 Xwayland approach, the problem was that each driver implements part of the
 rendering architecture and we'd have to audit every driver to make sure
 they
 generates opaque

[PATCH] toytoolkit: match parent surface type when adding a subsurface

[Manuel Bachmann]

When adding a subsurface (to display a tooltip) in toytoolkit,
we now get the parent window surface type (SHM or EGL) and
define the new surface type as the same.

This fixes crashes with tooltips in cases like having
Cairo-EGL available but running the X11 compositor.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
Reviewed-by: Jason Ekstrand ja...@jlekstrand.net
---
 clients/window.c |7 +++
 clients/window.h |3 +++
 2 files changed, 10 insertions(+)

diff --git a/clients/window.c b/clients/window.c
index 5ba7322..d974165 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -4607,6 +4607,12 @@ window_set_buffer_type(struct window *window, enum 
window_buffer_type type)
window-main_surface-buffer_type = type;
 }
 
+enum window_buffer_type
+window_get_buffer_type(struct window *window)
+{
+   return window-main_surface-buffer_type;
+}
+
 void
 window_set_preferred_format(struct window *window,
enum preferred_format format)
@@ -4624,6 +4630,7 @@ window_add_subsurface(struct window *window, void *data,
struct wl_subcompositor *subcompo = window-display-subcompositor;
 
surface = surface_create(window);
+   surface-buffer_type = window_get_buffer_type(window);
widget = widget_create(window, surface, data);
wl_list_init(widget-link);
surface-widget = widget;
diff --git a/clients/window.h b/clients/window.h
index 38d574f..c6388a2 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -364,6 +364,9 @@ display_surface_damage(struct display *display, 
cairo_surface_t *cairo_surface,
 void
 window_set_buffer_type(struct window *window, enum window_buffer_type type);
 
+enum window_buffer_type
+window_get_buffer_type(struct window *window);
+
 int
 window_is_fullscreen(struct window *window);
 
-- 
1.7.10.4

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

(RFC) weston-keyboard: enhancement proposal

[Manuel Bachmann]

) {
+   case KEYBOARD_STATE_DEFAULT:
+keyboard-state = KEYBOARD_STATE_UPPERCASE;
+break;
+   case KEYBOARD_STATE_UPPERCASE:
+keyboard-state = KEYBOARD_STATE_DEFAULT;
+break;
+   case KEYBOARD_STATE_SYMBOLS:
+keyboard-state = KEYBOARD_STATE_UPPERCASE;
+break;
+   }
break;
   case keytype_symbols:
if (state != WL_POINTER_BUTTON_STATE_PRESSED)
 break;
+   switch(keyboard-state) {
+   case KEYBOARD_STATE_DEFAULT:
+keyboard-state = KEYBOARD_STATE_SYMBOLS;
+break;
+   case KEYBOARD_STATE_UPPERCASE:
+keyboard-state = KEYBOARD_STATE_SYMBOLS;
+break;
+   case KEYBOARD_STATE_SYMBOLS:
+keyboard-state = KEYBOARD_STATE_DEFAULT;
+break;
+   }
break;
   case keytype_tab:
virtual_keyboard_commit_preedit(keyboard-keyboard);
@@ -821,7 +859,7 @@ input_method_activate(void *data,
  struct wl_array modifiers_map;
  const struct layout *layout;

- keyboard-keyboard-state = keyboardstate_default;
+ keyboard-keyboard-state = KEYBOARD_STATE_DEFAULT;

  if (keyboard-context)
   wl_input_method_context_destroy(keyboard-context);

-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Support on-the-fly transparency changes in pixman renderer

[Manuel Bachmann]

When the alpha channel of a surface is changed and the surface
refreshed, pixman renderer will now apply a mask corresponding
to the alpha channel value.

This allows visual effects like shell fade in, shell fade out,
window switching, to work when using pixman renderer.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 src/pixman-renderer.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/pixman-renderer.c b/src/pixman-renderer.c
index b999343..eff7201 100644
--- a/src/pixman-renderer.c
+++ b/src/pixman-renderer.c
@@ -340,9 +340,16 @@ repaint_region(struct weston_view *ev, struct 
weston_output *output,
if (ps-buffer_ref.buffer)
wl_shm_buffer_begin_access(ps-buffer_ref.buffer-shm_buffer);
 
+   pixman_image_t *mask_image;
+   if (ev-alpha  1.0) {
+   pixman_color_t mask = { 0x, 0x, 0x, 
0x*ev-alpha };
+   mask_image = pixman_image_create_solid_fill(mask);
+   } else
+   mask_image = NULL;
+
pixman_image_composite32(pixman_op,
 ps-image, /* src */
-NULL /* mask */,
+mask_image, /* mask */
 po-shadow_image, /* dest */
 0, 0, /* src_x, src_y */
 0, 0, /* mask_x, mask_y */
-- 
1.7.10.4

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

[PATCH] shell: position input panel layer above fullscreen layer

[Manuel Bachmann]

When a client calls the input panel (weston-keyboard e.g.)
and then goes fullscreen, the panel will not be hidden
anymore.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 desktop-shell/input-panel.c |2 +-
 desktop-shell/shell.c   |   17 +
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/desktop-shell/input-panel.c b/desktop-shell/input-panel.c
index c08a403..12fe686 100644
--- a/desktop-shell/input-panel.c
+++ b/desktop-shell/input-panel.c
@@ -63,7 +63,7 @@ show_input_panels(struct wl_listener *listener, void *data)
shell-showing_input_panels = true;
 
if (!shell-locked)
-   wl_list_insert(shell-panel_layer.link,
+   wl_list_insert(shell-compositor-cursor_layer.link,
   shell-input_panel_layer.link);
 
wl_list_for_each_safe(ipsurf, next,
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index fd9ead0..09d1914 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -72,9 +72,9 @@ enum shell_surface_type {
  * in the following order (top-most first):
  *  • Lock layer (only ever displayed on its own)
  *  • Cursor layer
+ *  • Input panel layer
  *  • Fullscreen layer
  *  • Panel layer
- *  • Input panel layer
  *  • Workspace layers
  *  • Background layer
  *
@@ -3794,18 +3794,19 @@ resume_desktop(struct desktop_shell *shell)
terminate_screensaver(shell);
 
wl_list_remove(shell-lock_layer.link);
-   wl_list_insert(shell-compositor-cursor_layer.link,
-  shell-fullscreen_layer.link);
-   wl_list_insert(shell-fullscreen_layer.link,
-  shell-panel_layer.link);
if (shell-showing_input_panels) {
-   wl_list_insert(shell-panel_layer.link,
+   wl_list_insert(shell-compositor-cursor_layer.link,
   shell-input_panel_layer.link);
wl_list_insert(shell-input_panel_layer.link,
-  ws-layer.link);
+  shell-fullscreen_layer.link);
} else {
-   wl_list_insert(shell-panel_layer.link, ws-layer.link);
+   wl_list_insert(shell-compositor-cursor_layer.link,
+  shell-fullscreen_layer.link);
}
+   wl_list_insert(shell-fullscreen_layer.link,
+  shell-panel_layer.link);
+   wl_list_insert(shell-panel_layer.link,
+  ws-layer.link),
 
restore_focus_state(shell, get_current_workspace(shell));
 
-- 
1.7.10.4

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

Re: [PATCH 3/5] shell: add managed_surface interface, request and events

[Manuel Bachmann]

Just some info regarding these taskbar patches ; I have some more patches
fixing bugs experienced on certain cases (multiples outputs, DRM
backend...). They are all available on GitHub,
https://github.com/Tarnyko/weston-taskbar/commits/HEAD-taskbar. I could
refactor and repost the whole set here.

However, I also realized that having an UI is maybe too early. I have sized
down a smaller set (2 patches) that only handles
xdg_surface_set_minimized() and allows to unminimize by doing Mod-Tab. So
no modification of desktop-shell is needed. Will post them in a few minutes.

Regards,
Manuel
2014-02-19 14:04 GMT+01:00 Manuel Bachmann 
manuel.bachm...@open.eurogiciel.org:


 Hi Pekka, and thanks a lot for your review !

 I changed my code, taking your comments into consideration. Here are the
 details :

  New events should be added last, so they do not change the opcodes of
 existing events.

 Ouch. You are right. I just reversed the order, so add_managed_surface
 is now the last event :

 --- a/clients/desktop-shell.c
 +++ b/clients/desktop-shell.c
 @@ -1239,21 +1239,6 @@ desktop_shell_prepare_lock_surface(void *data,
  }

  static void
 -desktop_shell_add_managed_surface(void *data,
 -   struct desktop_shell *desktop_shell,
 -   struct managed_surface *managed_surface)
 -{
 -struct desktop *desktop = data;
 -struct output *output;
 -
 -wl_list_for_each(output, desktop-outputs, link) {
 -/* add a handler with default title */
 -taskbar_add_handler(output-taskbar, managed_surface,
 Default);
 -update_window(output-taskbar-window);
 -}

 -}
 -
 -static void
  desktop_shell_grab_cursor(void *data,
struct desktop_shell *desktop_shell,
uint32_t cursor)
 @@ -1300,11 +1285,26 @@ desktop_shell_grab_cursor(void *data,
  }
  }

 +static void

 +desktop_shell_add_managed_surface(void *data,
 +   struct desktop_shell *desktop_shell,
 +   struct managed_surface *managed_surface)
 +{
 +struct desktop *desktop = data;
 +struct output *output;
 +
 +wl_list_for_each(output, desktop-outputs, link) {
 +/* add a handler with default title */
 +taskbar_add_handler(output-taskbar, managed_surface,
 Default);

 +update_window(output-taskbar-window);
 +}
 +}
 +
  static const struct desktop_shell_listener listener = {
  desktop_shell_configure,
  desktop_shell_prepare_lock_surface,
 -desktop_shell_add_managed_surface,
 -desktop_shell_grab_cursor
 +desktop_shell_grab_cursor,
 +desktop_shell_add_managed_surface

  };

  Copy-pasta? This is not a global interface, is it?

 Correct. The description is now :

 @@ -108,9 +108,16 @@


interface name=managed_surface version=1
  description summary=interface for handling managed surfaces
 -  Only one client can bind this interface at a time.
 +  Managed surfaces are abstractions for specific shell surfaces.
  /description



  You need protocol for destroying managed_surface objects

 Nice to have spotted that. More generally, I never called
 wl_resource_destroy(), which was bad. Here is the additional request and
 code :

 +request name=destroy type=destructor
 +  description summary=remove managed_surface interface
 +The managed_surface interface is removed and ceases to refer
 +to anything.
 +  /description
 +/request

 +

 --- a/desktop-shell/shell.c
 +++ b/desktop-shell/shell.c
 @@ -4020,6 +4020,13 @@ static const struct desktop_shell_interface
 desktop_shell_implementation = {
  };

  static void
 +managed_surface_destroy(struct wl_client *client,
 +struct wl_resource *resource)
 +{
 +wl_resource_destroy(resource);
 +}
 +
 +static void
  managed_surface_set_state(struct wl_client *client,
  struct wl_resource *resource,
  uint32_t state)
 @@ -4033,6 +4040,7 @@ managed_surface_set_state(struct wl_client *client,
  }

 --- a/clients/desktop-shell.c
 +++ b/clients/desktop-shell.c

  static const struct managed_surface_interface
 managed_surface_implementation = {
 +managed_surface_destroy,
  managed_surface_set_state
  };

 @@ -1344,6 +1344,8 @@ managed_surface_removed(void *data,
  /* destroy the handler */
  taskbar_destroy_handler(handler);
  update_window(handler-taskbar-window);
 +
 +managed_surface_destroy(managed_surface);

 I'm not sure if I need to do anything else. managed_surface only
 contains a reference to an object which is destroyed somewhere else, so I
 just destroy the wl_resource itself here.

 Thanks again. I'll be aware of any other suggestions , and will eventually
 repost a set of corrected modifications.

 Regards,
 Manuel



 2014-02-19 11:56 GMT+01:00 Pekka Paalanen ppaala...@gmail.com:

 On Wed, 19 Feb 2014 06:18:18 +0100
 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:

  We create a new managed_surface object which will track

[PATCH 2/2] compositor: use Mod-Tab to show/raise minimized surfaces

[Manuel Bachmann]

Temporarily show minimized surfaces when switching between
surfaces with the keyboard. If the final selected one was
minimized, it will be restored.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 desktop-shell/shell.c |   25 +
 1 file changed, 25 insertions(+)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 8ad528e..fb87587 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -5179,6 +5179,7 @@ struct switcher {
struct weston_surface *current;
struct wl_listener listener;
struct weston_keyboard_grab grab;
+   struct wl_array minimized_array;
 };
 
 static void
@@ -5189,6 +5190,16 @@ switcher_next(struct switcher *switcher)
struct shell_surface *shsurf;
struct workspace *ws = get_current_workspace(switcher-shell);
 
+/* temporary re-display minimized surfaces */
+   struct weston_view *tmp;
+   struct weston_view **minimized;
+   wl_list_for_each_safe(view, tmp, 
switcher-shell-minimized_layer.view_list, layer_link) {
+   wl_list_remove(view-layer_link);
+   wl_list_insert(ws-layer.view_list, view-layer_link);
+   minimized = wl_array_add(switcher-minimized_array, sizeof 
*minimized);
+   *minimized = view;
+   }
+
wl_list_for_each(view, ws-layer.view_list, layer_link) {
shsurf = get_shell_surface(view-surface);
if (shsurf 
@@ -5260,6 +5271,19 @@ switcher_destroy(struct switcher *switcher)
weston_keyboard_end_grab(keyboard);
if (keyboard-input_method_resource)
keyboard-grab = keyboard-input_method_grab;
+
+/* re-hide surfaces that were temporary shown during the switch */
+   struct weston_view **minimized;
+   wl_array_for_each(minimized, switcher-minimized_array) {
+   /* with the exception of the current selected */
+   if ((*minimized)-surface != switcher-current) {
+   wl_list_remove((*minimized)-layer_link);
+   
wl_list_insert(switcher-shell-minimized_layer.view_list, 
(*minimized)-layer_link);
+   weston_view_damage_below(*minimized);
+   }
+   }
+   wl_array_release(switcher-minimized_array);
+
free(switcher);
 }
 
@@ -5312,6 +5336,7 @@ switcher_binding(struct weston_seat *seat, uint32_t time, 
uint32_t key,
switcher-current = NULL;
switcher-listener.notify = switcher_handle_surface_destroy;
wl_list_init(switcher-listener.link);
+   wl_array_init(switcher-minimized_array);
 
restore_all_output_modes(shell-compositor);
lower_fullscreen_layer(switcher-shell);
-- 
1.7.10.4

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

Re: [PATCH 3/5] shell: add managed_surface interface, request and events

[Manuel Bachmann]

Hi Pekka, and thanks a lot for your review !

I changed my code, taking your comments into consideration. Here are the
details :

 New events should be added last, so they do not change the opcodes of
existing events.

Ouch. You are right. I just reversed the order, so add_managed_surface is
now the last event :

--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -1239,21 +1239,6 @@ desktop_shell_prepare_lock_surface(void *data,
 }

 static void
-desktop_shell_add_managed_surface(void *data,
-   struct desktop_shell *desktop_shell,
-   struct managed_surface *managed_surface)
-{
-struct desktop *desktop = data;
-struct output *output;
-
-wl_list_for_each(output, desktop-outputs, link) {
-/* add a handler with default title */
-taskbar_add_handler(output-taskbar, managed_surface, Default);
-update_window(output-taskbar-window);
-}
-}
-
-static void
 desktop_shell_grab_cursor(void *data,
   struct desktop_shell *desktop_shell,
   uint32_t cursor)
@@ -1300,11 +1285,26 @@ desktop_shell_grab_cursor(void *data,
 }
 }

+static void
+desktop_shell_add_managed_surface(void *data,
+   struct desktop_shell *desktop_shell,
+   struct managed_surface *managed_surface)
+{
+struct desktop *desktop = data;
+struct output *output;
+
+wl_list_for_each(output, desktop-outputs, link) {
+/* add a handler with default title */
+taskbar_add_handler(output-taskbar, managed_surface, Default);
+update_window(output-taskbar-window);
+}
+}
+
 static const struct desktop_shell_listener listener = {
 desktop_shell_configure,
 desktop_shell_prepare_lock_surface,
-desktop_shell_add_managed_surface,
-desktop_shell_grab_cursor
+desktop_shell_grab_cursor,
+desktop_shell_add_managed_surface
 };

 Copy-pasta? This is not a global interface, is it?

Correct. The description is now :

@@ -108,9 +108,16 @@

   interface name=managed_surface version=1
 description summary=interface for handling managed surfaces
-  Only one client can bind this interface at a time.
+  Managed surfaces are abstractions for specific shell surfaces.
 /description


 You need protocol for destroying managed_surface objects

Nice to have spotted that. More generally, I never called
wl_resource_destroy(), which was bad. Here is the additional request and
code :

+request name=destroy type=destructor
+  description summary=remove managed_surface interface
+The managed_surface interface is removed and ceases to refer
+to anything.
+  /description
+/request
+

--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -4020,6 +4020,13 @@ static const struct desktop_shell_interface
desktop_shell_implementation = {
 };

 static void
+managed_surface_destroy(struct wl_client *client,
+struct wl_resource *resource)
+{
+wl_resource_destroy(resource);
+}
+
+static void
 managed_surface_set_state(struct wl_client *client,
 struct wl_resource *resource,
 uint32_t state)
@@ -4033,6 +4040,7 @@ managed_surface_set_state(struct wl_client *client,
 }

--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
 static const struct managed_surface_interface
managed_surface_implementation = {
+managed_surface_destroy,
 managed_surface_set_state
 };

@@ -1344,6 +1344,8 @@ managed_surface_removed(void *data,
 /* destroy the handler */
 taskbar_destroy_handler(handler);
 update_window(handler-taskbar-window);
+
+managed_surface_destroy(managed_surface);

I'm not sure if I need to do anything else. managed_surface only contains
a reference to an object which is destroyed somewhere else, so I just
destroy the wl_resource itself here.

Thanks again. I'll be aware of any other suggestions , and will eventually
repost a set of corrected modifications.

Regards,
Manuel



2014-02-19 11:56 GMT+01:00 Pekka Paalanen ppaala...@gmail.com:

 On Wed, 19 Feb 2014 06:18:18 +0100
 Manuel Bachmann manuel.bachm...@open.eurogiciel.org wrote:

  We create a new managed_surface object which will track
  a surface compositor-side, and receive events shell-side
  to handle 3 cases :
  - a toplevel surface has been created ;
  - a toplevel surface has been destroyed ;
  - a toplevel surface has a new title ;
 
  Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
  ---
   clients/desktop-shell.c|   69
 
   desktop-shell/shell.c  |   63
 
   desktop-shell/shell.h  |8 +
   protocol/desktop-shell.xml |   49 +++
   4 files changed, 189 insertions(+)

 Hi,

 I'll comment only on the protocol bits, I didn't check the code.

  diff --git a/protocol/desktop-shell.xml b/protocol/desktop-shell.xml
  index 3ae5d33..2262ade 100644
  --- a/protocol/desktop

[PATCH 1/5] shell: add taskbar and taskbar_handler widgets

[Manuel Bachmann]

We draw a taskbar surface in desktop-shell, extend the
desktop-shell protocol to send it to the compositor, and
the compositor will draw it in a new taskbar layer at the
bottom.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 clients/desktop-shell.c|  144 
 desktop-shell/shell.c  |   53 +++-
 desktop-shell/shell.h  |1 +
 protocol/desktop-shell.xml |5 ++
 4 files changed, 201 insertions(+), 2 deletions(-)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index a0c6b6d..c341a91 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -85,6 +85,16 @@ struct panel {
uint32_t color;
 };
 
+struct taskbar {
+   struct surface base;
+   struct window *window;
+   struct widget *widget;
+   struct wl_list handler_list;
+   struct desktop *desktop;
+   int painted;
+   uint32_t color;
+};
+
 struct background {
struct surface base;
struct window *window;
@@ -102,6 +112,7 @@ struct output {
struct wl_list link;
 
struct panel *panel;
+   struct taskbar *taskbar;
struct background *background;
 };
 
@@ -123,6 +134,16 @@ struct panel_clock {
int clock_fd;
 };
 
+struct taskbar_handler {
+   struct widget *widget;
+   struct taskbar *taskbar;
+   cairo_surface_t *icon;
+   int focused, pressed;
+   char *title;
+   int state;
+   struct wl_list link;
+};
+
 struct unlock_dialog {
struct window *window;
struct widget *widget;
@@ -173,6 +194,8 @@ is_desktop_painted(struct desktop *desktop)
wl_list_for_each(output, desktop-outputs, link) {
if (output-panel  !output-panel-painted)
return 0;
+   if (output-taskbar  !output-taskbar-painted)
+   return 0;
if (output-background  !output-background-painted)
return 0;
}
@@ -566,6 +589,119 @@ panel_create(struct desktop *desktop)
return panel;
 }
 
+static void
+taskbar_redraw_handler(struct widget *widget, void *data)
+{
+   cairo_surface_t *surface;
+   cairo_t *cr;
+   struct taskbar *taskbar = data;
+
+   cr = widget_cairo_create(taskbar-widget);
+   cairo_set_operator(cr, CAIRO_OPERATOR_SOURCE);
+   set_hex_color(cr, taskbar-color);
+   cairo_paint(cr);
+
+   cairo_destroy(cr);
+   surface = window_get_surface(taskbar-window);
+   cairo_surface_destroy(surface);
+   taskbar-painted = 1;
+   check_desktop_ready(taskbar-window);
+}
+
+static void
+taskbar_resize_handler(struct widget *widget,
+int32_t width, int32_t height, void *data)
+{
+   struct taskbar_handler *handler;
+   struct taskbar *taskbar = data;
+   cairo_t *cr;
+   cairo_text_extents_t extents;
+   int x, y, w, h;
+   
+   x = 10;
+   y = 16;
+   wl_list_for_each(handler, taskbar-handler_list, link) {
+   cr = cairo_create (handler-icon);
+   cairo_text_extents (cr, handler-title, extents);
+
+   w = cairo_image_surface_get_width(handler-icon) + 
extents.width + 8;
+   h = cairo_image_surface_get_height(handler-icon);
+   widget_set_allocation(handler-widget,
+ x, y - h / 2, w + 1, h + 1);
+   x += w + 10;
+
+   cairo_destroy (cr);
+   }
+}
+
+static void
+taskbar_configure(void *data,
+   struct desktop_shell *desktop_shell,
+   uint32_t edges, struct window *window,
+   int32_t width, int32_t height)
+{
+   struct surface *surface = window_get_user_data(window);
+   struct taskbar *taskbar = container_of(surface, struct taskbar, base);
+
+   window_schedule_resize(taskbar-window, width, 32);
+}
+
+static void
+taskbar_destroy_handler(struct taskbar_handler *handler)
+{
+   free(handler-title);
+
+   cairo_surface_destroy(handler-icon);
+
+   widget_destroy(handler-widget);
+   wl_list_remove(handler-link);
+
+   free(handler);
+}
+
+static void
+taskbar_destroy(struct taskbar *taskbar)
+{
+   struct taskbar_handler *tmp;
+   struct taskbar_handler *handler;
+
+   wl_list_for_each_safe(handler, tmp, taskbar-handler_list, link) {
+   taskbar_destroy_handler(handler);
+   }
+
+   widget_destroy(taskbar-widget);
+   window_destroy(taskbar-window);
+
+   free(taskbar);
+}
+
+static struct taskbar *
+taskbar_create(struct desktop *desktop)
+{
+   struct taskbar *taskbar;
+   struct weston_config_section *s;
+
+   taskbar = xzalloc(sizeof *taskbar);
+
+   taskbar-base.configure = taskbar_configure;
+   taskbar-desktop = desktop;
+   taskbar-window = window_create_custom(desktop-display);
+   taskbar-widget = window_add_widget(taskbar-window, taskbar

[PATCH 3/5] shell: add managed_surface interface, request and events

[Manuel Bachmann]

We create a new managed_surface object which will track
a surface compositor-side, and receive events shell-side
to handle 3 cases :
- a toplevel surface has been created ;
- a toplevel surface has been destroyed ;
- a toplevel surface has a new title ;

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 clients/desktop-shell.c|   69 
 desktop-shell/shell.c  |   63 
 desktop-shell/shell.h  |8 +
 protocol/desktop-shell.xml |   49 +++
 4 files changed, 189 insertions(+)

diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
index c341a91..5f861b2 100644
--- a/clients/desktop-shell.c
+++ b/clients/desktop-shell.c
@@ -139,6 +139,7 @@ struct taskbar_handler {
struct taskbar *taskbar;
cairo_surface_t *icon;
int focused, pressed;
+   struct managed_surface *surface;
char *title;
int state;
struct wl_list link;
@@ -186,6 +187,14 @@ show_menu(struct panel *panel, struct input *input, 
uint32_t time)
 x - 10, y - 10, menu_func, entries, 4);
 }
 
+static void
+update_window(struct window *window)
+{
+   struct rectangle allocation;
+   window_get_allocation(window, allocation);
+   window_schedule_resize(window, allocation.width, allocation.height);
+}
+
 static int
 is_desktop_painted(struct desktop *desktop)
 {
@@ -1113,6 +1122,20 @@ desktop_shell_prepare_lock_surface(void *data,
 }
 
 static void
+desktop_shell_add_managed_surface(void *data,
+  struct desktop_shell *desktop_shell,
+  struct managed_surface *managed_surface)
+{
+   struct desktop *desktop = data;
+   struct output *output;
+
+   wl_list_for_each(output, desktop-outputs, link) {
+   /* will follow in next patch : add the actual handler here */
+   update_window(output-taskbar-window);
+   }
+}
+
+static void
 desktop_shell_grab_cursor(void *data,
  struct desktop_shell *desktop_shell,
  uint32_t cursor)
@@ -1162,10 +1185,56 @@ desktop_shell_grab_cursor(void *data,
 static const struct desktop_shell_listener listener = {
desktop_shell_configure,
desktop_shell_prepare_lock_surface,
+   desktop_shell_add_managed_surface,
desktop_shell_grab_cursor
 };
 
 static void
+managed_surface_state_changed(void *data,
+   struct managed_surface *managed_surface,
+   uint32_t state)
+{
+   struct taskbar_handler *handler = data;
+
+   if (handler-surface == managed_surface) {
+   /* set the handler state */
+   handler-state = state;
+   }
+}
+
+static void
+managed_surface_title_changed(void *data,
+   struct managed_surface *managed_surface,
+   const char *title)
+{
+   struct taskbar_handler *handler = data;
+
+   if (handler-surface == managed_surface) {
+   /* change the handler title text */
+   handler-title = strdup(title);
+   update_window(handler-taskbar-window);
+   }
+}
+
+static void
+managed_surface_removed(void *data,
+   struct managed_surface *managed_surface)
+{
+   struct taskbar_handler *handler = data;
+
+   if (handler-surface == managed_surface) {
+   /* will follow in next patch : destroy the actual handler here 
*/
+   update_window(handler-taskbar-window);
+   }
+}
+
+static const struct managed_surface_listener managed_surface_listener = {
+   managed_surface_state_changed,
+   managed_surface_title_changed,
+   managed_surface_removed
+};
+
+static void
 background_destroy(struct background *background)
 {
widget_destroy(background-widget);
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index b9b4ad9..57afe5b 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2023,6 +2023,14 @@ set_title(struct shell_surface *shsurf, const char 
*title)
 {
free(shsurf-title);
shsurf-title = strdup(title);
+
+   if (shsurf-type == SHELL_SURFACE_TOPLEVEL) {
+   struct managed_surface *managed_surface;
+   wl_list_for_each(managed_surface, 
shsurf-shell-managed_surfaces_list, link) {
+   if (managed_surface-surface == shsurf-surface)
+   managed_surface_send_title_changed 
(managed_surface-resource, shsurf-title);
+   }
+   }
 }
 
 static void
@@ -2991,6 +2999,16 @@ destroy_shell_surface(struct shell_surface *shsurf)
remove_popup_grab(shsurf);
}
 
+   if (shsurf-type == SHELL_SURFACE_TOPLEVEL) {
+   struct managed_surface *managed_surface;
+   wl_list_for_each(managed_surface, 
shsurf-shell-managed_surfaces_list, link

[PATCH 2/5] compositor: consider taskbar height on surfaces maximizing

[Manuel Bachmann]

As we have a new taskbar layer at the bottom, substract its
height from the desired size of maximized surfaces, so they
never get hovered by it.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 desktop-shell/shell.c |   26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 7d7efaa..b9b4ad9 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2084,6 +2084,26 @@ get_output_panel_height(struct desktop_shell *shell,
return panel_height;
 }
 
+static int
+get_output_taskbar_height(struct desktop_shell *shell,
+  struct weston_output *output)
+{
+struct weston_view *view;
+int taskbar_height = 0;
+
+if (!output)
+return 0;
+
+wl_list_for_each(view, shell-taskbar_layer.view_list, layer_link) {
+if (view-surface-output == output) {
+taskbar_height = view-surface-height;
+break;
+}
+}
+
+return taskbar_height;
+}
+
 /* The surface will be inserted into the list immediately after the link
  * returned by this function (i.e. will be stacked immediately above the
  * returned link). */
@@ -2404,17 +2424,19 @@ set_maximized(struct shell_surface *shsurf,
   struct weston_output *output)
 {
struct desktop_shell *shell;
-   uint32_t edges = 0, panel_height = 0;
+   uint32_t edges = 0, panel_height = 0, taskbar_height = 0;
 
shell_surface_set_output(shsurf, output);
 
shell = shell_surface_get_shell(shsurf);
panel_height = get_output_panel_height(shell, shsurf-output);
+   taskbar_height = get_output_taskbar_height(shell, shsurf-output);
edges = WL_SHELL_SURFACE_RESIZE_TOP | WL_SHELL_SURFACE_RESIZE_LEFT;
 
shsurf-client-send_configure(shsurf-surface, edges,
   shsurf-output-width,
-  shsurf-output-height - panel_height);
+  shsurf-output-height - panel_height
+ - taskbar_height);
 
shsurf-next_state.maximized = true;
shsurf-state_changed = true;
-- 
1.7.10.4

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

[PATCH 5/5] compositor: effectively minimize and unminimize.

[Manuel Bachmann]

When receiving a managed_surface_set_state request from
desktop-shell, compositor will know eventually hide the
target surface by sending it to an dedicated layer.

Signed-off-by: Manuel Bachmann manuel.bachm...@open.eurogiciel.org
---
 desktop-shell/shell.c |   48 ++--
 desktop-shell/shell.h |1 +
 2 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 8910df4..8f50046 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2473,6 +2473,45 @@ unset_maximized(struct shell_surface *shsurf)
 }
 
 static void
+set_minimized(struct weston_surface *surface, uint32_t is_true)
+{
+   struct shell_surface *shsurf;
+   struct workspace *current_ws;
+   struct weston_seat *seat;
+   struct weston_surface *focus;
+   struct weston_view *view;
+
+   view = get_default_view(surface);
+   if (!view)
+   return;
+
+   assert(weston_surface_get_main_surface(view-surface) == view-surface);
+
+   shsurf = get_shell_surface(surface);
+   current_ws = get_current_workspace(shsurf-shell);
+
+   wl_list_remove(view-layer_link);
+   if (is_true)
+   wl_list_insert(shsurf-shell-minimized_layer.view_list, 
view-layer_link);
+   else
+   wl_list_insert(current_ws-layer.view_list, view-layer_link);
+
+   shell_surface_update_child_surface_layers(shsurf);
+
+   drop_focus_state(shsurf-shell, current_ws, view-surface);
+   wl_list_for_each(seat, shsurf-shell-compositor-seat_list, link) {
+   if (!seat-keyboard)
+   continue;
+
+   focus = weston_surface_get_main_surface(seat-keyboard-focus);
+   if (focus == view-surface)
+   weston_keyboard_set_focus(seat-keyboard, NULL);
+   }
+
+   weston_view_damage_below(view);
+}
+
+static void
 shell_surface_set_maximized(struct wl_client *client,
 struct wl_resource *resource,
 struct wl_resource *output_resource)
@@ -3969,12 +4008,8 @@ managed_surface_set_state(struct wl_client *client,
struct managed_surface *managed_surface = 
wl_resource_get_user_data(resource);
struct weston_surface *surface = managed_surface-surface;
 
-   if (state)
-/* compositor hides surface on its own ; will follow in next 
patch */
-   weston_log (minimize stub\n);
-   else
-/* compositor unhides surface on its own ; will follow in next 
patch */
-   weston_log (unminimize stub\n);
+/* compositor hides/unhides surface on its own */
+   set_minimized(surface, state);
 }
 
 static const struct managed_surface_interface managed_surface_implementation = 
{
@@ -6020,6 +6055,7 @@ module_init(struct weston_compositor *ec,
activate_workspace(shell, 0);
 
wl_list_init(shell-managed_surfaces_list);
+   weston_layer_init(shell-minimized_layer, NULL);
 
wl_list_init(shell-workspaces.anim_sticky_list);
wl_list_init(shell-workspaces.animation.link);
diff --git a/desktop-shell/shell.h b/desktop-shell/shell.h
index ed563b9..8c62e3d 100644
--- a/desktop-shell/shell.h
+++ b/desktop-shell/shell.h
@@ -205,6 +205,7 @@ struct desktop_shell {
enum animation_type focus_animation_type;
 
struct wl_list managed_surfaces_list;
+   struct weston_layer minimized_layer;
 
struct wl_listener output_create_listener;
struct wl_listener output_move_listener;
-- 
1.7.10.4

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

Re: Weston : ideas about xdg_sell, and implementation for a taskbar

[Manuel Bachmann]

Hi Bill, hi Jasper, hi everybody again,

I just updated my taskbar code to make it work against Weston 1.4.0 :
https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar

And with regards to our former conversation, I added a logic that allows
the client to know when it has been minimized :
https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9

Here is how it works :

- there are 2 new compositor-to-client requests in xdg_shell.xml (not
upstream, added them for the demo) :
xdg_surface_request_set_minimized
xdg_surface_request_unset_minimized

- when a client using toytoolkit (weston-terminal for instance) wants to be
minimized, he asks the compositor :
xdg_surface_set_minimized(xdg_surface);

- the compositor handles this with its own logic. In my current
implementation, he hides it from view, but the code is in #ifdef
HAVE_TASKBAR and he could very well do anything else ;

- when the compositor is done, he tells the client surface it has been
minimized by sending :
xdg_surface_send_request_set_minimized(shsurf-resource);

- the client gets its answer in :
xdg_surface_request_set_minimized( ... ) {  }

and in the specific case of toytoolkit, decides to suspend the redraw with :

window_defer_redraw_until_configure (window);

So it doesn't consume too much CPU until it's unminimized again.

- if later, the surface would be un-mimimized, then the client would get
the answer with request_unset_minimized() and redraw its surface with :
window_schedule_redraw (window);

So a video player, for example, could cpntinue playing sound but avoid
decoding some frames.

BTW, if you remove the last commit of my code, the logic is
compositor-only, but with this commit, it becomes a kind of communication :
client-compositor-shell / shell-compositor-client.

What do you think of this ?

Regards,
Manuel

-


2014-01-31 7:11 GMT+01:00 Bill Spitzak spit...@gmail.com:



 Jasper St. Pierre wrote:

  A toolbox over a painting program that has two documents open.

 So, what is the expected behavior here exactly? There's a minimize button
 on both of the content window's decorations, and clicking on one should
 minimize all three windows?


 Clicking minimize of one of the documents makes only the document
 disappear. But then clicking on the minimize of the other document makes
 both the document and toolbox disappear.


  What should using the minimize keyboard shortcut functionality of your
 compositor do? Should it differ from using the button in the UI? What does
 it do right now on X11 or other platforms?


 It should do EXACTLY the same thing as a minimize button. Any different
 behavior is a bug.


  A client can ignore attempts to close it with the close box.

 Are you talking about simply having a minimize button in the server-side
 decoration that does nothing? Or are you talking about the compositor
 forcibly minimizing a window with e.g. a keyboard shortcut?

 The former is an application bug (the button does nothing because it was
 wired to do nothing), and while it's certainly frustrating from a user
 perspective, the compositor can still forcibly minimize or close the window.


 I would expect that a compositor shortcut key to close a window would
 first try sending a message to the app saying it wants to close, and the
 app can decide to not close (ideally by asking the user if they are sure,
 and the user says no). If it just killed the app or destroyed the window
 that could be very user-unfriendly and I am rather suprised anybody would
 suggest that.

 If an app is non-cooperative the compositor can do some stuff. For close
 it can kill the client if it is not responding to pings. Minimize probably
 should also force-hide the surface after a timeout even if the client is
 responding to pings. However this fallback stuff should not be part of the
 Wayland api and can be left up to the compositor writers to decide.




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston : ideas about xdg_sell, and implementation for a taskbar

[Manuel Bachmann]

Oh, and I forgot to add, the taskbar has its own logic asking the
compositor to hide, so clicking on the taskbar will do this, too. Sorry for
the additional noise.

Regards,
Manuel


2014-02-10 16:43 GMT+01:00 Manuel Bachmann 
manuel.bachm...@open.eurogiciel.org:

 Hi Guilio,

 In fact, the client will be hidden anyway, because in order to keep some
 consistency, the compositor will hide it :

 set_minimized() function in shell.c :

 https://github.com/Tarnyko/weston-taskbar/blob/1.4.0-taskbar/desktop-shell/shell.c#L3385

 What the client does, here, is that it knows it has been mimimized, and
 will handle in a specific way (slowing its rendering down, e.g.).

 It seemed like a good compromise between some opinions expressed before :
 server-side or client-side. Here the server-side will hide the window, but
 the client-side *may* do some useful stuff.

 I may be wrong of course, and in that case we could just handle this
 server-side (the code just did this before).

 Regards
 Tarnyko,


 2014-02-10 16:33 GMT+01:00 Giulio Camuffo giuliocamu...@gmail.com:

 2014-02-10 17:25 GMT+02:00 Manuel Bachmann
 manuel.bachm...@open.eurogiciel.org:
  Hi Bill, hi Jasper, hi everybody again,
 
  I just updated my taskbar code to make it work against Weston 1.4.0 :
  https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar
 
  And with regards to our former conversation, I added a logic that
 allows the
  client to know when it has been minimized :
 
 https://github.com/Tarnyko/weston-taskbar/commit/7b456ef103e9dd0e37d7cf74e55d87f7ffa64be9
 
  Here is how it works :
 
  - there are 2 new compositor-to-client requests in xdg_shell.xml (not
  upstream, added them for the demo) :
  xdg_surface_request_set_minimized
  xdg_surface_request_unset_minimized
 
  - when a client using toytoolkit (weston-terminal for instance) wants
 to be
  minimized, he asks the compositor :
  xdg_surface_set_minimized(xdg_surface);
 
  - the compositor handles this with its own logic. In my current
  implementation, he hides it from view, but the code is in #ifdef
  HAVE_TASKBAR and he could very well do anything else ;
 
  - when the compositor is done, he tells the client surface it has been
  minimized by sending :
  xdg_surface_send_request_set_minimized(shsurf-resource);
 
  - the client gets its answer in :
  xdg_surface_request_set_minimized( ... ) {  }

 I don't think that's a good idea. If i click on the taskbar I want the
 client to hide, even if it doesn't call the
 xdg_surface_request_set_minimized for any reason (it's frozen, it's
 broken, ...). It may make sense to send an event telling the client it
 has been minimized, thought it should not mean the client can stop
 rendering.

 
  and in the specific case of toytoolkit, decides to suspend the redraw
 with :
 
  window_defer_redraw_until_configure (window);
 
  So it doesn't consume too much CPU until it's unminimized again.
 
  - if later, the surface would be un-mimimized, then the client would
 get the
  answer with request_unset_minimized() and redraw its surface with :
  window_schedule_redraw (window);
 
  So a video player, for example, could cpntinue playing sound but avoid
  decoding some frames.
 
  BTW, if you remove the last commit of my code, the logic is
 compositor-only,
  but with this commit, it becomes a kind of communication :
  client-compositor-shell / shell-compositor-client.
 
  What do you think of this ?
 
  Regards,
  Manuel
 
  -
 
 
  2014-01-31 7:11 GMT+01:00 Bill Spitzak spit...@gmail.com:
 
 
 
  Jasper St. Pierre wrote:
 
  A toolbox over a painting program that has two documents open.
 
  So, what is the expected behavior here exactly? There's a minimize
 button
  on both of the content window's decorations, and clicking on one
 should
  minimize all three windows?
 
 
  Clicking minimize of one of the documents makes only the document
  disappear. But then clicking on the minimize of the other document
 makes
  both the document and toolbox disappear.
 
 
  What should using the minimize keyboard shortcut functionality of
 your
  compositor do? Should it differ from using the button in the UI? What
 does
  it do right now on X11 or other platforms?
 
 
  It should do EXACTLY the same thing as a minimize button. Any different
  behavior is a bug.
 
 
  A client can ignore attempts to close it with the close box.
 
  Are you talking about simply having a minimize button in the
 server-side
  decoration that does nothing? Or are you talking about the compositor
  forcibly minimizing a window with e.g. a keyboard shortcut?
 
  The former is an application bug (the button does nothing because it
 was
  wired to do nothing), and while it's certainly frustrating from a user
  perspective, the compositor can still forcibly minimize or close the
 window.
 
 
  I would expect that a compositor shortcut key to close a window would
  first try sending a message to the app saying it wants to close, and
 the app
  can decide to not close

Weston : ideas about xdg_sell, and implementation for a taskbar

[Manuel Bachmann]

Hi folks,

Where I work, we need to have some logic to manage surfaces from a client
point of view (application or toolkit). For example, we need to be able to :
- minimize (hide/show or more) surfaces, just like most desktop
environments allow ;
- manage layers, by arranging surfaces by z-orders e.g. ;
- ...

Having searched a bit, and because the core Wayland protocol does not
provide this, it seems that the xdg_shell protocol would be the way to go.

I just looked in the current Weston codebase, and found there are already
stubbed implementations for xdg_shell_set_minimize() e.g.. I plan to write
a minimal implementation adding the call handling to shell.c, and a new
taskbar.c plugin eventually receiving calls.
-
As a proof-of-concept, I just wrote a patch for weston 1.3.x that
implements all the logic needed for a graphical taskbar, and manages
minimization/raise events for surfaces.

 Here's the patched version, which basically modifies shell, desktop_shell
and toytoolkit :
https://github.com/Tarnyko/weston-taskbar

 Here are some screenshots :
http://www.tarnyko.net/repo/weston131-taskbar1.png
http://www.tarnyko.net/repo/weston131-taskbar2.png

 And for the lazy ;-) , here is a video :
http://www.youtube.com/watch?v=7Svrb3iGBAs
-
Here's how it works :

- When the compositor creates a shell_surface having the TOPLEVEL type,
it sets a numeral ID for it, and sends a map event to the desktop_shell
client ;

- the desktop_shell client receives the event, and then creates a
button on the taskbar associated with this ID. If the surface has a title
(typically set client-side with wl_shell_surface_set_title()), the button
will display it ; otherwise it will just contain Default:ID.

- when the button is clicked, and the window is shown, it asks the
compositor
to hide it... or asks the contrary in the other case ;-) ;

- if it should be hidden, then the compositor sends the shell_surface to a
new
weston_layer named taskbar_layer. This layer is not displayed at all. If
it
shouldn't, then it's moved back to the current workspace layer.

- lots of weston clients use the toytoolkit library (weston-terminal
e.g.).
When their minimize button is pressed, they now call a
taskbar_move_surface()
function which will do the former, and additionally send a hint to the
desktop_shell
that this has been done (so the corresponding taskbar button stays tuned).
---

As lots of code changed in 1.4, and xdg_shell interface is now implemented,
I will try to port it to git master along with xdg_shell additions.

Comments on this subject are very welcome !

PS : I will be at FOSDEM this w-e (
https://fosdem.org/2014/schedule/event/porting_legacy_x11_to_wayland/) if
anyone wants to discuss the subject with me.

-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston : ideas about xdg_sell, and implementation for a taskbar

[Manuel Bachmann]

Hi Bill, and thanks a lot for sharing your thoughts,

 You must allow a toplevel to become a non-toplevel and vice-versa

That's true ; the current implementation doesn't address this case.

 My recommendation is that a surface has a parent that can be changed at
any time to any other surface or to NULL

So for an application having a main surface (let's say, the first that
has been created) and child (transient ?) surfaces, the schema would be :
NULL - shell_surface - shell_surface - shell_surface
 |-shell_surface

In that case, an implementation *could* just display a button for the first
shell_surface on the left, and minimize it and all its children at the same
time. Well, I suppose it's really something up to the actual
implementation, so a sample impl. could just do it the easiest way.

 NO! The compositor must only send a hide request to the client. The
client MUST be in final control over when and how it's surfaces disappear.

Have just been reading the other (old) thread on this issue, so I get your
objection :-).
I suppose I'll have to write a sample client application able to process
such a request. GTK+ seems to have an impl, so I will check what it does.

 I'm not clear on why the former api can't do this and you felt a new api
had to be added.

Well it's just a demo, I don't really feel like it should be merged in this
state.In fact,  I'd like to avoid adding any API.


Taking your comments into account, here's what I think I should do next :

- write a sample client able to send xdg_shell_set_minimized() requests,
and process the responses to it ;
- write a minimal implementation for a taskbar/main_shell_surfaces_list
(?) in the shell directory, and allow it to be built on demand ;
- make sure these 2 components communicate and react well.

Thank you ; any further recommendation appreciated !

Regards,
Manuel


2014-01-31 Bill Spitzak spit...@gmail.com:


  - When the compositor creates a shell_surface having the TOPLEVEL type,
 it sets a numeral ID for it, and sends a map event to the desktop_shell
 client ;


 You must allow a toplevel to become a non-toplevel and vice-versa,
 otherwise useful api for rearranging windows is impossible. My
 recommendation is that a surface has a parent that can be changed at any
 time to any other surface or to NULL, the only restriction is that a loop
 cannot be created. In any case please do not make a type called TOPLEVEL.


  - if it should be hidden, then the compositor sends the shell_surface to
 a new
 weston_layer named taskbar_layer. This layer is not displayed at all.


 NO! The compositor must only send a hide request to the client. The
 client MUST be in final control over when and how it's surfaces disappear.
 This is to allow it to atomically remove child surfaces or to reparent them
 to other surfaces that are not being hidden.


  When their minimize button is pressed, they now call a
 taskbar_move_surface()
 function which will do the former, and additionally send a hint to the
 desktop_shell
 that this has been done (so the corresponding taskbar button stays tuned).


 I'm not clear on why the former api can't do this and you felt a new api
 had to be added.




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR*
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston : ideas about xdg_sell, and implementation for a taskbar

[Manuel Bachmann]

Well, having read Jasper's comment, he has some valid points, the most
important being in my opinion :

  it matches user expectations. If the user clicks minimize on a window,
they want it hidden

It the logic of what should *really* happen when a window is minimized is
implemented client-side, that means the UI experience will differ among
client applications. Some may hide, some may iconify, some may just do
nothing...

One could object that the logic is to be implemented in the toolkit, so all
applications using the same toolkit will end up doing the same. But that
still means that if we have, for example, an application using GTK+,
another one using EFL, another one using toytoolkit (weston-terminal),
they'll behave differently ? We'd really like to avoid that.

Maybe a middle ground can be found if :

1) the desktop-shell-component can force a behaviour which WON'T touch any
wl_surface nor wl_shell_surface state (i.e. no switch to any new MINIMIZED
or whatever state, surface still considered fullscreen or maximized if it
was before)

2) the client application can still get the response back, and react the
way it wants

Which would imply, taking the case of Weston :

- if no desktop_shell_taskbar or whatever manager plugin is present as a
module, then client app just gets its response, and react the way it wants ;

- if it is present, then this plugin communicates with the compositor to
enforce some behaviour, BUT the client app still react the way it wants.

What do you think of that ?

Regards,
Tarnyko


2014-01-31 Manuel Bachmann manuel.bachm...@open.eurogiciel.org:

 Hi Bill, and thanks a lot for sharing your thoughts,

  You must allow a toplevel to become a non-toplevel and vice-versa

 That's true ; the current implementation doesn't address this case.

  My recommendation is that a surface has a parent that can be changed
 at any time to any other surface or to NULL

 So for an application having a main surface (let's say, the first that
 has been created) and child (transient ?) surfaces, the schema would be :
 NULL - shell_surface - shell_surface - shell_surface
  |-shell_surface

 In that case, an implementation *could* just display a button for the
 first shell_surface on the left, and minimize it and all its children at
 the same time. Well, I suppose it's really something up to the actual
 implementation, so a sample impl. could just do it the easiest way.

  NO! The compositor must only send a hide request to the client. The
 client MUST be in final control over when and how it's surfaces disappear.

 Have just been reading the other (old) thread on this issue, so I get your
 objection :-).
 I suppose I'll have to write a sample client application able to process
 such a request. GTK+ seems to have an impl, so I will check what it does.

  I'm not clear on why the former api can't do this and you felt a new api
 had to be added.

 Well it's just a demo, I don't really feel like it should be merged in
 this state.In fact,  I'd like to avoid adding any API.
 

 Taking your comments into account, here's what I think I should do next :

 - write a sample client able to send xdg_shell_set_minimized() requests,
 and process the responses to it ;
 - write a minimal implementation for a taskbar/main_shell_surfaces_list
 (?) in the shell directory, and allow it to be built on demand ;
 - make sure these 2 components communicate and react well.

 Thank you ; any further recommendation appreciated !

 Regards,
 Manuel


 2014-01-31 Bill Spitzak spit...@gmail.com:


  - When the compositor creates a shell_surface having the TOPLEVEL type,
 it sets a numeral ID for it, and sends a map event to the
 desktop_shell client ;


 You must allow a toplevel to become a non-toplevel and vice-versa,
 otherwise useful api for rearranging windows is impossible. My
 recommendation is that a surface has a parent that can be changed at any
 time to any other surface or to NULL, the only restriction is that a loop
 cannot be created. In any case please do not make a type called TOPLEVEL.


  - if it should be hidden, then the compositor sends the shell_surface to
 a new
 weston_layer named taskbar_layer. This layer is not displayed at all.


 NO! The compositor must only send a hide request to the client. The
 client MUST be in final control over when and how it's surfaces disappear.
 This is to allow it to atomically remove child surfaces or to reparent them
 to other surfaces that are not being hidden.


  When their minimize button is pressed, they now call a
 taskbar_move_surface()
 function which will do the former, and additionally send a hint to the
 desktop_shell
 that this has been done (so the corresponding taskbar button stays
 tuned).


 I'm not clear on why the former api can't do this and you felt a new api
 had to be added.




 --
 Regards,



 *Manuel BACHMANN Tizen Project VANNES-FR*




-- 
Regards,



*Manuel BACHMANN Tizen Project VANNES-FR

[Weston] RDP backend state

[Manuel BACHMANN]

Hi folks,

I tried to build the Weston 1.3.1 RDP backend using latest FreeRDP master,
and I managed to get it to compile using the following trivial patch :

http://pastebin.com/XGz4xYaE

It basically runs, and I can connect to it with :
rdesktop -4 -b IP adresse

However, it renders only a black screen, and server-side I get the
following messages :

unable to checkDescriptor for fd
failed to initialize EGL
EGL does not seem to work, falling back to software rendering and wl_shm

(my EGL doesn't work, so it may be normal)
I noticed I can run clients, though, and they keep running until I kill
them or weston hangs. So it looks more like a rendering issue.

Does someone know how to make it work, or if it's supposed to ? Is it
linked the error messages ?

Thanks

-- 
Regards,

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