[PATCH] xdg-shell: remove constraint on popup parents

[Drew DeVault]

It seems that this was partially done in
a3cf97ff982638bf7ed23b4303eba280c521b54d; this patch just corrects an
oversight.
---
 stable/xdg-shell/xdg-shell.xml | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index d524ea9..2255d77 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -1007,9 +1007,6 @@
   surface of their own is clicked should dismiss the popup using the 
destroy
   request.
 
-  The parent surface must have either the xdg_toplevel or xdg_popup surface
-  role.
-
   A newly created xdg_popup will be stacked on top of all previously 
created
   xdg_popup surfaces associated with the same xdg_toplevel.
 
-- 
2.16.2

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

Re: Proposal: use of xdg-shell popups outside of xdg-shell

[Jonas Ådahl]

On Tue, Mar 13, 2018 at 09:29:30AM -0400, Drew DeVault wrote:
> Hi there! Over at the wlroots project we're thinking about repurposing
> xdg-shell popups for use in another protocol that needs popups. The
> popup interface is somewhat complex and duplicating it for each protocol
> that might want to support popups is less than ideal.
> 
> From an API perspective, both xdg positioner and xdg popup look easily
> reused with parents other than xdg toplevel. Everything is cleanly
> separated in xdg shell to accomodate for this. The only real issue is
> this line:
> 
> https://github.com/wayland-project/wayland-protocols/blob/master/stable/xdg-shell/xdg-shell.xml#L1010
> 
> I propose simply dropping this comment from the protocol description.
> It's a backwards- and forwards-compatible change, and there's no
> compelling API-driven reason not to permit the reuse of xdg popups
> elsewhere. Would definitely simplify the implementation of our new
> protocol and future protocols that could use them.

Sounds good to me. FWIW,
https://cgit.freedesktop.org/wayland/wayland-protocols/commit/?id=a3cf97ff982638bf7ed23b4303eba280c521b54d
had this possibility in mind, but seems I missed the part you pointed
out.


Jonas


> 
> --
> Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wl_buffer is not released for long time.

[Sichem Zhou]

Dear Pekka,

Thanks for your idea on this, I inserted a callback in the `surface_commit`
function in libweston. From the log I can see that the `surface commit` was
blocked on the server side until some other events happen. On the client
side it was clear that I committed two buffers then sleeped because of
lacking available buffers. I am using libweston and currently I didn't
setup any input callbacks. All I did was setting up an interface to set
views in background layers then call `wl_display_run()`. I hope to know is
there anyways to follow wayland server event queues in libweston?

Thanks very much,
SZ

Le mer. 14 mars 2018 04 h 49, Pekka Paalanen  a écrit :

> On Tue, 13 Mar 2018 14:11:29 +
> Sichem Zhou  wrote:
>
> > Dear Matt,
> >
> > I just checked my compiled version, indeed I was using a version without
> > this patch. I patched my local weston but it didn't seem that my problem
> is
> > gone. So I guess there could be other problems with my code, but thanks
> for
> > your assistance. Now I can insert the callback in weston to do some
> > inspection.
>
> Hi,
>
> note that there is no guarantee to get a wl_buffer.release until you
> have wl_surface.committed the next wl_buffer. A compositor could send a
> release without a new buffer, but that is only possible is the
> compositor made a copy of the buffer contents. Compositors try to avoid
> such copies.
>
> It didn't sound like this was your issue, but just reminding.
>
> It sounds more like the compositor might be blocked unnecessarily
> somewhere, and getting input events will let its main event loop
> un-block. This shouldn't happen, but there could be bugs.
>
>
> Thanks,
> pq
>
> > Le lun. 12 mars 2018 19 h 22, Matt Hoosier  a
> > écrit :
> >
> > > Here's the discussion and patch that addressed the issue I was
> mentioning:
> > >
> > >
> > >
> https://lists.freedesktop.org/archives/wayland-devel/2017-September/035191.html
> > >
> > > On Mon, Mar 12, 2018 at 3:51 PM, Matt Hoosier 
> > > wrote:
> > > > Hi,
> > > >
> > > > Unless you're using an unreleased version of Weston, I think you're
> > > > probably running into a bug that we fixed a few months ago in which
> > > > wl_buffer::release() events were prone to sit undispatched in the
> > > > server's outgoing queue until some other event happened to need
> > > > transmitted.
> > > >
> > > > -Matt
> > > >
> > > > On Mon, Mar 12, 2018 at 1:23 PM, Sichem Zhou 
> > > wrote:
> > > >> Hi all,
> > > >>
> > > >> Dear wayland devs, I have a question regarding to double `wl_buffer`
> > > >> management. I don't seem to have wl_buffer released untill some
> other
> > > events
> > > >> triggered (for example, the  inputs). My current environment is
> under
> > > >> `X11-backend` and a libweston based compositor.
> > > >>
> > > >> My pipeline follows: (frame, attach, damage, commit) -> buffer
> switch ->
> > > >> wait until one buffer available -> redraw. The `done` event is
> handled
> > > >> differently since it only signals if ready to draw.
> > > >>
> > > >> Through my experiments, I found out at I wouldn't get either of the
> > > >> `release` of `frame done` event if I wasn't using the compositor
> (moving
> > > >> cursor or typing). In this case I guess there is something wrong
> with my
> > > >> pipeline but I couldn't figure out which. I wish to know if there is
> > > obvious
> > > >> mistakes in my pipeline or the problem lies in the compositor.
> > > >>
> > > >>  Very appreciate any answers.
> > > >>
> > > >> SZ
> > > >>
> > > >>
> > > >>
> > > >> ___
> > > >> wayland-devel mailing list
> > > >> wayland-devel@lists.freedesktop.org
> > > >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > > >>
> > >
>
>
Le 14 mars 2018 04 h 49, "Pekka Paalanen"  a écrit :

