[PATCH weston 1/2] Fix build breakage when using older gbm lacking dmabuf import
The buildbots discovered this issue on Ubuntu 14.04, which carries
libgbm 10.1.3-0ubuntu0.4. The dmabuf changes need gbm 10.2, so it fails
during build like this:
src/compositor-drm.c: In function ‘drm_output_prepare_overlay_view’:
src/compositor-drm.c:984:10: error: variable ‘gbm_dmabuf’ has
initializer but incomplete type
struct gbm_import_fd_data gbm_dmabuf = {
^
etc.
Proposed fix is to conditionalize the gbm fd import feature in
compositor-drm.
This fix was suggested by daniels. I set up a synthetic test
environment to reproduce the issue as found by the buildbots and tweaked
the patch to get it to build both with and without gbm 10.2.
Signed-off-by: Bryce Harrington
---
configure.ac | 3 +++
src/compositor-drm.c | 4
2 files changed, 7 insertions(+)
diff --git a/configure.ac b/configure.ac
index 0f74581..e610e2d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -172,6 +172,9 @@ AM_CONDITIONAL(ENABLE_DRM_COMPOSITOR, test
x$enable_drm_compositor = xyes)
if test x$enable_drm_compositor = xyes; then
AC_DEFINE([BUILD_DRM_COMPOSITOR], [1], [Build the DRM compositor])
PKG_CHECK_MODULES(DRM_COMPOSITOR, [libudev >= 136 libdrm >= 2.4.30 gbm mtdev
>= 1.1.0])
+ PKG_CHECK_MODULES(DRM_COMPOSITOR_GBM, [gbm >= 10.2],
+ [AC_DEFINE([HAVE_GBM_FD_IMPORT], 1, [gbm supports dmabuf
import])],
+ [AC_MSG_WARN([gbm does not support dmabuf import, will omit
that capability])])
fi
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 1bfe263..26f0012 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -974,6 +974,7 @@ drm_output_prepare_overlay_view(struct drm_output *output,
return NULL;
if ((dmabuf = linux_dmabuf_buffer_get(buffer_resource))) {
+#ifdef HAVE_GBM_FD_IMPORT
/* XXX: TODO:
*
* Use AddFB2 directly, do not go via GBM.
@@ -994,6 +995,9 @@ drm_output_prepare_overlay_view(struct drm_output *output,
bo = gbm_bo_import(b->gbm, GBM_BO_IMPORT_FD, &gbm_dmabuf,
GBM_BO_USE_SCANOUT);
+#else
+ return NULL;
+#endif
} else {
bo = gbm_bo_import(b->gbm, GBM_BO_IMPORT_WL_BUFFER,
buffer_resource, GBM_BO_USE_SCANOUT);
--
1.9.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 2/2] Fix armhf configure breakage due to missing libdrm_intel package
The buildbots discovered that recent changes break on Ubuntu 15.04's armhf images: configure:16137: checking for SIMPLE_DMABUF_CLIENT configure:16144: $PKG_CONFIG --exists --print-errors "wayland-client libdrm libdrm_intel" Package libdrm_intel was not found in the pkg-config search path. ... configure:16194: error: Package requirements (wayland-client libdrm libdrm_intel) were not met: No package 'libdrm_intel' found This patch was provided by Daniel Stone. I've not tested it other than verifying it does not cause build problems on x86_64. Acked-by: Bryce Harrington Signed-off-by: Bryce Harrington --- configure.ac | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index e610e2d..64d2d13 100644 --- a/configure.ac +++ b/configure.ac @@ -341,11 +341,15 @@ fi AC_ARG_ENABLE(simple-intel-dmabuf-client, AS_HELP_STRING([--disable-simple-intel-dmabuf-client], [do not build the simple intel dmabuf client]),, - enable_simple_intel_dmabuf_client="yes") -AM_CONDITIONAL(BUILD_SIMPLE_INTEL_DMABUF_CLIENT, test "x$enable_simple_intel_dmabuf_client" = "xyes") -if test "x$enable_simple_intel_dmabuf_client" = "xyes"; then - PKG_CHECK_MODULES(SIMPLE_DMABUF_CLIENT, [wayland-client libdrm libdrm_intel]) + enable_simple_intel_dmabuf_client="auto") +if ! test "x$enable_simple_intel_dmabuf_client" = "xno"; then + PKG_CHECK_MODULES(SIMPLE_DMABUF_CLIENT, [wayland-client libdrm libdrm_intel], + have_simple_dmabuf_client=yes, have_simple_dmabuf_client=no) + if test "x$have_simple_dmabuf_client" = "xno" -a "x$enable_simple_intel_dmabuf_client" = "xyes"; then +AC_MSG_ERROR([Intel dmabuf client explicitly enabled, but libdrm_intel couldn't be found]) + fi fi +AM_CONDITIONAL(BUILD_SIMPLE_INTEL_DMABUF_CLIENT, test "x$enable_simple_intel_dmabuf_client" = "xyes") AC_ARG_ENABLE(clients, [ --enable-clients],, enable_clients=yes) AM_CONDITIONAL(BUILD_CLIENTS, test x$enable_clients = xyes) -- 1.9.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default
Hi, > thanks, and sorry I didn't see your reply before I pushed. :-D So this commit totally broke gtk+. Thread 1 (Thread 0x7f3813651980 (LWP 537)): #0 g_logv (log_domain=0x7f38128b01ce "Gdk", log_level=G_LOG_LEVEL_ERROR, format=, args=) at ../../glib/gmessages.c:1078 #1 0x7f380edd30cd in wl_log (fmt=fmt@entry=0x7f380edd31b8 "error: WAYLAND_DISPLAY not set in the environment.\n") at ../src/wayland-util.c:385 #2 0x7f380edd0115 in connect_to_socket (name=0x0) at ../src/wayland-client.c:768 #3 wl_display_connect (name=name@entry=0x0) at ../src/wayland-client.c:899 #4 0x7f38128a5f7e in _gdk_wayland_display_open (display_name=0x0) at ../../../gdk/wayland/gdkdisplay-wayland.c:443 #5 0x7f381285b357 in gdk_display_manager_open_display (manager=, name=0x0) at ../../gdk/gdkdisplaymanager.c:463 #6 0x7f3812d24c10 in gtk_init_check (argc=, argv=) at ../../gtk/gtkmain.c:1011 #7 0x7f3812d24c49 in gtk_init (argc=, argv=) at ../../gtk/gtkmain.c:1068 #8 0x00400e11 in main (argc=0, argv=0x0) at ../../tools/gnome-session-check-accelerated.c:121 gtk+ treats wl_log messages as fatal errors. See this commit from krh: https://git.gnome.org/browse/gtk+/commit/?id=4252ac6d6ce2a02efa0991fc0723f9522aff7a0f Gtk+ also uses its wayland backend by default, so after this change, it now dies instead of falings back to the x11 backend on non-wayland sessions. I've filed https://bugzilla.gnome.org/show_bug.cgi?id=753635 to change gtk+'s default behavior to treat wayland errors as debug messages now. Still, I think this change is wrong headed. We've been trying to cleave ourselves from environment variables for years in the default case. Having to set this seems like a step backward. This means having to jump through additional hoops when using systemd --user sessions, it means having to jump through an additional hoop when running a program from a VT, and it means having to jump through an additional hoop when ssh'ing in to debug something. if a user runs a program it should show up on the default display in a clean environment. save the environment variables for fringe cases like nested compositors. The problem purportedly getting fixed gives this as a rationale: > Now suppose you launch Weston while running the Gnome session. Suddenly, all > of the Gtk+ apps > launched from Gnome will show up inside Weston instead. That's unexpected. > There's also no good > way to prevent that from happening (other than perhaps setting > WAYLAND_DISPLAY to an invalid value > when launching an app). It's wrong to say there's no good way to prevent programs from launching on weston. This corner case, can be covered by setting the GDK_BACKEND environment variable. edge cases should use environment variables not the default case. Furthermore, the commit says it's trying to fix a scenario where the user is logged into X, but the commit actually breaks X logins (because of the above log handler issue)! That means it wasn't tested. I don't think the commit is good idea at all, can we revert it ? XDG_RUNTIME_DIR is supposed to free us from other environment variables. --Ray ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v2 0/8] Generic Wayland dmabuf protocol
On Wed, 1 Jul 2015 17:56:12 +0300 Pekka Paalanen wrote: > From: Pekka Paalanen > > Hi all, > > here is the v2 iteration of the Wayland protocol extension for generic sharing > of dmabufs between clients and the compositor. > > The RFCv1 can be found at > http://lists.freedesktop.org/archives/wayland-devel/2014-December/019006.html > > The related tracking bug is > https://bugs.freedesktop.org/show_bug.cgi?id=83881 > > > The major changes compared to RFCv1 are: > - use drm_fourcc.h to define format codes > - support FB modifiers and y-flip > - simplified protocol > - improved documentation > - flags for interlaced buffer content > > As you can see, we have dropped the "RFC" status from this series now. We > think > this is in a good enough shape to be merged into Weston as an experimental > protocol and implementation. Obviously we are still lacking on: > - agreed ways to flush caches (what can we cache? EGLImages? DRM FBs?) > - enumerating supported formats > - supported FB modifiers? > - do all imports in compositor before-hand, not as-needed > (the import as DRM FB) > - EGL doesn't support dmabuf import with modifiers yet > - a test application not specific to (Intel) hardware (vivid?) > - compositor-drm.c's import of dmabuf needs a rewrite to bypass GBM > (to be done after atomic lands) > - compositor-drm.c support for multi-planar buffers > > This patch series is also available at: > https://git.collabora.com/cgit/user/pq/weston.git/log/?h=dmabuf-v2 > > Cc: Daniel Stone > Cc: Louis-Francis Ratté-Boulianne > Cc: Benjamin Gaignard > Cc: Axel Davy > Cc: linaro-mm-...@lists.linaro.org > Cc: Daniel Vetter > Cc: Thomas Hellstrom > Cc: Rob Clark > Cc: George Kiagiadakis > > George Kiagiadakis (1): > clients: add simple-dmabuf client > > Louis-Francis Ratté-Boulianne (1): > gl-renderer: introduce struct egl_image > > Pekka Paalanen (6): > protocol: add linux_dmabuf extension (v2) > dmabuf: implement linux_dmabuf extension > gl-renderer: add dmabuf import > compositor-x11: init linux_dmabuf support > compositor-drm: init linux_dmabuf support > compositor-drm: dmabuf GBM import > > .gitignore| 1 + > Makefile.am | 25 +- > clients/simple-dmabuf.c | 591 > ++ > configure.ac | 10 + > protocol/linux-dmabuf.xml | 279 ++ > src/compositor-drm.c | 49 +++- > src/compositor-x11.c | 7 + > src/compositor.c | 28 +++ > src/compositor.h | 9 + > src/gl-renderer.c | 303 +++- > src/linux-dmabuf.c| 497 ++ > src/linux-dmabuf.h| 84 +++ > src/weston-egl-ext.h | 16 ++ > 13 files changed, 1885 insertions(+), 14 deletions(-) > create mode 100644 clients/simple-dmabuf.c > create mode 100644 protocol/linux-dmabuf.xml > create mode 100644 src/linux-dmabuf.c > create mode 100644 src/linux-dmabuf.h > Hi all, with Daniel Vetter's and Carlos Olmedo Escobar's comments addressed, v3 (a trivial rebase) of this series is now pushed to Weston: f3c8336..5386898 master -> master We can continue testing, developing, and changing the dmabuf protocol in Weston until we are happy with it. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] ivi-shell: bugfix, list of surfaces on a layer are cumulated when set render order is called several time in one commitchanges.
On Wed, 5 Aug 2015 16:00:57 +0900
Nobuhiko Tanibata wrote:
> The final list of surfaces of set render order shall be applied. So link
> of surfaces and list of surfaces in a layer shall be initialized. And
> then the order of surfaces shall be restructured.
>
> Signed-off-by: Nobuhiko Tanibata
> ---
> ivi-shell/ivi-layout.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> index bb175b0..2b61ff2 100644
> --- a/ivi-shell/ivi-layout.c
> +++ b/ivi-shell/ivi-layout.c
> @@ -2082,14 +2082,14 @@ ivi_layout_layer_set_render_order(struct
> ivi_layout_layer *ivilayer,
> return IVI_FAILED;
> }
>
> - if (pSurface == NULL) {
> - wl_list_for_each_safe(ivisurf, next,
> &ivilayer->pending.surface_list, pending.link) {
> - if (!wl_list_empty(&ivisurf->pending.link)) {
> - wl_list_remove(&ivisurf->pending.link);
> - }
> + wl_list_for_each_safe(ivisurf, next,
> + &ivilayer->pending.surface_list, pending.link) {
> + wl_list_init(&ivisurf->pending.link);
> + }
>
> - wl_list_init(&ivisurf->pending.link);
> - }
> + wl_list_init(&ivilayer->pending.surface_list);
Hi,
heh, I don't recall seeing this code pattern before. It looks fragile
or even dangerous, because it is init'ing a link that is part of a
list, and doing that while traversing that list. However, I think it is
safe in this case, because:
- wl_list_for_each_safe protects against removal of the current item by
fetching the pointer to the next item before-hand, so init'ing rather
than removing the current item is still ok, and
- the whole list is always processed through, and finally the list head
is init'd, so all involved pointers are reset.
I've been using another pattern, e.g. src/rpi-renderer.c:1768
while (!wl_list_empty(&output->view_cleanup_list)) {
view = container_of(output->view_cleanup_list.next,
struct rpir_view, link);
rpir_view_destroy(view);
}
I'm not sure if we should prefer one or the other, because I'm
obviously biased in my judgement. :-)
The latter one does not involve temporarily broken list structures...
> +
> + if (pSurface == NULL || number ==0) {
> ivilayer->event_mask |= IVI_NOTIFICATION_REMOVE;
> return IVI_SUCCEEDED;
> }
Reviewed-by: Pekka Paalanen
Thanks,
pq
pgp67rMgTaLKk.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default
On Thu, 13 Aug 2015 13:12:42 +1000 Peter Hutterer wrote: > On Wed, Aug 12, 2015 at 02:41:08PM +0300, Pekka Paalanen wrote: > > On Mon, 25 May 2015 01:12:15 -0700 > > Dima Ryazanov wrote: > > > > > Although defaulting to wayland-0 seems convenient, it has an undesirable > > > side effect: clients may unintentionally connect to the wrong compositor. > > > Generally, it's safer to fail instead. Here's a real example: ... > > > > gathering the comments from the thread, it seems we have Acked-bys from: > > Pekka Paalanen > > Giulio Camuffo > > Daniel Stone > > "Jasper St. Pierre" > > > > Seems like a pretty strong set. Would you like to send a non-RFC > > version of this patch? > > > > I think you can include also the above Acked-bys. > > if you need another vote to tilt the favours, you can add > Acked-by: Peter Hutterer > > sorry, didn't see this earlier. Hi Peter, thanks, and sorry I didn't see your reply before I pushed. :-D - pq pgpA_ZKnfYc2T.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default
Oh, you're right, I didn't realize that's what that code was doing.
Thanks!
On Fri, Aug 14, 2015 at 12:20 AM, Pekka Paalanen
wrote:
> On Wed, 12 Aug 2015 19:34:31 -0700
> Dima Ryazanov wrote:
>
> > Although defaulting to wayland-0 seems convenient, it has an undesirable
> > side effect: clients may unintentionally connect to the wrong compositor.
> > Generally, it's safer to fail instead. Here's a real example:
> >
> > In Fedora 22, Gtk+ prefers Wayland over X11, though the default session
> is still
> > a normal X11 Gnome session. When you launch a Gtk+ app, it will try
> Wayland,
> > fail, then try X11, and succesfully start up. That works fine.
> >
> > Now suppose you launch Weston while running the Gnome session. Suddenly,
> all
> > of the Gtk+ apps launched from Gnome will show up inside Weston instead.
> > That's unexpected. There's also no good way to prevent that from
> happening
> > (other than perhaps setting WAYLAND_DISPLAY to an invalid value when
> launching
> > an app).
> >
> > Not using wayland-0 as the default will solve that problem: an app
> launched
> > from the X11 Gnome session will use the X11 backend regardless of whether
> > there's a wayland compositor running at the same time.
> >
> > Everything else should work as before. The compositor already sets
> > the WAYLAND_DISPLAY when starting the session, so the lack of the
> default value
> > should not make a difference to the user.
> >
> > Signed-off-by: Dima Ryazanov
> > Acked-by: Pekka Paalanen
> > Acked-by: Giulio Camuffo
> > Acked-by: Daniel Stone
> > Acked-by: Jasper St. Pierre
> > ---
> > doc/man/wl_display_connect.xml| 5 ++---
> > doc/publican/sources/Protocol.xml | 8
> > src/wayland-client.c | 10 ++
> > src/wayland-server.c | 6 +++---
> > 4 files changed, 15 insertions(+), 14 deletions(-)
> >
> > diff --git a/doc/man/wl_display_connect.xml
> b/doc/man/wl_display_connect.xml
> > index 7e6e05c..ded3cbd 100644
> > --- a/doc/man/wl_display_connect.xml
> > +++ b/doc/man/wl_display_connect.xml
> > @@ -57,9 +57,8 @@
> >that was previously opened by a Wayland server. The server
> socket must
> >be placed in XDG_RUNTIME_DIR for this function
> to
> >find it. The name argument specifies the
> name of
> > - the socket or NULL to use the default
> (which is
> > - "wayland-0"). The environment variable
> > - WAYLAND_DISPLAY replaces the default value. If
> > + the socket or NULL to use the default
> > + (which is the value of WAYLAND_DISPLAY). If
> >WAYLAND_SOCKET is set, this function behaves
> like
> >wl_display_connect_to_fd with the
> file-descriptor
> >number taken from the environment variable.
> > diff --git a/doc/publican/sources/Protocol.xml
> b/doc/publican/sources/Protocol.xml
> > index 477063b..9464953 100644
> > --- a/doc/publican/sources/Protocol.xml
> > +++ b/doc/publican/sources/Protocol.xml
> > @@ -60,10 +60,10 @@
> > Wire Format
> >
> >The protocol is sent over a UNIX domain stream socket, where the
> endpoint
> > - usually is named class="service">wayland-0
> > - (although it can be changed via
> WAYLAND_DISPLAY
> > - in the environment). The protocol is message-based. A
> > - message sent by a client to the server is called request. A
> message
> > + name is determined by the WAYLAND_DISPLAY
> > + environment variable. Its value will usually be
> > + wayland-0. The protocol
> is message-based.
> > + A message sent by a client to the server is called request. A
> message
> >from the server to a client is called event. Every message is
> >structured as 32-bit words, values are represented in the host's
> >byte-order.
> > diff --git a/src/wayland-client.c b/src/wayland-client.c
> > index 09c594a..ffbca4b 100644
> > --- a/src/wayland-client.c
> > +++ b/src/wayland-client.c
> > @@ -764,8 +764,11 @@ connect_to_socket(const char *name)
> >
> > if (name == NULL)
> > name = getenv("WAYLAND_DISPLAY");
> > - if (name == NULL)
> > - name = "wayland-0";
> > + if (name == NULL) {
> > + wl_log("error: WAYLAND_DISPLAY not set in the
> environment.\n");
> > + errno = ENOENT;
> > + return -1;
> > + }
> >
> > fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
> > if (fd < 0)
> > @@ -869,8 +872,7 @@ wl_display_connect_to_fd(int fd)
> > * \return A \ref wl_display object or \c NULL on failure
> > *
> > * Connect to the Wayland display named \c name. If \c name is \c NULL,
> > - * its value will be replaced with the WAYLAND_DISPLAY environment
> > - * variable if it is set, otherwise display "wayland-0" will be used.
> > + * its value will be replaced with the WAYLAND_DISPLAY environment
> variable.
> > *
> > * \memberof wl_display
> > */
>
> Hi,
>
> this patch is Re
Re: [PATCH wayland] Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default
On Wed, 12 Aug 2015 19:34:31 -0700
Dima Ryazanov wrote:
> Although defaulting to wayland-0 seems convenient, it has an undesirable
> side effect: clients may unintentionally connect to the wrong compositor.
> Generally, it's safer to fail instead. Here's a real example:
>
> In Fedora 22, Gtk+ prefers Wayland over X11, though the default session is
> still
> a normal X11 Gnome session. When you launch a Gtk+ app, it will try Wayland,
> fail, then try X11, and succesfully start up. That works fine.
>
> Now suppose you launch Weston while running the Gnome session. Suddenly, all
> of the Gtk+ apps launched from Gnome will show up inside Weston instead.
> That's unexpected. There's also no good way to prevent that from happening
> (other than perhaps setting WAYLAND_DISPLAY to an invalid value when launching
> an app).
>
> Not using wayland-0 as the default will solve that problem: an app launched
> from the X11 Gnome session will use the X11 backend regardless of whether
> there's a wayland compositor running at the same time.
>
> Everything else should work as before. The compositor already sets
> the WAYLAND_DISPLAY when starting the session, so the lack of the default
> value
> should not make a difference to the user.
>
> Signed-off-by: Dima Ryazanov
> Acked-by: Pekka Paalanen
> Acked-by: Giulio Camuffo
> Acked-by: Daniel Stone
> Acked-by: Jasper St. Pierre
> ---
> doc/man/wl_display_connect.xml| 5 ++---
> doc/publican/sources/Protocol.xml | 8
> src/wayland-client.c | 10 ++
> src/wayland-server.c | 6 +++---
> 4 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/doc/man/wl_display_connect.xml b/doc/man/wl_display_connect.xml
> index 7e6e05c..ded3cbd 100644
> --- a/doc/man/wl_display_connect.xml
> +++ b/doc/man/wl_display_connect.xml
> @@ -57,9 +57,8 @@
>that was previously opened by a Wayland server. The server socket
> must
>be placed in XDG_RUNTIME_DIR for this function to
>find it. The name argument specifies the name of
> - the socket or NULL to use the default (which
> is
> - "wayland-0"). The environment variable
> - WAYLAND_DISPLAY replaces the default value. If
> + the socket or NULL to use the default
> + (which is the value of WAYLAND_DISPLAY). If
>WAYLAND_SOCKET is set, this function behaves like
>wl_display_connect_to_fd with the
> file-descriptor
>number taken from the environment variable.
> diff --git a/doc/publican/sources/Protocol.xml
> b/doc/publican/sources/Protocol.xml
> index 477063b..9464953 100644
> --- a/doc/publican/sources/Protocol.xml
> +++ b/doc/publican/sources/Protocol.xml
> @@ -60,10 +60,10 @@
> Wire Format
>
>The protocol is sent over a UNIX domain stream socket, where the
> endpoint
> - usually is named wayland-0
> - (although it can be changed via WAYLAND_DISPLAY
> - in the environment). The protocol is message-based. A
> - message sent by a client to the server is called request. A message
> + name is determined by the WAYLAND_DISPLAY
> + environment variable. Its value will usually be
> + wayland-0. The protocol is
> message-based.
> + A message sent by a client to the server is called request. A message
>from the server to a client is called event. Every message is
>structured as 32-bit words, values are represented in the host's
>byte-order.
> diff --git a/src/wayland-client.c b/src/wayland-client.c
> index 09c594a..ffbca4b 100644
> --- a/src/wayland-client.c
> +++ b/src/wayland-client.c
> @@ -764,8 +764,11 @@ connect_to_socket(const char *name)
>
> if (name == NULL)
> name = getenv("WAYLAND_DISPLAY");
> - if (name == NULL)
> - name = "wayland-0";
> + if (name == NULL) {
> + wl_log("error: WAYLAND_DISPLAY not set in the environment.\n");
> + errno = ENOENT;
> + return -1;
> + }
>
> fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
> if (fd < 0)
> @@ -869,8 +872,7 @@ wl_display_connect_to_fd(int fd)
> * \return A \ref wl_display object or \c NULL on failure
> *
> * Connect to the Wayland display named \c name. If \c name is \c NULL,
> - * its value will be replaced with the WAYLAND_DISPLAY environment
> - * variable if it is set, otherwise display "wayland-0" will be used.
> + * its value will be replaced with the WAYLAND_DISPLAY environment variable.
> *
> * \memberof wl_display
> */
Hi,
this patch is Reviewed-by me up to this point, but I don't agree with
the below change to wayland-server.c as part of this patch.
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index 0f04f66..1ea53f9 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -1209,8 +1209,8 @@ wl_display_add_socket_auto(struct wl_display *display)
> * connect to Wayland d
Re: [PATCH wayland] Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default
So, it seems like pretty much everyone agrees with this change. Could we
actually get it in for the 1.9 release?
On Thu, Aug 13, 2015 at 4:47 AM, Ryo Munakata wrote:
> On Wed, 12 Aug 2015 19:34:31 -0700
> Dima Ryazanov wrote:
>
> Hi Dima.
>
> Reviewed-by: Ryo Munakata
>
> Thanks.
>
> > Although defaulting to wayland-0 seems convenient, it has an undesirable
> > side effect: clients may unintentionally connect to the wrong compositor.
> > Generally, it's safer to fail instead. Here's a real example:
> >
> > In Fedora 22, Gtk+ prefers Wayland over X11, though the default session
> is still
> > a normal X11 Gnome session. When you launch a Gtk+ app, it will try
> Wayland,
> > fail, then try X11, and succesfully start up. That works fine.
> >
> > Now suppose you launch Weston while running the Gnome session. Suddenly,
> all
> > of the Gtk+ apps launched from Gnome will show up inside Weston instead.
> > That's unexpected. There's also no good way to prevent that from
> happening
> > (other than perhaps setting WAYLAND_DISPLAY to an invalid value when
> launching
> > an app).
> >
> > Not using wayland-0 as the default will solve that problem: an app
> launched
> > from the X11 Gnome session will use the X11 backend regardless of whether
> > there's a wayland compositor running at the same time.
> >
> > Everything else should work as before. The compositor already sets
> > the WAYLAND_DISPLAY when starting the session, so the lack of the
> default value
> > should not make a difference to the user.
> >
> > Signed-off-by: Dima Ryazanov
> > Acked-by: Pekka Paalanen
> > Acked-by: Giulio Camuffo
> > Acked-by: Daniel Stone
> > Acked-by: Jasper St. Pierre
> > ---
> > doc/man/wl_display_connect.xml| 5 ++---
> > doc/publican/sources/Protocol.xml | 8
> > src/wayland-client.c | 10 ++
> > src/wayland-server.c | 6 +++---
> > 4 files changed, 15 insertions(+), 14 deletions(-)
> >
> > diff --git a/doc/man/wl_display_connect.xml
> b/doc/man/wl_display_connect.xml
> > index 7e6e05c..ded3cbd 100644
> > --- a/doc/man/wl_display_connect.xml
> > +++ b/doc/man/wl_display_connect.xml
> > @@ -57,9 +57,8 @@
> >that was previously opened by a Wayland server. The server
> socket must
> >be placed in XDG_RUNTIME_DIR for this function
> to
> >find it. The name argument specifies the
> name of
> > - the socket or NULL to use the default
> (which is
> > - "wayland-0"). The environment variable
> > - WAYLAND_DISPLAY replaces the default value. If
> > + the socket or NULL to use the default
> > + (which is the value of WAYLAND_DISPLAY). If
> >WAYLAND_SOCKET is set, this function behaves
> like
> >wl_display_connect_to_fd with the
> file-descriptor
> >number taken from the environment variable.
> > diff --git a/doc/publican/sources/Protocol.xml
> b/doc/publican/sources/Protocol.xml
> > index 477063b..9464953 100644
> > --- a/doc/publican/sources/Protocol.xml
> > +++ b/doc/publican/sources/Protocol.xml
> > @@ -60,10 +60,10 @@
> > Wire Format
> >
> >The protocol is sent over a UNIX domain stream socket, where the
> endpoint
> > - usually is named class="service">wayland-0
> > - (although it can be changed via
> WAYLAND_DISPLAY
> > - in the environment). The protocol is message-based. A
> > - message sent by a client to the server is called request. A
> message
> > + name is determined by the WAYLAND_DISPLAY
> > + environment variable. Its value will usually be
> > + wayland-0. The protocol
> is message-based.
> > + A message sent by a client to the server is called request. A
> message
> >from the server to a client is called event. Every message is
> >structured as 32-bit words, values are represented in the host's
> >byte-order.
> > diff --git a/src/wayland-client.c b/src/wayland-client.c
> > index 09c594a..ffbca4b 100644
> > --- a/src/wayland-client.c
> > +++ b/src/wayland-client.c
> > @@ -764,8 +764,11 @@ connect_to_socket(const char *name)
> >
> > if (name == NULL)
> > name = getenv("WAYLAND_DISPLAY");
> > - if (name == NULL)
> > - name = "wayland-0";
> > + if (name == NULL) {
> > + wl_log("error: WAYLAND_DISPLAY not set in the
> environment.\n");
> > + errno = ENOENT;
> > + return -1;
> > + }
> >
> > fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
> > if (fd < 0)
> > @@ -869,8 +872,7 @@ wl_display_connect_to_fd(int fd)
> > * \return A \ref wl_display object or \c NULL on failure
> > *
> > * Connect to the Wayland display named \c name. If \c name is \c NULL,
> > - * its value will be replaced with the WAYLAND_DISPLAY environment
> > - * variable if it is set, otherwise display "wayland-0" will be used.
> > + * its value will be replaced with the WAYLAND_DISPLAY environmen
