[PATCH weston] Add a help string for --xwayland

[Dima Ryazanov]

Signed-off-by: Dima Ryazanov 
---
 compositor/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/compositor/main.c b/compositor/main.c
index 18810f28..1e827884 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -469,6 +469,7 @@ usage(int error_code)
"  --shell=MODULE\tShell module, defaults to desktop-shell.so\n"
"  -S, --socket=NAME\tName of socket to listen on\n"
"  -i, --idle-time=SECS\tIdle time in seconds\n"
+   "  --xwayland\t\tLoad the xwayland module\n"
"  --modules\t\tLoad the comma-separated list of modules\n"
"  --log=FILE\t\tLog to the given file\n"
"  -c, --config=FILE\tConfig file to load, defaults to 
weston.ini\n"
-- 
2.14.3

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

2018 X.Org Foundation Election Candidates

[Rob Clark]

To all X.Org Foundation Members:

The election for the X.Org Foundation Board of Directors will begin on
22 March 2018. We have 6 candidates who are running for 4 seats. They
are (in alphabetical order):

Eric Anholt
Robert Foss
Bryce Harrington
Keith Packard
Laurent Pinchart
Harry Wentland


Attached below are the Personal Statements each candidate submitted
for your consideration along with their Statements of Contribution
that they submitted with the membership application. Please review
each of the candidates' statements to help you decide whom to vote for
during the upcoming election.

If you have questions of the candidates, you should feel free to ask
them here on the mailing list.

The election committee will provide detailed instructions on how the
voting system will work when the voting period begins.

Rob Clark,
on behalf of the X.Org elections committee



Eric Anholt
Current Affiliation: Broadcom

Personal Statement:
Being on the X.Org Foundation board is primarily a non-technical
position, managing the funds, conferences, and mentoring activities of
the project. Our board has been doing an excellent job on improving
those systems over time, and I'm ready to help out with them again. My
interest is in continuing to reduce the barrier to entry to our
projects and encouraging a welcoming environment for all contributors.



Robert Foss
Current Affiliation: Collabora

Statement of Contribution:
I've contributed to various X.Org projects, spoken publicly about
using the X.Org stack instead of prorietary ones and worked towards
migrating features for new usecases to the X.Org stack. Additionally
I've worked towards migrating graphics stack projects, like
drm_hwcomposer into X.Org.

Personal Statement:
Before having contributed any lines of code to any X.Org project, I
went to XDC which demonstrated not only what a nice community the
X.Org is but also what technically is around the corner, and what
needs more attention.

As a professional working inside the X.Org sphere I'm going to
continue to work towards harmonizing various projects and increasing
compatability, with the goal of growing the community, making the
individual projects easier to adopt and reducing the need for forks.

If elected I would like to work towards lowering the bar of entry for
new developers by providing support for mordern workflows. I would
also like to provide support for having low hanging fruit for new
developers to pick, in order to attract more developers, but also in
order to provide a less steep learning curve.

But maybe more importantly I would like to contribute something back
to the X.Org community, which has been a tremendous resource to me.



Bryce Harrington
Current Affiliation: Samsung Research America

Statement of Contribution:
Inkscape, Cairo (release management, maintenance, etc.)

Personal Statement:
I am currently serving on the X.org Board as Treasurer. In this role I
helped in getting X.org registered with SPI, re-established our
donation systems and policies for individual donors and corporate
sponsors, and worked to get X.org's financial data better organized.

Professionally, I work on Cairo (maintenance, releases, general
development) and various other graphics-related FOSS technologies; In
my spare time, I run the Inkscape project and dabble in game
development.



Keith Packard
Current Affiliation: HP

Personal Statement:
The X.org board continues to perform an important role in the X
community. Over the last couple of years, the primary activities of
the board have involved organizing technical conferences and providing
funding for developers to attend both those conferences and other
important free software conferences around the world. I've been
involved in the board since the reformation of the X.org foundation.
If elected, I will continue to support free software developers
working on the X window system and related technologies.



Laurent Pinchart
Current Affiliation: Ideas on Board Oy

Statement of Contribution:
I've contributed to the Linux kernel DRM subsystem for nearly 6 years
by developing drivers, writing the initial KMS documentation,
reviewing core and driver changes and participating in design
discussions.

Personal Statement:
Since my first contributions to the Linux kernel DRM subsystem I have
approached X.org from a different perspective than many, making my way
through the stack from the bottom up, and reaching it from an embedded
ARM perspective. If elected I would like to help those once
second-class citizens in the graphics world continue to collaborate
hand-and-hand with with the rest of the ecosystem by ensuring that
they are correctly represented in the community.



Harry Wentland
Current Affiliation: AMD

Statement of Contribution:
I maintain the amdgpu DC display driver, and contributed and reviewed
patches to DRM.

Personal Statement:
Having had a fondness for open-source and Linux for more than 15 years
I jumped 

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

[Michael Tretter]

On Thu, 15 Mar 2018 14:20:21 +, Emil Velikov wrote:
> 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 ;-)
> 
> v2: auto disable systemd as dbus is missing
> 
> Cc: Michael Tretter 
> Reported-by: Michael Tretter 
> Signed-off-by: Emil Velikov 
> ---
> Thanks for the review Michael!
> 
> You're right - the else hunk is only for consistency with surrounding
> code.
> ---
>  configure.ac | 28 +---
>  1 file changed, 17 insertions(+), 11 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 0b326ccc..a3453d15 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -524,7 +524,12 @@ 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 = xyes -a x$enable_dbus = xno; then
> +  AC_MSG_ERROR([systemd-login support explicitly requested, but dbus not 
> available])
> +fi
> +
> +if test x$enable_systemd_login = xauto -a x$enable_dbus = xno; then

If systemd-login is explicitly enabled, it will not enable
systemd-login. The second condition is also wrong, because dbus must be
enabled (or auto). It should read

if test x$enable_systemd_login != xno -a x$enable_dbus != xno; then

Michael

>PKG_CHECK_MODULES(SYSTEMD_LOGIN,
>  [libsystemd >= 209],
>  [have_systemd_login_209=yes;have_systemd_login=yes],
> @@ -537,21 +542,22 @@ if test x$enable_systemd_login != xno -a x$have_dbus != 
> xno; then
>[have_systemd_login=yes],
>[have_systemd_login=no])
>  ])
> +
> +  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
> +
> +  if test "x$have_systemd_login" = "xyes"; then
> +AC_DEFINE([HAVE_SYSTEMD_LOGIN], [1], [Have systemd-login])]
> +  fi
> +
> +  AS_IF([test "x$have_systemd_login_209" = "xyes"],
> +[AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 
> 209])])
>  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
___
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]

> I understand you dislike Wayland's established window-management model
> and you wish it was the same as X11. I disagree, but that's fine.
> What's not fine, is trying to rewrite history and insulting everyone's
> intelligence. You're acting as if the consensus which has underpinned
> everything since the start of the project doesn't exist, just because
> a) you don't like it, and b) mpv doesn't have decorations so it
> invalidates everything else.

I apologise for insulting your intelligence, it was not my goal. This is
a difficult subject to have productive discourse on, because it's been a
subject of debate for a very long time and we hold very different
opinions. Our goal is to find a compromise, and this protocol is an
attempt to do that.

> Denying facts and being disingenuous doesn't help anyone, and it's
> tiring. Tiring enough that I came into this thread with the intention
> of giving this protocol a couple of suggestions and a push towards
> getting it merged, because I'm tired of the totally counterproductive
> division between wlc/wlroots/Sway/mpv and the rest of the Wayland
> world, but I've lost all motivation to continue.

This is not something wlc/wlroots/sway/mpv is pushing for alone. This
thread represents the opinions of several major players in the Wayland
ecosystem: Sway, KDE, Mir, Way Cooler, waymonad, and bspwc are all
represented here. Given this, it's difficult for me to accept that a
consensus has been reached.

It is my intention to earnestly express the opinion of our projects and
work towards a common goal. We are all on the same team here, we just
want to work together. However, if we can't agree on the issue of making
CSD mandatory for all clients, we'd rather take that then have this
protocol unmerged.

> > In fact, I have done so. Before we started working on this protocol,
> > Sway did exactly this. We have provided users the means of overriding
> > the approach to decorations, including what ends up being double
> > decorations sometimes.
> 
> OK, but that doesn't seem like the kind of user experience to aim for ... ?

Yeah, it's not ideal. The impetus for this protocol is to solve this
problem by getting software written by both camps to negotiate. It's
clear we're not going to get either side to agree to buy into the other,
so in the interests of the user we're trying to accomodate both.

> No, it really has. GTK+ has always - well, until you got the patches
> for this protocol merged a month or two ago - decorated its own
> windows under Wayland. Same with Qt. Same with EFL. These are toolkits
> which have been around and deployed for several years, doing exactly
> what I'm describing. Sticking server-side decorations on them gives
> you two completely different titlebars, and anyone trying to use it
> justifiably thinking the result is an incoherent mess.