On Tue, 13 Mar 2018 14:11:29 +
Sichem Zhou  wrote:

> Dear Matt,
>
> I just checked my compiled version, indeed I was using a version without
> this patch. I patched my local weston but it didn't seem that my problem
is
> gone. So I guess there could be other problems with my code, but thanks
for
> your assistance. Now I can insert the callback in weston to do some
> inspection.

Hi,

note that there is no guarantee to get a wl_buffer.release until you
have wl_surface.committed the next wl_buffer. A compositor could send a
release without a new buffer, but that is only possible is the
compositor made a copy of the buffer contents. Compositors try to avoid
such copies.

It didn't sound like this was your issue, but just reminding.

It sounds more like the compositor might be blocked unnecessarily
somewhere, and getting input events will let its main event loop
un-block. This shouldn't happen, but there could be bugs.


Thanks,
pq


> Le lun. 12 mars 2018 19 h 22, Matt Hoosier  a
> écrit :
>
> > Here's 

Re: [PATCH weston] libweston-desktop/xdg-shell-v6: Fix crash when surface has buffer at creation

[Derek Foreman]

On 2018-03-13 01:18 PM, Quentin Glidic wrote:

On 3/13/18 5:34 PM, Derek Foreman wrote:
When a surface has a buffer at creation time we send an error, which 
results

in a disconnection and all resources being destroyed.

Since we send that error and return before performing the 
configure_list init

weston_desktop_xdg_surface_destroy() will walk an uninitialized list and
dereference a NULL pointer.

Initializing the list earlier prevents this from happening.

Signed-off-by: Derek Foreman 


Good catch:
Reviewed-by: Quentin Glidic 


And pushed.
Thanks,
Derek


Thanks,


---
  libweston-desktop/xdg-shell-v6.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libweston-desktop/xdg-shell-v6.c 
b/libweston-desktop/xdg-shell-v6.c

index f9902ff0..8fa01a32 100644
--- a/libweston-desktop/xdg-shell-v6.c
+++ b/libweston-desktop/xdg-shell-v6.c
@@ -1370,6 +1370,7 @@ 
weston_desktop_xdg_shell_protocol_get_xdg_surface(struct wl_client 
*wl_client,

  surface->desktop = weston_desktop_client_get_desktop(client);
  surface->surface = wsurface;
+    wl_list_init(>configure_list);
  surface->desktop_surface =
  weston_desktop_surface_create(surface->desktop, client,
@@ -1395,8 +1396,6 @@ 
weston_desktop_xdg_shell_protocol_get_xdg_surface(struct wl_client 
*wl_client,
 "xdg_surface must not have a buffer at 
creation");

  return;
  }
-
-    wl_list_init(>configure_list);
  }
  static void






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

Re: [PATCH libinput] tools: libinput-debug-events stop variable needs volatile

[Peter Hutterer]

On Tue, Mar 13, 2018 at 09:28:22PM +0100, Peter Seiderer wrote:
> The stop variable set in the signal handler needs
> volatile (and use the defined sig_atomic_t instead
> of unsigned int).
> 
> Signed-off-by: Peter Seiderer 
> ---
>  tools/libinput-debug-events.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libinput-debug-events.c b/tools/libinput-debug-events.c
> index 33f51d0e..32782c21 100644
> --- a/tools/libinput-debug-events.c
> +++ b/tools/libinput-debug-events.c
> @@ -48,7 +48,7 @@ static const uint32_t screen_width = 100;
>  static const uint32_t screen_height = 100;
>  static struct tools_options options;
>  static bool show_keycodes;
> -static unsigned int stop = 0;
> +static volatile sig_atomic_t stop = 0;
>  static bool be_quiet = false;
>  
>  #define printq(...) ({ if (!be_quiet)  printf(__VA_ARGS__); })
> -- 
> 2.16.2

pushed, thanks

Cheers,
   Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

[Drew DeVault]

On 2018-03-14  3:16 PM, Simon Ser wrote:
> However, the situation we'd like to avoid is clients wanting decorations not
> implementing CSD at all and relying on this protocol to show them via SSD. 
> What
> about rewording this sentence to:

I understand where you're coming from, but this is not something to be
avoided, rather it should be embraced.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

[Simon Ser]

On March 14, 2018 7:33 PM, Drew DeVault  wrote:
> On 2018-03-14  6:41 AM, Simon Ser wrote:
> > > Since we assume CSD by default, this implies that any client must be able 
> > > to
> > > do CSD, which should be explicitly stated here.
> > 
> > It's already stated in the protocol description ("Note that even if
> > the server supports server-side window decorations, clients must still
> > support client-side decorations"). Is it necessary to write it one
> > more time here?
> 
> I don't think this is right. The protocol has nothing to say at all
> about decorations, client side or not. A Wayland surface without CSD is
> a valid Wayland surface on any compositor. I don't think we need to
> explicitly require clients to handle CSD for that reason.

You're right, xdg-shell does mention client-side decorations, but never makes
them mandatory. Clients not having decorations can use xdg-toplevel.

However, the situation we'd like to avoid is clients wanting decorations not
implementing CSD at all and relying on this protocol to show them via SSD. What
about rewording this sentence to:

  Note that even if the server supports server-side window decorations, clients
  having decorations must still support client-side decorations.

> The assumption is that the compositor implementing this protocol will
> support both.
> 
> --
> Drew DeVault

---
Simon Ser
https://emersion.fr​

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

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

[Drew DeVault]

On 2018-03-14  6:41 AM, Simon Ser wrote:
> > Since we assume CSD by default, this implies that any client must be able to
> > do CSD, which should be explicitly stated here.
> 
> It's already stated in the protocol description ("Note that even if
> the server supports server-side window decorations, clients must still
> support client-side decorations"). Is it necessary to write it one
> more time here?

I don't think this is right. The protocol has nothing to say at all
about decorations, client side or not. A Wayland surface without CSD is
a valid Wayland surface on any compositor. I don't think we need to
explicitly require clients to handle CSD for that reason.

The assumption is that the compositor implementing this protocol will
support both.

--
Drew DeVault
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] configure.ac: fixup systemd/systemd-login detection

