Re: [RFC wayland] protocol: Add wl_surface.buffer_damage
On Nov 13, 2015 10:43 AM, "Derek Foreman" wrote: > > On 13/11/15 02:03 AM, Pekka Paalanen wrote: > > On Thu, 12 Nov 2015 13:48:10 -0600 > > Derek Foreman wrote: > > > >> On 12/11/15 01:27 PM, Jason Ekstrand wrote: > >>> Thanks for picking this up! Also, thanks for posting this on the bug, > >>> I would have missed it otherwise! > >> > >> Thanks to Pekka for prodding me to do so. :) > >> > >>> On Thu, Nov 12, 2015 at 11:16 AM, Derek Foreman < der...@osg.samsung.com> wrote: > On 09/11/15 09:06 AM, Pekka Paalanen wrote: > > On Fri, 6 Nov 2015 12:55:19 -0600 > > Derek Foreman wrote: > > > > > > >> +Mixing wl_surface.buffer_damage and wl_surface.damage requests > >> +on the same surface will result in undefined behaviour. > > > > Why undefined? The compositor will always transform between surface and > > buffer coordinate systems: surface to buffer for texture updates, and > > buffer to surface for repaint damage. > > > > I suppose you can avoid accumulating two different regions depending on > > the coordinate space until wl_surface.commit by saying only one > > coordinate space is guaranteed to work at a time. Is that reason > > enough, or the only reason? > > Just lazy. I don't want to care about it or have to test it. Saying > not to mix them within a commit is just fine too, I think. > > Realistically, I can't imagine anyone wanting to do this in the first > place, so I didn't see much point in spending any time verifying the two > requests worked well together. > > I suppose it'd be possible to slaughter clients trying to mix them - > would that be preferably to undefined? > >>> > >>> We could say that it's the union of the two but I kind of like "don't > >>> do this" better. > > > > Don't do this indeed, but should it be a fatal error, or just > > undefined? Or defined as whole-surface damage? :-) > > > > I have hard time making my mind. If it's not a fatal error, I am sure > > someone will do it even if by accident. When someone does it, I'd > > expect the undefined behaviour to be practically damaging the whole > > surface, so you wouldn't easily notice it. > > > > So... for the sake of forcing programs to be more correct, make it a > > fatal error? In which case we need a new error code in wl_surface. > > Interesting problem just occurred to me... I don't think just not > mixing damage/buffer_damage within a commit is good enough. > > What if a client commits faster than the screen refresh rate? Then > we're expected to accumulate the damage inside the compositor, right? > > So a client could use damage exclusively in one commit, damage_buffer > exclusively in another, and the compositor still has to mix the result... > > Is it too heavy handed to allow the first damage/damage_buffer to set > what must be used on the surface for its lifetime? I think it's better to just let the client damage however it wants and highly recommend they pick one and stick with it. It's perfectly well-defined to damage in both and trying to come up with a precise condition for a protocol error is, as you pointed out, rather difficult. The only sane condition I can think of is "don't use both in the same commit" but, as you pointed out, that doesn't actually help the compositor. Compositors that don't want to deal with it can just stomp to full damage as soon as things get complicated. --Jason ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] Add the tablet protocol
Hey, On Fri, Nov 6, 2015 at 5:24 AM, Peter Hutterer wrote: > Signed-off-by: Peter Hutterer > --- > This is the revamped version of the tablet protocol for graphics tablets > (e.g. Wacom tablets). Too many changes from the last version (a year ago or > so), so I won't detail them, best to look at it with fresh eyes. > > Makefile.am| 1 + > unstable/tablet/README | 4 + > unstable/tablet/tablet-unstable-v1.xml | 588 > + > 3 files changed, 593 insertions(+) > create mode 100644 unstable/tablet/README > create mode 100644 unstable/tablet/tablet-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 4bcab32..588cb2c 100644 > + > + > + Describes the type of tablet > + > + > + > + > + > + > + > + > + > + This event is sent in the initial burst of events before the > + wp_tablet.done event. > + > + > + I'm tbh wondering whether this is all that useful. I'm seeing the fixme in your 01/13 weston patch where this is missing a dependency on libwacom, and I've got a similar fixme in mutter. The protocol already exports vid/pid and node file, that seems enough to poke libwacom on the client side, and it's not like many clients need this to implement different behavior (the only potential user I see on my side is gnome-control-center). I think that's my only nitpick at this stage. Consider this: Reviewed-by: Carlos Garnacho And the weston series really, I could see nothing wrong with it, even helped me spot a couple of bugs in my mutter branch. Cheers, Carlos ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland] protocol: Add wl_surface.buffer_damage
On 13/11/15 02:03 AM, Pekka Paalanen wrote: > On Thu, 12 Nov 2015 13:48:10 -0600 > Derek Foreman wrote: > >> On 12/11/15 01:27 PM, Jason Ekstrand wrote: >>> Thanks for picking this up! Also, thanks for posting this on the bug, >>> I would have missed it otherwise! >> >> Thanks to Pekka for prodding me to do so. :) >> >>> On Thu, Nov 12, 2015 at 11:16 AM, Derek Foreman >>> wrote: On 09/11/15 09:06 AM, Pekka Paalanen wrote: > On Fri, 6 Nov 2015 12:55:19 -0600 > Derek Foreman wrote: > >> +Mixing wl_surface.buffer_damage and wl_surface.damage requests >> +on the same surface will result in undefined behaviour. > > Why undefined? The compositor will always transform between surface and > buffer coordinate systems: surface to buffer for texture updates, and > buffer to surface for repaint damage. > > I suppose you can avoid accumulating two different regions depending on > the coordinate space until wl_surface.commit by saying only one > coordinate space is guaranteed to work at a time. Is that reason > enough, or the only reason? Just lazy. I don't want to care about it or have to test it. Saying not to mix them within a commit is just fine too, I think. Realistically, I can't imagine anyone wanting to do this in the first place, so I didn't see much point in spending any time verifying the two requests worked well together. I suppose it'd be possible to slaughter clients trying to mix them - would that be preferably to undefined? >>> >>> We could say that it's the union of the two but I kind of like "don't >>> do this" better. > > Don't do this indeed, but should it be a fatal error, or just > undefined? Or defined as whole-surface damage? :-) > > I have hard time making my mind. If it's not a fatal error, I am sure > someone will do it even if by accident. When someone does it, I'd > expect the undefined behaviour to be practically damaging the whole > surface, so you wouldn't easily notice it. > > So... for the sake of forcing programs to be more correct, make it a > fatal error? In which case we need a new error code in wl_surface. Interesting problem just occurred to me... I don't think just not mixing damage/buffer_damage within a commit is good enough. What if a client commits faster than the screen refresh rate? Then we're expected to accumulate the damage inside the compositor, right? So a client could use damage exclusively in one commit, damage_buffer exclusively in another, and the compositor still has to mix the result... Is it too heavy handed to allow the first damage/damage_buffer to set what must be used on the surface for its lifetime? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland] Track protocol object versions inside wl_proxy.
On Fri, Nov 13, 2015 at 3:18 AM, Giulio Camuffo wrote:
> So do i understand correctly that if the app creating the
> wl_compositor was built against a libwayland without this patch the
> version returned in mesa by wl_proxy_get_version() for every proxy
> will be always 1?
Yes, see also the second e-mail link below. I proposed to make
wl_display version 0 so that libraries can detect whether the client
was built against old or new libwayland.
--Jason
> 2015-11-12 22:01 GMT+02:00 Derek Foreman :
>> From: Jason Ekstrand
>>
>> This provides a standardized mechanism for tracking protocol object
>> versions in client code. The wl_display object is created with version 1.
>> Every time an object is created from within wl_registry_bind, it gets the
>> bound version. Every other time an object is created, it simply inherits
>> it's version from the parent object that created it.
>>
>> ---
>> Sooo, seems to finally fix the EGLSwapBuffersWithDamage problem, we also
>> need this patch. However, it's not complete.
>>
>> I've rebased it and updated it. Here's the original posting:
>> http://lists.freedesktop.org/archives/wayland-devel/2014-April/014004.html
>>
>> Of special importance is:
>> http://lists.freedesktop.org/archives/wayland-devel/2014-April/014011.html
>>
>> And the proposed solution to the new backwards compatibility issue. If we
>> get a consensus on a way forward, I can pick this up and finish it off...
>>
>> src/scanner.c | 29
>> src/wayland-client-core.h | 14 ++
>> src/wayland-client.c | 112
>> +++---
>> 3 files changed, 140 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/scanner.c b/src/scanner.c
>> index 8ecdd56..850e72a 100644
>> --- a/src/scanner.c
>> +++ b/src/scanner.c
>> @@ -889,6 +889,14 @@ emit_stubs(struct wl_list *message_list, struct
>> interface *interface)
>>interface->name, interface->name, interface->name,
>>interface->name);
>>
>> + printf("static inline uint32_t\n"
>> + "%s_get_version(struct %s *%s)\n"
>> + "{\n"
>> + "\treturn wl_proxy_get_version((struct wl_proxy *) %s);\n"
>> + "}\n\n",
>> + interface->name, interface->name, interface->name,
>> + interface->name);
>> +
>> has_destructor = 0;
>> has_destroy = 0;
>> wl_list_for_each(m, message_list, link) {
>> @@ -960,20 +968,25 @@ emit_stubs(struct wl_list *message_list, struct
>> interface *interface)
>>
>> printf(")\n"
>>"{\n");
>> - if (ret) {
>> + if (ret && ret->interface_name == NULL) {
>> printf("\tstruct wl_proxy *%s;\n\n"
>> - "\t%s = wl_proxy_marshal_constructor("
>> + "\t%s =
>> wl_proxy_marshal_constructor_versioned("
>>"(struct wl_proxy *) %s,\n"
>> - "\t\t\t %s_%s, ",
>> + "\t\t\t %s_%s, interface, version",
>>ret->name, ret->name,
>>interface->name,
>>interface->uppercase_name,
>>m->uppercase_name);
>> -
>> - if (ret->interface_name == NULL)
>> - printf("interface");
>> - else
>> - printf("&%s_interface", ret->interface_name);
>> + } else if (ret) {
>> + printf("\tstruct wl_proxy *%s;\n\n"
>> + "\t%s = wl_proxy_marshal_constructor("
>> + "(struct wl_proxy *) %s,\n"
>> + "\t\t\t %s_%s, &%s_interface",
>> + ret->name, ret->name,
>> + interface->name,
>> + interface->uppercase_name,
>> + m->uppercase_name,
>> + ret->interface_name);
>> } else {
>> printf("\twl_proxy_marshal((struct wl_proxy *) %s,\n"
>>"\t\t\t %s_%s",
>> diff --git a/src/wayland-client-core.h b/src/wayland-client-core.h
>> index 8b4b4b8..ed41773 100644
>> --- a/src/wayland-client-core.h
>> +++ b/src/wayland-client-core.h
>> @@ -138,10 +138,21 @@ wl_proxy_marshal_constructor(struct wl_proxy *proxy,
>> const struct wl_interface *interface,
>> ...);
>>
>> +struct wl_proxy *wl_proxy_marshal_constructor_versioned(struct wl_proxy
>> *proxy,
>> + uint32_t opcode,
>> + const struct
>> wl_interface *interface,
>> +
Re: [RFC wayland] protocol: Add wl_surface.buffer_damage
On 13/11/15 02:03 AM, Pekka Paalanen wrote: > On Thu, 12 Nov 2015 13:48:10 -0600 > Derek Foreman wrote: > >> On 12/11/15 01:27 PM, Jason Ekstrand wrote: >>> Thanks for picking this up! Also, thanks for posting this on the bug, >>> I would have missed it otherwise! >> >> Thanks to Pekka for prodding me to do so. :) >> >>> On Thu, Nov 12, 2015 at 11:16 AM, Derek Foreman >>> wrote: On 09/11/15 09:06 AM, Pekka Paalanen wrote: > On Fri, 6 Nov 2015 12:55:19 -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.buffer_damage 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.buffer_damage request >> was another option. >> > > Hi Derek, > > please mention https://bugs.freedesktop.org/show_bug.cgi?id=78190 in > this patch. Will do. >> Signed-off-by: Derek Foreman >> --- >> >> Necro-posting on: >> http://lists.freedesktop.org/archives/wayland-devel/2014-February/013440.html >> and >> http://lists.freedesktop.org/archives/wayland-devel/2014-February/013442.html >> >> This came up on IRC again the other day, and it's still an unsolved >> problem... >> I'm posting this as RFC to see if anyone's interested in it - I'll do an >> implementation if we can get an agreement on the protocol text. > > Thanks for picking this up! Since all the conflict seems to be around how aggressively we should encourage people to use this instead of the existing surface damage request, I'll write a weston implementation. >> protocol/wayland.xml | 44 ++-- >> 1 file changed, 42 insertions(+), 2 deletions(-) >> >> diff --git a/protocol/wayland.xml b/protocol/wayland.xml >> index 9c22d45..1cb2f66 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. >> @@ -1327,6 +1327,46 @@ >> >> >> > > I know Jasper suggested deprecating wl_surface.damage, but I see no > reason for that. wl_surface.damage is well-defined - it is only misused. > > We could add some wording to have both refer to each other as an > alternative way to post damage. Especially to wl_surface.damage should > mention buffer_damage as doing what you'd usually expect. Ok, that sounds viable. >> + >> + >> + > > The name "buffer_damage" is slightly unfortunate. See: > https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_swap_buffers_with_damage.txt > > What we are doing in Wayland is always "surface damage"[*], while that > EGL extension reserves "buffer damage" for a different purpose. I feel > it might be confusing. > > Could we come up with a another name for this request? > - wl_surface.damage_pixels > - wl_surface.damage_by_buffer > > eh... buffer_damage is fine if nothing else sticks. The specification > language below is clear anyway, IMO. I'll call it damage_pixels in the next revision. >>> >>> Either buffer_damage or damage_pixels is fine by me. I think I would >>> have a slight preference towards buffer_damage but meh. >> >> Me too, honestly. :) > > Haha, sorry for the bad suggestion. :-D > > My opposition to damage_pixels is: what if the buffer does not contain > pixels?
Re: [PATCH weston] Fix build error caused by missing header inclusion
On 13/11/15 07:34 AM, ahmet acar wrote: > Hi. This fix that: > > https://bugs.freedesktop.org/show_bug.cgi?id=92104 > This is a harmless solution to a disgusting problem with eglplatform.h Basically, if you have no X11 include files and you include eglplatform.h without -DMESA_EGL_NO_X11_HEADERS then eglplatform.h will try to #include X11/Xlib.h and X11/Xutil.h if you include wayland-egl.h first it will define WL_EGL_PLATFORM which shorts out a bunch of logic before it even gets to the EGL_NO_X11_HEADERS check. This patch is probably the least worst solution to the problem, so... pushed. Ahmet, I'll write a commit log and add the appropriate attribution for this patch, but in the future it'd make it easier to land your contributions if you set up git send-email. Thanks for sorting this out. Reviewed-by: Derek Foreman (and pushed...) > --- > shared/platform.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/shared/platform.h b/shared/platform.h > index 64e1fbf..cf4ecc0 100644 > --- a/shared/platform.h > +++ b/shared/platform.h > @@ -29,6 +29,7 @@ > #include > > #ifdef ENABLE_EGL > +#include > #include > #include > #endif > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] Fix build error caused by missing header inclusion
Hi. This fix that: https://bugs.freedesktop.org/show_bug.cgi?id=92104 --- shared/platform.h | 1 + 1 file changed, 1 insertion(+) diff --git a/shared/platform.h b/shared/platform.h index 64e1fbf..cf4ecc0 100644 --- a/shared/platform.h +++ b/shared/platform.h @@ -29,6 +29,7 @@ #include #ifdef ENABLE_EGL +#include #include #include #endif -- 2.5.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland] Track protocol object versions inside wl_proxy.
So do i understand correctly that if the app creating the
wl_compositor was built against a libwayland without this patch the
version returned in mesa by wl_proxy_get_version() for every proxy
will be always 1?
2015-11-12 22:01 GMT+02:00 Derek Foreman :
> From: Jason Ekstrand
>
> This provides a standardized mechanism for tracking protocol object
> versions in client code. The wl_display object is created with version 1.
> Every time an object is created from within wl_registry_bind, it gets the
> bound version. Every other time an object is created, it simply inherits
> it's version from the parent object that created it.
>
> ---
> Sooo, seems to finally fix the EGLSwapBuffersWithDamage problem, we also
> need this patch. However, it's not complete.
>
> I've rebased it and updated it. Here's the original posting:
> http://lists.freedesktop.org/archives/wayland-devel/2014-April/014004.html
>
> Of special importance is:
> http://lists.freedesktop.org/archives/wayland-devel/2014-April/014011.html
>
> And the proposed solution to the new backwards compatibility issue. If we
> get a consensus on a way forward, I can pick this up and finish it off...
>
> src/scanner.c | 29
> src/wayland-client-core.h | 14 ++
> src/wayland-client.c | 112
> +++---
> 3 files changed, 140 insertions(+), 15 deletions(-)
>
> diff --git a/src/scanner.c b/src/scanner.c
> index 8ecdd56..850e72a 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -889,6 +889,14 @@ emit_stubs(struct wl_list *message_list, struct
> interface *interface)
>interface->name, interface->name, interface->name,
>interface->name);
>
> + printf("static inline uint32_t\n"
> + "%s_get_version(struct %s *%s)\n"
> + "{\n"
> + "\treturn wl_proxy_get_version((struct wl_proxy *) %s);\n"
> + "}\n\n",
> + interface->name, interface->name, interface->name,
> + interface->name);
> +
> has_destructor = 0;
> has_destroy = 0;
> wl_list_for_each(m, message_list, link) {
> @@ -960,20 +968,25 @@ emit_stubs(struct wl_list *message_list, struct
> interface *interface)
>
> printf(")\n"
>"{\n");
> - if (ret) {
> + if (ret && ret->interface_name == NULL) {
> printf("\tstruct wl_proxy *%s;\n\n"
> - "\t%s = wl_proxy_marshal_constructor("
> + "\t%s =
> wl_proxy_marshal_constructor_versioned("
>"(struct wl_proxy *) %s,\n"
> - "\t\t\t %s_%s, ",
> + "\t\t\t %s_%s, interface, version",
>ret->name, ret->name,
>interface->name,
>interface->uppercase_name,
>m->uppercase_name);
> -
> - if (ret->interface_name == NULL)
> - printf("interface");
> - else
> - printf("&%s_interface", ret->interface_name);
> + } else if (ret) {
> + printf("\tstruct wl_proxy *%s;\n\n"
> + "\t%s = wl_proxy_marshal_constructor("
> + "(struct wl_proxy *) %s,\n"
> + "\t\t\t %s_%s, &%s_interface",
> + ret->name, ret->name,
> + interface->name,
> + interface->uppercase_name,
> + m->uppercase_name,
> + ret->interface_name);
> } else {
> printf("\twl_proxy_marshal((struct wl_proxy *) %s,\n"
>"\t\t\t %s_%s",
> diff --git a/src/wayland-client-core.h b/src/wayland-client-core.h
> index 8b4b4b8..ed41773 100644
> --- a/src/wayland-client-core.h
> +++ b/src/wayland-client-core.h
> @@ -138,10 +138,21 @@ wl_proxy_marshal_constructor(struct wl_proxy *proxy,
> const struct wl_interface *interface,
> ...);
>
> +struct wl_proxy *wl_proxy_marshal_constructor_versioned(struct wl_proxy
> *proxy,
> + uint32_t opcode,
> + const struct
> wl_interface *interface,
> + uint32_t version,
> + ...);
> struct wl_proxy *
> wl_proxy_marshal_array_constructor(struct wl_proxy *proxy,
>uint32_t opcode, union wl_argument *args,
>const struct wl_interface *interface);
> +struct wl_proxy *
>
signal 11 of weston-ivi-shell-user-interface on qemux86
Hi all. when I build/run weston on yocto for qemux86 device, I've got an error, and no screen. [08:02:07.897] launching '/usr/lib/weston/weston-ivi-shell-user-interface' [08:02:08.201] /usr/lib/weston/weston-ivi-shell-user-interface died on signal 11 it is caused everytime when I build yocto software on Ubuntu 12.04 64bit desktop for qemux86 device. (s/w for qemux86-64 has no such error) to resolve this, apply following patch. --- a/clients/ivi-shell-user-interface.c 2015-08-08 04:01:22.0 +0900 +++ b/clients/ivi-shell-user-interface.c 2015-11-13 19:26:38.844430385 +0900 @@ -21,6 +21,8 @@ * DEALINGS IN THE SOFTWARE. */ +#include "config.h" + #include #include #include please, include this patch on next release. thank you. __ Yong-iL Joh, Sr.MTS, Wind River ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH wayland] add apis to enable/disable wayland debug at runtime
Sorry, I attached the patch at the end of the following email. :)
Thanks,
Sung-Jin Park
-Original Message-
From: 박성진 [mailto:sj76.p...@samsung.com]
Sent: Friday, November 13, 2015 7:33 PM
To: wayland-devel@lists.freedesktop.org
Cc: Sung-Jin Park/Common Platform Lab(S/W Center)/S5/Samsung Electronics
Subject: [PATCH wayland] add apis to enable/disable wayland debug at runtime
Hello,
I added two apis in wayland-util to enable/disable display of wayland debug
information at runtime.
I had a difficulty to see wayland debug information at runtime when I'd
like to debug both a compositor and client(s).
And I found that there is no proper apis yet to enable/disable wayland
debug information at runtime.
Actually, we already know that we can see wayland debug information by
setting WAYLAND_DEBUG environment to 1.
But the environment will merely check when a compositor creates a wayland
display or a client tries to connect to an wayland display.
IMO, it's better to have the additional apis to enable/disable wayland
debug information at runtime.
It would also help if we are to catch the problems associated with timing.
Plz kindly review this patch.
=
>From 018eec7b3a7a0667d25b116945a2c98dc914dc38 Mon Sep 17 00:00:00 2001
From: Sung-Jin Park
Date: Fri, 13 Nov 2015 18:55:17 +0900
Subject: [PATCH] add apis to enable/disable wayland debug at runtime
---
src/wayland-client.c | 2 --
src/wayland-private.h | 9 +
src/wayland-server.c | 2 --
src/wayland-util.c| 15 +++
4 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index b1c600f..151d18e 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -110,8 +110,6 @@ struct wl_display {
/** \endcond */
-static int debug_client = 0;
-
/**
* This helper function wakes up all threads that are
* waiting for display->reader_cond (i. e. when reading is done,
diff --git a/src/wayland-private.h b/src/wayland-private.h
index da9040a..3003417 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -206,6 +206,15 @@ wl_closure_print(struct wl_closure *closure,
void
wl_closure_destroy(struct wl_closure *closure);
+extern int debug_client;
+extern int debug_server;
+
+void
+wl_debug_client_enable(int enable);
+
+void
+wl_debug_server_enable(int enable);
+
extern wl_log_func_t wl_log_handler;
void wl_log(const char *fmt, ...);
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 0f04f66..c3c35ed 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -122,8 +122,6 @@ struct wl_resource {
wl_dispatcher_func_t dispatcher;
};
-static int debug_server = 0;
-
WL_EXPORT void
wl_resource_post_event_array(struct wl_resource *resource, uint32_t opcode,
union wl_argument *args)
diff --git a/src/wayland-util.c b/src/wayland-util.c
index 00265e9..8f9f30b 100644
--- a/src/wayland-util.c
+++ b/src/wayland-util.c
@@ -33,6 +33,9 @@
#include "wayland-util.h"
#include "wayland-private.h"
+int debug_client = 0;
+int debug_server = 0;
+
struct wl_object global_zombie_object;
WL_EXPORT void
@@ -366,6 +369,18 @@ wl_map_for_each(struct wl_map *map, wl_iterator_func_t
func, void *data)
for_each_helper(&map->server_entries, func, data);
}
+WL_EXPORT void
+wl_debug_client_enable(int enable)
+{
+ debug_client = !!enable;
+}
+
+WL_EXPORT void
+wl_debug_server_enable(int enable)
+{
+ debug_server = !!enable;
+}
+
/** \endcond */
static void
--
1.9.1
Thanks,
Sung-Jin Park
0001-add-apis-to-enable-disable-wayland-debug-at-runtime.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] add apis to enable/disable wayland debug at runtime
Hello, I added two apis in wayland-util to enable/disable display of wayland debug information at runtime. I had a difficulty to see wayland debug information at runtime when I'd like to debug both a compositor and client(s). And I found that there is no proper apis yet to enable/disable wayland debug information at runtime. Actually, we already know that we can see wayland debug information by setting WAYLAND_DEBUG environment to 1. But the environment will merely check when a compositor creates a wayland display or a client tries to connect to an wayland display. IMO, it's better to have the additional apis to enable/disable wayland debug information at runtime. It would also help if we are to catch the problems associated with timing. Plz kindly review this patch. Thanks, Sung-Jin Park 0001-add-apis-to-enable-disable-wayland-debug-at-runtime.patch Description: Binary data ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Patchwork to require git-send-email formatted patches?
On Thu, Nov 12, 2015 at 06:40:48PM -0800, Bryce Harrington wrote: > On Thu, Nov 12, 2015 at 09:38:48AM +, Ucan, Emre (ADITG/SW1) wrote: > > Hi, > > > > I personally create the patches with git format-patch and then copy to the > > email. > > Because I have to use windows and outlook for my company email. > > This might be more trouble than worth for you, but for a while I was in > a similar boat at Samsung, which is all MS Exchange based, and for me > copying the patches in email was beyond my tolerance threshold. I was > able to interface with it using DavMail. It was a bit clunky but worked > adequately for me. YMMV. I have in mind a 'git pw submit' command that would work like git send-email but would send the git-format patches to an HTTP/REST end point. Patchwork would, then, send the emails to the ml on behalf of the author. It would help people that are in these situations. I'd also love if that command could take care of sending successive revisions for me (either with --in-reply-to or full series depending how much has changed). But that's all handy wavy and I may not have time to reach that point. -- Damien ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 1/8] tablet: widen the tool id to 64 bits
Hi Peter,
Code-wise this series looks good to me. Assuming the new
"tip" behavior is the result of discussions with / a request
of toolkit people, this series is:
Reviewed-by: Hans de Goede
Regards,
Hans
On 11-11-15 22:12, Peter Hutterer wrote:
Signed-off-by: Peter Hutterer
---
src/libinput.c | 2 +-
src/libinput.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/libinput.c b/src/libinput.c
index a05148f..79e4863 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -1101,7 +1101,7 @@ libinput_tool_get_type(struct libinput_tool *tool)
return tool->type;
}
-LIBINPUT_EXPORT uint32_t
+LIBINPUT_EXPORT uint64_t
libinput_tool_get_tool_id(struct libinput_tool *tool)
{
return tool->tool_id;
diff --git a/src/libinput.h b/src/libinput.h
index 3962b9d..018dbd4 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -1583,7 +1583,7 @@ libinput_tool_get_type(struct libinput_tool *tool);
*
* @see libinput_tool_get_type
*/
-uint32_t
+uint64_t
libinput_tool_get_tool_id(struct libinput_tool *tool);
/**
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland] protocol: Add wl_surface.buffer_damage
On Thu, 12 Nov 2015 13:48:10 -0600 Derek Foreman wrote: > On 12/11/15 01:27 PM, Jason Ekstrand wrote: > > Thanks for picking this up! Also, thanks for posting this on the bug, > > I would have missed it otherwise! > > Thanks to Pekka for prodding me to do so. :) > > > On Thu, Nov 12, 2015 at 11:16 AM, Derek Foreman > > wrote: > >> On 09/11/15 09:06 AM, Pekka Paalanen wrote: > >>> On Fri, 6 Nov 2015 12:55:19 -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.buffer_damage 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.buffer_damage request > was another option. > > >>> > >>> Hi Derek, > >>> > >>> please mention https://bugs.freedesktop.org/show_bug.cgi?id=78190 in > >>> this patch. > >> > >> Will do. > >> > Signed-off-by: Derek Foreman > --- > > Necro-posting on: > http://lists.freedesktop.org/archives/wayland-devel/2014-February/013440.html > and > http://lists.freedesktop.org/archives/wayland-devel/2014-February/013442.html > > This came up on IRC again the other day, and it's still an unsolved > problem... > I'm posting this as RFC to see if anyone's interested in it - I'll do an > implementation if we can get an agreement on the protocol text. > >>> > >>> Thanks for picking this up! > >> > >> Since all the conflict seems to be around how aggressively we should > >> encourage people to use this instead of the existing surface damage > >> request, I'll write a weston implementation. > >> > protocol/wayland.xml | 44 ++-- > 1 file changed, 42 insertions(+), 2 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 9c22d45..1cb2f66 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. > @@ -1327,6 +1327,46 @@ > > > > >>> > >>> I know Jasper suggested deprecating wl_surface.damage, but I see no > >>> reason for that. wl_surface.damage is well-defined - it is only misused. > >>> > >>> We could add some wording to have both refer to each other as an > >>> alternative way to post damage. Especially to wl_surface.damage should > >>> mention buffer_damage as doing what you'd usually expect. > >> > >> Ok, that sounds viable. > >> > + > + > + > >>> > >>> The name "buffer_damage" is slightly unfortunate. See: > >>> https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_swap_buffers_with_damage.txt > >>> > >>> What we are doing in Wayland is always "surface damage"[*], while that > >>> EGL extension reserves "buffer damage" for a different purpose. I feel > >>> it might be confusing. > >>> > >>> Could we come up with a another name for this request? > >>> - wl_surface.damage_pixels > >>> - wl_surface.damage_by_buffer > >>> > >>> eh... buffer_damage is fine if nothing else sticks. The specification > >>> language below is clear anyway, IMO. > >> > >> I'll call it damage_pixels in the next revision. > > > > Either buffer_damage or damage_pixels is fine by me. I think I would > > have a slight preference towards buffer_damage but meh. > > Me too, honestly. :) Haha, sorry for the bad suggestion. :-D My opposition to damage_pixels is: what if the buffer does not contain pixels? > + > +This request is used to describe t