Qt (with KDE's help) was the first toolkit to support server side
decorations - Sway adopted this protocol and sent a patch to GTK+ for
it. This is a couple of years in the works. Qt has had
QT_WAYLAND_DISABLE_WINDOWDECORATION for ages.

> Xwayland isn't a shell. Xwayland requires active co-operation from the
> compositor to act just like an X11 window manager, so X11 clients can
> display in the shell being used. X11 has very well-established means
> of doing window management via the ICCCM and EWMH, and the
> implementations I've seen try to respect those as closely as they can.

All of the shells (including xdg-shell) require active co-operation from
the compositor to display correcty.

> It is a concrete, unarguable, fact that the core Wayland protocol
> implies client-side decorations. The protocol text in this thread
> acknowledges that fact:

This isn't true. The core Wayland protocol takes no stance at all on any
kind of decorations. It's designed to accommodate for systems where CSD
doesn't even make sense, like IVI systems or phones.

I don't want to drag this on much further, what changes do we need to
make to get this merged?

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

Re: [PATCH v15 00/34] Atomic modesetting

[Thierry Reding]

On Mon, Feb 05, 2018 at 06:44:09PM +, Daniel Stone wrote:
> Hi,
> Thanks a lot to Pekka and Philipp in particular for their really
> thorough review; things seem to be looking quite positive now!
> 
> I am _mostly_ sending this for the part up until the patch which
> actually enables use of the atomic API. I believe I've handled the
> review comments on all the patches before that, including 05 which is
> new.
> 
> In 01 and 02 where we deal with unused connectors and CRTCs, we now
> implement what Pekka suggested. 01 maintains a list of every output
> which has not yet been through a repaint cycle, and patch 02 ensures
> that all these outputs are disabled on our first repaint.
> 
> (This does still have the problem Philipp mentioned, though it would be
>  trivially 'fixable' by not doing _all_ disables when we are called with
>  b->state_invalid && !b->repaint_data, i.e. are likely to be disabling a
>  single output. But it does increase my desire for a better output
>  configuration API! I guess with my work in the backend and Pekka's
>  clone-mode work as well, we at least have a far better idea what that
>  would look like now. Hm, did I say I was trying out brevity earlier
>  today? Oh well.)
> 
> 03 has seen a few cleanups and fixes, most notably using
> weston_output_update_complete() and drm_pending_state_apply_sync()
> consistently.
> 
> Following on from 05, 06 should now have clean failures on output
> creation.
> 
> 09 has much less broken state handling, with the state ownership much
> more consistently documented and enforced.
> 
> I wrote a fair bit of comment and doc verbiage to clarify
> questions/comments from review, in these earlier patches.
> 
> A few of the later patches in the series have seen relatively minor
> fixes, but nothing dramatic. There are still outstanding review comments
> from Pekka (and perhaps from Philipp as well), and Sergi has rewritten
> the IN_FORMATS blob parsing. I haven't merged these in yet, in the
> interest of trying to get the earlier part of the series out for review.
> 
> This series is available at:
>   https://gitlab.collabora.com/daniels/weston # wip/2017-02/atomic-v15
> 
> Obviously the 'drm debug' patch is not meant for inclusion or review,
> but is hopefully a useful aid to, well, debugging.
> 
> Cheers,
> Daniel

FWIW, I tested this on Tegra with some patches to the kernel to enable
the IN_FORMATS property and it all seems to work, so:

Tested-by: Thierry Reding 


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

Re: [PATCH v15 20/34] compositor-drm: Support modifiers for drm_fb

[Thierry Reding]

On Mon, Feb 05, 2018 at 06:44:29PM +, Daniel Stone wrote:
> Use the new drmModeAddFB2WithModifiers interface to import buffers with
> modifiers.
> 
> Signed-off-by: Daniel Stone 
> Reviewed-by: Pekka Paalanen 
> ---
>  configure.ac   |  3 +++
>  libweston/compositor-drm.c | 26 +-
>  2 files changed, 28 insertions(+), 1 deletion(-)

Just a drive-by comment, haven't looked at any of this in great detail.

[...]
> @@ -845,7 +846,28 @@ drm_fb_destroy_gbm(struct gbm_bo *bo, void *data)
>  static int
>  drm_fb_addfb(struct drm_fb *fb)
>  {
> - int ret;
> + int ret = -EINVAL;
> +#ifdef HAVE_DRM_ADDFB2_MODIFIERS
> + uint64_t mods[4] = { };
> + int i;

Why not make this size_t...

> +#endif
> +
> + /* If we have a modifier set, we must only use the WithModifiers
> +  * entrypoint; we cannot import it through legacy ioctls. */
> + if (fb->modifier != DRM_FORMAT_MOD_INVALID) {
> + /* KMS demands that if a modifier is set, it must be the same
> +  * for all planes. */
> +#ifdef HAVE_DRM_ADDFB2_MODIFIERS
> + for (i = 0; i < (int) ARRAY_LENGTH(mods) && fb->handles[i]; i++)

... so you can get rid of the cast here?

Thierry


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

[PATCH weston v2 0/1] Allow simple-dmabuf-drm to pass y_inverted flag

[Guido Günther]

Changes from v1

 - introduce opts as a bitmask of features that can be used to
   manipulate the displayed image

Guido Günther (1):
  Allow simple-dmabuf-drm to pass y_inverted flag

 clients/simple-dmabuf-drm.c | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

-- 
2.16.1

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

[PATCH weston v2 1/1] Allow simple-dmabuf-drm to pass y_inverted flag

[Guido Günther]

This allows to check if ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT is
interpreted correctly by the compositor.
---
 clients/simple-dmabuf-drm.c | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
index 14d716de..a6e8d870 100644
--- a/clients/simple-dmabuf-drm.c
+++ b/clients/simple-dmabuf-drm.c
@@ -59,6 +59,10 @@
 extern const unsigned nv12_tiled[];
 struct buffer;
 
+/* Possible options that affect the displayed image */
+#define OPT_Y_INVERTED 1
+
+
 struct display {
struct wl_display *display;
struct wl_registry *registry;
@@ -379,11 +383,11 @@ static const struct zwp_linux_buffer_params_v1_listener 
params_listener = {
 
 static int
 create_dmabuf_buffer(struct display *display, struct buffer *buffer,
-int width, int height, int format)
+int width, int height, int format, uint32_t opts)
 {
struct zwp_linux_buffer_params_v1 *params;
uint64_t modifier = 0;
-   uint32_t flags;
+   uint32_t flags = 0;
struct drm_device *drm_dev;
 
if (!drm_connect(buffer)) {
@@ -434,7 +438,8 @@ create_dmabuf_buffer(struct display *display, struct buffer 
*buffer,
 * correct height to the compositor.
 */
buffer->height = height;
-   flags = 0;
+   if (opts & OPT_Y_INVERTED)
+   flags |= ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT;
 
params = zwp_linux_dmabuf_v1_create_params(display->dmabuf);
zwp_linux_buffer_params_v1_add(params,
@@ -517,7 +522,8 @@ static const struct zxdg_toplevel_v6_listener 
xdg_toplevel_listener = {
 };
 
 static struct window *
-create_window(struct display *display, int width, int height, int format)
+create_window(struct display *display, int width, int height, int format,
+ uint32_t opts)
 {
struct window *window;
int i;
@@ -566,7 +572,7 @@ create_window(struct display *display, int width, int 
height, int format)
 
for (i = 0; i < NUM_BUFFERS; ++i) {
ret = create_dmabuf_buffer(display, >buffers[i],
-  width, height, format);
+  width, height, format, opts);
 
if (ret < 0)
return NULL;
@@ -814,13 +820,15 @@ print_usage_and_exit(void)
printf("usage flags:\n"
"\t'--import-immediate=<>'\n\t\t0 to import dmabuf via 
roundtrip,"
"\n\t\t1 to enable import without roundtrip\n"
+   "\t'--y-inverted=<>'\n\t\t0 to not pass Y_INVERTED flag,"
+   "\n\t\t1 to pass Y_INVERTED flag\n"
"\t'--import-format=<>'\n\t\tXRGB to import dmabuf as XRGB,"
"\n\t\tNV12 to import as multi plane NV12 with tiling 
modifier\n");
exit(0);
 }
 
 static int
-is_import_mode_immediate(const char* c)
+is_true(const char* c)
 {
if (!strcmp(c, "1"))
return 1;
@@ -852,22 +860,29 @@ main(int argc, char **argv)
struct display *display;
struct window *window;
int is_immediate = 0;
+   int opts = 0;
int import_format = DRM_FORMAT_XRGB;
int ret = 0, i = 0;
 
if (argc > 1) {
static const char import_mode[] = "--import-immediate=";
static const char format[] = "--import-format=";
+   static const char y_inverted[] = "--y-inverted=";
for (i = 1; i < argc; i++) {
if (!strncmp(argv[i], import_mode,
 sizeof(import_mode) - 1)) {
-   is_immediate = is_import_mode_immediate(argv[i]
+   is_immediate = is_true(argv[i]
+ sizeof(import_mode) - 
1);
}
else if (!strncmp(argv[i], format, sizeof(format) - 1)) 
{
import_format = parse_import_format(argv[i]
+ sizeof(format) - 1);
}
+   else if (!strncmp(argv[i], y_inverted,
+ sizeof(y_inverted) - 1)) {
+   if (is_true(argv[i] + sizeof(y_inverted) - 1))
+   opts |= OPT_Y_INVERTED;
+   }
else {
print_usage_and_exit();
}
@@ -875,7 +890,7 @@ main(int argc, char **argv)
}
 
display = create_display(is_immediate, import_format);
-   window = create_window(display, 256, 256, import_format);
+   window = create_window(display, 256, 256, import_format, opts);
if (!window)
return 1;
 
-- 
2.16.1

___

[PATCH weston v2 4/4] simple-dmabuf-drm: support etnaviv drm as well

[Guido Günther]

---
 Makefile.am |  1 +
 clients/simple-dmabuf-drm.c | 73 +
 configure.ac|  5 +++-
 3 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index c2d448e7..19319fa2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -626,6 +626,7 @@ nodist_weston_simple_dmabuf_drm_SOURCES =   \
 weston_simple_dmabuf_drm_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_DMABUF_DRM_CLIENT_CFLAGS)
 weston_simple_dmabuf_drm_LDADD = $(SIMPLE_DMABUF_DRM_CLIENT_LIBS) \
$(LIBDRM_PLATFORM_FREEDRENO_LIBS) \
+   $(LIBDRM_PLATFORM_ETNAVIV_LIBS)   \
$(LIBDRM_PLATFORM_INTEL_LIBS) \
libshared.la
 endif
diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
index 492c9667..a445ffb2 100644
--- a/clients/simple-dmabuf-drm.c
+++ b/clients/simple-dmabuf-drm.c
@@ -48,6 +48,9 @@
 #ifdef HAVE_LIBDRM_FREEDRENO
 #include 
 #endif
+#ifdef HAVE_LIBDRM_ETNAVIV
+#include 
+#endif
 #include 
 
 #include 
@@ -101,6 +104,10 @@ struct buffer {
struct fd_device *fd_dev;
struct fd_bo *fd_bo;
 #endif /* HAVE_LIBDRM_FREEDRENO */
+#if HAVE_LIBDRM_ETNAVIV
+   struct etna_device *etna_dev;
+   struct etna_bo *etna_bo;
+#endif /* HAVE_LIBDRM_ETNAVIV */
 
uint32_t gem_handle;
int dmabuf_fd;
@@ -264,6 +271,62 @@ fd_device_destroy(struct buffer *buf)
fd_device_del(buf->fd_dev);
 }
 #endif /* HAVE_LIBDRM_FREEDRENO */
+#ifdef HAVE_LIBDRM_ETNAVIV
+#define ROUND_DOWN(v, a) ((v) & ~(a - 1))
+
+static int
+etna_alloc_bo(struct buffer *buf)
+{
+   int flags = DRM_ETNA_GEM_CACHE_WC;
+   int size = buf->width * buf->height * buf->bpp / 8;
+   buf->etna_dev = etna_device_new(buf->drm_fd);
+
+   buf->etna_bo = etna_bo_new(buf->etna_dev, size, flags);
+
+   if (!buf->etna_bo)
+   return 0;
+   buf->stride = ROUND_DOWN(buf->width, 32) * buf->bpp / 8;
+   return 1;
+}
+
+static void
+etna_free_bo(struct buffer *buf)
+{
+   etna_bo_del(buf->etna_bo);
+}
+
+static int
+etna_bo_export_to_prime(struct buffer *buf)
+{
+   buf->dmabuf_fd = etna_bo_dmabuf(buf->etna_bo);
+   if (buf->dmabuf_fd > 0)
+   return 0;
+
+   return 1;
+}
+
+static int
+etna_map_bo(struct buffer *buf)
+{
+   buf->mmap = etna_bo_map(buf->etna_bo);
+
+   if (buf->mmap != NULL)
+   return 1;
+
+   return 0;
+}
+
+static void
+etna_unmap_bo(struct buffer *buf)
+{
+}
+
+static void
+etna_device_destroy(struct buffer *buf)
+{
+   etna_device_del(buf->etna_dev);
+}
+#endif /* HAVE_LIBDRM_ENTAVIV */
 
 static void
 fill_content(struct buffer *my_buf)
@@ -331,6 +394,16 @@ drm_device_init(struct buffer *buf)
dev->unmap_bo = fd_unmap_bo;
dev->device_destroy = fd_device_destroy;
}
+#endif
+#ifdef HAVE_LIBDRM_ETNAVIV
+   else if (!strcmp(dev->name, "etnaviv")) {
+   dev->alloc_bo = etna_alloc_bo;
+   dev->free_bo = etna_free_bo;
+   dev->export_bo_to_prime = etna_bo_export_to_prime;
+   dev->map_bo = etna_map_bo;
+   dev->unmap_bo = etna_unmap_bo;
+   dev->device_destroy = etna_device_destroy;
+   }
 #endif
else {
fprintf(stderr, "Error: drm device %s unsupported.\n",
diff --git a/configure.ac b/configure.ac
index dc2fbe93..e86c31fa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -393,11 +393,14 @@ if ! test "x$enable_simple_dmabuf_drm_client" = "xno"; 
then
   PKG_CHECK_MODULES(LIBDRM_PLATFORM_INTEL, [libdrm_intel],
   AC_DEFINE([HAVE_LIBDRM_INTEL], [1], [Build intel dmabuf client]) 
have_simple_dmabuf_drm_client=yes,
   [true])
+  PKG_CHECK_MODULES(LIBDRM_PLATFORM_ETNAVIV, [libdrm_etnaviv],
+  AC_DEFINE([HAVE_LIBDRM_ETNAVIV], [1], [Build etnaviv dmabuf client]) 
have_simple_dmabuf_drm_client=yes,
+  [have_etnaviv=no])
 
   if test "x$have_simple_dmabuf_drm_client" != "xyes" -o \
  "x$have_simple_dmabuf_libs" = "xno" && \
  "x$enable_simple_dmabuf_drm_client" = "xyes"; then
-AC_MSG_ERROR([DRM dmabuf client explicitly enabled, but libdrm_intel or 
libdrm_freedreno not found])
+AC_MSG_ERROR([DRM dmabuf client explicitly enabled, but neither 
libdrm_intel, libdrm_freedreno or libdrm_etnaviv found])
   fi
 
   if test "x$have_simple_dmabuf_drm_client" = "xyes" -a 
"x$have_simple_dmabuf_libs"; then
-- 
2.16.1

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

[PATCH weston v2 0/4] simple-dmabuf-drm: multiple backends and etnaviv support

[Guido Günther]

Changes from v1:
- Split up changes
- autoconf:
  - don't define unused have_ variables. Use true instead to prevent
abort of PKG_CHECK_MODULES
  - use && instead of -a in test
  - properly check variables
- use vfunc for drm_device_destroy

Guido Günther (4):
  simple-dmabuf-drm: allow multiple backends
  simpla-dmabuf-drm: Use more weston like coding style
  simple-dmabuf-drm: use vfunc for drm_device_destroy
  simple-dmabuf-drm: support etnaviv drm as well

 Makefile.am |   6 +-
 clients/simple-dmabuf-drm.c | 166 +---
 configure.ac|  29 +---
 3 files changed, 150 insertions(+), 51 deletions(-)

-- 
2.16.1

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

[PATCH weston v2 1/4] simple-dmabuf-drm: allow multiple backends

[Guido Günther]

This allows to enable freedreno and intel backends at the same time
building the prerequisites for adding further ones.
---
 Makefile.am |  5 -
 clients/simple-dmabuf-drm.c | 53 +
 configure.ac| 24 +++-
 3 files changed, 47 insertions(+), 35 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e028a2a1..c2d448e7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -624,7 +624,10 @@ nodist_weston_simple_dmabuf_drm_SOURCES =  \
protocol/linux-dmabuf-unstable-v1-protocol.c \
protocol/linux-dmabuf-unstable-v1-client-protocol.h
 weston_simple_dmabuf_drm_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_DMABUF_DRM_CLIENT_CFLAGS)
-weston_simple_dmabuf_drm_LDADD = $(SIMPLE_DMABUF_DRM_CLIENT_LIBS) 
$(LIBDRM_PLATFORM_LIBS) libshared.la
+weston_simple_dmabuf_drm_LDADD = $(SIMPLE_DMABUF_DRM_CLIENT_LIBS) \
+   $(LIBDRM_PLATFORM_FREEDRENO_LIBS) \
+   $(LIBDRM_PLATFORM_INTEL_LIBS) \
+   libshared.la
 endif
 
 if BUILD_SIMPLE_DMABUF_V4L_CLIENT
diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
index 14d716de..51ad51f8 100644
--- a/clients/simple-dmabuf-drm.c
+++ b/clients/simple-dmabuf-drm.c
@@ -44,7 +44,8 @@
 #ifdef HAVE_LIBDRM_INTEL
 #include 
 #include 
-#elif HAVE_LIBDRM_FREEDRENO
+#endif
+#ifdef HAVE_LIBDRM_FREEDRENO
 #include 
 #endif
 #include 
@@ -93,10 +94,11 @@ struct buffer {
 
 #ifdef HAVE_LIBDRM_INTEL
drm_intel_bufmgr *bufmgr;
-   drm_intel_bo *bo;
-#elif HAVE_LIBDRM_FREEDRENO
+   drm_intel_bo *intel_bo;
+#endif /* HAVE_LIBDRM_INTEL */
+#if HAVE_LIBDRM_FREEDRENO
struct fd_device *fd_dev;
-   struct fd_bo *bo;
+   struct fd_bo *fd_bo;
 #endif /* HAVE_LIBDRM_FREEDRENO */
 
uint32_t gem_handle;
@@ -152,15 +154,15 @@ intel_alloc_bo(struct buffer *my_buf)
 
assert(my_buf->bufmgr);
 
-   my_buf->bo = drm_intel_bo_alloc_tiled(my_buf->bufmgr, "test",
- my_buf->width, my_buf->height,
- (my_buf->bpp / 8), ,
- _buf->stride, 0);
+   my_buf->intel_bo = drm_intel_bo_alloc_tiled(my_buf->bufmgr, "test",
+   my_buf->width, 
my_buf->height,
+   (my_buf->bpp / 8), ,
+   _buf->stride, 0);
 
printf("buffer allocated w %d, h %d, stride %lu, size %lu\n",
-  my_buf->width, my_buf->height, my_buf->stride, my_buf->bo->size);
+  my_buf->width, my_buf->height, my_buf->stride, 
my_buf->intel_bo->size);
 
-   if (!my_buf->bo)
+   if (!my_buf->intel_bo)
return 0;
 
if (tiling != I915_TILING_NONE)
@@ -172,16 +174,16 @@ intel_alloc_bo(struct buffer *my_buf)
 static void
 intel_free_bo(struct buffer *my_buf)
 {
-   drm_intel_bo_unreference(my_buf->bo);
+   drm_intel_bo_unreference(my_buf->intel_bo);
 }
 
 static int
 intel_map_bo(struct buffer *my_buf)
 {
-   if (drm_intel_gem_bo_map_gtt(my_buf->bo) != 0)
+   if (drm_intel_gem_bo_map_gtt(my_buf->intel_bo) != 0)
return 0;
 
-   my_buf->mmap = my_buf->bo->virtual;
+   my_buf->mmap = my_buf->intel_bo->virtual;
 
return 1;
 }
@@ -189,15 +191,16 @@ intel_map_bo(struct buffer *my_buf)
 static int
 intel_bo_export_to_prime(struct buffer *buffer)
 {
-   return drm_intel_bo_gem_export_to_prime(buffer->bo, >dmabuf_fd);
+   return drm_intel_bo_gem_export_to_prime(buffer->intel_bo, 
>dmabuf_fd);
 }
 
 static void
 intel_unmap_bo(struct buffer *my_buf)
 {
-   drm_intel_gem_bo_unmap_gtt(my_buf->bo);
+   drm_intel_gem_bo_unmap_gtt(my_buf->intel_bo);
 }
-#elif HAVE_LIBDRM_FREEDRENO
+#endif /* HAVE_LIBDRM_INTEL */
+#ifdef HAVE_LIBDRM_FREEDRENO
 #define ALIGN(v, a) ((v + a - 1) & ~(a - 1))
 
 static
@@ -207,9 +210,9 @@ int fd_alloc_bo(struct buffer *buf)
int size = buf->width * buf->height * buf->bpp / 8;
buf->fd_dev = fd_device_new(buf->drm_fd);
 
-   buf->bo = fd_bo_new(buf->fd_dev, size, flags);
+   buf->fd_bo = fd_bo_new(buf->fd_dev, size, flags);
 
-   if (!buf->bo)
+   if (!buf->fd_bo)
return 0;
buf->stride = ALIGN(buf->width, 32) * buf->bpp / 8;
return 1;
@@ -218,13 +221,13 @@ int fd_alloc_bo(struct buffer *buf)
 static
 void fd_free_bo(struct buffer *buf)
 {
-   fd_bo_del(buf->bo);
+   fd_bo_del(buf->fd_bo);
 }
 
 static
 int fd_bo_export_to_prime(struct buffer *buf)
 {
-   buf->dmabuf_fd = fd_bo_dmabuf(buf->bo);
+   buf->dmabuf_fd = fd_bo_dmabuf(buf->fd_bo);
if (buf->dmabuf_fd > 0)
return 0;
 
@@ -234,7 +237,7 @@ int fd_bo_export_to_prime(struct buffer *buf)
 static
 int fd_map_bo(struct buffer *buf)
 {
-   buf->mmap = fd_bo_map(buf->bo);
+   buf->mmap = fd_bo_map(buf->fd_bo);
 
if (buf->mmap != 

[PATCH weston v2 3/4] simple-dmabuf-drm: use vfunc for drm_device_destroy

[Guido Günther]

Remove ifdef clutter and makes sure it's only called for the active
backend.
---
 clients/simple-dmabuf-drm.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
index b576ad3a..492c9667 100644
--- a/clients/simple-dmabuf-drm.c
+++ b/clients/simple-dmabuf-drm.c
@@ -83,6 +83,7 @@ struct drm_device {
int (*export_bo_to_prime)(struct buffer *buf);
int (*map_bo)(struct buffer *buf);
void (*unmap_bo)(struct buffer *buf);
+   void (*device_destroy)(struct buffer *buf);
 };
 
 struct buffer {
@@ -199,6 +200,13 @@ intel_unmap_bo(struct buffer *my_buf)
 {
drm_intel_gem_bo_unmap_gtt(my_buf->intel_bo);
 }
+
+static void
+intel_device_destroy(struct buffer *my_buf)
+{
+   drm_intel_bufmgr_destroy(my_buf->bufmgr);
+}
+
 #endif /* HAVE_LIBDRM_INTEL */
 #ifdef HAVE_LIBDRM_FREEDRENO
 #define ALIGN(v, a) ((v + a - 1) & ~(a - 1))
@@ -249,6 +257,12 @@ static void
 fd_unmap_bo(struct buffer *buf)
 {
 }
+
+static void
+fd_device_destroy(struct buffer *buf)
+{
+   fd_device_del(buf->fd_dev);
+}
 #endif /* HAVE_LIBDRM_FREEDRENO */
 
 static void
@@ -279,13 +293,7 @@ fill_content(struct buffer *my_buf)
 static void
 drm_device_destroy(struct buffer *buf)
 {
-#ifdef HAVE_LIBDRM_INTEL
-   drm_intel_bufmgr_destroy(buf->bufmgr);
-#endif
-#ifdef HAVE_LIBDRM_FREEDRENO
-   fd_device_del(buf->fd_dev);
-#endif
-
+   buf->dev->device_destroy(buf);
close(buf->drm_fd);
 }
 
@@ -311,6 +319,7 @@ drm_device_init(struct buffer *buf)
dev->export_bo_to_prime = intel_bo_export_to_prime;
dev->map_bo = intel_map_bo;
dev->unmap_bo = intel_unmap_bo;
+   dev->device_destroy = intel_device_destroy;
}
 #endif
 #ifdef HAVE_LIBDRM_FREEDRENO
@@ -320,6 +329,7 @@ drm_device_init(struct buffer *buf)
dev->export_bo_to_prime = fd_bo_export_to_prime;
dev->map_bo = fd_map_bo;
dev->unmap_bo = fd_unmap_bo;
+   dev->device_destroy = fd_device_destroy;
}
 #endif
else {
-- 
2.16.1

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

[PATCH weston v2 2/4] simpla-dmabuf-drm: Use more weston like coding style

[Guido Günther]

---
 clients/simple-dmabuf-drm.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
index 51ad51f8..b576ad3a 100644
--- a/clients/simple-dmabuf-drm.c
+++ b/clients/simple-dmabuf-drm.c
@@ -203,8 +203,8 @@ intel_unmap_bo(struct buffer *my_buf)
 #ifdef HAVE_LIBDRM_FREEDRENO
 #define ALIGN(v, a) ((v + a - 1) & ~(a - 1))
 
-static
-int fd_alloc_bo(struct buffer *buf)
+static int
+fd_alloc_bo(struct buffer *buf)
 {
int flags = DRM_FREEDRENO_GEM_CACHE_WCOMBINE;
int size = buf->width * buf->height * buf->bpp / 8;
@@ -218,14 +218,14 @@ int fd_alloc_bo(struct buffer *buf)
return 1;
 }
 
-static
-void fd_free_bo(struct buffer *buf)
+static void
+fd_free_bo(struct buffer *buf)
 {
fd_bo_del(buf->fd_bo);
 }
 
-static
-int fd_bo_export_to_prime(struct buffer *buf)
+static int
+fd_bo_export_to_prime(struct buffer *buf)
 {
buf->dmabuf_fd = fd_bo_dmabuf(buf->fd_bo);
if (buf->dmabuf_fd > 0)
@@ -234,8 +234,8 @@ int fd_bo_export_to_prime(struct buffer *buf)
return 1;
 }
 
-static
-int fd_map_bo(struct buffer *buf)
+static int
+fd_map_bo(struct buffer *buf)
 {
buf->mmap = fd_bo_map(buf->fd_bo);
 
@@ -245,8 +245,8 @@ int fd_map_bo(struct buffer *buf)
return 0;
 }
 
-static
-void fd_unmap_bo(struct buffer *buf)
+static void
+fd_unmap_bo(struct buffer *buf)
 {
 }
 #endif /* HAVE_LIBDRM_FREEDRENO */
-- 
2.16.1

___
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]

Hi,

Sorry for the trouble, I forgot to ask that is it safe to call
`wl_display_flush` and `wl_display_dispatch` in different threads?

Regards,
SZ


Le jeu. 15 mars 2018 11 h 17, Sichem Zhou  a écrit :

> Hi,
>
> Thanks very much for the patience so far. It's because I didn't do
> `wl_display_flush` before polling.
>
> Regards,
> SZ
>
> Le jeu. 15 mars 2018 04 h 41, Pekka Paalanen  a
> écrit :
>
>> On Thu, 15 Mar 2018 00:19:10 +
>> Sichem Zhou  wrote:
>>
>> > 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?
>>
>> Hi,
>>
>> there is only one event queue in the server-side per client. IIRC, it's
>> not really even a queue as much as just a buffer.
>>
>> You can use WAYLAND_DEBUG=server environment variable to have
>> libwayland-server print all protocol messages at the time they are
>> processed. That means, the time when requests are being dispatched, and
>> events are being queued for sending. There is WAYLAND_DEBUG=client
>> working the same way for clients, but it might be confusing if it is
>> set for multiple clients at the same time.
>>
>> If you need to check the messages on "the wire" instead, the Wayland
>> website extras have a list of some debugger programs. Messages enter
>> the wire on flush after send. Forgetting to flush will show the message
>> in WAYLAND_DEBUG=1 output, but it might not be actually sent at the
>> time.
>>
>> This issue could also be a client bug. If you do not ensure that all
>> requests have been flushed out before going to sleep in poll(), they
>> might never actually reach the server until something else happens.
>>
>>
>> Thanks,
>> pq
>>
>
___
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

[Daniel Stone]

On 15 March 2018 at 15:21, Drew DeVault  wrote:
> On 2018-03-15  3:16 PM, Daniel Stone wrote:
>> You could write a compositor which put decorations on everything
>> unless explicitly instructed not to, and claim victory in the name of
>> technical correctness. Even though it's double-decorating GTK+, EFL,
>> Weston, and pretty much everything deployed under the sun.
>
> In fact, I have done so. Before we started working on this protocol,
> Sway did exactly this. We have provided users the means of overriding
> the approach to decorations, including what ends up being double
> decorations sometimes.

OK, but that doesn't seem like the kind of user experience to aim for ... ?

'You might have no titlebars and controls, or one of them, or maybe
two completely different ones, depending on historical decisions made
by developers who weren't talking to each other at the time. Have
fun.'

>> We already have a specification, which is what every client expects:
>> that clients are responsible for the decorations (or absence thereof).
>> We now have a new protocol which allows the client and server, when
>> both agree, to have the server take responsibility for drawing (or not
>> drawing) the decorations. And that's fine, but why try to retcon
>> history as if the past several years never existed, just because you
>> disagree with it?
>
> I don't think I'm being overtly "technically strict" in my
> interpretation of the standard. This assumption hasn't really been true.
> Take Xwayland, for example, a shell where the compositor has always been
> expected to handle decorations.

Xwayland isn't a shell. Xwayland requires active co-operation from the
compositor to act just like an X11 window manager, so X11 clients can
display in the shell being used. X11 has very well-established means
of doing window management via the ICCCM and EWMH, and the
implementations I've seen try to respect those as closely as they can.

> There are also other clients in the wild which are not amenable to
> client side decorations. mpv comes to mind, there was a big debate over
> it and to date it still doesn't support CSD (it uses xdg-shell).

Yes, so mpv gets no decorations unless it asks the server for them.
Neither does weston-simple-egl. There are several compositors which
will never provide decorations for mpv, because they don't support
server-side decorations. And that's OK, because that's the established
ecosystem: clients provide decorations.

> The "requirement" has never been as strong as you're implying, and
> certainly has never been expressed in the protocols.

No, it really has. GTK+ has always - well, until you got the patches
for this protocol merged a month or two ago - decorated its own
windows under Wayland. Same with Qt. Same with EFL. These are toolkits
which have been around and deployed for several years, doing exactly
what I'm describing. Sticking server-side decorations on them gives
you two completely different titlebars, and anyone trying to use it
justifiably thinking the result is an incoherent mess.

I understand you dislike Wayland's established window-management model
and you wish it was the same as X11. I disagree, but that's fine.
What's not fine, is trying to rewrite history and insulting everyone's
intelligence. You're acting as if the consensus which has underpinned
everything since the start of the project doesn't exist, just because
a) you don't like it, and b) mpv doesn't have decorations so it
invalidates everything else.

It is a concrete, unarguable, fact that the core Wayland protocol
implies client-side decorations. The protocol text in this thread
acknowledges that fact:
By advertizing this interface the server anounces support for
server-side window decorations.

Denying facts and being disingenuous doesn't help anyone, and it's
tiring. Tiring enough that I came into this thread with the intention
of giving this protocol a couple of suggestions and a push towards
getting it merged, because I'm tired of the totally counterproductive
division between wlc/wlroots/Sway/mpv and the rest of the Wayland
world, but I've lost all motivation to continue.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Simon Ser]

On March 15, 2018 4:15 PM, Emil Velikov  wrote:
> On 2 March 2018 at 15:33, 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 
> >
> More of a fly-by comment.
> 
> Having a quick look does not list any of these R-B tags making it to the list.
> Was it done in private, or I failed at searching?

Yeah, it was done prior to submission to wayland-devel. See the commentary below
the commit message:

> 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).

> If the former - it's very concerning practise.
>
> -Emil

___
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-15  3:16 PM, Daniel Stone wrote:
> You could write a compositor which put decorations on everything
> unless explicitly instructed not to, and claim victory in the name of
> technical correctness. Even though it's double-decorating GTK+, EFL,
> Weston, and pretty much everything deployed under the sun.

In fact, I have done so. Before we started working on this protocol,
Sway did exactly this. We have provided users the means of overriding
the approach to decorations, including what ends up being double
decorations sometimes.

> We already have a specification, which is what every client expects:
> that clients are responsible for the decorations (or absence thereof).
> We now have a new protocol which allows the client and server, when
> both agree, to have the server take responsibility for drawing (or not
> drawing) the decorations. And that's fine, but why try to retcon
> history as if the past several years never existed, just because you
> disagree with it?

I don't think I'm being overtly "technically strict" in my
interpretation of the standard. This assumption hasn't really been true.
Take Xwayland, for example, a shell where the compositor has always been
expected to handle decorations.

There are also other clients in the wild which are not amenable to
client side decorations. mpv comes to mind, there was a big debate over
it and to date it still doesn't support CSD (it uses xdg-shell).

The "requirement" has never been as strong as you're implying, and
certainly has never been expressed in the protocols.

--
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]

Hi,

Thanks very much for the patience so far. It's because I didn't do
`wl_display_flush` before polling.

Regards,
SZ

Le jeu. 15 mars 2018 04 h 41, Pekka Paalanen  a écrit :

> On Thu, 15 Mar 2018 00:19:10 +
> Sichem Zhou  wrote:
>
> > 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?
>
> Hi,
>
> there is only one event queue in the server-side per client. IIRC, it's
> not really even a queue as much as just a buffer.
>
> You can use WAYLAND_DEBUG=server environment variable to have
> libwayland-server print all protocol messages at the time they are
> processed. That means, the time when requests are being dispatched, and
> events are being queued for sending. There is WAYLAND_DEBUG=client
> working the same way for clients, but it might be confusing if it is
> set for multiple clients at the same time.
>
> If you need to check the messages on "the wire" instead, the Wayland
> website extras have a list of some debugger programs. Messages enter
> the wire on flush after send. Forgetting to flush will show the message
> in WAYLAND_DEBUG=1 output, but it might not be actually sent at the
> time.
>
> This issue could also be a client bug. If you do not ensure that all
> requests have been flushed out before going to sleep in poll(), they
> might never actually reach the server until something else happens.
>
>
> Thanks,
> pq
>
___
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

[Daniel Stone]

Hi,

On 15 March 2018 at 15:12, Drew DeVault  wrote:
> On 2018-03-15  3:04 PM, Mike Blumenkrantz wrote:
>> It seems to me that there is no harm in restating that clients are required
>> to implement CSD inside a protocol which permits adding a separate,
>> optional method of window decoration.
>>
>> Note that it is not an assumption that clients/compositors "support both"
>> modes, it's a hard requirement that clients/compositors support CSD. If
>> there is some confusion about this due to other protocols not explicitly
>> stating that CSD is required then this can easily be remedied by adding
>> such clauses.
>
> Sorry for the confusion. My point is that Wayland does not and has never
> required clients to show client side decorations.

In the most strict technical terms, you're right.

> The only connection is
> a rather loose one specified in xdg-shell. In practice, clients and
> compositors alike are free to do whatever they want with decorations.

You could write a compositor which put decorations on everything
unless explicitly instructed not to, and claim victory in the name of
technical correctness. Even though it's double-decorating GTK+, EFL,
Weston, and pretty much everything deployed under the sun.

> We
> should not formalize a requirement to behave any particular way. This
> just provides a means of communicating each side's preferences.

We already have a specification, which is what every client expects:
that clients are responsible for the decorations (or absence thereof).
We now have a new protocol which allows the client and server, when
both agree, to have the server take responsibility for drawing (or not
drawing) the decorations. And that's fine, but why try to retcon
history as if the past several years never existed, just because you
disagree with it?

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

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

[Emil Velikov]

On 2 March 2018 at 15:33, 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 
>
More of a fly-by comment.

Having a quick look does not list any of these R-B tags making it to the list.
Was it done in private, or I failed at searching?

If the former - it's very concerning practise.

-Emil
___
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-15  3:04 PM, Mike Blumenkrantz wrote:
> It seems to me that there is no harm in restating that clients are required
> to implement CSD inside a protocol which permits adding a separate,
> optional method of window decoration.
> 
> Note that it is not an assumption that clients/compositors "support both"
> modes, it's a hard requirement that clients/compositors support CSD. If
> there is some confusion about this due to other protocols not explicitly
> stating that CSD is required then this can easily be remedied by adding
> such clauses.

Sorry for the confusion. My point is that Wayland does not and has never
required clients to show client side decorations. The only connection is
a rather loose one specified in xdg-shell. In practice, clients and
compositors alike are free to do whatever they want with decorations. We
should not formalize a requirement to behave any particular way. This
just provides a means of communicating each side's preferences.
___
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

[Mike Blumenkrantz]

It seems to me that there is no harm in restating that clients are required
to implement CSD inside a protocol which permits adding a separate,
optional method of window decoration.

Note that it is not an assumption that clients/compositors "support both"
modes, it's a hard requirement that clients/compositors support CSD. If
there is some confusion about this due to other protocols not explicitly
stating that CSD is required then this can easily be remedied by adding
such clauses.

On Wed, Mar 14, 2018 at 3:20 PM Drew DeVault  wrote:

> 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
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [weston PATCH] simple-dmabuf-drm: support etnaviv drm as well

[Emil Velikov]

On 15 March 2018 at 13:58, Pekka Paalanen  wrote:
> On Mon, 12 Mar 2018 16:41:46 +0100
> Guido Günther  wrote:
>
>> Since freedreno and etnaviv can live in parallel allow to build in
>> different DRM backends.
>> ---
>>  Makefile.am |   6 ++-
>>  clients/simple-dmabuf-drm.c | 122 
>> +++-
>>  configure.ac|  29 +++
>>  3 files changed, 121 insertions(+), 36 deletions(-)
>
> Hi,
>
> this seems mostly fine, but there are some issues noted below. It would
> be appropriate to split this into two patches: "allow intel and
> freedreno to be built together" and "add etnaviv support".
>
Just throwing it out there - one might be able to utilise the
gbm_bo_{un,}map API.
Haven't looked at the weston code, yet ^^ was sufficient for the
piglit tests + kmscube.

Less code, fewer vendor quirks ;-)

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

[PATCH wayland v3 3/3] wayland-egl: bump the version number to 18.1.0

[Emil Velikov]

From: Emil Velikov 

Seems like I was overoptimistic with my earlier assumption, namely:

"... 17.3.x should be the last version that ships the library."

Mesa 18.0.0 and its wayland-egl is about to be released any time soon,
so bump the number since it must no be smaller. As soon as we get
a wayland release I'll drop the Mesa copy but for now.

Signed-off-by: Emil Velikov 
---
 egl/wayland-egl.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/egl/wayland-egl.pc.in b/egl/wayland-egl.pc.in
index 943442e..2e2d4c4 100644
--- a/egl/wayland-egl.pc.in
+++ b/egl/wayland-egl.pc.in
@@ -5,7 +5,7 @@ includedir=@includedir@
 
 Name: wayland-egl
 Description: Frontend wayland-egl library
-Version: 17.4.0
+Version: 18.1.0
 Requires: wayland-client
 Libs: -L${libdir} -lwayland-egl
 Cflags: -I${includedir}
-- 
2.16.0

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

[PATCH wayland v3 2/3] wayland-egl: enhance the symbol test

[Emil Velikov]

From: Emil Velikov 

The current test had a few fall-outs:
 - it was checking only for T (.text) symbols
 - did not consider symbol removal

Fix that by fetching all the symbols and doing a bidirectional check -
for added and removed symbols. Error out with informative message for
each case.

v2: Rebase on top of $NM patch.

Signed-off-by: Emil Velikov 
---
 egl/wayland-egl-symbols-check | 36 
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/egl/wayland-egl-symbols-check b/egl/wayland-egl-symbols-check
index 8b3d711..c47026b 100755
--- a/egl/wayland-egl-symbols-check
+++ b/egl/wayland-egl-symbols-check
@@ -8,17 +8,37 @@ if [ ! -f "$LIB" ]; then
exit 1
 fi
 
-FUNCS=$($NM -D --defined-only $LIB | grep -o "T .*" | cut -c 3- | while read 
func; do
-( grep -q "^$func$" || echo $func )  

[PATCH wayland v3 1/3] wayland-egl: fail the symbol check if lib is missing

[Emil Velikov]

From: Emil Velikov 

Based on a similar patch (in Mesa) by Eric Engestrom.

v2: Rebase on top of $NM patch
v3: Rebase

Reviewed-by: Eric Engestrom  (v1)
Signed-off-by: Emil Velikov 
---
 egl/wayland-egl-symbols-check | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/egl/wayland-egl-symbols-check b/egl/wayland-egl-symbols-check
index 6ad28f3..8b3d711 100755
--- a/egl/wayland-egl-symbols-check
+++ b/egl/wayland-egl-symbols-check
@@ -1,6 +1,14 @@
 #!/bin/sh
+set -eu
 
-FUNCS=$($NM -D --defined-only ${WAYLAND_EGL_LIB} | grep -o "T .*" | cut -c 3- 
| while read func; do
+LIB=${WAYLAND_EGL_LIB}
+
+if [ ! -f "$LIB" ]; then
+   echo "The test binary \"$LIB\" does no exist"
+   exit 1
+fi
+
+FUNCS=$($NM -D --defined-only $LIB | grep -o "T .*" | cut -c 3- | while read 
func; do
 ( grep -q "^$func$" || echo $func )  

[PATCH weston v2] 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 ;-)

v2: auto disable systemd as dbus is missing

Cc: Michael Tretter 
Reported-by: Michael Tretter 
Signed-off-by: Emil Velikov 
---
Thanks for the review Michael!

You're right - the else hunk is only for consistency with surrounding
code.
---
 configure.ac | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/configure.ac b/configure.ac
index 0b326ccc..a3453d15 100644
--- a/configure.ac
+++ b/configure.ac
@@ -524,7 +524,12 @@ 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 = xyes -a x$enable_dbus = xno; then
+  AC_MSG_ERROR([systemd-login support explicitly requested, but dbus not 
available])
+fi
+
+if test x$enable_systemd_login = xauto -a x$enable_dbus = xno; then
   PKG_CHECK_MODULES(SYSTEMD_LOGIN,
 [libsystemd >= 209],
 [have_systemd_login_209=yes;have_systemd_login=yes],
@@ -537,21 +542,22 @@ if test x$enable_systemd_login != xno -a x$have_dbus != 
xno; then
   [have_systemd_login=yes],
   [have_systemd_login=no])
 ])
+
+  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
+
+  if test "x$have_systemd_login" = "xyes"; then
+AC_DEFINE([HAVE_SYSTEMD_LOGIN], [1], [Have systemd-login])]
+  fi
+
+  AS_IF([test "x$have_systemd_login_209" = "xyes"],
+[AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 
209])])
 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
-- 
2.16.0

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

Re: [PATCH weston v2] build: honour libinput header location

[Daniel Stone]

Hi,

On 15 March 2018 at 13:45, Emil Velikov  wrote:
> Add the respective CFLAGS to the build, otherwise it will error out as
> seen below.
>
> src/libinput-seat.c:30:22: fatal error: libinput.h: No such file or directory
>
> v2: add the CFLAGS only as needed, suggested by Pekka
>
> Cc: Pekka Paalanen 
> Cc: Jan Engelhardt 
> [Emil Velikov: polish commit message, v2]
> Signed-off-by: Emil Velikov 
> ---
> Pekka feel free to pick whichever patch you feel more confortable with.

I have a mild preference for this one, but either is:
Reviewed-by: Daniel Stone 

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

Re: [weston PATCH] simple-dmabuf-drm: support etnaviv drm as well

[Pekka Paalanen]

On Mon, 12 Mar 2018 16:41:46 +0100
Guido Günther  wrote:

> Since freedreno and etnaviv can live in parallel allow to build in
> different DRM backends.
> ---
>  Makefile.am |   6 ++-
>  clients/simple-dmabuf-drm.c | 122 
> +++-
>  configure.ac|  29 +++
>  3 files changed, 121 insertions(+), 36 deletions(-)

Hi,

this seems mostly fine, but there are some issues noted below. It would
be appropriate to split this into two patches: "allow intel and
freedreno to be built together" and "add etnaviv support".

> diff --git a/Makefile.am b/Makefile.am
> index e028a2a1..19319fa2 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -624,7 +624,11 @@ nodist_weston_simple_dmabuf_drm_SOURCES =
> \
>   protocol/linux-dmabuf-unstable-v1-protocol.c \
>   protocol/linux-dmabuf-unstable-v1-client-protocol.h
>  weston_simple_dmabuf_drm_CFLAGS = $(AM_CFLAGS) 
> $(SIMPLE_DMABUF_DRM_CLIENT_CFLAGS)
> -weston_simple_dmabuf_drm_LDADD = $(SIMPLE_DMABUF_DRM_CLIENT_LIBS) 
> $(LIBDRM_PLATFORM_LIBS) libshared.la
> +weston_simple_dmabuf_drm_LDADD = $(SIMPLE_DMABUF_DRM_CLIENT_LIBS) \
> + $(LIBDRM_PLATFORM_FREEDRENO_LIBS) \
> + $(LIBDRM_PLATFORM_ETNAVIV_LIBS)   \
> + $(LIBDRM_PLATFORM_INTEL_LIBS) \
> + libshared.la
>  endif
>  
>  if BUILD_SIMPLE_DMABUF_V4L_CLIENT
> diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
> index 1073930f..8b7acd39 100644
> --- a/clients/simple-dmabuf-drm.c
> +++ b/clients/simple-dmabuf-drm.c
> @@ -44,9 +44,13 @@
>  #ifdef HAVE_LIBDRM_INTEL
>  #include 
>  #include 
> -#elif HAVE_LIBDRM_FREEDRENO
> +#endif
> +#ifdef HAVE_LIBDRM_FREEDRENO
>  #include 
>  #endif
> +#ifdef HAVE_LIBDRM_ETNAVIV
> +#include 
> +#endif
>  #include 

It's nice to see that the three can all be built at the same time.

>  
>  #include 
> @@ -93,11 +97,16 @@ struct buffer {
>  
>  #ifdef HAVE_LIBDRM_INTEL
>   drm_intel_bufmgr *bufmgr;
> - drm_intel_bo *bo;
> -#elif HAVE_LIBDRM_FREEDRENO
> + drm_intel_bo *intel_bo;
> +#endif /* HAVE_LIBDRM_INTEL */
> +#if HAVE_LIBDRM_FREEDRENO
>   struct fd_device *fd_dev;
> - struct fd_bo *bo;
> + struct fd_bo *fd_bo;
>  #endif /* HAVE_LIBDRM_FREEDRENO */
> +#if HAVE_LIBDRM_ETNAVIV
> + struct etna_device *etna_dev;
> + struct etna_bo *etna_bo;
> +#endif /* HAVE_LIBDRM_ETNAVIV */

The mechanical renames seem to be fine.

> @@ -246,7 +256,57 @@ static
>  void fd_unmap_bo(struct buffer *buf)
>  {
>  }
> -#endif
> +#endif /* HAVE_LIBDRM_FREEDRENO */
> +#ifdef HAVE_LIBDRM_ETNAVIV
> +#define ALIGN(v, a) ((v + a - 1) & ~(a - 1))
> +
> +static
> +int etna_alloc_bo(struct buffer *buf)

It seems freedreno was consistently using an incorrect style and you
copied it. Please follow the intel style instead, that is:

static int
etna_alloc_bo(...

That's what we use everywhere in weston.

> +{
> + int flags = DRM_ETNA_GEM_CACHE_WC;
> + int size = buf->width * buf->height * buf->bpp / 8;
> + buf->etna_dev = etna_device_new(buf->drm_fd);
> +
> + buf->etna_bo = etna_bo_new(buf->etna_dev, size, flags);
> +
> + if (!buf->etna_bo)
> + return 0;
> + buf->stride = ALIGN(buf->width, 32) * buf->bpp / 8;

ALIGN rounds up, right?

So, if you allocate 'size' bytes, and then the caller computes stride *
height, they end up accessing out of bounds, no?

> + return 1;
> +}
> +
> +static
> +void etna_free_bo(struct buffer *buf)
> +{
> + etna_bo_del(buf->etna_bo);
> +}
> +
> +static
> +int etna_bo_export_to_prime(struct buffer *buf)
> +{
> + buf->dmabuf_fd = etna_bo_dmabuf(buf->etna_bo);
> + if (buf->dmabuf_fd > 0)
> + return 0;
> +
> + return 1;
> +}
> +
> +static
> +int etna_map_bo(struct buffer *buf)
> +{
> + buf->mmap = etna_bo_map(buf->etna_bo);
> +
> + if (buf->mmap != NULL)
> + return 1;
> +
> + return 0;
> +}
> +
> +static
> +void etna_unmap_bo(struct buffer *buf)
> +{
> +}
> +#endif /* HAVE_LIBDRM_ENTAVIV */
>  
>  static void
>  fill_content(struct buffer *my_buf)
> @@ -278,9 +338,13 @@ drm_device_destroy(struct buffer *buf)
>  {
>  #ifdef HAVE_LIBDRM_INTEL
>   drm_intel_bufmgr_destroy(buf->bufmgr);
> -#elif HAVE_LIBDRM_FREEDRENO
> +#endif
> +#ifdef HAVE_LIBDRM_FREEDRENO
>   fd_device_del(buf->fd_dev);
>  #endif
> +#ifdef HAVE_LIBDRM_ETNAVIV
> + etna_device_del(buf->etna_dev);
> +#endif

Are all these del functions safe to call with NULL, or why wouldn't
they crash is more than one was supported?

I think it might be better to have these called via a vfunc.

>  
>   close(buf->drm_fd);
>  }
> @@ -308,7 +372,8 @@ drm_device_init(struct buffer *buf)
>   dev->map_bo = intel_map_bo;
>   dev->unmap_bo = intel_unmap_bo;
>   }
> -#elif HAVE_LIBDRM_FREEDRENO
> +#endif
> +#ifdef HAVE_LIBDRM_FREEDRENO
>   else if (!strcmp(dev->name, "msm")) {
>   dev->alloc_bo = fd_alloc_bo;
>   

[PATCH weston v2] build: honour libinput header location

[Emil Velikov]

From: Jan Engelhardt 

Add the respective CFLAGS to the build, otherwise it will error out as
seen below.

src/libinput-seat.c:30:22: fatal error: libinput.h: No such file or directory

v2: add the CFLAGS only as needed, suggested by Pekka

Cc: Pekka Paalanen 
Cc: Jan Engelhardt 
[Emil Velikov: polish commit message, v2]
Signed-off-by: Emil Velikov 
---
Pekka feel free to pick whichever patch you feel more confortable with.
---
 Makefile.am | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index e028a2a1..7e930d2b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -178,7 +178,7 @@ weston_LDFLAGS = -export-dynamic
 weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON   \
 -DMODULEDIR='"$(moduledir)"' \
 -DXSERVER_PATH='"@XSERVER_PATH@"'
-weston_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS)
+weston_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBINPUT_BACKEND_CFLAGS)
 weston_LDADD = libshared.la libweston-@LIBWESTON_MAJOR@.la \
$(COMPOSITOR_LIBS) \
$(DL_LIBS) $(LIBINPUT_BACKEND_LIBS) \
@@ -346,6 +346,7 @@ x11_backend_la_SOURCES =\
shared/helpers.h
 endif
 
+INPUT_BACKEND_CFLAGS = $(LIBINPUT_BACKEND_CFLAGS)
 INPUT_BACKEND_LIBS = $(LIBINPUT_BACKEND_LIBS)
 INPUT_BACKEND_SOURCES =\
libweston/libinput-seat.c   \
@@ -369,6 +370,7 @@ drm_backend_la_CFLAGS = \
$(COMPOSITOR_CFLAGS)\
$(EGL_CFLAGS)   \
$(DRM_COMPOSITOR_CFLAGS)\
+   $(INPUT_BACKEND_CFLAGS) \
$(AM_CFLAGS)
 drm_backend_la_SOURCES =   \
libweston/compositor-drm.c  \
@@ -443,6 +445,7 @@ fbdev_backend_la_CFLAGS =   \
$(EGL_CFLAGS)   \
$(FBDEV_COMPOSITOR_CFLAGS)  \
$(PIXMAN_CFLAGS)\
+   $(INPUT_BACKEND_CFLAGS) \
$(AM_CFLAGS)
 fbdev_backend_la_SOURCES = \
libweston/compositor-fbdev.c\
-- 
2.16.0

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

Re: [PATCH weston] build: honour libinput header location

[Emil Velikov]

On 15 March 2018 at 13:11, Jan Engelhardt  wrote:
>
> On Thursday 2018-03-15 13:20, Pekka Paalanen wrote:
>>> diff --git a/Makefile.am b/Makefile.am
>>> index b5c29c04..8de40e51 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -43,7 +43,8 @@ AM_CPPFLAGS =  \
>>>  -I$(top_builddir)/protocol  \
>>>  -DLIBWESTON_MODULEDIR='"$(libweston_moduledir)"' \
>>>  -DLIBEXECDIR='"$(libexecdir)"'  \
>>> --DBINDIR='"$(bindir)"'
>>> +-DBINDIR='"$(bindir)"' \
>>> +$(LIBINPUT_BACKEND_CFLAGS)
>>>
>>>  CLEANFILES = weston.ini \
>>>  ivi-shell/weston.ini\
>>
>>I don't think we want the libinput flags on *everything*
>
> It does not really matter, the libinput API is not bad.
> Not nearly as bad as some science software, anyhow.
>
> The "only" downside of using target_CPPFLAGS is that
> (a) the generated Makefile, Makefile.in gets bigger - somewhat larger release 
> tarball
> (b) sources part of multiple targets can get built twice to accomodate 
> invocations
> with different CPPFLAGS, even if the different CPPFLAGS still lead to the
> same gcc -E output.
>
Or in a Tl;Dr - there are no serious issues either way.
Proposed patch/result is shorter. Regardless, will send v2 in a moment.

>
>>Or do you think we should actually have CFLAGS of all deps with
>>everything we build, and just gate the LIBS we link with to the targets
>>that actually need it?
>
> That's the easy way, and the one requiring the fewest keystrokes IMO.
Agreed. Some projects opt for unconditionally add all CFLAGS, while
others prefer to keep it conditional.

In either case, I'd welcome if any notable changes/reshuffle do not
hold this* fix.
Thanks
Emil

* ... or analogous of course.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] build: honour libinput header location

[Jan Engelhardt]

On Thursday 2018-03-15 13:20, Pekka Paalanen wrote:
>> diff --git a/Makefile.am b/Makefile.am
>> index b5c29c04..8de40e51 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -43,7 +43,8 @@ AM_CPPFLAGS =  \
>>  -I$(top_builddir)/protocol  \
>>  -DLIBWESTON_MODULEDIR='"$(libweston_moduledir)"' \
>>  -DLIBEXECDIR='"$(libexecdir)"'  \
>> --DBINDIR='"$(bindir)"'
>> +-DBINDIR='"$(bindir)"' \
>> +$(LIBINPUT_BACKEND_CFLAGS)
>>  
>>  CLEANFILES = weston.ini \
>>  ivi-shell/weston.ini\
>
>I don't think we want the libinput flags on *everything*

It does not really matter, the libinput API is not bad.
Not nearly as bad as some science software, anyhow.

The "only" downside of using target_CPPFLAGS is that
(a) the generated Makefile, Makefile.in gets bigger - somewhat larger release 
tarball
(b) sources part of multiple targets can get built twice to accomodate 
invocations
with different CPPFLAGS, even if the different CPPFLAGS still lead to the
same gcc -E output.


>Or do you think we should actually have CFLAGS of all deps with
>everything we build, and just gate the LIBS we link with to the targets
>that actually need it?

That's the easy way, and the one requiring the fewest keystrokes IMO.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] tests: disable coredumps on sanity-test

[Pekka Paalanen]

On Thu, 15 Mar 2018 10:57:26 +
Daniel Stone  wrote:

> On 14 February 2018 at 12:38, Pekka Paalanen  wrote:
> > SEGV and ABRT by default cause a core dump, which may create a file,
> > launch crash handlers, and so on. sanity-test has 21 processes that
> > are expected to crash like this. Disable core dumps on them all.
> >
> > I counted 21 entries in coredumpctl list, while only 16 functions needed
> > patching. After this patch no entries appear in coredumpctl list.  
> 
> Very nice, thankyou!
> 
> Reviewed-by: Daniel Stone 

Pushed:
   adda7cb..371c26d  master -> master


Thanks,
pq


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

Re: [weston PATCH] Allow simple-dmabuf-drm to pass y_inverted flag

[Pekka Paalanen]

On Thu, 8 Mar 2018 18:06:14 +0100
Guido Günther  wrote:

> This allows to check if ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT is
> interpreted correctly by the compositor.
> ---
>  clients/simple-dmabuf-drm.c | 27 +++
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/clients/simple-dmabuf-drm.c b/clients/simple-dmabuf-drm.c
> index 14d716de..1073930f 100644
> --- a/clients/simple-dmabuf-drm.c
> +++ b/clients/simple-dmabuf-drm.c
> @@ -379,11 +379,11 @@ static const struct zwp_linux_buffer_params_v1_listener 
> params_listener = {
>  
>  static int
>  create_dmabuf_buffer(struct display *display, struct buffer *buffer,
> -  int width, int height, int format)
> +  int width, int height, int format, int is_y_inverted)

Hi,

rather than adding boolean arguments (pretending to be int) for each
flag one might want to control, I would prefer just uint32_t flags with
a doc about the possible values.

>  {
>   struct zwp_linux_buffer_params_v1 *params;
>   uint64_t modifier = 0;
> - uint32_t flags;
> + uint32_t flags = 0;
>   struct drm_device *drm_dev;
>  
>   if (!drm_connect(buffer)) {
> @@ -434,7 +434,8 @@ create_dmabuf_buffer(struct display *display, struct 
> buffer *buffer,
>* correct height to the compositor.
>*/
>   buffer->height = height;
> - flags = 0;
> + if (is_y_inverted)
> + flags |= ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT;
>  
>   params = zwp_linux_dmabuf_v1_create_params(display->dmabuf);
>   zwp_linux_buffer_params_v1_add(params,
> @@ -517,7 +518,8 @@ static const struct zxdg_toplevel_v6_listener 
> xdg_toplevel_listener = {
>  };
>  
>  static struct window *
> -create_window(struct display *display, int width, int height, int format)
> +create_window(struct display *display, int width, int height, int format,
> +   int is_y_inverted)

Here as well.

>  {
>   struct window *window;
>   int i;
> @@ -566,7 +568,7 @@ create_window(struct display *display, int width, int 
> height, int format)
>  
>   for (i = 0; i < NUM_BUFFERS; ++i) {
>   ret = create_dmabuf_buffer(display, >buffers[i],
> -width, height, format);
> +width, height, format, 
> is_y_inverted);
>  
>   if (ret < 0)
>   return NULL;
> @@ -814,13 +816,15 @@ print_usage_and_exit(void)
>   printf("usage flags:\n"
>   "\t'--import-immediate=<>'\n\t\t0 to import dmabuf via 
> roundtrip,"
>   "\n\t\t1 to enable import without roundtrip\n"
> + "\t'--y-inverted=<>'\n\t\t0 to not pass Y_INVERTED flag,"
> + "\n\t\t1 to pass Y_INVERTED flag\n"
>   "\t'--import-format=<>'\n\t\tXRGB to import dmabuf as XRGB,"
>   "\n\t\tNV12 to import as multi plane NV12 with tiling 
> modifier\n");
>   exit(0);
>  }
>  
>  static int
> -is_import_mode_immediate(const char* c)
> +is_true(const char* c)
>  {
>   if (!strcmp(c, "1"))
>   return 1;
> @@ -852,22 +856,29 @@ main(int argc, char **argv)
>   struct display *display;
>   struct window *window;
>   int is_immediate = 0;
> + int is_y_inverted= 0;
>   int import_format = DRM_FORMAT_XRGB;
>   int ret = 0, i = 0;
>  
>   if (argc > 1) {
>   static const char import_mode[] = "--import-immediate=";
>   static const char format[] = "--import-format=";
> + static const char y_inverted[] = "--y-inverted=";
>   for (i = 1; i < argc; i++) {
>   if (!strncmp(argv[i], import_mode,
>sizeof(import_mode) - 1)) {
> - is_immediate = is_import_mode_immediate(argv[i]
> + is_immediate = is_true(argv[i]
>   + sizeof(import_mode) - 
> 1);
>   }
>   else if (!strncmp(argv[i], format, sizeof(format) - 1)) 
> {
>   import_format = parse_import_format(argv[i]
>   + sizeof(format) - 1);
>   }
> + else if (!strncmp(argv[i], y_inverted,
> +  sizeof(y_inverted) - 1)) {
> + is_y_inverted = is_true(argv[i]
> + + sizeof(y_inverted) - 
> 1);
> + }
>   else {
>   print_usage_and_exit();
>   }

The command line parsing bit is probably ok, but if we are going to add
more options, I'd really prefer it migrating to getopt_long().

> @@ -875,7 +886,7 @@ main(int argc, char **argv)
>   }
>  
>   display = create_display(is_immediate, 

Re: [PATCH weston] build: honour libinput header location

[Pekka Paalanen]

On Tue, 27 Feb 2018 14:14:27 +
Emil Velikov  wrote:

> From: Jan Engelhardt 
> 
> Add the respective CFLAGS to the build, otherwise the build will error
> out as seen below.
> 
> src/libinput-seat.c:30:22: fatal error: libinput.h: No such file or directory
> 
> [Emil Velikov: polish commit message]
> Signed-off-by: Emil Velikov 
> ---
> Jan, don't be shy to send patches upstream. Devs. won't bite... most of
> the time ;-)
> ---
>  Makefile.am | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index b5c29c04..8de40e51 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -43,7 +43,8 @@ AM_CPPFLAGS =   \
>   -I$(top_builddir)/protocol  \
>   -DLIBWESTON_MODULEDIR='"$(libweston_moduledir)"' \
>   -DLIBEXECDIR='"$(libexecdir)"'  \
> - -DBINDIR='"$(bindir)"'
> + -DBINDIR='"$(bindir)"' \
> + $(LIBINPUT_BACKEND_CFLAGS)
>  
>  CLEANFILES = weston.ini  \
>   ivi-shell/weston.ini\

Hi,

I don't think we want the libinput flags on *everything*, but in the
same places where LIBINPUT_BACKEND_LIBS are already used.

Or do you think we should actually have CFLAGS of all deps with
everything we build, and just gate the LIBS we link with to the targets
that actually need it?


Thanks,
pq


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

Re: [PATCH wayland] tests: disable coredumps on sanity-test

[Daniel Stone]

On 14 February 2018 at 12:38, Pekka Paalanen  wrote:
> SEGV and ABRT by default cause a core dump, which may create a file,
> launch crash handlers, and so on. sanity-test has 21 processes that
> are expected to crash like this. Disable core dumps on them all.
>
> I counted 21 entries in coredumpctl list, while only 16 functions needed
> patching. After this patch no entries appear in coredumpctl list.

Very nice, thankyou!

Reviewed-by: Daniel Stone 

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

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

[Michael Tretter]

On Wed, 14 Mar 2018 14:06:59 +, Emil Velikov wrote:
> 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

These checks allow to configure systemd login support without dbus by
setting enable_systemd_login=auto and enable_dbus=no. In this case,
systemd login support should be disabled without error.

Having a separate message for dbus is good, but not sure if the
conditions are actually clearer.

> +
>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

The else branch is not needed, because it is only taken if
have_systemd_login already is no.

Michael

>  
> -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
___
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 Thu, 15 Mar 2018 00:19:10 +
Sichem Zhou  wrote:

> 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?

Hi,

there is only one event queue in the server-side per client. IIRC, it's
not really even a queue as much as just a buffer.

You can use WAYLAND_DEBUG=server environment variable to have
libwayland-server print all protocol messages at the time they are
processed. That means, the time when requests are being dispatched, and
events are being queued for sending. There is WAYLAND_DEBUG=client
working the same way for clients, but it might be confusing if it is
set for multiple clients at the same time.

If you need to check the messages on "the wire" instead, the Wayland
website extras have a list of some debugger programs. Messages enter
the wire on flush after send. Forgetting to flush will show the message
in WAYLAND_DEBUG=1 output, but it might not be actually sent at the
time.

This issue could also be a client bug. If you do not ensure that all
requests have been flushed out before going to sleep in poll(), they
might never actually reach the server until something else happens.


Thanks,
pq


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