[Emil Velikov]

From: Emil Velikov 

Current systemd/systemd-login integration requires dbus. Although that
is far from clear the way current checks are handled.

Be explicit and clear, effectively fixing cases where the systemd
auto detection will trip when dbus is explicitly disabled.

Using git show -w will make things easier to read ;-)

Cc: Michael Tretter 
Reported-by: Michael Tretter 
Signed-off-by: Emil Velikov 
---
Michael, can you give this a try instead?
---
 configure.ac | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index dd344d6a..89b89d3c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -524,7 +524,11 @@ 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
+if test x$enable_systemd_login != xno; then
+  if test x$enable_systemd_login = xyes -a x$enable_dbus = xno; then
+AC_MSG_ERROR([systemd-login support explicitly requested, but dbus not 
available])
+  fi
+
   PKG_CHECK_MODULES(SYSTEMD_LOGIN,
 [libsystemd >= 209],
 [have_systemd_login_209=yes;have_systemd_login=yes],
@@ -537,20 +541,21 @@ if test x$enable_systemd_login != xno -a x$have_dbus != 
xno; then
   [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
+  if test "x$have_systemd_login" = "xno" -a "x$enable_systemd_login" = "xyes"; 
then
+AC_MSG_ERROR([systemd-login support explicitly requested, 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")
+  if test "x$have_systemd_login" = "xyes"; then
+AC_DEFINE([HAVE_SYSTEMD_LOGIN], [1], [Have systemd-login])]
+  else
+have_systemd_login=no
+  fi
 
-AS_IF([test "x$have_systemd_login_209" = "xyes"],
-  [AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 209])])
+  AS_IF([test "x$have_systemd_login_209" = "xyes"],
+[AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 
209])])
+fi
+AM_CONDITIONAL(HAVE_SYSTEMD_LOGIN, test "x$have_systemd_login" = "xyes")
 
 
 # Note that other features might want libxml2, or this feature might use
-- 
2.16.0

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

Re: weston-launch: libEGL: no configs with appropriate attributes

[Emil Velikov]

