Re: [PATCH wayland-web 1/3] toolkits: Don't say the core protocol is changing
On Tue, Aug 25, 2015 at 12:01:46PM +0800, Jonas Ådahl wrote: > The core protocol is not changing. Experimental protocols may be, so say > that instead. > > Signed-off-by: Jonas Ådahl LGTM. For all three: Reviewed-by: Bryce Harrington Pushed to trunk: db4285d..f7cbaeb master -> master > --- > toolkits.html | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/toolkits.html b/toolkits.html > index 6ada2d8..875ead3 100644 > --- a/toolkits.html > +++ b/toolkits.html > @@ -13,9 +13,8 @@ > > Before trying to compile and run any of the toolkits below, keep in > mind that they're all in progress and at most at the prototype stage. > -And Wayland is still in development and the API and the core protocol > -is still changing. We try to keep things up to date, but you're > -likely run into breakage. > +While the Wayland core protocol has been stable for some time, experimental > +protocols extensions are still changing. > > Qt 5 > > -- > 2.1.4 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v2 1/2] Extend WAYLAND_DISPLAY and name parameter semantics to support absolute paths.
On Thu, Aug 06, 2015 at 03:30:58PM +0200, Marek Chalupa wrote: > Hi, > > On 08/06/2015 01:49 PM, Davide Bettio wrote: > >Hello, > > > >On 2015-08-06 10:37, Marek Chalupa wrote: > >>the patch does not apply in the first place: > >> > >>Applying: Extend WAYLAND_DISPLAY and name parameter semantics to > >>support absolute paths. > >>fatal: corrupt patch at line 15 > >>Repository lacks necessary blobs to fall back on 3-way merge. > >>Cannot fall back to three-way merge. > > > >I hope the patch in my last mail can be applied. > >If it doesn't can you give me any hint about what should be fixed? > > Unfortunately, the patch still does not apply. Do you use git > send-email? Because it looks like the lines in the patch are > wrapped, not matching the code. Yeah, the line wrapping for this patch is messed up. git send-email would be worth trying. Bryce > Regards, > Marek > > >>On line 756 before this new code we check if XDG_RUNTIME_DIR is set in > >>the environment and if it is not we return an error. But when you use > >>absolute path, you don't need XDG_RUNTIME_DIR to be set. > > > >v3 fixes this issue. > > > >>The same XDG_RUNTIME_DIR thing in this function. > >> > > > >This is going to be changed by another patch so if you don't mind I'm > >not going to change this if all the other patches are going to be accepted. > > > >Bye, > >Davide Bettio. > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-web 1/3] toolkits: Don't say the core protocol is changing
The core protocol is not changing. Experimental protocols may be, so say that instead. Signed-off-by: Jonas Ådahl --- toolkits.html | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/toolkits.html b/toolkits.html index 6ada2d8..875ead3 100644 --- a/toolkits.html +++ b/toolkits.html @@ -13,9 +13,8 @@ Before trying to compile and run any of the toolkits below, keep in mind that they're all in progress and at most at the prototype stage. -And Wayland is still in development and the API and the core protocol -is still changing. We try to keep things up to date, but you're -likely run into breakage. +While the Wayland core protocol has been stable for some time, experimental +protocols extensions are still changing. Qt 5 -- 2.1.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 3/3] wayland: port the wayland backend to the new api
On Thu, Aug 13, 2015 at 01:53:06PM +0300, Pekka Paalanen wrote:
> From: Giulio Camuffo
So much is being moved around here that it's hard to assure that no bugs
got introduced. It feels like there's 2 or 3 refactoring steps being
done in one go; if we're dead set on landing this for beta perhaps
splitting those would make it easier to be certain it's correct.
That said, this looks pretty solid. After reading patch #2, I'm
understanding how this hangs together better. I've got a few comments
below, mainly about function names, but in general would be comfortable
seeing this land post-release. I'd like to see a bit more documentation
at least for the new structs being introduced, and I really would like
to see some test cases added, at least for the smaller easily-tested
functions.
> ---
> Makefile.am | 3 +
> src/compositor-wayland.c | 220
> ---
> src/compositor-wayland.h | 58 +
> src/main.c | 198 +-
> 4 files changed, 296 insertions(+), 183 deletions(-)
> create mode 100644 src/compositor-wayland.h
>
> diff --git a/Makefile.am b/Makefile.am
> index 2f21930..d05bf88 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -73,6 +73,7 @@ weston_SOURCES =\
> src/compositor.c\
> src/compositor.h\
> src/compositor-drm.h\
> + src/compositor-wayland.h\
> src/input.c \
> src/data-device.c \
> src/screenshooter.c \
> @@ -190,6 +191,7 @@ westoninclude_HEADERS = \
> src/version.h \
> src/compositor.h\
> src/compositor-drm.h\
> + src/compositor-wayland.h\
> src/timeline-object.h \
> shared/matrix.h \
> shared/config-parser.h \
> @@ -283,6 +285,7 @@ wayland_backend_la_CFLAGS = \
> $(AM_CFLAGS)
> wayland_backend_la_SOURCES = \
> src/compositor-wayland.c\
> + src/compositor-wayland.h\
> shared/helpers.h
> nodist_wayland_backend_la_SOURCES = \
> protocol/fullscreen-shell-protocol.c\
> diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
> index 9788714..1f04e65 100644
> --- a/src/compositor-wayland.c
> +++ b/src/compositor-wayland.c
> @@ -40,6 +40,7 @@
> #include
>
> #include "compositor.h"
> +#include "compositor-wayland.h"
> #include "gl-renderer.h"
> #include "pixman-renderer.h"
> #include "shared/helpers.h"
> @@ -49,8 +50,6 @@
> #include "fullscreen-shell-client-protocol.h"
> #include "presentation_timing-server-protocol.h"
>
> -#define WINDOW_TITLE "Weston Compositor"
> -
> struct wayland_backend {
> struct weston_backend base;
> struct weston_compositor *compositor;
> @@ -71,6 +70,7 @@ struct wayland_backend {
>
> int use_pixman;
> int sprawl_across_outputs;
> + char *window_title;
>
> struct theme *theme;
> cairo_device_t *frame_device;
> @@ -752,21 +752,15 @@ wayland_output_set_windowed(struct wayland_output
> *output)
> {
> struct wayland_backend *b =
> (struct wayland_backend *)output->base.compositor->backend;
> - int tlen;
> char *title;
>
> if (output->frame)
> return 0;
>
> if (output->name) {
> - tlen = strlen(output->name) + strlen(WINDOW_TITLE " - ");
> - title = malloc(tlen + 1);
> - if (!title)
> - return -1;
> -
> - snprintf(title, tlen + 1, WINDOW_TITLE " - %s", output->name);
> + title = strdup(output->name);
> } else {
> - title = strdup(WINDOW_TITLE);
> + title = strdup(b->window_title);
> }
>
> if (!b->theme) {
> @@ -1083,65 +1077,6 @@ err_name:
> }
>
> static struct wayland_output *
> -wayland_output_create_for_config(struct wayland_backend *b,
> - struct weston_config_section *config_section,
> - int option_width, int option_height,
> - int option_scale, int32_t x, int32_t y)
> -{
> - struct wayland_output *output;
> - char *mode, *t, *name, *str;
> - int width, height, scale;
> - uint32_t transform;
> - unsigned int slen;
> -
> - weston_config_section_get_string(config_section, "name", &name, NULL);
> - if (name) {
> - slen = strlen(name);
> - slen += strlen(WINDOW_TITLE " - ");
> - str = malloc(slen + 1);
> - if (str)
> -
Re: [PATCH weston 2/3] drm: port the drm backend to the new init api
On Thu, Aug 13, 2015 at 01:53:05PM +0300, Pekka Paalanen wrote:
> From: Giulio Camuffo
This is a big patch with a lot of changes, and I'm worried about landing
it right as we're on the eve of beta. If it could be broken up into
smaller easy-to-review bits, it might make it more digestible...
That said, I like where this is going. I'd be totally okay with landing
it post-release.
> ---
> Makefile.am | 3 +
> src/compositor-drm.c | 234
> ---
> src/compositor-drm.h | 89
> src/main.c | 127 +++-
> 4 files changed, 292 insertions(+), 161 deletions(-)
> create mode 100644 src/compositor-drm.h
>
> diff --git a/Makefile.am b/Makefile.am
> index 76ab546..2f21930 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -72,6 +72,7 @@ weston_SOURCES =\
> src/log.c \
> src/compositor.c\
> src/compositor.h\
> + src/compositor-drm.h\
> src/input.c \
> src/data-device.c \
> src/screenshooter.c \
> @@ -188,6 +189,7 @@ westonincludedir = $(includedir)/weston
> westoninclude_HEADERS = \
> src/version.h \
> src/compositor.h\
> + src/compositor-drm.h\
> src/timeline-object.h \
> shared/matrix.h \
> shared/config-parser.h \
> @@ -251,6 +253,7 @@ drm_backend_la_CFLAGS = \
> $(AM_CFLAGS)
> drm_backend_la_SOURCES = \
> src/compositor-drm.c\
> + src/compositor-drm.h\
> $(INPUT_BACKEND_SOURCES)\
> shared/helpers.h\
> shared/timespec-util.h \
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index ce95d05..4c298fe 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -50,6 +50,7 @@
> #include "shared/timespec-util.h"
> #include "libbacklight.h"
> #include "compositor.h"
> +#include "compositor-drm.h"
> #include "gl-renderer.h"
> #include "pixman-renderer.h"
> #include "libinput-seat.h"
> @@ -73,17 +74,6 @@
> #define GBM_BO_USE_CURSOR GBM_BO_USE_CURSOR_64X64
> #endif
>
> -static int option_current_mode = 0;
> -
> -enum output_config {
> - OUTPUT_CONFIG_INVALID = 0,
> - OUTPUT_CONFIG_OFF,
> - OUTPUT_CONFIG_PREFERRED,
> - OUTPUT_CONFIG_CURRENT,
> - OUTPUT_CONFIG_MODE,
> - OUTPUT_CONFIG_MODELINE
> -};
> -
> struct drm_backend {
> struct weston_backend base;
> struct weston_compositor *compositor;
> @@ -106,6 +96,7 @@ struct drm_backend {
> uint32_t connector_allocator;
> struct wl_listener session_listener;
> uint32_t format;
> + bool option_current_mode;
>
> /* we need these parameters in order to not fail drmModeAddFB2()
>* due to out of bounds dimensions, and then mistakenly set
> @@ -129,6 +120,10 @@ struct drm_backend {
>
> int32_t cursor_width;
> int32_t cursor_height;
> +
> + void (*configure_output)(struct weston_compositor *compositor,
> + const char *name,
> + struct weston_drm_backend_output_config
> *config);
> };
>
> struct drm_mode {
> @@ -219,13 +214,6 @@ struct drm_sprite {
> uint32_t formats[];
> };
>
> -struct drm_parameters {
> - int connector;
> - int tty;
> - int use_pixman;
> - const char *seat_id;
> -};
> -
> static struct gl_renderer_interface *gl_renderer;
>
> static const char default_seat[] = "seat0";
> @@ -2026,47 +2014,26 @@ find_and_parse_output_edid(struct drm_backend *b,
>
>
>
> -static int
> -parse_modeline(const char *s, drmModeModeInfo *mode)
> -{
> - char hsync[16];
> - char vsync[16];
> - float fclock;
> -
> - mode->type = DRM_MODE_TYPE_USERDEF;
> - mode->hskew = 0;
> - mode->vscan = 0;
> - mode->vrefresh = 0;
> - mode->flags = 0;
> -
> - if (sscanf(s, "%f %hd %hd %hd %hd %hd %hd %hd %hd %15s %15s",
> -&fclock,
> -&mode->hdisplay,
> -&mode->hsync_start,
> -&mode->hsync_end,
> -&mode->htotal,
> -&mode->vdisplay,
> -&mode->vsync_start,
> -&mode->vsync_end,
> -&mode->vtotal, hsync, vsync) != 11)
> - return -1;
> -
> - mode->clock = fclock * 1000;
> - if (strcmp(hsync, "+hsync") == 0)
> - mode->flags |= DRM_MODE_FLAG_PHSYNC;
> - else if (strcmp(hsync, "-hsync") == 0)
> - mode->f
Re: [PATCH weston 1/3] compositor: prep for migration to new config system
On Thu, Aug 13, 2015 at 12:30:01PM +0200, Giulio Camuffo wrote:
> From: Pekka Paalanen
>
> Add new configuration argument to the backend_init() function, which
> will replace the current argc, argv, and config arguments.
>
> Next, each backend is converted individually, after which the unused
> arguments will be removed.
>
> Also add the skeleton to main.c for picking the right configuration path
> by the backend.
>
> Fix an error path that forgot to destroy weston_compositor.
This will be a nice cleanup. I like that we're being deliberate in
setting things up for a series of refactorings. That said, this
description seems to suggest several distinct changes are being done;
maybe that's ok and appropriate, but I'm finding it makes the review a
touch more involved.
The bit that fixes the weston_compositor destruction sounds like it may
be landable on its own, if it can be teased out without too much effort.
> Signed-off-by: Pekka Paalanen
> ---
> src/compositor-drm.c | 3 +-
> src/compositor-fbdev.c| 3 +-
> src/compositor-headless.c | 3 +-
> src/compositor-rdp.c | 3 +-
> src/compositor-rpi.c | 3 +-
> src/compositor-wayland.c | 3 +-
> src/compositor-x11.c | 3 +-
> src/compositor.h | 21 --
> src/main.c| 71
> ---
> 9 files changed, 93 insertions(+), 20 deletions(-)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 585169e..ce95d05 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -3182,7 +3182,8 @@ err_base:
>
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_backend_config *config_base)
> {
> struct drm_backend *b;
> struct drm_parameters param = { 0, };
> diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> index 051a381..1431621 100644
> --- a/src/compositor-fbdev.c
> +++ b/src/compositor-fbdev.c
> @@ -903,7 +903,8 @@ out_compositor:
>
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_backend_config *config_base)
> {
> struct fbdev_backend *b;
> /* TODO: Ideally, available frame buffers should be enumerated using
> diff --git a/src/compositor-headless.c b/src/compositor-headless.c
> index dba21a6..ba0d8d7 100644
> --- a/src/compositor-headless.c
> +++ b/src/compositor-headless.c
> @@ -260,7 +260,8 @@ err_free:
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor,
>int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_backend_config *config_base)
> {
> int width = 1024, height = 640;
> char *display_name = NULL;
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index c221eb9..36c22d8 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -1269,7 +1269,8 @@ err_free_strings:
>
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
> - struct weston_config *wconfig)
> + struct weston_config *wconfig,
> + struct weston_backend_config *config_base)
> {
> struct rdp_backend *b;
> struct rdp_backend_config config;
> diff --git a/src/compositor-rpi.c b/src/compositor-rpi.c
> index 602cbee..f4b33ee 100644
> --- a/src/compositor-rpi.c
> +++ b/src/compositor-rpi.c
> @@ -551,7 +551,8 @@ out_compositor:
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor,
>int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_backend_config *config_base)
> {
> const char *transform = "normal";
> struct rpi_backend *b;
> diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
> index f6c84d4..9788714 100644
> --- a/src/compositor-wayland.c
> +++ b/src/compositor-wayland.c
> @@ -2049,7 +2049,8 @@ wayland_backend_destroy(struct wayland_backend *b)
>
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_backend_config *config_base)
> {
> struct wayland_backend *b;
> struct wayland_output *output;
> diff --git a/src/compositor-x11.c b/src/compositor-x11.c
> index 73ba783..d18595d 100644
> --- a/src/compositor-x11.c
> +++ b/src/compositor-x11.c
> @@ -1681,7 +1681,8 @@ err_free:
>
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_ba
Re: [PATCH v3 weston] Introduce pointer locking and confinement protocol
On Mon, Aug 24, 2015 at 10:44:55AM -0700, Bill Spitzak wrote: > On Sun, Aug 23, 2015 at 8:19 PM, Jonas Ådahl wrote: > > > > > 1. the pointer "attaches" to the UI element. > > > > One would create a lock region on the scroll handle. When enabled one > > would hide the cursor, create an identical cursor surface and add it as > > a subsurface positioning relative to the scroll handle. One would now > > listen for events from wl_relative_pointer, update the subsurface > > position and the scroll handle widget under it. When done, one would > > unlock the lock, destroy the subsurface, and reset the pointer cursor. > > During the moving, one would set the cursor position hint so when > > resetting the cursor position would be updated. > > > > This is the first sign that you have actually thought about this. However > you seem blind to the trivial solution. Here is my rewrite of the above > paragraph with the set_cursor_pos proposal: > > "One would create a lock region on the scroll handle. When enabled one > would now listen for events from wl_relative_pointer, update the cursor > position and the scroll handle widget under it. When done, one would unlock > the lock." > > This is the only way to guarantee the "attachment" effect. There is one > > unsolved issue which is that the cursor sprite and the subsurface might > > be visible at the same time, and we'd need some kind of "transaction" > > protocol to solve this. There has been ideas to have a "set_cursor_pos" > > but this method would never give us any guarantees about "attachment". > > > > WTF???. Your proposal is that the client draw a fake cursor in a subsurface > and setting that to some x,y position to move the cursor. I propose that > the same x,y are sent to set_cursor_pos. THE EXACT SAME NUMBERS! It is > impossible for "attachement" to be different between the two proposals > > All I can guess is that you think that there is going to be synchronization > between subsurface positioning and the surface image, but for some reason > such synchronization will be missing for set_cursor_pos. But why? The > cursor surface belongs to the locking client just as much as any > subsurface, so any rules for subsurfaces can be applied to it as well. I'd > also like to know why suddenly this is important, when you have repeatedly > claimed that avoiding latency is more important that sync image updating. Not going to go down this road again. > > If the client wants to control the activation, it can simply request the > > lock exactly at the point it wants it to be activated. resize.c in > > weston is an example of this - it activates the lock on a pointer button > > event. > > > > This is great if it works, however I hope you realize that this will be the > ONLY way that any clients with small lock regions will turn on pointer > lock. Having to update the "activation region" for every widget on every > layout change is extremely bad, it will send large amounts of data to the > server for no reason, kind of like old X11 toolkits that sent every widget > as a subwindow. This was known to be a mistake back in the mid 80's when > lightweight widgets were added to x intrinsics. Requesting a lock as a response to a click sounds like a reasonable way to implement it to me. Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 0/3] start making backends not weston specific
On Mon, Aug 17, 2015 at 11:29:01AM +0300, Pekka Paalanen wrote: > On Thu, 13 Aug 2015 12:30:00 +0200 > Giulio Camuffo wrote: > > > The first patch by Pekka adds some functions to ease a smooth migration > > from the old way of initializing the backends to a new one which is > > libweston friendly. > > The other two patches make the drm and wayland backends use that new way. > > The other backends will follow if we're ok with the direction this is going. > > > > Giulio Camuffo (2): > > drm: port the drm backend to the new init api > > wayland: port the wayland backend to the new api > > > > Pekka Paalanen (1): > > compositor: prep for migration to new config system > > > > Makefile.am | 6 + > > src/compositor-drm.c | 233 +-- > > src/compositor-drm.h | 89 +++ > > src/compositor-fbdev.c| 3 +- > > src/compositor-headless.c | 3 +- > > src/compositor-rdp.c | 3 +- > > src/compositor-rpi.c | 3 +- > > src/compositor-wayland.c | 219 +- > > src/compositor-wayland.h | 58 +++ > > src/compositor-x11.c | 3 +- > > src/compositor.h | 21 ++- > > src/main.c| 392 > > -- > > 12 files changed, 675 insertions(+), 358 deletions(-) > > create mode 100644 src/compositor-drm.h > > create mode 100644 src/compositor-wayland.h > > > > Hi all, > > what do people think of landing this stuff before the 1.9-beta release, > would anyone object? IMO it's ok as it's only Weston internals > restructuring. Conceptually I like the patches, but the changes seem a little jumbled. I'll try and provide more constructive feedback separately. While these mostly just are refactoring internals, the size of the patches worries me a bit simply that the quantity of code changes might hide a bug or two. Correct me if I'm wrong, but more work is still needed before libweston is a usable library for end users, and whether this lands or waits a bit won't impact that? Assuming that's true, I'd kind of prefer holding off on landing these until 1.10, and get a bit more review and testing done on them. Maybe there's some smaller bits that would be ok to land; I'll try to flag what looks safe to me. Bryce > Of course I need to review the patches first, and I'd like at least an > ack for the first patch from someone else. > > "This stuff" would be the backend conversion patches like done for DRM > and Wayland backends in this series and possibly some more libweston > preparatory work, but not the patch to build libweston.so as we already > agreed the cut-off point for that was the alpha release. > > Hmm, need to patch README to not say "Libweston was first introduced in > Weston 1.9"... > > Oh yeah, I'm also aware of > https://bugs.freedesktop.org/show_bug.cgi?id=91654 > > > Thanks, > pq > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIVAwUBVdGbVCNf5bQRqqqnAQiRcA//eRBftcguI7pqRqaCpYRnLzzf5jprt3fk > cyXlD/fEVb7oGxzMCRkmGn32+2bxXH3ujJpeXVIBAc0kPkkVycAqH0uxzaH+7Syk > RS2o82RSkVrf8qQHcPkPWMV2d1C35fqr2bF9pSJJAPZlfGxpFKJ4IObAv9632Zfp > pJrssTYjeftPy+gVX2a4sXWVh528pO2qp8ioOAJ5MFtr6LfWov1WTEcD8VKtiBUC > udEU7XctEDUCtOIBSILQeLRwOCjG5u67n9w3SHwFhU3pKWrlIfmFYNNX+ETN5Ue5 > NohFy9Asfsptjkb6hrjrrU3MF9ypq3WU86yyPwZKgX/dYQzSMQmi4f15HSpTIyvg > gdmXFSx5ws2152qt15L95o6mLXSUMpyplfFNnTkHDdNKaKNataDMLNy3WKNKymrJ > VOLxnI7CqGsIznUs7+1YFmNeE4u63VFQ8JVrKpeTUQK4WIYIXDh/AJq+c26zQDv/ > 1+mZ+IPgFiyuXCuNOM2z0CyumVeY2ln/7Vg1QXm8qtCTu1h+S2LSSVajO/zSmDZo > neP0FgKnpQVTCDaiQYe/hn6l+847rXizHNpohtGNK9Ny1R1rEsX2LIHjZ5CJNFBy > cx+WpJ4fm/yF1n85BShkDdaZDNm1leeQ/efNDIWZ/nXy5czBi48CuXuqDP9kPIih > oW45eklDHlk= > =RR3y > -END PGP SIGNATURE- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v2] ivi-layout: implement surface clipping
On Mon, Aug 24, 2015 at 01:21:21PM +0300, Pekka Paalanen wrote: > On Mon, 24 Aug 2015 10:24:15 +0900 > Nobuhiko Tanibata wrote: > > > From: Nobuhiko Tanibata > > > > View clip region is set in surface-local coordinates. To compute that > > region, the ivi-layer destination rectangle in the global coordinates > > are transformed back into the surface-local coordinates. > > > > The transformation is computed by first forming the transformation > > matric for the forward mappings, and then inverting it. The inverse > > matric is used to transform the destination rectangles to the > > surface-local coordinate system. The intersection of the rectangles is > > the view clip mask. > > > > Signed-off-by: Nobuhiko Tanibata > > Reviewed-by: Pekka Paalanen > > --- > > Changes for v2 > > - fix whitespaces > > - rebase on master branch > > > > ivi-shell/ivi-layout.c | 147 > > +++-- > > 1 file changed, 141 insertions(+), 6 deletions(-) > > Hi all, > > I think this can land for the 1.9-beta, so I will be pushing these on, say, > Wednesday if no-one objects. This includes "hmi-controller: fix the > laucher layer width" and "hmi-controller: fix wrong width and height > are set to a layer of workspace." too. I did a cursory review of the three patches and didn't spot anything to object to. +1 to landing for 1.9-beta. Reviewed-by: Bryce Harrington Bryce > Thanks, > pq > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIVAwUBVdrwKiNf5bQRqqqnAQjrRw/+OygTSWiTMlNUxWXPOcnCFUUguQWkTZwk > 1FYtMTzVV1whpCNyYeUkOZ8GgdB+2nR5BZweSA6AzXrHmbDk8KUkmhvY2wUr4Hs+ > xrPU0iY4uNJXCID5Q18onXo/IJwAhfZk/gPN4kdLG6qbF5ra82ebb6Hu0RAjY/pA > bmXtFWU7/9f88b5YFa8lOh43ARAigca4WxANq/DryJY2OkdiXnqgIbcOGnuhZ5ab > Iu3xQmUvCsWi80pTM3qMmANpV1fjEvTXHMs3mWlG0z1wYe86liaMIEeCsNPOtCxt > Py0LwHjnlrY2g/UcY3Hk5JDw8Ws10f1zUu4Hhz8wWQJOKGqwA9kPFT2lsQJNJtHg > XepVrfuavoZbZXR0fkfTe3HtpPxCLSnF7jrSQ2RRtUwv02nRvqit1TGYvb5wR8Jd > Ae12BLHN+jJMT4jbBa6sSrmlM8oghly9QooJOrlQRWTI1bZ15gYNIe3To7x1SGOf > NRFaVA/edqb7vSJNruLkip63UrCbFLtj+JJlE8lw9UpReD3aJ8FcydXOpOpXzswD > NH8N1oxa34eMo+Sge6DexYCJn0YGsU0W0EIiwJsn8Y70BCeLVExt8bk+21EXgF+4 > OoIT/cCMvu7MBUPGRljp5mo/8IJ+Juma3J3Rzg2DmSVXpxiBLOkeNy1tyLElUKsx > zsZbLl5qQqA= > =EDf9 > -END PGP SIGNATURE- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston test suite
On 08/24/2015 02:50 AM, Pekka Paalanen wrote: > On Sat, 22 Aug 2015 00:00:58 -0700 > Bryce Harrington wrote: > >> On Fri, Aug 21, 2015 at 10:35:34AM +0300, Pekka Paalanen wrote: >>> On Thu, 20 Aug 2015 11:05:39 -0700 >>> Bryce Harrington wrote: >>> > (I wish we had some tests with coverage of this chunk of code, so I could give my usual plug for adding test cases; if we did, it'd probably pretty easy to add a couple test cases here and give us a bit extra confidence.) >>> >>> It's a bit tough in this case, I'm not sure if we can affect what >>> outputs the kernel exposes, so it'd be tied to the test machine. >> >> No, the way you'd do it is to construct a "mock kernel", and then >> whereever the functionality expects data from the kernel (or is making >> kernel calls), you abstract that so you can slip your mock in instead. >> Sort of the same idea as how we replaced the graphics card / monitor >> with synthetic ones in the headless testing. >> >> I know it probably sounds like a pain in the ass (and it is), but if >> you're serious about wanting stronger automated testing of Weston, then >> that's the sort of stuff that needs done. And it's certainly >> understandable to want to put off spending time writing tests, but it's >> the same thing with documentation and look how horribly undocumented >> Wayland is - unless you document and write tests as you go, it ain't >> gonna get done. > > Hi, > > it's actually good to bring this up right now. We have the old test > suite which is painful to work with, and we have the new test suite > which is seriously lacking to become on par even with the old suite in > terms of helpers. > > Jon, what are your plans in continuing with the test suite? > > I haven't seen a new patch series in quite a while, and I don't see any > pending in Patchwork either. Yes, The other project I work on just finished pushing out their latest version, so Wayland was getting refocused for my attention. Patches for both base Wayland testing and explicit Weston testing fixtures should be coming once things are updated to apply to the latest code. Also, if we are talking about actual mocking actual system calls, that can be done but does take a little thought. If we can pinpoint a few target cases for testing to cover, then getting the needed support in place can flow a lot quicker. At many other groups I've been the main person to deliver fixtures and mocks to allow other people to write tests against them. Ideally we do the heavy lifting once and then allow individual developers to easily test a much wider range of functionality and scenarios. Pragmatically, If I don't make testing easy, then I end up the only one writing tests. Don't want that case :-) -- Jon A. Cruz - Senior Open Source Developer Samsung Open Source Group j...@osg.samsung.com signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] build, compositor-drm: fix output name constants another way
On Mon, Aug 24, 2015 at 12:32:33PM -0500, Derek Foreman wrote:
> On 24/08/15 06:27 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen
> >
> > Bumping libdrm requirement by 3 years just for output connector name
> > constants was a bit much. Fix the problem introduced in
> > 89c49b3060a115e846ba1e7fbef94d14894244f2 by conditionally using the new
> > additions.
> >
> > Both VIRTUAL and DSI came in the same libdrm commit
> > 566c3ce877a4be72697e15cdfc421ce965f7c37d, so we check only for DSI.
>
> Hmm, this is somewhat gross. Is there a solid reason to care about
> people who want to run new weston and ancient libdrm?
I've been on the other side of this equation. libdrm can be a royal
PITA to have to change out, I can totally imagine there are several
quite solid reasons one would want to run new weston and oldish libdrm.
> Shouldn't anyone doing that be responsible for their own sketchy out
> of tree patches to make things go?
Perhaps. I certainly have had to do that myself for Ubuntu. But
it adds inconvenience to have to have local patches, and then you're not
running *exactly* upstream's code, so reporting bugs upstream becomes
more involved, etc.
In this case the patch we'd need to carry is fairly tiny, and it
presumably will help not only this guy but anyone else in the same
situation. Like pq pointed out, this got flagged so quickly there could
be quite a few others.
> At this point I guess atomic isn't likely to land in time for 1.9, but
> as soon as it does (presumably before 1.10) an even newer libdrm will be
> required anyway.
>
> Can you add a comment about why we have the ifdef so there's a greater
> chance someone will actually remove it after the mandatory version bump
> happens for 1.10?
Perhaps a patch to remove the #ifdefs could be added to the atomic kms
patch stack, so no one has to remember to do anything. :-)
> (either that or just ignore those two weird connector types and let them
> be unknown - what are they anyway?)
I'd be fine with that too, but I really don't see the harm in having
them there but #ifdef'd.
Bryce
> That done,
> Reviewed-by: Derek Foreman
>
> > This patch also reverts faee330c5e027011941d50533156683be3a67ca3.
> >
> > Reported-by: Eugen Friedrich
> > Cc: Derek Foreman
> > Signed-off-by: Pekka Paalanen
> > ---
> > configure.ac | 2 +-
> > src/compositor-drm.c | 2 ++
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index d70777d..425f071 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -171,7 +171,7 @@ AC_ARG_ENABLE(drm-compositor, [
> > --enable-drm-compositor],,
> > 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.59 gbm
> > mtdev >= 1.1.0])
> > + 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])])
> > diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> > index c85a462..f5f125a 100644
> > --- a/src/compositor-drm.c
> > +++ b/src/compositor-drm.c
> > @@ -1760,8 +1760,10 @@ static const char * const connector_type_names[] = {
> > [DRM_MODE_CONNECTOR_HDMIB] = "HDMI-B",
> > [DRM_MODE_CONNECTOR_TV] = "TV",
> > [DRM_MODE_CONNECTOR_eDP] = "eDP",
> > +#ifdef DRM_MODE_CONNECTOR_DSI
> > [DRM_MODE_CONNECTOR_VIRTUAL] = "Virtual",
> > [DRM_MODE_CONNECTOR_DSI] = "DSI",
> > +#endif
> > };
> >
> > static char *
> >
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] build: Require newer version of libdrm
On Mon, Aug 24, 2015 at 01:06:45PM +0200, Eugen Friedrich wrote: > Hello dear community, > > in our current project we are trying to follow the weston master branch as > much as possible, Hi Eugen, can you tell us more about your project? Bryce > recently introduced dependency to libdrm 2.4.59 will prevent us to use > weston 1.9, > The patches for naming correction are good and important. > so we would love to see a missing defines in the corresponding #ifdef > statement. > > Are display name defines the only reason to add a dependency to 2.4.59? > > 2015-08-24 10:52 GMT+02:00 Pekka Paalanen : > > > On Fri, 21 Aug 2015 23:24:54 -0700 > > Bryce Harrington wrote: > > > > > On Fri, Aug 21, 2015 at 11:06:02PM -0500, Derek Foreman wrote: > > > > commit 89c49b3060a115e846ba1e7fbef94d14894244f2 changed the way we name > > > > outputs, but it also added the new output names VIRTUAL and DSI. > > > > > > > > These aren't available until libdrm 2.4.59 > > > > Hi, > > > > sorry I forgot to check when those appeared. > > > > > Ubuntu 14.04 appears to have 2.4.60. Presumably other distros of that > > > vintige will have similar. So this looks like a reasonable dependency > > > bump to me. > > > > > > > Signed-off-by: Derek Foreman > > > > > > Reviewed-by: Bryce Harrington > > > > Alright. It would be very easy to just #ifdef these in case we wanted > > to keep the libdrm requirement the same. I pushed your patch, and we > > can fix it the other way if someone complains. (It's a 3 year bump, so > > I'm not surprised if I need to fix it the other way.) > >decc965..faee330 master -> master > > > > > > Thanks, > > pq > > > > > > --- > > > > configure.ac | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/configure.ac b/configure.ac > > > > index 425f071..d70777d 100644 > > > > --- a/configure.ac > > > > +++ b/configure.ac > > > > @@ -171,7 +171,7 @@ AC_ARG_ENABLE(drm-compositor, [ > > --enable-drm-compositor],, > > > > 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, [libudev >= 136 libdrm >= 2.4.59 > > 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])]) > > > > -- > > > > 2.4.6 > > > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Libinput: Halfkey/Mirrorboard implementation
On 24 August 2015 at 18:57, Bill Spitzak wrote: > There is considerable dislike for this idea from the Wayland developers, > though I am stumped why. Not really sure how you're stumped, given that I've reiterated the reason several times. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Libinput: Halfkey/Mirrorboard implementation
On Sun, Aug 23, 2015 at 11:38 AM, Kieran Bingham wrote: > > > This is a very common request, usually for the opposite reason: to make a > > modifier also produce a keysym. In particular it would allow Ctrl or > AltGr > > to act as a compose prefix, something a lot of plugins for Windows does, > > while X (which invented the compose key) is forced to dedicate a key. > > (compose is (I hope) actually done by the input method, which can in > fact do > > this handling of Ctrl, the problem is that it can't use the mapping of > the > > compose key, it has to actually use Ctrl, and thus it has to have a > > different configuration file to control what key is the compose prefix > than > > the keyboard layout). > > > > This can also make Windows style things like Alt moving the focus to the > > menubar, or the Super key popping up a dialog while still acting like a > > modifier. I know these work on Linux but they do so because the apps are > > actually looking at the Alt or Super key to see if they are released. It > > seems more consistent that these actually produce a "Move to menubar" or > > "super menu" keysym, thus allowing keyboard layouts to move them around. > > Yes - these are perfect examples. I guess you are saying that this is > not currently > handled by xkb, but by the desktop manager or UI toolkit? > Yes. Currently the toolkit has the information "the Alt modifier moves the focus to the menubar". Rather than the more consistent "the Alt key has the MOVE_FOCUS_TO_MENUBAR keysym". This is somewhat annoying because what the user considers key assignments is done in different places. In reality it is more of a conceptual problem than practical one, as users rarely change such assignments. > > And before you say "rollover" I am well aware of that. The toolkits > handling > > the Alt key are already dealing with this, and it is no excuse for > > completely disabling functionality!. I think xkb could use the event > > timestamps to detect this. Though it really sounds like that touch > handling > > stuff with all the fiddly timing and dependency on hardware details, so > > maybe (yeah right) we could again consider moving keysym translation to > > libinput and out of clients. > > > What's 'rollover' in this context? > If a user types quickly they may not release the previous key fast enough and thus the release is after the press for the next key. In your example a user may just be typing fast, and intending to type a space and then the letter 'a', but they are going quick enough that the space is still held down. Your keyboard would then type a semicolon when the user expected an 'a'. Yes this is a problem, but it is not a reason to make it impossible for xkb to do this at all. However I believe that is the excuse being used for this lack of ability. (normal solution is to apply complicated timing rules to detect if this is happening. Certainly xkb could do this, it gets timing information. I personally feel this is a complexity similar to the touch rules being done by libinput, therefore the entire decoding should be moved from clients to libinput, and Wayland clients would get events with the already-decoded keysyms attached to them. There is considerable dislike for this idea from the Wayland developers, though I am stumped why. My best guess is that it makes X11 emulation harder). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3 weston] Introduce pointer locking and confinement protocol
On Sun, Aug 23, 2015 at 8:19 PM, Jonas Ådahl wrote: > > 1. the pointer "attaches" to the UI element. > > One would create a lock region on the scroll handle. When enabled one > would hide the cursor, create an identical cursor surface and add it as > a subsurface positioning relative to the scroll handle. One would now > listen for events from wl_relative_pointer, update the subsurface > position and the scroll handle widget under it. When done, one would > unlock the lock, destroy the subsurface, and reset the pointer cursor. > During the moving, one would set the cursor position hint so when > resetting the cursor position would be updated. > This is the first sign that you have actually thought about this. However you seem blind to the trivial solution. Here is my rewrite of the above paragraph with the set_cursor_pos proposal: "One would create a lock region on the scroll handle. When enabled one would now listen for events from wl_relative_pointer, update the cursor position and the scroll handle widget under it. When done, one would unlock the lock." This is the only way to guarantee the "attachment" effect. There is one > unsolved issue which is that the cursor sprite and the subsurface might > be visible at the same time, and we'd need some kind of "transaction" > protocol to solve this. There has been ideas to have a "set_cursor_pos" > but this method would never give us any guarantees about "attachment". > WTF???. Your proposal is that the client draw a fake cursor in a subsurface and setting that to some x,y position to move the cursor. I propose that the same x,y are sent to set_cursor_pos. THE EXACT SAME NUMBERS! It is impossible for "attachement" to be different between the two proposals All I can guess is that you think that there is going to be synchronization between subsurface positioning and the surface image, but for some reason such synchronization will be missing for set_cursor_pos. But why? The cursor surface belongs to the locking client just as much as any subsurface, so any rules for subsurfaces can be applied to it as well. I'd also like to know why suddenly this is important, when you have repeatedly claimed that avoiding latency is more important that sync image updating. If the client wants to control the activation, it can simply request the > lock exactly at the point it wants it to be activated. resize.c in > weston is an example of this - it activates the lock on a pointer button > event. > This is great if it works, however I hope you realize that this will be the ONLY way that any clients with small lock regions will turn on pointer lock. Having to update the "activation region" for every widget on every layout change is extremely bad, it will send large amounts of data to the server for no reason, kind of like old X11 toolkits that sent every widget as a subwindow. This was known to be a mistake back in the mid 80's when lightweight widgets were added to x intrinsics. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] build, compositor-drm: fix output name constants another way
On 24/08/15 06:27 AM, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> Bumping libdrm requirement by 3 years just for output connector name
> constants was a bit much. Fix the problem introduced in
> 89c49b3060a115e846ba1e7fbef94d14894244f2 by conditionally using the new
> additions.
>
> Both VIRTUAL and DSI came in the same libdrm commit
> 566c3ce877a4be72697e15cdfc421ce965f7c37d, so we check only for DSI.
Hmm, this is somewhat gross. Is there a solid reason to care about
people who want to run new weston and ancient libdrm? Shouldn't anyone
doing that be responsible for their own sketchy out of tree patches to
make things go?
At this point I guess atomic isn't likely to land in time for 1.9, but
as soon as it does (presumably before 1.10) an even newer libdrm will be
required anyway.
Can you add a comment about why we have the ifdef so there's a greater
chance someone will actually remove it after the mandatory version bump
happens for 1.10?
(either that or just ignore those two weird connector types and let them
be unknown - what are they anyway?)
That done,
Reviewed-by: Derek Foreman
> This patch also reverts faee330c5e027011941d50533156683be3a67ca3.
>
> Reported-by: Eugen Friedrich
> Cc: Derek Foreman
> Signed-off-by: Pekka Paalanen
> ---
> configure.ac | 2 +-
> src/compositor-drm.c | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index d70777d..425f071 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -171,7 +171,7 @@ AC_ARG_ENABLE(drm-compositor, [
> --enable-drm-compositor],,
> 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.59 gbm
> mtdev >= 1.1.0])
> + 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])])
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index c85a462..f5f125a 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -1760,8 +1760,10 @@ static const char * const connector_type_names[] = {
> [DRM_MODE_CONNECTOR_HDMIB] = "HDMI-B",
> [DRM_MODE_CONNECTOR_TV] = "TV",
> [DRM_MODE_CONNECTOR_eDP] = "eDP",
> +#ifdef DRM_MODE_CONNECTOR_DSI
> [DRM_MODE_CONNECTOR_VIRTUAL] = "Virtual",
> [DRM_MODE_CONNECTOR_DSI] = "DSI",
> +#endif
> };
>
> static char *
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] build: Require newer version of libdrm
On Mon, 24 Aug 2015 14:16:17 +0300 Pekka Paalanen wrote: > On Mon, 24 Aug 2015 13:06:45 +0200 > Eugen Friedrich wrote: > > > Hello dear community, > > > > in our current project we are trying to follow the weston master branch as > > much as possible, > > recently introduced dependency to libdrm 2.4.59 will prevent us to use > > weston 1.9, > > The patches for naming correction are good and important. > > so we would love to see a missing defines in the corresponding #ifdef > > statement. > > Heh, that came even faster than I expected. :-) > > > Are display name defines the only reason to add a dependency to 2.4.59? > > Yes, as far as I know. > By the way, once Weston's atomic KMS feature lands in full, we will probably bump the libdrm version requirement to at least 2.4.62. I think this is quite likely to happen for Weston 1.10 (i.e. during 1.9.90). Thanks, pq pgpbrckOsdGDr.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] build, compositor-drm: fix output name constants another way
From: Pekka Paalanen
Bumping libdrm requirement by 3 years just for output connector name
constants was a bit much. Fix the problem introduced in
89c49b3060a115e846ba1e7fbef94d14894244f2 by conditionally using the new
additions.
Both VIRTUAL and DSI came in the same libdrm commit
566c3ce877a4be72697e15cdfc421ce965f7c37d, so we check only for DSI.
This patch also reverts faee330c5e027011941d50533156683be3a67ca3.
Reported-by: Eugen Friedrich
Cc: Derek Foreman
Signed-off-by: Pekka Paalanen
---
configure.ac | 2 +-
src/compositor-drm.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index d70777d..425f071 100644
--- a/configure.ac
+++ b/configure.ac
@@ -171,7 +171,7 @@ AC_ARG_ENABLE(drm-compositor, [ --enable-drm-compositor],,
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.59 gbm mtdev
>= 1.1.0])
+ 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])])
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index c85a462..f5f125a 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1760,8 +1760,10 @@ static const char * const connector_type_names[] = {
[DRM_MODE_CONNECTOR_HDMIB] = "HDMI-B",
[DRM_MODE_CONNECTOR_TV] = "TV",
[DRM_MODE_CONNECTOR_eDP] = "eDP",
+#ifdef DRM_MODE_CONNECTOR_DSI
[DRM_MODE_CONNECTOR_VIRTUAL] = "Virtual",
[DRM_MODE_CONNECTOR_DSI] = "DSI",
+#endif
};
static char *
--
2.4.6
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] build: Require newer version of libdrm
On Mon, 24 Aug 2015 13:06:45 +0200 Eugen Friedrich wrote: > Hello dear community, > > in our current project we are trying to follow the weston master branch as > much as possible, > recently introduced dependency to libdrm 2.4.59 will prevent us to use > weston 1.9, > The patches for naming correction are good and important. > so we would love to see a missing defines in the corresponding #ifdef > statement. Heh, that came even faster than I expected. :-) > Are display name defines the only reason to add a dependency to 2.4.59? Yes, as far as I know. I'll whip up a patch. Thanks, pq > 2015-08-24 10:52 GMT+02:00 Pekka Paalanen : > > > On Fri, 21 Aug 2015 23:24:54 -0700 > > Bryce Harrington wrote: > > > > > On Fri, Aug 21, 2015 at 11:06:02PM -0500, Derek Foreman wrote: > > > > commit 89c49b3060a115e846ba1e7fbef94d14894244f2 changed the way we name > > > > outputs, but it also added the new output names VIRTUAL and DSI. > > > > > > > > These aren't available until libdrm 2.4.59 > > > > Hi, > > > > sorry I forgot to check when those appeared. > > > > > Ubuntu 14.04 appears to have 2.4.60. Presumably other distros of that > > > vintige will have similar. So this looks like a reasonable dependency > > > bump to me. > > > > > > > Signed-off-by: Derek Foreman > > > > > > Reviewed-by: Bryce Harrington > > > > Alright. It would be very easy to just #ifdef these in case we wanted > > to keep the libdrm requirement the same. I pushed your patch, and we > > can fix it the other way if someone complains. (It's a 3 year bump, so > > I'm not surprised if I need to fix it the other way.) > >decc965..faee330 master -> master > > pgp5s5JFUirF_.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] build: Require newer version of libdrm
Hello dear community, in our current project we are trying to follow the weston master branch as much as possible, recently introduced dependency to libdrm 2.4.59 will prevent us to use weston 1.9, The patches for naming correction are good and important. so we would love to see a missing defines in the corresponding #ifdef statement. Are display name defines the only reason to add a dependency to 2.4.59? 2015-08-24 10:52 GMT+02:00 Pekka Paalanen : > On Fri, 21 Aug 2015 23:24:54 -0700 > Bryce Harrington wrote: > > > On Fri, Aug 21, 2015 at 11:06:02PM -0500, Derek Foreman wrote: > > > commit 89c49b3060a115e846ba1e7fbef94d14894244f2 changed the way we name > > > outputs, but it also added the new output names VIRTUAL and DSI. > > > > > > These aren't available until libdrm 2.4.59 > > Hi, > > sorry I forgot to check when those appeared. > > > Ubuntu 14.04 appears to have 2.4.60. Presumably other distros of that > > vintige will have similar. So this looks like a reasonable dependency > > bump to me. > > > > > Signed-off-by: Derek Foreman > > > > Reviewed-by: Bryce Harrington > > Alright. It would be very easy to just #ifdef these in case we wanted > to keep the libdrm requirement the same. I pushed your patch, and we > can fix it the other way if someone complains. (It's a 3 year bump, so > I'm not surprised if I need to fix it the other way.) >decc965..faee330 master -> master > > > Thanks, > pq > > > > --- > > > configure.ac | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/configure.ac b/configure.ac > > > index 425f071..d70777d 100644 > > > --- a/configure.ac > > > +++ b/configure.ac > > > @@ -171,7 +171,7 @@ AC_ARG_ENABLE(drm-compositor, [ > --enable-drm-compositor],, > > > 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, [libudev >= 136 libdrm >= 2.4.59 > 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])]) > > > -- > > > 2.4.6 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v2] ivi-layout: implement surface clipping
On Mon, 24 Aug 2015 10:24:15 +0900 Nobuhiko Tanibata wrote: > From: Nobuhiko Tanibata > > View clip region is set in surface-local coordinates. To compute that > region, the ivi-layer destination rectangle in the global coordinates > are transformed back into the surface-local coordinates. > > The transformation is computed by first forming the transformation > matric for the forward mappings, and then inverting it. The inverse > matric is used to transform the destination rectangles to the > surface-local coordinate system. The intersection of the rectangles is > the view clip mask. > > Signed-off-by: Nobuhiko Tanibata > Reviewed-by: Pekka Paalanen > --- > Changes for v2 > - fix whitespaces > - rebase on master branch > > ivi-shell/ivi-layout.c | 147 > +++-- > 1 file changed, 141 insertions(+), 6 deletions(-) Hi all, I think this can land for the 1.9-beta, so I will be pushing these on, say, Wednesday if no-one objects. This includes "hmi-controller: fix the laucher layer width" and "hmi-controller: fix wrong width and height are set to a layer of workspace." too. Thanks, pq pgpi4Ej2HHTwp.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] Revert "client: require WAYLAND_DISPLAY to be set"
On Mon, 17 Aug 2015 16:17:57 +0300 Pekka Paalanen wrote: > From: Pekka Paalanen > > This reverts commit fb7e13021730d0a5516ecbd3712ea4235e05d24d. > > Developers have been trying to reduce the number of by default required > environment variables, and the mentioned commit is a step backwards in > that sense. The fundamental assumption is that a user has only one main > (Wayland) display server where all programs should connect to by > default, and do so with an a priori known socket name. > > The commit also broke various use cases in the wild, some accidentally > due to other causes, some intentionally. This revert allows those use > cases to continue. > > The original problem of running Weston in a window in an existing GNOME > X11 session and getting applications unintentionally launched into > Weston can be circumvented by letting Weston use a non-default socket > name, leaving wayland-0 unused. > > Discussion: > http://lists.freedesktop.org/archives/wayland-devel/2015-August/023927.html > http://lists.freedesktop.org/archives/wayland-devel/2015-August/023937.html > > Cc: Dima Ryazanov > Cc: Giulio Camuffo > Cc: Daniel Stone > Cc: Jasper St. Pierre > Cc: Ryo Munakata > Cc: Ray Strode > Cc: Peter Hutterer > Cc: Matthias Clasen > Cc: Sjoerd Simons > Signed-off-by: Pekka Paalanen > --- > doc/man/wl_display_connect.xml| 5 +++-- > doc/publican/sources/Protocol.xml | 8 > src/wayland-client.c | 10 -- > 3 files changed, 11 insertions(+), 12 deletions(-) Pushed: c0636dd..c7dbaa1 master -> master Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Weston test suite
On Sat, 22 Aug 2015 00:00:58 -0700 Bryce Harrington wrote: > On Fri, Aug 21, 2015 at 10:35:34AM +0300, Pekka Paalanen wrote: > > On Thu, 20 Aug 2015 11:05:39 -0700 > > Bryce Harrington wrote: > > > > > (I wish we had some tests with coverage of this chunk of code, so I could > > > give my usual plug for adding test cases; if we did, it'd probably > > > pretty easy to add a couple test cases here and give us a bit extra > > > confidence.) > > > > It's a bit tough in this case, I'm not sure if we can affect what > > outputs the kernel exposes, so it'd be tied to the test machine. > > No, the way you'd do it is to construct a "mock kernel", and then > whereever the functionality expects data from the kernel (or is making > kernel calls), you abstract that so you can slip your mock in instead. > Sort of the same idea as how we replaced the graphics card / monitor > with synthetic ones in the headless testing. > > I know it probably sounds like a pain in the ass (and it is), but if > you're serious about wanting stronger automated testing of Weston, then > that's the sort of stuff that needs done. And it's certainly > understandable to want to put off spending time writing tests, but it's > the same thing with documentation and look how horribly undocumented > Wayland is - unless you document and write tests as you go, it ain't > gonna get done. Hi, it's actually good to bring this up right now. We have the old test suite which is painful to work with, and we have the new test suite which is seriously lacking to become on par even with the old suite in terms of helpers. Jon, what are your plans in continuing with the test suite? I haven't seen a new patch series in quite a while, and I don't see any pending in Patchwork either. Thanks, pq pgpEkpyOaHrJF.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wl_surface.attach with NULL wl_buffer behaviour
On Fri, 21 Aug 2015 19:04:11 -0500
Prabhu S wrote:
> Below is the case where I'm getting stuck with the actual test case.
> Wondering why there is no callback wl_callb...@25.done or
> wl_buffer@29.release
> The EGL implementation depends on these callback/buffer release.
You will not get wl_callb...@25.done, because the NULL wl_buffer has
overwritten the other wl_buffer, leaving the wl_surface without any
content, which makes it disappear from screen. Frame callbacks are not
intended to be posted for non-visible wl_surfaces.
You should get wl_buffer@29.release though. I bet you actually do get
it, but something else is stopping the incoming Wayland events from
being dispatched. See:
http://lists.freedesktop.org/archives/wayland-devel/2014-April/014121.html
and "protocol dumpers" on:
http://wayland.freedesktop.org/extras.html
My wild guess would be that something is blocking, waiting on the frame
callback, likely EGL. It's not really EGL's bug but the application's
(or Qt).
> Also noticed if the valid buffer is attached immediately after null buffer,
> everything is fine, so most of the time it is unnoticed. If the frame is
Hmm, no, things should not be fine in that case. Well, it depends on
what role the wl_surface you are committing on has, but the very least
it may cause flicker.
You definetely want to get rid of that null attach. You do not want to
just ignore it.
> complex, egl will attach after null frame.
>
It sounds like your application is committing to the wl_surface behind
Qt's back somehow, and it only works occasionally by luck.
> I will keep debug if any other race conditions in my implementation.
>
> [3741557.293] -> wl_surface@20.frame(new id wl_callback@25)
> [3741557.476] -> wl_surface@20.attach(wl_buffer@29, 0, 0)
> [3741557.676] -> wl_surface@20.damage(0, 0, 800, 480)
> [3741557.906] -> wl_surface@20.commit() <=EGL
> [3741558.500] -> wl_surface@20.attach(nil, 0, 0) <=QTWayland
> [3741558.604] -> wl_surface@20.commit() <=QTWayland
> stuck
>
>
> On Fri, Aug 21, 2015 at 12:16 PM, Jasper St. Pierre
> wrote:
...
> > However crazy it is, the logic sort of makes sense -- the "frame"
> > event is guaranteed to be called once a frame when the surface content
> > is painted and shown on the screen. When there's no surface content,
> > it isn't painted, so the frame event isn't called.
> >
> > I'm not sure what you mean about a buffer release event -- you never
> > attached a buffer to begin with, so I can't imagine how you'll get an
> > event on it.
> >
> > On Fri, Aug 21, 2015 at 10:03 AM, Prabhu S wrote:
> > > Hi,
> > > Based on the wayland protocol specification for wl_surface::attach
> > >>>If wl_surface.attach is sent with a NULL wl_buffer, the following
> > >>> wl_surface.commit will remove the surface content.
> > >
> > > Wondering if wl_surface_attach called with wl_buffer=NULL, will there be
> > any
> > > wl_buffer release event or frame callbacks?
> > >
> > > Modified the redraw in simple-shm.c as below and not receiving any
> > callback
> > > or buffer release. It just got stuck.
> > > The same thing is being done in qtwayland to hide the surface and it is
> > > getting stuck. Some help to check this case would be helpful.
> > >
> > > static int odd = 1;
> > > if(odd == 1){
> > > wl_surface_attach(window->surface, buffer->buffer, 0, 0);
> > > wl_surface_damage(window->surface,
> > > 20, 20, window->width - 40, window->height -
> > 40);
> > > odd = 0;
> > > }
> > > else{
> > > wl_surface_attach(window->surface, 0, 0, 0);
> > > wl_surface_damage(window->surface,
> > > 0, 0, 0, 0);
> > > odd=1;
> > > }
> > >
> > >
> > >
> > > [823379.816] -> wl_compositor@4.create_surface(new id wl_surface@3)
> > > [823379.949] -> xdg_shell@6.get_xdg_surface(new id xdg_surface@7,
> > > wl_surface@3)
> > > [823380.120] -> xdg_surface@7.set_title("simple-shm")
> > > [823380.244] -> wl_surface@3.damage(0, 0, 250, 250)
> > > [823381.333] -> wl_shm@5.create_pool(new id wl_shm_pool@8, fd 5,
> > 25)
> > > [823381.561] -> wl_shm_pool@8.create_buffer(new id wl_buffer@9, 0, 250,
> > > 250, 1000, 1)
> > > [823381.870] -> wl_shm_pool@8.destroy()
> > > [823384.880] -> wl_surface@3.attach(wl_buffer@9, 0, 0)
> > > [823385.095] -> wl_surface@3.damage(20, 20, 210, 210)
> > > [823385.317] -> wl_surface@3.frame(new id wl_callback@10)
> > > [823385.443] -> wl_surface@3.commit()
> > > [823388.852] wl_display@1.delete_id(8)
> > > [823388.979] xdg_surface@7.configure(0, 0, array, 4)
> > > [823389.238] -> xdg_surface@7.ack_configure(4)
> > > [823401.773] wl_display@1.delete_id(10)
> > > [823401.908] wl_buffer@9.release()
This is the buffer release you expected. Note, that release can come
before the next buffer is attached, like here. This is typical for a
compositor using GL while the client is using software rendering
(wl_shm). Things can differ if the client is us
Re: wl_surface.attach with NULL wl_buffer behaviour
On Fri, 21 Aug 2015 10:16:09 -0700 "Jasper St. Pierre" wrote: > We need to fix that documentation, then, along with fixing Weston. > mutter will give you an error with this event stream, since attaching > a NULL buffer for an xdg_surface is invalid. This applies only to xdg_surface, and perhaps other roles that explicitly define it to be an error. I believe we want to keep this core protocol definition as it is already carved in stone. New extensions can make their own rules, but whether they should is a whole another matter. Thanks, pq pgp3fxTrjZuQ9.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] build: Require newer version of libdrm
On Fri, 21 Aug 2015 23:24:54 -0700 Bryce Harrington wrote: > On Fri, Aug 21, 2015 at 11:06:02PM -0500, Derek Foreman wrote: > > commit 89c49b3060a115e846ba1e7fbef94d14894244f2 changed the way we name > > outputs, but it also added the new output names VIRTUAL and DSI. > > > > These aren't available until libdrm 2.4.59 Hi, sorry I forgot to check when those appeared. > Ubuntu 14.04 appears to have 2.4.60. Presumably other distros of that > vintige will have similar. So this looks like a reasonable dependency > bump to me. > > > Signed-off-by: Derek Foreman > > Reviewed-by: Bryce Harrington Alright. It would be very easy to just #ifdef these in case we wanted to keep the libdrm requirement the same. I pushed your patch, and we can fix it the other way if someone complains. (It's a 3 year bump, so I'm not surprised if I need to fix it the other way.) decc965..faee330 master -> master Thanks, pq > > --- > > configure.ac | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/configure.ac b/configure.ac > > index 425f071..d70777d 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -171,7 +171,7 @@ AC_ARG_ENABLE(drm-compositor, [ > > --enable-drm-compositor],, > > 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, [libudev >= 136 libdrm >= 2.4.59 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])]) > > -- > > 2.4.6 pgpVOf7jhC6E_.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v2] clients: Require EGL_MIN_SWAP_INTERVAL to be 0 for subsurfaces
On Fri, 21 Aug 2015 22:32:40 +0800
Jonas Ådahl wrote:
> On Fri, Aug 21, 2015 at 04:05:34PM +0300, Pekka Paalanen wrote:
> > On Tue, 27 Jan 2015 10:47:29 +0800
> > Jonas Ådahl wrote:
> >
> > > Warn and fail when assert to create sub surfaces when swap interval 0 is
> > > not supported by the EGL platform.
> > >
> > > Programs wanting to add subsurfaces need to check whether it is
> > > subsurfaces are supported by the display with the new
> > > display_is_subsurfaces_supported() function.
> > >
> > > Signed-off-by: Jonas Ådahl
> > > ---
> > >
> > > Changed since v1:
> > >
> > > Coding style fix.
> > >
> > > Require clients to check whether subsurfaces is supported or not prior to
> > > adding them.
> > >
> > >
> > > clients/nested.c | 6 ++
> > > clients/subsurfaces.c | 6 ++
> > > clients/window.c | 30 ++
> > > clients/window.h | 4
> > > 4 files changed, 46 insertions(+)
> > > +{
> > > + GLint min_swap_interval;
> > > +
> > > + if (!display_has_subcompositor(display)) {
> > > + return false;
> > > + }
> > > +
> > > + if (!eglGetConfigAttrib(display->dpy,
> > > + display->argb_config,
> > > + EGL_MIN_SWAP_INTERVAL,
> > > + &min_swap_interval)) {
> > > + fprintf(stderr, "failed to retrieve EGL_MIN_SWAP_INTERVAL\n");
> > > + return false;
> > > + }
> > > +
> > > + if (min_swap_interval > 0) {
> > > + fprintf(stderr, "warning: EGLSwapInterval(0) not supported\n");
> > > + return false;
> > > + }
> > > +
> > > + return true;
> > > +}
> > > +
> > > cairo_device_t *
> > > display_get_cairo_device(struct display *display)
> > > {
> > > diff --git a/clients/window.h b/clients/window.h
> > > index 5247f19..b47e0b2 100644
> > > --- a/clients/window.h
> > > +++ b/clients/window.h
> > > @@ -28,6 +28,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include "../shared/config-parser.h"
> > > #include "../shared/zalloc.h"
> > >
> > > @@ -84,6 +85,9 @@ display_get_display(struct display *display);
> > > int
> > > display_has_subcompositor(struct display *display);
> > >
> > > +bool
> > > +display_is_subsurfaces_supported(struct display *display);
> > > +
> > > cairo_device_t *
> > > display_get_cairo_device(struct display *display);
> > >
> >
> > clients/subsurfaces.c already has egl_make_swapbuffers_nonblock(), and
> > I'm not sure nested.c even needs this. Nested.c does not attempt to set
> > zero swap interval either.
> >
> > Therefore I don't think this patch really adds anything worthwhile.
>
> Right. The purpose was to not knowingly let the subsurface demo dead
> lock. Now it will warn it might dead lock, and then dead lock. The point
> was to make it clear that one cannot use an EGL surface as a subsurface
> reliably if eglSwapInterval(0) is not supported. But since it's a demo
> client, I guess it doesn't really matter if we dead lock, at least when
> we warn about it first.
Yeah. We'd need even more code in toytoolkit to ensure that the app
actually did set swap interval to zero, or set it in the toolkit. I
think it would be going too far in pretending that toytoolkit is
actually a robust toolkit.
Thanks,
pq
pgpXwLbbECXIe.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
