Re: [PATCH wayland] server: remove redundant include
On 27/11/15 08:39 AM, Marek Chalupa wrote: > we don't use ffi in wayland-server.c > > Signed-off-by: Marek Chalupa Reviewed-by: Derek Foreman and pushed. > --- > src/wayland-server.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/src/wayland-server.c b/src/wayland-server.c > index bac98bf..bee9a70 100644 > --- a/src/wayland-server.c > +++ b/src/wayland-server.c > @@ -42,7 +42,6 @@ > #include > #include > #include > -#include > > #include "wayland-private.h" > #include "wayland-server.h" > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 11/11] simple-damage: Add --use-buffer-damage flag
On 27/11/15 07:47 AM, Pekka Paalanen wrote:
> On Wed, 18 Nov 2015 16:32:34 -0600
> Derek Foreman wrote:
>
>> Add a new flag for testing damage in buffer co-ordinates
>>
>> Signed-off-by: Derek Foreman
>> ---
>> clients/simple-damage.c | 62
>> +
>> 1 file changed, 47 insertions(+), 15 deletions(-)
>>
>
> Hi Derek,
>
> even without your series, running simple-damage --use-viewport
> --scale=2 will leave trails. It's not a damage issue, because
> compositor repaints do not clear it. It seems to be a rendering issue
> in the app. Using viewport with any scale > 1 will trigger that.
Yes, I was seeing this too. Doesn't happen with the pixman renderer.
Figuring it out is on my TODO list somewhere, right next to sorting out
the damage issues when zoomed and when changing transforms between
commits. :)
If I mess up the gl renderer to do a full texture upload with ever
damage commit the problem goes away.
Checking the damage co-ordinates in gl_renderer_flush_damage(),
sometimes thin areas are getting shrunk to 0 (when they look like they
should be getting expanded by the transform)
I guess the thing damage regions come from the two (erase, replace)
damage regions being bashed together and overlapping when the ball is
moving slowly...
weston_surface_to_buffer_rect() looks like it could be part of the
problem, since it looks like it does the viewport stuff first, then
truncates to integer, then transforms the resulting rect. Could be
losing thing rectangles in the middle?
Appears to not happen with my transforms branch that replaced all sorts
of this stuff with matrix mults with no conversion to integer in
between. Likely because it doesn't have to round off stuff to ints
between steps?
I think that's as far as I'm going to go in debugging this one.
> Anyway, I didn't see this patch changing any behaviour that I tried.
>
>> diff --git a/clients/simple-damage.c b/clients/simple-damage.c
>> index 0551b9d..8929071 100644
>> --- a/clients/simple-damage.c
>> +++ b/clients/simple-damage.c
>> @@ -64,6 +64,7 @@ struct buffer {
>> enum window_flags {
>> WINDOW_FLAG_USE_VIEWPORT = 0x1,
>> WINDOW_FLAG_ROTATING_TRANSFORM = 0x2,
>> +WINDOW_FLAG_USE_DAMAGE_BUFFER = 0x4,
>> };
>>
>> struct window {
>> @@ -261,6 +262,14 @@ create_window(struct display *display, int width, int
>> height,
>> exit(1);
>> }
>>
>> +if (display->compositor_version < 4 &&
>> +(flags & WINDOW_FLAG_USE_DAMAGE_BUFFER)) {
>> +fprintf(stderr, "wl_surface.damage_buffer unsupported in "
>> +"wl_surface version %d\n",
>> +display->compositor_version);
>> +exit(1);
>> +}
>> +
>> window = calloc(1, sizeof *window);
>> if (!window)
>> return NULL;
>> @@ -303,8 +312,12 @@ create_window(struct display *display, int width, int
>> height,
>> }
>>
>> /* Initialise damage to full surface, so the padding gets painted */
>> -wl_surface_damage(window->surface, 0, 0, INT32_MAX, INT32_MAX);
>> -
>> +if (window->flags & WINDOW_FLAG_USE_DAMAGE_BUFFER) {
>> +wl_surface_damage_buffer(window->surface, 0, 0,
>> + INT32_MAX, INT32_MAX);
>> +} else {
>> +wl_surface_damage(window->surface, 0, 0, INT32_MAX, INT32_MAX);
>> +}
>> return window;
>> }
>>
>> @@ -567,12 +580,20 @@ redraw(void *data, struct wl_callback *callback,
>> uint32_t time)
>>bwidth - 2 * bborder, bheight - 2 * bborder, 0x8000);
>>
>> /* Damage where the ball was */
>> -wl_surface_damage(window->surface,
>> - window->ball.x - window->ball.radius,
>> - window->ball.y - window->ball.radius,
>> - window->ball.radius * 2 + 1,
>> - window->ball.radius * 2 + 1);
>> -
>> +if (window->flags & WINDOW_FLAG_USE_DAMAGE_BUFFER) {
>> +window_get_transformed_ball(window, &bx, &by);
>> +wl_surface_damage_buffer(window->surface,
>> + bx - bradius + off_x,
>> + by - bradius + off_y,
>> + bradius * 2 + 1,
>> + bradius * 2 + 1);
>
> Should the +1 be buffer-transformed too?
>
> The loop in paint_circle() goes from x-r to x+r inclusive, so was the
> +1 to account for the center pixel, or is it just a rounding?
>
> Hmm, but these are buffer coordinates, so +1 is correct here. For
> surface coordinates it might be too much, but won't hurt. It's probably
> fine afterall.
It is possible that it's 1 too far. It was present in the --debug print
already, and I copied that without thinking about it too much.
If paint_circle() colored every pixel it iterated over, the +1 would
make sense due to the center pixel... I'm not 100% certain
paint_circle() can
Re: [PATCH wayland v4] protocol: Add wl_surface.damage_buffer
On Nov 27, 2015 1:35 AM, "Pekka Paalanen" wrote: > > On Fri, 27 Nov 2015 16:47:19 +0800 > Jonas Ådahl wrote: > > > On Thu, Nov 26, 2015 at 03:44:12PM -0600, Derek Foreman wrote: > > > wl_surface.damage uses surface local co-ordinates. > > > > > > Buffer scale and buffer transforms came along, and EGL surfaces > > > have no understanding of them. > > > > > > Theoretically, clients pass damage rectangles - in Y-inverted surface > > > co-ordinates) to EGLSwapBuffersWithDamage, and the EGL implementation > > > passed them on to wayland. However, for this to work the EGL > > > implementation must be able to flip those rectangles into the space > > > the compositor is expecting, but it's unable to do so because it > > > doesn't know the height of the transformed buffer. > > > > > > So, currently, EGLSwapBuffersWithDamage is unusable and EGLSwapBuffers > > > has to pass (0,0) - (INT32_MAX, INT32_MAX) damage to function. > > > > > > wl_surface.damage_buffer allows damage to be registered on a surface > > > in buffer co-ordinates, avoiding this problem. > > > > > > Credit where it's due, these ideas are not entirely my own: > > > Over a year ago the idea of changing damage co-ordinates to buffer > > > co-ordinates was suggested (by Jason Ekstrand), and it was at least > > > partially rejected and abandoned. At the time it was also suggested > > > (by Pekka Paalanen) that adding a new wl_surface.damage_buffer request > > > was another option. > > > > > > This will eventually resolve: > > > https://bugs.freedesktop.org/show_bug.cgi?id=78190 > > > by making the problem irrelevant. > > > > > > Signed-off-by: Derek Foreman > > > > Reviewed-by: Jonas Ådahl , with a couple of comments > > below. > > Reviewed-by: Pekka Paalanen > > ... > > > > --- > > > > > > Changes from v3: > > > replaced the last paragraph with Pekka's version > > > (with one tiny grammar change) > > > > > > protocol/wayland.xml | 49 +++-- > > > 1 file changed, 47 insertions(+), 2 deletions(-) > > > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > > index f9e6d76..4e97bb9 100644 > > > --- a/protocol/wayland.xml > > > +++ b/protocol/wayland.xml > > > @@ -176,7 +176,7 @@ > > > > > > > > > > > > - > > > + > > > > > >A compositor. This object is a singleton global. The > > >compositor is in charge of combining the contents of multiple > > > @@ -986,7 +986,7 @@ > > > > > > > > > > > > - > > > + > > > > > >A surface is a rectangular area that is displayed on the screen. > > >It has a location, size and pixel contents. > > > @@ -1109,6 +1109,10 @@ > > > wl_surface.commit assigns pending damage as the current damage, > > > and clears pending damage. The server will clear the current > > > damage as it repaints the surface. > > > + > > > + Alternatively, damage can be posted with wl_surface.damage_buffer > > > + which uses buffer co-ordinates instead of surface co-ordinates, > > > + and is probably the preferred and intuitive way of doing this. > > > > > > > > > > > > @@ -1325,6 +1329,47 @@ > > > > > > > > > > > > + > > > + > > > > Bikeshed mode enabled: missing empty line between "Version N additions" > > and actual additions. > > > > > + > > > + > > > + This request is used to describe the regions where the pending > > > + buffer is different from the current surface contents, and where > > > + the surface therefore needs to be repainted. The compositor > > > + ignores the parts of the damage that fall outside of the surface. > > > + > > > + Damage is double-buffered state, see wl_surface.commit. > > > + > > > + The damage rectangle is specified in buffer coordinates. > > > + > > > + The initial value for pending damage is empty: no damage. > > > + wl_surface.damage_buffer adds pending damage: the new pending > > > + damage is the union of old pending damage and the given rectangle. > > > + > > > + wl_surface.commit assigns pending damage as the current damage, > > > + and clears pending damage. The server will clear the current > > > + damage as it repaints the surface. > > > + > > > + This request differs from wl_surface.damage in only one way - it > > > + takes damage in buffer co-ordinates instead of surface local > > > + co-ordinates. While this generally is more intuitive than surface > > > + co-ordinates, it is especially desirable when using wp_viewport > > > + or when a drawing library (like EGL) is unaware of buffer scale > > > + and buffer transform. > > > + > > > + Since it is impossible to convert between buffer and surface > > > + co-ordinates until all the possible parameters affecting the > > > + surface size and the buffer-surface mapping are known at > > > + wl_surface.commit time, damage from wl_surface.damage and > > > + wl_surface.damage_buffer must be accumulated separately in a
Re: [PATCH v1] rephrasing the index.html to match the current shape of the project
Hi Found a few typos that I point out below. On Fri, Nov 27, 2015 at 03:35:11PM +0100, Benoit Gschwind wrote: > I added bryce comments, my comments and my favorite capitalization. > > Best regards > > --- > index.html | 39 --- > 1 file changed, 24 insertions(+), 15 deletions(-) > > diff --git a/index.html b/index.html > index a9ebcaa..0788cef 100644 > --- a/index.html > +++ b/index.html > @@ -12,21 +12,30 @@ > > Wayland > > -Wayland is intended as a simpler replacement for X, easier to develop > -and maintain. GNOME and KDE are expected to be ported to it. > - > -Wayland is a protocol for a compositor to talk to its clients as > -well as a C library implementation of that protocol. The compositor > -can be a standalone display server running on Linux kernel modesetting > -and evdev input devices, an X application, or a wayland client itself. > -The clients can be traditional applications, X servers (rootless or > -fullscreen) or other display servers. > - > -Part of the Wayland project is also the Weston reference > -implementation of a Wayland compositor. Weston can run as an X client > -or under Linux KMS and ships with a few demo clients. The Weston > -compositor is a minimal and fast compositor and is suitable for many > -embedded and mobile use cases. > +Wayland intends to replace the X11 protocol. The aim is to be easier > +to use, improve on the X11 protocol, and perform better. GNOME and KDE > +are expected to implement this protocol in their own servers. The > +Wayland project produces 3 components: wayland, libwayland and > +weston. > + > +wayland is a protocol for sharing screens and input devices between > +concurent clients. It defines the way servers and clients talks to each s/talks/talk/ > +other. The server is reponsible for setting up screens and input > +devices, and for displaying the final images that the user sees on the > +screen. We term this server a 'compositor'. > + > +libwayland is a reference library that implements the Wayland > +protocol. This library is intended to help developers implement > +compositors and clients. This library is split into a client-side part > +and a server-side part. > + > +weston is a reference compositor that use libwayland to talk s/use/uses/ > +with its clients. It can run under Linux's Kernel Mode Setting (KMS) as a > +stand-alone compositor, or it can run as X client. In the later case, More common is "In the latter case", Cheers, Silvan > +weston creates a virtual screen that is drawn in an X window and > creates > +virtual input devices taken from the X server; this works similarly to > +Xnest or Xephyr. weston also includes a few proof-of-concept clients > +such as weston-flower, weston-gears, and weston-terminal. > > Information: > > -- > 2.4.10 > > ___ > 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] compositor-drm: fix hw cursor positioning
On 27/11/15 06:20 AM, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> Fix a regression introduced by be428b3825043cbcc676d2526fe6213bea7f676a
> which accidentally removed the global-to-output space conversion.
Sigh. Yup.
> Signed-off-by: Pekka Paalanen
> Cc: Derek Foreman
> Cc: Daniel Stone
Reviewed-by: Derek Foreman
Tested-by: Derek Foreman
> ---
> src/compositor-drm.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> Hi Derek,
>
> if you want to fix this with some matrix stuff instead, that would be
> cool. This fixes my use case at least.
I think what you've done is complete anyway - once rotations or scales
are involved we can't get here (as your comment explains). That's why I
didn't bother in the first place - seems I forgot about translations
though. Winning.
Actually, I guess it should be possible to match the display rotation
and scale with the cursor's buffer, so we can use hardware cursors even
on rotated or scaled displays. I'll probably play with that later, but
an immediate fix is appropriate, so:
Pushed.
Thanks for the quick fix!
Derek
(Who's trying to remember why he didn't follow through with his patch
series to randomize the position of the first display :)
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 6575847..4f9bbaf 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -1196,6 +1196,13 @@ drm_output_set_cursor(struct drm_output *output)
> }
>
> weston_view_to_global_float(ev, 0, 0, &x, &y);
> +
> + /* From global to output space, output transform is guaranteed to be
> + * NORMAL by drm_output_prepare_cursor_view().
> + */
> + x = (x - output->base.x) * output->base.current_scale;
> + y = (y - output->base.y) * output->base.current_scale;
> +
> if (output->cursor_plane.x != x || output->cursor_plane.y != y) {
> if (drmModeMoveCursor(b->drm.fd, output->crtc_id, x, y)) {
> weston_log("failed to move cursor: %m\n");
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] server: remove redundant include
we don't use ffi in wayland-server.c Signed-off-by: Marek Chalupa --- src/wayland-server.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/wayland-server.c b/src/wayland-server.c index bac98bf..bee9a70 100644 --- a/src/wayland-server.c +++ b/src/wayland-server.c @@ -42,7 +42,6 @@ #include #include #include -#include #include "wayland-private.h" #include "wayland-server.h" -- 2.5.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] configure.ac: add explicit enable/disable for lcms
This is useful for reproducable builds. Signed-off-by: Jussi Kukkonen --- This was originally sent by Tim Orling on May 2014. I've moved the AM_CONDITIONAL below the test as requested in Kristians review. He also said AM_CONDITIONAL needs to key off have_lcms but I believe that would break "--disable-lcms" when lcms2-dev is present so did not include that change: I think this version works for all cases. Have a nice weekend everyone, Jussi configure.ac | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 23b0790..bba8050 100644 --- a/configure.ac +++ b/configure.ac @@ -577,12 +577,24 @@ AC_ARG_ENABLE(demo-clients-install, enable_demo_clients_install=no) AM_CONDITIONAL(INSTALL_DEMO_CLIENTS, [test "x$enable_demo_clients_install" = "xyes"]) -PKG_CHECK_MODULES(LCMS, lcms2, - [have_lcms=yes], [have_lcms=no]) -if test "x$have_lcms" = xyes; then - AC_DEFINE(HAVE_LCMS, 1, [Have lcms support]) +AC_ARG_ENABLE(lcms, + AS_HELP_STRING([--disable-lcms], + [Disable lcms support]),, + enable_lcms=auto) +if test "x$enable_lcms" != "xno"; then +PKG_CHECK_MODULES(LCMS, + lcms2, + have_lcms=yes, + have_lcms=no) +if test "x$have_lcms" = "xno" -a "x$enable_lcms" = "xyes"; then + AC_MSG_ERROR([lcms support explicitly requested, but lcms couldn't be found]) +fi +if test "x$have_lcms" = "xyes"; then +enable_lcms=yes +AC_DEFINE(HAVE_LCMS, 1, [Have lcms support]) +fi fi -AM_CONDITIONAL(HAVE_LCMS, [test "x$have_lcms" = xyes]) +AM_CONDITIONAL(HAVE_LCMS, [test "x$enable_lcms" = xyes]) AC_PATH_PROG([wayland_scanner], [wayland-scanner]) if test x$wayland_scanner = x; then -- 2.6.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v1] rephrasing the index.html to match the current shape of the project
Hello, I added bryce comments, my comments and my favorite capitalization. Best regards --- index.html | 39 --- 1 file changed, 24 insertions(+), 15 deletions(-) diff --git a/index.html b/index.html index a9ebcaa..0788cef 100644 --- a/index.html +++ b/index.html @@ -12,21 +12,30 @@ Wayland -Wayland is intended as a simpler replacement for X, easier to develop -and maintain. GNOME and KDE are expected to be ported to it. - -Wayland is a protocol for a compositor to talk to its clients as -well as a C library implementation of that protocol. The compositor -can be a standalone display server running on Linux kernel modesetting -and evdev input devices, an X application, or a wayland client itself. -The clients can be traditional applications, X servers (rootless or -fullscreen) or other display servers. - -Part of the Wayland project is also the Weston reference -implementation of a Wayland compositor. Weston can run as an X client -or under Linux KMS and ships with a few demo clients. The Weston -compositor is a minimal and fast compositor and is suitable for many -embedded and mobile use cases. +Wayland intends to replace the X11 protocol. The aim is to be easier +to use, improve on the X11 protocol, and perform better. GNOME and KDE +are expected to implement this protocol in their own servers. The +Wayland project produces 3 components: wayland, libwayland and +weston. + +wayland is a protocol for sharing screens and input devices between +concurent clients. It defines the way servers and clients talks to each +other. The server is reponsible for setting up screens and input +devices, and for displaying the final images that the user sees on the +screen. We term this server a 'compositor'. + +libwayland is a reference library that implements the Wayland +protocol. This library is intended to help developers implement +compositors and clients. This library is split into a client-side part +and a server-side part. + +weston is a reference compositor that use libwayland to talk +with its clients. It can run under Linux's Kernel Mode Setting (KMS) as a +stand-alone compositor, or it can run as X client. In the later case, +weston creates a virtual screen that is drawn in an X window and creates +virtual input devices taken from the X server; this works similarly to +Xnest or Xephyr. weston also includes a few proof-of-concept clients +such as weston-flower, weston-gears, and weston-terminal. Information: -- 2.4.10 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 1/2] compositor, input: Don't use MIN() macro for new resource versions
On Thu, 26 Nov 2015 14:17:47 -0600
Derek Foreman wrote:
> libwayland-server protects us from invalid serial numbers by
> posting an error already.
>
> MIN() is for clients when selecting interface versions.
>
> Signed-off-by: Derek Foreman
> ---
> src/compositor.c | 8
> src/input.c | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/compositor.c b/src/compositor.c
> index 65abb72..3c86f67 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -3883,7 +3883,7 @@ bind_output(struct wl_client *client,
> struct wl_resource *resource;
>
> resource = wl_resource_create(client, &wl_output_interface,
> - MIN(version, 2), id);
> + version, id);
> if (resource == NULL) {
> wl_client_post_no_memory(client);
> return;
> @@ -4369,7 +4369,7 @@ bind_scaler(struct wl_client *client,
> struct wl_resource *resource;
>
> resource = wl_resource_create(client, &wl_scaler_interface,
> - MIN(version, 2), id);
> + version, id);
> if (resource == NULL) {
> wl_client_post_no_memory(client);
> return;
> @@ -,7 +,7 @@ bind_presentation(struct wl_client *client,
> struct wl_resource *resource;
>
> resource = wl_resource_create(client, &presentation_interface,
> - MIN(version, 1), id);
> + version, id);
> if (resource == NULL) {
> wl_client_post_no_memory(client);
> return;
> @@ -4463,7 +4463,7 @@ compositor_bind(struct wl_client *client,
> struct wl_resource *resource;
>
> resource = wl_resource_create(client, &wl_compositor_interface,
> - MIN(version, 3), id);
> + version, id);
> if (resource == NULL) {
> wl_client_post_no_memory(client);
> return;
> diff --git a/src/input.c b/src/input.c
> index 1cc2540..097c8e7 100644
> --- a/src/input.c
> +++ b/src/input.c
> @@ -2142,7 +2142,7 @@ bind_seat(struct wl_client *client, void *data,
> uint32_t version, uint32_t id)
> enum wl_seat_capability caps = 0;
>
> resource = wl_resource_create(client,
> - &wl_seat_interface, MIN(version, 4), id);
> + &wl_seat_interface, version, id);
> wl_list_insert(&seat->base_resource_list,
> wl_resource_get_link(resource));
> wl_resource_set_implementation(resource, &seat_interface, data,
> unbind_resource);
Oh wow, that was a lot of cases, some even my fault I think. :-)
Reviewed-by: Pekka Paalanen
Thanks,
pq
pgpF2JUGQNVXY.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 11/11] simple-damage: Add --use-buffer-damage flag
On Wed, 18 Nov 2015 16:32:34 -0600
Derek Foreman wrote:
> Add a new flag for testing damage in buffer co-ordinates
>
> Signed-off-by: Derek Foreman
> ---
> clients/simple-damage.c | 62
> +
> 1 file changed, 47 insertions(+), 15 deletions(-)
>
Hi Derek,
even without your series, running simple-damage --use-viewport
--scale=2 will leave trails. It's not a damage issue, because
compositor repaints do not clear it. It seems to be a rendering issue
in the app. Using viewport with any scale > 1 will trigger that.
Anyway, I didn't see this patch changing any behaviour that I tried.
> diff --git a/clients/simple-damage.c b/clients/simple-damage.c
> index 0551b9d..8929071 100644
> --- a/clients/simple-damage.c
> +++ b/clients/simple-damage.c
> @@ -64,6 +64,7 @@ struct buffer {
> enum window_flags {
> WINDOW_FLAG_USE_VIEWPORT = 0x1,
> WINDOW_FLAG_ROTATING_TRANSFORM = 0x2,
> + WINDOW_FLAG_USE_DAMAGE_BUFFER = 0x4,
> };
>
> struct window {
> @@ -261,6 +262,14 @@ create_window(struct display *display, int width, int
> height,
> exit(1);
> }
>
> + if (display->compositor_version < 4 &&
> + (flags & WINDOW_FLAG_USE_DAMAGE_BUFFER)) {
> + fprintf(stderr, "wl_surface.damage_buffer unsupported in "
> + "wl_surface version %d\n",
> + display->compositor_version);
> + exit(1);
> + }
> +
> window = calloc(1, sizeof *window);
> if (!window)
> return NULL;
> @@ -303,8 +312,12 @@ create_window(struct display *display, int width, int
> height,
> }
>
> /* Initialise damage to full surface, so the padding gets painted */
> - wl_surface_damage(window->surface, 0, 0, INT32_MAX, INT32_MAX);
> -
> + if (window->flags & WINDOW_FLAG_USE_DAMAGE_BUFFER) {
> + wl_surface_damage_buffer(window->surface, 0, 0,
> + INT32_MAX, INT32_MAX);
> + } else {
> + wl_surface_damage(window->surface, 0, 0, INT32_MAX, INT32_MAX);
> + }
> return window;
> }
>
> @@ -567,12 +580,20 @@ redraw(void *data, struct wl_callback *callback,
> uint32_t time)
> bwidth - 2 * bborder, bheight - 2 * bborder, 0x8000);
>
> /* Damage where the ball was */
> - wl_surface_damage(window->surface,
> - window->ball.x - window->ball.radius,
> - window->ball.y - window->ball.radius,
> - window->ball.radius * 2 + 1,
> - window->ball.radius * 2 + 1);
> -
> + if (window->flags & WINDOW_FLAG_USE_DAMAGE_BUFFER) {
> + window_get_transformed_ball(window, &bx, &by);
> + wl_surface_damage_buffer(window->surface,
> + bx - bradius + off_x,
> + by - bradius + off_y,
> + bradius * 2 + 1,
> + bradius * 2 + 1);
Should the +1 be buffer-transformed too?
The loop in paint_circle() goes from x-r to x+r inclusive, so was the
+1 to account for the center pixel, or is it just a rounding?
Hmm, but these are buffer coordinates, so +1 is correct here. For
surface coordinates it might be too much, but won't hurt. It's probably
fine afterall.
I'm a bit uneasy with all the float to int conversions. Feels like it
would be too easy to round in the wrong direction.
> + } else {
> + wl_surface_damage(window->surface,
> + window->ball.x - window->ball.radius,
> + window->ball.y - window->ball.radius,
> + window->ball.radius * 2 + 1,
> + window->ball.radius * 2 + 1);
> + }
> window_advance_game(window, time);
>
> window_get_transformed_ball(window, &bx, &by);
> @@ -595,12 +616,19 @@ redraw(void *data, struct wl_callback *callback,
> uint32_t time)
> }
>
> /* Damage where the ball is now */
> - wl_surface_damage(window->surface,
> - window->ball.x - window->ball.radius,
> - window->ball.y - window->ball.radius,
> - window->ball.radius * 2 + 1,
> - window->ball.radius * 2 + 1);
> -
> + if (window->flags & WINDOW_FLAG_USE_DAMAGE_BUFFER) {
> + wl_surface_damage_buffer(window->surface,
> + bx - bradius + off_x,
> + by - bradius + off_y,
> + bradius * 2 + 1,
> + bradius * 2 + 1);
> + } else {
> + wl_surface_damage(window->surface,
> + window->ball.x - window->ball.radius,
> + window->ball.y - window->ball.radius,
> +
Re: [PATCH weston 0/4] fix bugs and TODO to support multi screens
On Thu, 26 Nov 2015 14:06:13 +0200 Pekka Paalanen wrote: > On Wed, 25 Nov 2015 23:30:05 +0900 > Nobuhiko Tanibata wrote: > > > Hi, > > > > I am proposing 4 patches to fix potential bugs and TODOs to support > > multi screens. > > Hi, > > it's all R-b me already and IMO ready to land. Feel free to push, or I > can push on Friday I think, if no-one screams. Pushed: 7d967da..747c386 master -> master Thanks, pq pgpRWKSpfMxQv.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] compositor-drm: fix hw cursor positioning
From: Pekka Paalanen
Fix a regression introduced by be428b3825043cbcc676d2526fe6213bea7f676a
which accidentally removed the global-to-output space conversion.
Signed-off-by: Pekka Paalanen
Cc: Derek Foreman
Cc: Daniel Stone
---
src/compositor-drm.c | 7 +++
1 file changed, 7 insertions(+)
Hi Derek,
if you want to fix this with some matrix stuff instead, that would be
cool. This fixes my use case at least.
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 6575847..4f9bbaf 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1196,6 +1196,13 @@ drm_output_set_cursor(struct drm_output *output)
}
weston_view_to_global_float(ev, 0, 0, &x, &y);
+
+ /* From global to output space, output transform is guaranteed to be
+* NORMAL by drm_output_prepare_cursor_view().
+*/
+ x = (x - output->base.x) * output->base.current_scale;
+ y = (y - output->base.y) * output->base.current_scale;
+
if (output->cursor_plane.x != x || output->cursor_plane.y != y) {
if (drmModeMoveCursor(b->drm.fd, output->crtc_id, x, y)) {
weston_log("failed to move cursor: %m\n");
--
2.4.10
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] configure: don't control egl version
On Wed, 18 Nov 2015 13:33:19 +0200 Pekka Paalanen wrote: > On Wed, 18 Nov 2015 10:23:50 + > "Ucan, Emre (ADITG/SW1)" wrote: > > > The required version only corresponds to version of mesa implementation. > > This mesa version requirement causes configure errors, > > when weston is configured for a different egl implementation than mesa. > > Because the version of the egl drivers are not alligned > > to the mesa version. > > Yes, this is sad. When Mesa started providing a egl.pc file and others, > it encoded the Mesa version in them, not the EGL version. I've tried to > ask around about this and people mostly do not care. I think someone > even said that other implementations should just advertise Mesa version > numbers in their .pc files. > > Furthermore, Mesa does not install any .pc file that would be specific > to Mesa, which means that egl.pc et al. are the only way to impose > version requirements on Mesa at build time. > > We should also note, that .pc version requirements are build time > requirements, not necessarily runtime requirements. That's hard to > remember, and especially tricky with EGL and GL libs that have several > implementations. > > Often binaries are built against Mesa, but then deployed with a > proprietary EGL/GL stack. This is probably a major reason why people > don't care that egl.pc encodes Mesa version. If you hacked Weston to > use some proprietary APIs, this won't work. > > > Therefore, I deleted the version controlling for egl, > > so that weston can be configured for a different egl implementation. > > Because of all the above, I will not object to this patch, so: > Acked-by: Pekka Paalanen > Hi Emre, thanks for the poke. Indeed, it's been a while without any comment. Pushed: 062edf2..7d967da master -> master Thanks, pq pgp0eEyT2WmaR.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 10/11] simple-damage: Offset drawing co-ordinates not buffer start
On Wed, 18 Nov 2015 16:32:33 -0600 Derek Foreman wrote: > We've been setting up the viewport by moving the start pointer of the > draw buffer, but later when we want to post damage in buffer co-ordinates > we'll need to keep track of the x,y offsets anyway. > > Signed-off-by: Derek Foreman > --- > clients/simple-damage.c | 58 > + > 1 file changed, 34 insertions(+), 24 deletions(-) Hi, I read this through and checked that you do not change the behaviour, except for the debug print. I agree with the idea of not playing with the data pointer. Reviewed-by: Pekka Paalanen Thanks, pq pgpUhgSFHfVRZ.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 v4] protocol: Add wl_surface.damage_buffer
On Fri, 27 Nov 2015 16:47:19 +0800 Jonas Ådahl wrote: > On Thu, Nov 26, 2015 at 03:44:12PM -0600, Derek Foreman wrote: > > wl_surface.damage uses surface local co-ordinates. > > > > Buffer scale and buffer transforms came along, and EGL surfaces > > have no understanding of them. > > > > Theoretically, clients pass damage rectangles - in Y-inverted surface > > co-ordinates) to EGLSwapBuffersWithDamage, and the EGL implementation > > passed them on to wayland. However, for this to work the EGL > > implementation must be able to flip those rectangles into the space > > the compositor is expecting, but it's unable to do so because it > > doesn't know the height of the transformed buffer. > > > > So, currently, EGLSwapBuffersWithDamage is unusable and EGLSwapBuffers > > has to pass (0,0) - (INT32_MAX, INT32_MAX) damage to function. > > > > wl_surface.damage_buffer allows damage to be registered on a surface > > in buffer co-ordinates, avoiding this problem. > > > > Credit where it's due, these ideas are not entirely my own: > > Over a year ago the idea of changing damage co-ordinates to buffer > > co-ordinates was suggested (by Jason Ekstrand), and it was at least > > partially rejected and abandoned. At the time it was also suggested > > (by Pekka Paalanen) that adding a new wl_surface.damage_buffer request > > was another option. > > > > This will eventually resolve: > > https://bugs.freedesktop.org/show_bug.cgi?id=78190 > > by making the problem irrelevant. > > > > Signed-off-by: Derek Foreman > > Reviewed-by: Jonas Ådahl , with a couple of comments > below. Reviewed-by: Pekka Paalanen ... > > --- > > > > Changes from v3: > > replaced the last paragraph with Pekka's version > > (with one tiny grammar change) > > > > protocol/wayland.xml | 49 +++-- > > 1 file changed, 47 insertions(+), 2 deletions(-) > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index f9e6d76..4e97bb9 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -176,7 +176,7 @@ > > > > > > > > - > > + > > > >A compositor. This object is a singleton global. The > >compositor is in charge of combining the contents of multiple > > @@ -986,7 +986,7 @@ > > > > > > > > - > > + > > > >A surface is a rectangular area that is displayed on the screen. > >It has a location, size and pixel contents. > > @@ -1109,6 +1109,10 @@ > > wl_surface.commit assigns pending damage as the current damage, > > and clears pending damage. The server will clear the current > > damage as it repaints the surface. > > + > > + Alternatively, damage can be posted with wl_surface.damage_buffer > > + which uses buffer co-ordinates instead of surface co-ordinates, > > + and is probably the preferred and intuitive way of doing this. > > > > > > > > @@ -1325,6 +1329,47 @@ > > > > > > > > + > > + > > Bikeshed mode enabled: missing empty line between "Version N additions" > and actual additions. > > > + > > + > > + This request is used to describe the regions where the pending > > + buffer is different from the current surface contents, and where > > + the surface therefore needs to be repainted. The compositor > > + ignores the parts of the damage that fall outside of the surface. > > + > > + Damage is double-buffered state, see wl_surface.commit. > > + > > + The damage rectangle is specified in buffer coordinates. > > + > > + The initial value for pending damage is empty: no damage. > > + wl_surface.damage_buffer adds pending damage: the new pending > > + damage is the union of old pending damage and the given rectangle. > > + > > + wl_surface.commit assigns pending damage as the current damage, > > + and clears pending damage. The server will clear the current > > + damage as it repaints the surface. > > + > > + This request differs from wl_surface.damage in only one way - it > > + takes damage in buffer co-ordinates instead of surface local > > + co-ordinates. While this generally is more intuitive than surface > > + co-ordinates, it is especially desirable when using wp_viewport > > + or when a drawing library (like EGL) is unaware of buffer scale > > + and buffer transform. > > + > > + Since it is impossible to convert between buffer and surface > > + co-ordinates until all the possible parameters affecting the > > + surface size and the buffer-surface mapping are known at > > + wl_surface.commit time, damage from wl_surface.damage and > > + wl_surface.damage_buffer must be accumulated separately in a > > + compositor and combined during wl_surface.commit at the earliest. > > As Jason already pointed out, this looks out of place. With some > imagination, it might also not entirely true. A compositor may put > damage "together" in a single list, with "transform this w
Re: [PATCH wayland v4] protocol: Add wl_surface.damage_buffer
On Thu, Nov 26, 2015 at 03:44:12PM -0600, Derek Foreman wrote: > wl_surface.damage uses surface local co-ordinates. > > Buffer scale and buffer transforms came along, and EGL surfaces > have no understanding of them. > > Theoretically, clients pass damage rectangles - in Y-inverted surface > co-ordinates) to EGLSwapBuffersWithDamage, and the EGL implementation > passed them on to wayland. However, for this to work the EGL > implementation must be able to flip those rectangles into the space > the compositor is expecting, but it's unable to do so because it > doesn't know the height of the transformed buffer. > > So, currently, EGLSwapBuffersWithDamage is unusable and EGLSwapBuffers > has to pass (0,0) - (INT32_MAX, INT32_MAX) damage to function. > > wl_surface.damage_buffer allows damage to be registered on a surface > in buffer co-ordinates, avoiding this problem. > > Credit where it's due, these ideas are not entirely my own: > Over a year ago the idea of changing damage co-ordinates to buffer > co-ordinates was suggested (by Jason Ekstrand), and it was at least > partially rejected and abandoned. At the time it was also suggested > (by Pekka Paalanen) that adding a new wl_surface.damage_buffer request > was another option. > > This will eventually resolve: > https://bugs.freedesktop.org/show_bug.cgi?id=78190 > by making the problem irrelevant. > > Signed-off-by: Derek Foreman Reviewed-by: Jonas Ådahl , with a couple of comments below. > --- > > Changes from v3: > replaced the last paragraph with Pekka's version > (with one tiny grammar change) > > protocol/wayland.xml | 49 +++-- > 1 file changed, 47 insertions(+), 2 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index f9e6d76..4e97bb9 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -176,7 +176,7 @@ > > > > - > + > >A compositor. This object is a singleton global. The >compositor is in charge of combining the contents of multiple > @@ -986,7 +986,7 @@ > > > > - > + > >A surface is a rectangular area that is displayed on the screen. >It has a location, size and pixel contents. > @@ -1109,6 +1109,10 @@ > wl_surface.commit assigns pending damage as the current damage, > and clears pending damage. The server will clear the current > damage as it repaints the surface. > + > + Alternatively, damage can be posted with wl_surface.damage_buffer > + which uses buffer co-ordinates instead of surface co-ordinates, > + and is probably the preferred and intuitive way of doing this. > > > > @@ -1325,6 +1329,47 @@ > > > > + > + Bikeshed mode enabled: missing empty line between "Version N additions" and actual additions. > + > + > + This request is used to describe the regions where the pending > + buffer is different from the current surface contents, and where > + the surface therefore needs to be repainted. The compositor > + ignores the parts of the damage that fall outside of the surface. > + > + Damage is double-buffered state, see wl_surface.commit. > + > + The damage rectangle is specified in buffer coordinates. > + > + The initial value for pending damage is empty: no damage. > + wl_surface.damage_buffer adds pending damage: the new pending > + damage is the union of old pending damage and the given rectangle. > + > + wl_surface.commit assigns pending damage as the current damage, > + and clears pending damage. The server will clear the current > + damage as it repaints the surface. > + > + This request differs from wl_surface.damage in only one way - it > + takes damage in buffer co-ordinates instead of surface local > + co-ordinates. While this generally is more intuitive than surface > + co-ordinates, it is especially desirable when using wp_viewport > + or when a drawing library (like EGL) is unaware of buffer scale > + and buffer transform. > + > + Since it is impossible to convert between buffer and surface > + co-ordinates until all the possible parameters affecting the > + surface size and the buffer-surface mapping are known at > + wl_surface.commit time, damage from wl_surface.damage and > + wl_surface.damage_buffer must be accumulated separately in a > + compositor and combined during wl_surface.commit at the earliest. As Jason already pointed out, this looks out of place. With some imagination, it might also not entirely true. A compositor may put damage "together" in a single list, with "transform this way" flags next to regions in different coordinate spaces, and then later process and combine at commit when all information is available. Sure, it makes little sense to do things this way, but it wouldn't be wrong while still, depending on how interpreted, not really doing what th
Re: black surface in desktop shell fullscreen mode
On Thu, 26 Nov 2015 15:33:24 +0800 zou lan wrote: > Hi Pekka > > I have another question about the fullscreen NULL buffer display black > surface. Why the fullscreen App call hide(commit Null buffer), then start > another App, only the fullscreen App can show normally? Is the normal > screen App's layer below on the black surface? Like Giulio mentioned before, sounds like a Weston bug. The relevant window manager code is in desktop-shell/shell.c. I don't think I can explain how to fix it in any more detail without going in and fixing it myself. I rarely look into shell.c and that probably applies to most developers. The black surface should be torn down when the window gets unmapped. The entrypoint into shell.c for all window state changes is the weston_surface::configure vfunc. Thanks, pq > 2015-11-20 17:31 GMT+08:00 zou lan : > > > Hi pekka > > > > >Or are you asking for instructions on how to fix the alleged Weston > > >desktop-shell bug where the black surface is not removed when attaching > > >a NULL wl_buffer to the wl_surface? > > > > Actually I ask for instructions on this. Because I use "hide" to switch > > the apps. But I met some problems of the black screen if I just hide the > > surface. > > > > I want to implement the function like "background" or "home", just hide > > the UI. > > > > Thank you. > > > > Best Regards > > Nancy > > > > 2015-11-20 16:03 GMT+08:00 Pekka Paalanen : > > > >> On Fri, 20 Nov 2015 10:52:54 +0800 > >> zou lan wrote: > >> > >> > Hi Pekka > >> > > >> > How to not use the black surface behind the fullscreen surface? I want > >> to > >> > >> Hi Nancy, > >> > >> are you looking for disabling the black surface in a way that would > >> work on upstream Weston or be upstreamable, or something you hack just > >> for yourself? > >> > >> Or are you asking for instructions on how to fix the alleged Weston > >> desktop-shell bug where the black surface is not removed when attaching > >> a NULL wl_buffer to the wl_surface? > >> > >> > have a try for the special needs to switch the apps. I can't use the > >> > minimize because it can't restore to its original shape. > >> > >> Oh that's the real problem here. Obviously restoring to original size > >> and position after minimization should work, so I think that is the > >> primary issue to be solved. However, I'm not sure if it is possible > >> with wl_shell, but it should be possible with xdg_shell. > >> > >> You have to note, that both desktop shell protocols are still far from > >> being finished. Switching the active window from clients is still on > >> the drawing board, AFAIK. > >> > >> Hmm, or is the fundamental problem really that you want to reassign > >> which window is active and on top from the client? > >> > >> There is a continuum of possible solutions, ranging from > >> non-upstreamable quick hacks on one end to joining the work on > >> designing the family of desktop related protocol extensions on the > >> other end which can take at least months. > >> > >> I think we should go back to the original use case you are trying to > >> make work: > >> > >> App1 launches App2. App2 appears on top and active (by the current > >> policy implemented in Weston's desktop shell, which is subject to > >> change). Then App2 wants to put App1 on top and active again. Is this > >> right? > >> > >> Should App2 stay up but behind App1? Or should App2 be hidden or > >> minimized? > >> > >> Note that hiding and minimizing are two different things: minimizing > >> leaves a window handle in something like a task bar, while hiding does > >> not. (Hiding with wl_shell probably triggers a (mis?)feature in Weston > >> where it forgets the window position, IIRC.) > >> > >> And you want App2 to be able to come back later in the original > >> position and size, active and on top of App1? > >> > >> I'm afraid on short term, all workable solutions will be more or less > >> hacks, because the desktop shell protocol extensions just do not exist > >> yet for this sort of things. > >> > >> > >> Thanks, > >> pq > >> > >> > > > 2015-10-09 9:29 GMT+02:00 Pekka Paalanen : > >> > > > > On Fri, 9 Oct 2015 10:04:49 +0300 > >> > > > > Giulio Camuffo wrote: > >> > > > > > >> > > > >> You get a black surface because weston puts a black surface > >> behind the > >> > > > >> fullscreen one even if it has the right size, and it seems like > >> it > >> > > > >> doesn't remove the black surface when the client surface attachs > >> a > >> > > > >> NULL buffer. That's a weston bug, i'd say. > >> > > > > > >> > > > > Giulio's analysis sounds good to me. I think no-one has tried - or > >> > > > > reported - to hide a window using wl_shell that was also > >> fullscreen, so > >> > > > > probably we have never considered that case in the code. > >> > > > > > >> > > > > Very likely a Weston bug indeed, specifically in the case of > >> committing > >> > > > > a NULL wl_buffer when using wl_shell. Transparency was a red >