On 14 March 2018 at 11:36, Pekka Paalanen  wrote:
> On Wed, 14 Mar 2018 11:55:54 +0100
> Král Gergely  wrote:
>
>> Hi,
>>
>>
>> On my old notebook I would like to set up a test environment by running
>> weston and let clients to connect to it. I am stuck in the very
>> beginning and after almost a day of googling and trying to understand
>> documentation that are over my expertise I am asking your help.
>>
>> According to the weston building page the radeon RV200 video card should
>> work with wayland and weston. The DRM looks OK to me. Am I missing
>> something? How could I further debug to see what is exactly failing?
>>
>> Any comment is appreciated.
>>
>>
>> root$ weston-launch
>> Date: 2018-03-14 CET
>> [00:08:15.465] weston 1.12.0
>> http://wayland.freedesktop.org
>> Bug reports to:
>> https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland=weston=1.12.0
>> Build: 1.11.94-2-ga08dff5 configure.ac: bump to version
>> 1.12.0 for the official release (2016-09-20 12:22:46 -0700)
>> [00:08:15.465] Command line: /usr/bin/weston
>> [00:08:15.465] OS: Linux, 4.9.0-4-686-pae, #1 SMP Debian 4.9.65-3
>> (2017-12-03), i686
>> [00:08:15.466] Using config file '/root/.config/weston.ini'
>> [00:08:15.466] Output repaint window is 7 ms maximum.
>> [00:08:15.466] Loading module
>> '/usr/lib/i386-linux-gnu/libweston-1/drm-backend.so'
>> [00:08:15.475] initializing drm backend
>> [00:08:15.476] logind: not running in a systemd session
>> [00:08:15.476] logind: cannot setup systemd-logind helper (-6), using
>> legacy fallback
>> [00:08:15.479] using /dev/dri/card0
>> [00:08:15.479] Loading module
>> '/usr/lib/i386-linux-gnu/libweston-1/gl-renderer.so'
>> libGL: Can't open configuration file /root/.drirc: No such file or
>> directory.
>> [00:08:15.514] EGL client extensions: EGL_EXT_client_extensions
>> EGL_EXT_platform_base EGL_EXT_platform_wayland
>> EGL_EXT_platform_x11 EGL_MESA_platform_gbm
>> EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug
>> libEGL debug: added egl_dri2 to module array
>> libEGL debug: No DRI config supports native format 0x30335258
>> libEGL debug: No DRI config supports native format 0x30335241
>
> Hi,
>
> not sure where this comes from, and I'm not sure it wouldn't cause the
> below.
>
>> libEGL debug: the best driver is DRI2
>> libEGL debug: the value (0x9) of attribute 0x3040 did not meet the
>> criteria (0x4)
>
> The attribute is EGL_RENDERABLE_TYPE, where the system has OPENGL and
> OPENGL_ES, while Weston needs OPENGL_ES2.
>
r100/r200 only supports GL 1.3 and GLES1 1.1

One can easily check the above for any card, via glxinfo | grep
"Max.*profile version" ;-)

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

[PATCH libinput] tools: libinput-debug-events stop variable needs volatile

[Peter Seiderer]

The stop variable set in the signal handler needs
volatile (and use the defined sig_atomic_t instead
of unsigned int).

Signed-off-by: Peter Seiderer 
---
 tools/libinput-debug-events.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libinput-debug-events.c b/tools/libinput-debug-events.c
index 33f51d0e..32782c21 100644
--- a/tools/libinput-debug-events.c
+++ b/tools/libinput-debug-events.c
@@ -48,7 +48,7 @@ static const uint32_t screen_width = 100;
 static const uint32_t screen_height = 100;
 static struct tools_options options;
 static bool show_keycodes;
-static unsigned int stop = 0;
+static volatile sig_atomic_t stop = 0;
 static bool be_quiet = false;
 
 #define printq(...) ({ if (!be_quiet)  printf(__VA_ARGS__); })
-- 
2.16.2

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

Re: Proposal: use of xdg-shell popups outside of xdg-shell

[Pekka Paalanen]

On Wed, 14 Mar 2018 09:13:48 -0400
Drew DeVault  wrote:

> >just checking, how did you design your own protocol extension to take
> >advantage of xdg_popup? I mean, mechanically, what does the protocol
> >request sequence look like when you create an xdp_popup for your own
> >purpose?
> >
> >I'm asking because there is a pretty subtle and horrible catch if it's
> >done "wrong". Having your own protocol extension include a request that
> >creates a protocol object of type xdg_popup is the wrong way. There are
> >other ways to do it without accidentally freezing the xdp_popup
> >interface for all eternity.  
> 
> Yeah, thankfully this is not how we do it. We do something like this:
> 
> 1. xdg_surface = xdg_shell.get_xdg_surface(surface=wl_surface)
> 2. xdg_positioner = xdg_shell.get_positioner()
> 3. xdg_popup = surface.get_popup(parent=NULL, positioner=xdg_positioner)
> 4. layer_surface.assign_popup(popup=xdg_popup)
> 
> 
>   
> This assigns an xdg_popup's parent to this layer_surface.  This popup
> should have been created via xdg_surface::get_popup with the parent set
> to NULL, and this request must be invoked before committing the popup's
> initial state.
> 
> See the documentation of xdg_popup for more details about what an
> xdg_popup is and how it is used.
>   
>   
> 

Alright, cool. Carry on! :-)

So that's how Weston's panel and background could regain their popup
menus as well, good to know.


Thanks,
pq


> Discussion on the specific protocol we're working on is here:
> 
> https://github.com/swaywm/wlr-protocols/pull/7
> 
> --
> Drew DeVault



pgphDNN_F_RW8.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: weston-launch: libEGL: no configs with appropriate attributes

[Pekka Paalanen]

On Wed, 14 Mar 2018 11:55:54 +0100
Král Gergely  wrote:

> Hi,
> 
> 
> On my old notebook I would like to set up a test environment by running 
> weston and let clients to connect to it. I am stuck in the very 
> beginning and after almost a day of googling and trying to understand 
> documentation that are over my expertise I am asking your help.
> 
> According to the weston building page the radeon RV200 video card should 
> work with wayland and weston. The DRM looks OK to me. Am I missing 
> something? How could I further debug to see what is exactly failing?
> 
> Any comment is appreciated.
> 
> 
> root$ weston-launch
> Date: 2018-03-14 CET
> [00:08:15.465] weston 1.12.0
> http://wayland.freedesktop.org
> Bug reports to: 
> https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland=weston=1.12.0
> Build: 1.11.94-2-ga08dff5 configure.ac: bump to version 
> 1.12.0 for the official release (2016-09-20 12:22:46 -0700)
> [00:08:15.465] Command line: /usr/bin/weston
> [00:08:15.465] OS: Linux, 4.9.0-4-686-pae, #1 SMP Debian 4.9.65-3 
> (2017-12-03), i686
> [00:08:15.466] Using config file '/root/.config/weston.ini'
> [00:08:15.466] Output repaint window is 7 ms maximum.
> [00:08:15.466] Loading module 
> '/usr/lib/i386-linux-gnu/libweston-1/drm-backend.so'
> [00:08:15.475] initializing drm backend
> [00:08:15.476] logind: not running in a systemd session
> [00:08:15.476] logind: cannot setup systemd-logind helper (-6), using 
> legacy fallback
> [00:08:15.479] using /dev/dri/card0
> [00:08:15.479] Loading module 
> '/usr/lib/i386-linux-gnu/libweston-1/gl-renderer.so'
> libGL: Can't open configuration file /root/.drirc: No such file or 
> directory.
> [00:08:15.514] EGL client extensions: EGL_EXT_client_extensions
> EGL_EXT_platform_base EGL_EXT_platform_wayland
> EGL_EXT_platform_x11 EGL_MESA_platform_gbm
> EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug
> libEGL debug: added egl_dri2 to module array
> libEGL debug: No DRI config supports native format 0x30335258
> libEGL debug: No DRI config supports native format 0x30335241

Hi,

not sure where this comes from, and I'm not sure it wouldn't cause the
below.

> libEGL debug: the best driver is DRI2
> libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
> criteria (0x4)

The attribute is EGL_RENDERABLE_TYPE, where the system has OPENGL and
OPENGL_ES, while Weston needs OPENGL_ES2.

> [00:08:15.515] No EGL configs with appropriate attributes.
> [00:08:15.515] failed to choose EGL config
> [00:08:15.516] failed to initialize egl
> [00:08:15.521] fatal: failed to create compositor backend
> 
> 
> [   13.090647] [drm] Loading R100 Microcode

Does this card actually support any kind of shaders? Maybe the Weston
build guide is mistaken there.

Weston's GL renderer supports only GL ES 2.0, which implies shaders.
You should still be able to get Weston running by using the weston
command line option --use-pixman, but that makes it software rendered.

If you have to use weston-launch, then the command would be:
weston-launch -- --use-pixman


Thanks,
pq


pgpxoPpanYa1K.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

weston-launch: libEGL: no configs with appropriate attributes

[Král Gergely]

Hi,


On my old notebook I would like to set up a test environment by running 
weston and let clients to connect to it. I am stuck in the very 
beginning and after almost a day of googling and trying to understand 
documentation that are over my expertise I am asking your help.


According to the weston building page the radeon RV200 video card should 
work with wayland and weston. The DRM looks OK to me. Am I missing 
something? How could I further debug to see what is exactly failing?


Any comment is appreciated.


root$ weston-launch
Date: 2018-03-14 CET
[00:08:15.465] weston 1.12.0
   http://wayland.freedesktop.org
   Bug reports to: 
https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland=weston=1.12.0
   Build: 1.11.94-2-ga08dff5 configure.ac: bump to version 
1.12.0 for the official release (2016-09-20 12:22:46 -0700)

[00:08:15.465] Command line: /usr/bin/weston
[00:08:15.465] OS: Linux, 4.9.0-4-686-pae, #1 SMP Debian 4.9.65-3 
(2017-12-03), i686

[00:08:15.466] Using config file '/root/.config/weston.ini'
[00:08:15.466] Output repaint window is 7 ms maximum.
[00:08:15.466] Loading module 
'/usr/lib/i386-linux-gnu/libweston-1/drm-backend.so'

[00:08:15.475] initializing drm backend
[00:08:15.476] logind: not running in a systemd session
[00:08:15.476] logind: cannot setup systemd-logind helper (-6), using 
legacy fallback

[00:08:15.479] using /dev/dri/card0
[00:08:15.479] Loading module 
'/usr/lib/i386-linux-gnu/libweston-1/gl-renderer.so'
libGL: Can't open configuration file /root/.drirc: No such file or 
directory.

[00:08:15.514] EGL client extensions: EGL_EXT_client_extensions
   EGL_EXT_platform_base EGL_EXT_platform_wayland
   EGL_EXT_platform_x11 EGL_MESA_platform_gbm
   EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug
libEGL debug: added egl_dri2 to module array
libEGL debug: No DRI config supports native format 0x30335258
libEGL debug: No DRI config supports native format 0x30335241
libEGL debug: the best driver is DRI2
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)
libEGL debug: the value (0x9) of attribute 0x3040 did not meet the 
criteria (0x4)

[00:08:15.515] No EGL configs with appropriate attributes.
[00:08:15.515] failed to choose EGL config
[00:08:15.516] failed to initialize egl
[00:08:15.521] fatal: failed to create compositor backend


$ dmesg | grep "radeon\|drm\|agp\|fb"
[1.370456] Linux agpgart interface v0.103
[1.370655] agpgart-intel :00:00.0: Intel i845 Chipset
[1.374723] agpgart-intel :00:00.0: AGP aperture is 64M @ 
0xe000

[   12.052247] [drm] Initialized
[   13.073251] [drm] radeon kernel modesetting enabled.
[   13.074159] [drm] initializing kernel modesetting (RV200 
0x1002:0x4C57 0x1014:0x0509 0x00).

[   13.074208] [drm] register mmio base: 0xD010
[   13.074211] [drm] register mmio size: 65536
[   13.074488] agpgart-intel :00:00.0: AGP 2.0 bridge
[   13.074511] agpgart-intel :00:00.0: putting AGP V2 device into 4x 
mode

[   13.074546] radeon :01:00.0: putting AGP V2 device into 4x mode
[   13.074580] radeon :01:00.0: GTT: 64M 0xE000 - 0xE3FF
[   13.074595] radeon :01:00.0: VRAM: 128M 0xE800 - 
0xEFFF (32M used)

[   13.074623] [drm] Detected VRAM RAM=128M, BAR=128M
[   13.074626] [drm] RAM width 128bits DDR
[   13.088655] [drm] radeon: 32M of VRAM memory ready
[   13.088659] [drm] radeon: 64M of GTT memory ready.
[   13.090563] radeon :01:00.0: WB disabled
[   13.090578] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0xe000 and cpu addr 0xf07a
[   13.090583] [drm] Supports vblank timestamp caching Rev 2 
(21.10.2013).

[   13.090586] [drm] Driver supports precise vblank timestamp query.
[   13.090615] [drm] radeon: irq initialized.
[   13.090647] [drm] Loading R100 Microcode
[   13.544379] radeon :01:00.0: firmware: direct-loading firmware 
radeon/R100_cp.bin

[   13.544792] [drm] radeon: ring at 0xE0001000
[   13.544824] [drm] ring test succeeded in 1 usecs
[   13.545177] [drm] ib test succeeded in 0 usecs
[   

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

[Simon Ser]

On March 14, 2018 10:22 AM, Peter Hutterer  wrote:
> sorry about the delay, but better late than too late ;)

No problem, thanks for your review!

> On Sun, Mar 11, 2018 at 05:53:42PM -0400, Simon Ser wrote:
> > This adds a new protocol to negotiate server- and client-side rendering of
> > window decorations for xdg-toplevels. This allows compositors that want
> > to draw decorations themselves to send their preference to clients, and
> > clients that prefer server-side decorations to request them.
> > 
> > This is inspired by a protocol from KDE [1] which has been implemented in
> > KDE and Sway and was submitted for consideration in 2017 [2]. This patch
> > provides an updated protocol with those concerns taken into account.
> > 
> > Signed-off-by: Simon Ser 
> > Reviewed-by: Drew DeVault 
> > Reviewed-by: David Edmundson 
> > Reviewed-by: Alan Griffiths 
> > Reviewed-by: Tony Crisci 
> > 
> > [1] 
> > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> > [2] 
> > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> > ---
> > 
> > This was iterated on privately between representatives of Sway and wlroots
> > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson),
> > and Mir (Alan Griffiths).
> > 
> > A proof-of-concept of a client and server implementation is available at 
> > [1].
> > 
> > Changes from v2 to v3: fix typos, clarify xdg_toplevel_decoration.destroy
> > semantics, clarify that clients always need to support CSD and can receive
> > configure events at any time.
> > 
> > [1] https://github.com/swaywm/wlroots/pull/638
> > 
> >  Makefile.am|   1 +
> >  unstable/xdg-toplevel-decoration/README|   4 +
> >  .../xdg-toplevel-decoration-unstable-v1.xml| 132 
> > +
> >  3 files changed, 137 insertions(+)
> >  create mode 100644 unstable/xdg-toplevel-decoration/README
> >  create mode 100644 
> > unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 4b9a901..07744e9 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -17,6 +17,7 @@ unstable_protocols =  
> > \
> > 
> > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> >  \
> > unstable/xdg-output/xdg-output-unstable-v1.xml  
> > \
> > unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> > +   
> > unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> > \
> > $(NULL)
> >  
> >  stable_protocols = 
> > \
> > diff --git a/unstable/xdg-toplevel-decoration/README 
> > b/unstable/xdg-toplevel-decoration/README
> > new file mode 100644
> > index 000..e927110
> > --- /dev/null
> > +++ b/unstable/xdg-toplevel-decoration/README
> > @@ -0,0 +1,4 @@
> > +xdg_toplevel_decoration protocol
> > +
> > +Maintainers:
> > +Simon Ser 
> > diff --git 
> > a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml 
> > b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> > new file mode 100644
> > index 000..a34cb73
> > --- /dev/null
> > +++ 
> > b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> > @@ -0,0 +1,132 @@
> > +
> > +
> > +  
> > +Copyright © 2018 Simon Ser
> > +
> > +Permission is hereby granted, free of charge, to any person obtaining a
> > +copy of this software and associated documentation files (the 
> > "Software"),
> > +to deal in the Software without restriction, including without 
> > limitation
> > +the rights to use, copy, modify, merge, publish, distribute, 
> > sublicense,
> > +and/or sell copies of the Software, and to permit persons to whom the
> > +Software is furnished to do so, subject to the following conditions:
> > +
> > +The above copyright notice and this permission notice (including the 
> > next
> > +paragraph) shall be included in all copies or substantial portions of 
> > the
> > +Software.
> > +
> > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > EXPRESS OR
> > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > MERCHANTABILITY,
> > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > SHALL
> > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > +DEALINGS IN THE SOFTWARE.
> > +  
> > +
> > +  
> > +
> > +  This interface permits 

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

[Peter Hutterer]

sorry about the delay, but better late than too late ;)

On Sun, Mar 11, 2018 at 05:53:42PM -0400, Simon Ser wrote:
> This adds a new protocol to negotiate server- and client-side rendering of
> window decorations for xdg-toplevels. This allows compositors that want
> to draw decorations themselves to send their preference to clients, and
> clients that prefer server-side decorations to request them.
> 
> This is inspired by a protocol from KDE [1] which has been implemented in
> KDE and Sway and was submitted for consideration in 2017 [2]. This patch
> provides an updated protocol with those concerns taken into account.
> 
> Signed-off-by: Simon Ser 
> Reviewed-by: Drew DeVault 
> Reviewed-by: David Edmundson 
> Reviewed-by: Alan Griffiths 
> Reviewed-by: Tony Crisci 
> 
> [1] 
> https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> [2] 
> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> ---
> 
> This was iterated on privately between representatives of Sway and wlroots
> (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson),
> and Mir (Alan Griffiths).
> 
> A proof-of-concept of a client and server implementation is available at [1].
> 
> Changes from v2 to v3: fix typos, clarify xdg_toplevel_decoration.destroy
> semantics, clarify that clients always need to support CSD and can receive
> configure events at any time.
> 
> [1] https://github.com/swaywm/wlroots/pull/638
> 
>  Makefile.am|   1 +
>  unstable/xdg-toplevel-decoration/README|   4 +
>  .../xdg-toplevel-decoration-unstable-v1.xml| 132 
> +
>  3 files changed, 137 insertions(+)
>  create mode 100644 unstable/xdg-toplevel-decoration/README
>  create mode 100644 
> unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 4b9a901..07744e9 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -17,6 +17,7 @@ unstable_protocols =
> \
>   
> unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
>  \
>   unstable/xdg-output/xdg-output-unstable-v1.xml  
> \
>   unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> + 
> unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml  
>   \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/unstable/xdg-toplevel-decoration/README 
> b/unstable/xdg-toplevel-decoration/README
> new file mode 100644
> index 000..e927110
> --- /dev/null
> +++ b/unstable/xdg-toplevel-decoration/README
> @@ -0,0 +1,4 @@
> +xdg_toplevel_decoration protocol
> +
> +Maintainers:
> +Simon Ser 
> diff --git 
> a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml 
> b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> new file mode 100644
> index 000..a34cb73
> --- /dev/null
> +++ b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> @@ -0,0 +1,132 @@
> +
> +
> +  
> +Copyright © 2018 Simon Ser
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +
> +  This interface permits choosing between client-side and server-side
> +  window decorations for a toplevel surface.
> +
> +  A window decoration is a user interface component used to move, resize 
> and
> +  change a window's state. It can be managed either by the client (part 
> of
> +  the surface) or by the server.
> +
> +  By advertising this interface the server 

compositor: do not free output region twice in weston_output_set_transform()

[Ilia Bozhinov]

This is already done when weston_output_init_geometry() is called.
Actually this is a fix for 8564a0d, because without this patch, the
compositor sometimes crashes when setting output transform

Signed-off-by: Ilia Bozhinov 
---
 libweston/compositor.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index aec937bb..0079c848 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -4705,9 +4705,6 @@ weston_output_set_transform(struct weston_output *output,
pixman_region32_init(_region);
pixman_region32_copy(_region, >region);
 
-   pixman_region32_fini(>region);
-   pixman_region32_fini(>previous_damage);
-
weston_output_init_geometry(output, output->x, output->y);
 
output->dirty = 1;
-- 
2.14.3

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

Re: [PATCH wayland] configure.ac: don't install the static libraries

[Peter Hutterer]

On Tue, Mar 13, 2018 at 01:43:37PM +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> One should always be using the shared libraries.
> 
> Spotted while going through the Debian packaing.
> 
> Signed-off-by: Emil Velikov 
> ---
> Can we have this in the 1.5 release, please?

Reviewed-by: Peter Hutterer 
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index a53b6cc..26e517a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -44,7 +44,7 @@ AM_CONDITIONAL(ENABLE_CPP_TEST, test "x$have_cpp_compiler" 
> = "xyes")
>  
>  # Initialize libtool
>  LT_PREREQ([2.2])
> -LT_INIT
> +LT_INIT([disable-static])
>  
>  PKG_PROG_PKG_CONFIG()
>  
> -- 
> 2.16.0
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wl_buffer is not released for long time.

[Pekka Paalanen]

On Tue, 13 Mar 2018 14:11:29 +
Sichem Zhou  wrote:

> Dear Matt,
> 
> I just checked my compiled version, indeed I was using a version without
> this patch. I patched my local weston but it didn't seem that my problem is
> gone. So I guess there could be other problems with my code, but thanks for
> your assistance. Now I can insert the callback in weston to do some
> inspection.

Hi,

note that there is no guarantee to get a wl_buffer.release until you
have wl_surface.committed the next wl_buffer. A compositor could send a
release without a new buffer, but that is only possible is the
compositor made a copy of the buffer contents. Compositors try to avoid
such copies.

It didn't sound like this was your issue, but just reminding.

It sounds more like the compositor might be blocked unnecessarily
somewhere, and getting input events will let its main event loop
un-block. This shouldn't happen, but there could be bugs.


Thanks,
pq

> Le lun. 12 mars 2018 19 h 22, Matt Hoosier  a
> écrit :
> 
> > Here's the discussion and patch that addressed the issue I was mentioning:
> >
> >
> > https://lists.freedesktop.org/archives/wayland-devel/2017-September/035191.html
> >
> > On Mon, Mar 12, 2018 at 3:51 PM, Matt Hoosier 
> > wrote:  
> > > Hi,
> > >
> > > Unless you're using an unreleased version of Weston, I think you're
> > > probably running into a bug that we fixed a few months ago in which
> > > wl_buffer::release() events were prone to sit undispatched in the
> > > server's outgoing queue until some other event happened to need
> > > transmitted.
> > >
> > > -Matt
> > >
> > > On Mon, Mar 12, 2018 at 1:23 PM, Sichem Zhou   
> > wrote:  
> > >> Hi all,
> > >>
> > >> Dear wayland devs, I have a question regarding to double `wl_buffer`
> > >> management. I don't seem to have wl_buffer released untill some other  
> > events  
> > >> triggered (for example, the  inputs). My current environment is under
> > >> `X11-backend` and a libweston based compositor.
> > >>
> > >> My pipeline follows: (frame, attach, damage, commit) -> buffer switch ->
> > >> wait until one buffer available -> redraw. The `done` event is handled
> > >> differently since it only signals if ready to draw.
> > >>
> > >> Through my experiments, I found out at I wouldn't get either of the
> > >> `release` of `frame done` event if I wasn't using the compositor (moving
> > >> cursor or typing). In this case I guess there is something wrong with my
> > >> pipeline but I couldn't figure out which. I wish to know if there is  
> > obvious  
> > >> mistakes in my pipeline or the problem lies in the compositor.
> > >>
> > >>  Very appreciate any answers.
> > >>
> > >> SZ
> > >>
> > >>
> > >>
> > >> ___
> > >> wayland-devel mailing list
> > >> wayland-devel@lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > >>  
> >  



pgpiBBKRm5t4e.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Proposal: use of xdg-shell popups outside of xdg-shell

[Pekka Paalanen]

On Tue, 13 Mar 2018 09:29:30 -0400
Drew DeVault  wrote:

> Hi there! Over at the wlroots project we're thinking about repurposing
> xdg-shell popups for use in another protocol that needs popups. The
> popup interface is somewhat complex and duplicating it for each protocol
> that might want to support popups is less than ideal.
> 
> From an API perspective, both xdg positioner and xdg popup look easily
> reused with parents other than xdg toplevel. Everything is cleanly
> separated in xdg shell to accomodate for this. The only real issue is
> this line:
> 
> https://github.com/wayland-project/wayland-protocols/blob/master/stable/xdg-shell/xdg-shell.xml#L1010
> 
> I propose simply dropping this comment from the protocol description.
> It's a backwards- and forwards-compatible change, and there's no
> compelling API-driven reason not to permit the reuse of xdg popups
> elsewhere. Would definitely simplify the implementation of our new
> protocol and future protocols that could use them.

Hi,

just checking, how did you design your own protocol extension to take
advantage of xdg_popup? I mean, mechanically, what does the protocol
request sequence look like when you create an xdp_popup for your own
purpose?

I'm asking because there is a pretty subtle and horrible catch if it's
done "wrong". Having your own protocol extension include a request that
creates a protocol object of type xdg_popup is the wrong way. There are
other ways to do it without accidentally freezing the xdp_popup
interface for all eternity.


Thanks,
pq


pgplnhvPTox55.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel