Re: Wayland/weston, Qt and RDP connection...

[Hardening]

Le 13/01/2023 à 13:13, Matti Ristimäki a écrit :

Hi,

Any tips, where/how to debug RDP related problem with Wayland/Weston. 
Not kind of sure if this is Weston problem or Qt problem…


Goal:

Trying to create a RDP connection to a Qt GUI-application.

[Service]

# Requires systemd-notify.so Weston plugin.

Type=notify

EnvironmentFile=/etc/default/weston

ExecStart=/usr/bin/weston --log=${XDG_RUNTIME_DIR}/weston.log 
--modules=systemd-notify.so *--modules=screen.share.so*


Problem:

Seems, that the Qt application doesn't start after adding the 
"--modules=screen.share.so" to services. And it doesn’t start:


Hi,

sorry very late reply, but if the goal is to export a Qt app through 
RDP, you may be interested by qfreerdp_platform 
(https://github.com/hardening/qfreerdp_platform). This a QPA (Qt 
Platform Abstraction module) that expose the screen and inputs through a 
RDP listener (using FreeRDP just like the weston-rdp backend).


Best regards.


--
David FORT
website: https://www.hardening-consulting.com/

Re: [PATCH] rdp-compositor: fix compilation against last FreeRDP 2.0

[Hardening]

Le 25/05/2018 à 16:17, Pekka Paalanen a écrit :
> On Thu, 24 May 2018 14:55:20 +0200
> David Fort  wrote:
> 
>> The SURFACE_BITS_COMMAND struct has changed and some members have been moved 
>> in the
>> bmp field.
>> ---
>>  configure.ac   |  5 ++-

[...]

>>  
> 
> Hi,
> 
> with freerdp-2.0.0_rc1, this results in the following and tons more:
> 
> /home/pq/git/weston/libweston/compositor-rdp.c: In function 
> ‘rdp_peer_refresh_rfx’:
> /home/pq/git/weston/libweston/compositor-rdp.c:70:29: error: 
> ‘SURFACE_BITS_COMMAND {aka struct _SURFACE_BITS_COMMAND}’ has no member named 
> ‘bmp’; did you mean ‘bpp’?
>  #define SURFACE_BPP(cmd) cmd->bmp.bpp
>  ^
> /home/pq/git/weston/libweston/compositor-rdp.c:219:2: note: in expansion of 
> macro ‘SURFACE_BPP’
>   SURFACE_BPP(cmd) = 32;
> 
> 
> However, configure says:
> 
> checking for SURFACE_BITS_COMMAND.bmp... no
> 
> 
> But config.h contains:
> 
> /* SURFACE_BITS_CMD has bmp field */
> #define HAVE_SURFACE_BITS_BMP $have_bmp
> 
> So, something to fix. :-)
> 

Hi Pekka,
the new version should works with older versions.

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] compositor-rdp: fix compilation with freerdp 2.0.0-rc2

[Hardening]

Le 22/05/2018 à 16:12, Pekka Paalanen a écrit :
> On Fri, 11 May 2018 11:47:47 +0200
> Luca Weiss  wrote:
> 
>> See 
>> https://github.com/FreeRDP/FreeRDP/commit/1f7d33a2f22a372c124ce985a394619e186e06b9
>>  for the upstream change.
>>
>> Signed-off-by: Luca Weiss 
>> ---
>>  libweston/compositor-rdp.c | 50 +++---
>>  1 file changed, 25 insertions(+), 25 deletions(-)
>>
> 
> Hi,
> 
> obviously this breaks the build for freerdp 2.0.0-rc1. Personally I'd
> be fine with this change, the distro I use has rc2.
> 
> David, do we want to do this? Have we ever or is it feasible to support
> more than a single freerdp version at a time?
> 
> The patch looks fine and works fine for me, so the very least:
> 
> Tested-by: Pekka Paalanen 
> 

Yeah I've hit the same problem on another project using FreeRDP 2.0,
what about testing the bmp field of the SURFACE_BITS_COMMAND struct in
configure.ac and adjusting code ? I can submit something like that
except if Luca want to do it...

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 3/3] rdp-backend.so: OpenGL hardware acceleration

[Hardening]

Le 06/07/2017 à 12:06, Olivier Blin a écrit :
> From: DRC 
> 
> ---
>  compositor/main.c  |  23 +++-
>  configure.ac   |   4 +-
>  libweston/compositor-rdp.c | 314 
> +++--
>  libweston/compositor-rdp.h |  24 
>  4 files changed, 352 insertions(+), 13 deletions(-)
> 
> diff --git a/compositor/main.c b/compositor/main.c
> index f8a60e97..125cc0f8 100644
> --- a/compositor/main.c
> +++ b/compositor/main.c
> @@ -601,6 +601,7 @@ usage(int error_code)
>   "  --rdp4-key=FILE\tThe file containing the key for RDP4 
> encryption\n"
>   "  --rdp-tls-cert=FILE\tThe file containing the certificate for 
> TLS encryption\n"
>   "  --rdp-tls-key=FILE\tThe file containing the private key for 
> TLS encryption\n"
> + "  --use-pixman\t\tUse the pixman (CPU) renderer\n"
>   "\n");
>  #endif
>  
> @@ -1331,11 +1332,14 @@ static void
>  rdp_backend_output_configure(struct wl_listener *listener, void *data)
>  {
>   struct weston_output *output = data;
> + struct weston_config *wc = wet_get_config(output->compositor);
>   struct wet_compositor *compositor = 
> to_wet_compositor(output->compositor);
>   struct wet_output_config *parsed_options = compositor->parsed_options;
> + struct weston_config_section *section;
>   const struct weston_rdp_output_api *api = 
> weston_rdp_output_get_api(output->compositor);
>   int width = 640;
>   int height = 480;
> + char *gbm_format = NULL;
>  
>   assert(parsed_options);
>  
> @@ -1344,6 +1348,8 @@ rdp_backend_output_configure(struct wl_listener 
> *listener, void *data)
>   return;
>   }
>  
> + section = weston_config_get_section(wc, "output", "name", output->name);
> +
>   if (parsed_options->width)
>   width = parsed_options->width;
>  
> @@ -1353,6 +1359,12 @@ rdp_backend_output_configure(struct wl_listener 
> *listener, void *data)
>   weston_output_set_scale(output, 1);
>   weston_output_set_transform(output, WL_OUTPUT_TRANSFORM_NORMAL);
>  
> + weston_config_section_get_string(section,
> +  "gbm-format", &gbm_format, NULL);
> +
> + api->set_gbm_format(output, gbm_format);
> + free(gbm_format);
> +
>   if (api->output_set_size(output, width, height) < 0) {
>   weston_log("Cannot configure output \"%s\" using 
> weston_rdp_output_api.\n",
>  output->name);
> @@ -1375,6 +1387,7 @@ weston_rdp_backend_config_init(struct 
> weston_rdp_backend_config *config)
>   config->server_key = NULL;
>   config->env_socket = 0;
>   config->no_clients_resize = 0;
> + config->use_pixman = false;
>  }
>  
>  static int
> @@ -1382,6 +1395,7 @@ load_rdp_backend(struct weston_compositor *c,
>   int *argc, char *argv[], struct weston_config *wc)
>  {
>   struct weston_rdp_backend_config config  = {{ 0, }};
> + struct weston_config_section *section;
>   int ret = 0;
>  
>   struct wet_output_config *parsed_options = wet_init_parsed_options(c);
> @@ -1399,11 +1413,17 @@ load_rdp_backend(struct weston_compositor *c,
>   { WESTON_OPTION_BOOLEAN, "no-clients-resize", 0, 
> &config.no_clients_resize },
>   { WESTON_OPTION_STRING,  "rdp4-key", 0, &config.rdp_key },
>   { WESTON_OPTION_STRING,  "rdp-tls-cert", 0, &config.server_cert 
> },
> - { WESTON_OPTION_STRING,  "rdp-tls-key", 0, &config.server_key }
> + { WESTON_OPTION_STRING,  "rdp-tls-key", 0, &config.server_key },
> + { WESTON_OPTION_BOOLEAN, "use-pixman", 0, &config.use_pixman }
>   };
>  
>   parse_options(rdp_options, ARRAY_LENGTH(rdp_options), argc, argv);
>  
> + section = weston_config_get_section(wc, "core", NULL, NULL);
> + weston_config_section_get_string(section,
> +  "gbm-format", &config.gbm_format,
> +  NULL);
> +
>   ret = weston_compositor_load_backend(c, WESTON_BACKEND_RDP,
>&config.base);
>  
> @@ -1417,6 +1437,7 @@ out:
>   free(config.rdp_key);
>   free(config.server_cert);
>   free(config.server_key);
> + free(config.gbm_format);
>  
>   return ret;
>  }
> diff --git a/configure.ac b/configure.ac
> index 53faee34..a7b2d517 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -250,9 +250,9 @@ AM_CONDITIONAL([ENABLE_RDP_COMPOSITOR],
> [test x$enable_rdp_compositor = xyes])
>  if test x$enable_rdp_compositor = xyes; then
>AC_DEFINE([BUILD_RDP_COMPOSITOR], [1], [Build the RDP compositor])
> -  PKG_CHECK_MODULES(RDP_COMPOSITOR, [freerdp2 >= 2.0.0],
> +  PKG_CHECK_MODULES(RDP_COMPOSITOR, [freerdp2 >= 2.0.0 libudev >= 136 gbm],
>  [],
> -[PKG_CHECK_MODULES(RDP_COMPOSITOR, [freerdp >= 1.1.0],[])]
> +[PKG_CHECK_MODULES(RDP_COMPOSITOR, [freerdp >= 1.1.0 l

Re: [PATCH 2/3] gl-renderer: read PIXMAN_x8r8g8b8 as GL_BGRA_EXT

[Hardening]

Le 06/07/2017 à 12:06, Olivier Blin a écrit :
> This is needed by the RDP backend, which uses PIXMAN_x8r8g8b8 for its
> shadow buffers.
> ---
>  libweston/gl-renderer.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
> index da29b072..b8b120a1 100644
> --- a/libweston/gl-renderer.c
> +++ b/libweston/gl-renderer.c
> @@ -1213,6 +1213,7 @@ gl_renderer_read_pixels(struct weston_output *output,
>  
>   switch (format) {
>   case PIXMAN_a8r8g8b8:
> + case PIXMAN_x8r8g8b8:
>   gl_format = GL_BGRA_EXT;
>   break;
>   case PIXMAN_a8b8g8r8:
> 

Reviewed-by: David Fort 

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] compositor-rdp: Correct mouse scrolling direction

[Hardening]

Le 21/02/2018 à 11:09, Hardening a écrit :
> Le 09/02/2018 à 17:14, Jason Gerecke a écrit :
>> The direction of scrolling in the RDP compositor appears to be inverted.
>> When using Weston directly in X, sending X11 button 4 cuases window
>> contents to scroll up and button 4 to be reported to xwayland clients.
>> Conversely, when using Weston through RDP (xfreerdp client), sending
>> X11 button 4 causes window contents to scroll down and button 5 to be
>> reported to xwayland clients. The xfreerdp client does not seem to be
>> the cause of this since scrolling works correctly when connecting to
>> a Windows host.
>>
>> Signed-off-by: Jason Gerecke 
>> ---
>>  libweston/compositor-rdp.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libweston/compositor-rdp.c b/libweston/compositor-rdp.c
>> index 4a4dc696..ee68e969 100644
>> --- a/libweston/compositor-rdp.c
>> +++ b/libweston/compositor-rdp.c
>> @@ -1062,7 +1062,7 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
>> UINT16 y)
>>   *
>>   * 
>> https://blogs.msdn.microsoft.com/oldnewthing/20130123-00/?p=5473 explains 
>> the 120 value
>>   */
>> -value = (flags & 0xff) / 120.0;
>> +value = -(flags & 0xff) / 120.0;
>>  if (flags & PTR_FLAGS_WHEEL_NEGATIVE)
>>  value = -value;
>>  
>>
> Looks good.
> 
> Reviewed-by: David FORT 
> 
Pushed:

1f78176..9fc2e46  master -> master

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] compositor-rdp: Correct mouse scrolling direction

[Hardening]

Le 09/02/2018 à 17:14, Jason Gerecke a écrit :
> The direction of scrolling in the RDP compositor appears to be inverted.
> When using Weston directly in X, sending X11 button 4 cuases window
> contents to scroll up and button 4 to be reported to xwayland clients.
> Conversely, when using Weston through RDP (xfreerdp client), sending
> X11 button 4 causes window contents to scroll down and button 5 to be
> reported to xwayland clients. The xfreerdp client does not seem to be
> the cause of this since scrolling works correctly when connecting to
> a Windows host.
> 
> Signed-off-by: Jason Gerecke 
> ---
>  libweston/compositor-rdp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libweston/compositor-rdp.c b/libweston/compositor-rdp.c
> index 4a4dc696..ee68e969 100644
> --- a/libweston/compositor-rdp.c
> +++ b/libweston/compositor-rdp.c
> @@ -1062,7 +1062,7 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
> UINT16 y)
>*
>* 
> https://blogs.msdn.microsoft.com/oldnewthing/20130123-00/?p=5473 explains the 
> 120 value
>*/
> - value = (flags & 0xff) / 120.0;
> + value = -(flags & 0xff) / 120.0;
>   if (flags & PTR_FLAGS_WHEEL_NEGATIVE)
>   value = -value;
>  
> 
Looks good.

Reviewed-by: David FORT 

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston 05/21] libweston: weston_output_init(..., +name)

[Hardening]

Le 22/09/2017 à 16:31, Pekka Paalanen a écrit :
> From: Pekka Paalanen 
> 
> Add 'name' argument to weston_output_init(). This is much more obvious
> than the assert inside weston_output_init() to ensure the caller has set
> a field in weston_output first.
> 
> Now weston_output_init() will strdup() the name itself, which means we
> can drop a whole bunch of strdup()s in the backends. This matches
> weston_output_destroy() which was already calling free() on the name.
> 
> All backends are slightly reordered to call weston_output_init() before
> accessing any fields of weston_output, except the Wayland backend which
> would make it a little awkward to do it in this patch. Mind, that
> weston_output_init() still does not reset the struct to zero - it is
> presumed the caller has done it, since weston_output is embedded in the
> backend output structs.
> 
> Signed-off-by: Pekka Paalanen 

Reviewed-by: David Fort 

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

Re: [PATCH] Fix API troubles with FreeRDP 2.0

[Hardening]

Le 25/09/2017 à 10:49, Pekka Paalanen a écrit :
> On Fri, 22 Sep 2017 11:17:41 +0200
> David Fort  wrote:
> 
>> With FreeRDP 2.0 the crypto needs to be initialized or we fail as soon as we 
>> try to
>> compute a md5. The API also changed for the suppress output callback.
>> ---
>>  libweston/compositor-rdp.c | 15 ++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/libweston/compositor-rdp.c b/libweston/compositor-rdp.c
>> index 091472b..6706765 100644
>> --- a/libweston/compositor-rdp.c
>> +++ b/libweston/compositor-rdp.c
>> @@ -76,6 +76,10 @@
>>  #include 
>>  #include 
>>  
>> +#if FREERDP_VERSION_MAJOR >= 2
>> +#include 
>> +#endif
>> +
>>  #include "shared/helpers.h"
>>  #include "compositor.h"
>>  #include "compositor-rdp.h"
>> @@ -159,6 +163,7 @@ to_rdp_backend(struct weston_compositor *base)
>>  return container_of(base->backend, struct rdp_backend, base);
>>  }
>>  
>> +
> 
> Stray newline?

Sorry, will fix that

> 
>>  static void
>>  rdp_peer_refresh_rfx(pixman_region32_t *damage, pixman_image_t *image, 
>> freerdp_peer *peer)
>>  {
>> @@ -1013,7 +1018,8 @@ xf_peer_activate(freerdp_peer* client)
>>  return TRUE;
>>  }
>>  
>> -static BOOL xf_peer_post_connect(freerdp_peer *client)
>> +static BOOL
>> +xf_peer_post_connect(freerdp_peer *client)
>>  {
>>  return TRUE;
>>  }
>> @@ -1166,7 +1172,11 @@ xf_input_unicode_keyboard_event(rdpInput *input, 
>> UINT16 flags, UINT16 code)
>>  
>>  
>>  static FREERDP_CB_RET_TYPE
>> +#if FREERDP_VERSION_MAJOR >= 2
>> +xf_suppress_output(rdpContext *context, BYTE allow, const RECTANGLE_16 
>> *area)
>> +#else
>>  xf_suppress_output(rdpContext *context, BYTE allow, RECTANGLE_16 *area)
>> +#endif
>>  {
>>  RdpPeerContext *peerContext = (RdpPeerContext *)context;
>>  
>> @@ -1387,6 +1397,9 @@ weston_backend_init(struct weston_compositor 
>> *compositor,
>>  struct weston_rdp_backend_config config = {{ 0, }};
>>  int major, minor, revision;
>>  
>> +#if FREERDP_VERSION_MAJOR >= 2
>> +winpr_InitializeSSL(0);
>> +#endif
>>  freerdp_get_version(&major, &minor, &revision);
>>  weston_log("using FreeRDP version %d.%d.%d\n", major, minor, revision);
>>  
> 
> Hi,
> 
> I currently have net-misc/freerdp-2.0.0_pre20160722. Without this
> patch, the build runs fine.
> 
> When I apply this patch and build, I get:
> 
>   CC   libweston/rdp_backend_la-compositor-rdp.lo
> /home/pq/git/weston/libweston/compositor-rdp.c: In function ‘rdp_peer_init’:
> /home/pq/git/weston/libweston/compositor-rdp.c:1240:33: warning: assignment 
> from incompatible pointer type
>   client->update->SuppressOutput = xf_suppress_output;
>  ^
> 

A const has been added on the rect parameter, ignoring the warning is
ok, but I will resubmit something to drop it. Except with some
configure.ac tests, I'm not sure there's a way to determine if the const
is there (tests on sub-version aren't reliable).


> What is the FreeRDP version we should be using?
> 
> Is there a reasonable way to make the warning go away, is it a fatal
> problem, or should we just live with it and suggest people to upgrade
> their FreeRDP snapshot to fix it?
> 
> Can/should we have more strict FreeRDP configure.ac tests locking us to
> a compatible FreeRDP version?
> 
> FWIW, the FreeRDP versions I seem to have available in Gentoo are:
> freerdp-1.2.1_pre20150326-r1
> freerdp-2.0.0_pre20160722
> freerdp-2.0.0_pre20161219
> freerdp-2.0.0_rc0
> 
> Fedora 26 seems to have freerdp-2.0.0-34.20170831git3b83526.
> 
> 
IIRC I did some tests on Fedora 25 and Fedora 26 and it was compiling
fine. Anyway I noticed that remote connection does not refresh correctly
when plain bitmap encoding is used (looking at that).

Best regards

PS: I did (multiple time) promised a doc to test the RDP compositor, I'm
on it.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 1/3] compositor-rdp: fix leak of frame bitmap in raw mode

[Hardening]

Le 06/07/2017 à 12:06, Olivier Blin a écrit :
> In rdp_peer_refresh_raw(), cmd->bitmapData was reallocated, but never freed.
> 
> The cmd content (actually peer->update->surface_bits_command) was
> re-initialized to zero at the beginning of the function, losing the
> pointer to the previously allocated bitmap data.
> 
> Move the bitmap data in the peer->context structure instead, so that
> it can be reused for every frame, and freed at destruction.
> ---
>  libweston/compositor-rdp.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/libweston/compositor-rdp.c b/libweston/compositor-rdp.c
> index 091472b0..7b1ab06d 100644
> --- a/libweston/compositor-rdp.c
> +++ b/libweston/compositor-rdp.c
> @@ -142,6 +142,7 @@ struct rdp_peer_context {
>   wStream *encode_stream;
>   RFX_RECT *rfx_rects;
>   NSC_CONTEXT *nsc_context;
> + BYTE * bitmapData;
>  
>   struct rdp_peers_item item;
>  };
> @@ -312,7 +313,10 @@ rdp_peer_refresh_raw(pixman_region32_t *region, 
> pixman_image_t *image, freerdp_p
>  cmd->destTop = top;
>  cmd->destBottom = top + cmd->height;
>  cmd->bitmapDataLength = cmd->width * cmd->height * 4;
> -cmd->bitmapData = (BYTE *)realloc(cmd->bitmapData, 
> cmd->bitmapDataLength);
> +
> +RdpPeerContext *context = (RdpPeerContext 
> *)peer->context;
> +context->bitmapData = (BYTE 
> *)realloc(context->bitmapData, cmd->bitmapDataLength);
> +cmd->bitmapData = context->bitmapData;
>  
>  subrect.y1 = top;
>  subrect.y2 = top + cmd->height;
> @@ -659,6 +663,7 @@ int rdp_implant_listener(struct rdp_backend *b, 
> freerdp_listener* instance)
>  static FREERDP_CB_RET_TYPE
>  rdp_peer_context_new(freerdp_peer* client, RdpPeerContext* context)
>  {
> + context->bitmapData = NULL;
>   context->item.peer = client;
>   context->item.flags = RDP_PEER_OUTPUT_ENABLED;
>  
> @@ -715,6 +720,8 @@ rdp_peer_context_free(freerdp_peer* client, 
> RdpPeerContext* context)
>* but it would crash on reconnect */
>   }
>  
> + free(context->bitmapData);
> +
>   Stream_Free(context->encode_stream, TRUE);
>   nsc_context_free(context->nsc_context);
>   rfx_context_free(context->rfx_context);
> 

Reviewed-by: David Fort 

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: Remote display with 3D acceleration using Wayland/Weston

[Hardening]

Le 24/02/2017 à 00:51, DRC a écrit :
> On 12/15/16 3:01 AM, Pekka Paalanen wrote:
>> The current RDP-backed is written to set up and use only the Pixman
>> renderer. Pixman renderer is a software renderer, and will not
>> initialize EGL in the compositor. Therefore no support for hardware
>> accelerated OpenGL gets advertised to clients, and clients fall back to
>> software GL.
>>
>> You can fix this purely by modifying libweston/compositor-rdp.c file,
>> writing the support for initializing the GL-renderer. Then you get
>> hardware accelerated GL support for all Wayland clients without any
>> other modifications anywhere.
>>
>> Why that has not been done already is because it was thought that
>> having clients using hardware OpenGL while the compositor is not cannot
>> be performant enough to justify the effort. Also, it pulls in the
>> dependency to EGL and GL libs, which are huge. Obviously your use case
>> is different and this rationale does not apply.
>>
>> The hardest part in adding the support to the RDP-backend is
>> implementing the buffer content access efficiently. RDP requires pixel
>> data in system memory so the CPU can read it, but GL-renderer has all
>> pixel data in graphics memory which often cannot be directly read by
>> the CPU. Accessing that pixel data requires a copy (glReadPixels), and
>> there is nowadays a helper: weston_surface_copy_content(), however the
>> function is not efficient and is so far meant only for debugging and
>> testing.
> 
> I am attempting to modify the RDP backend to prove the concept that
> hardware-accelerated OpenGL is possible with a remote display backend,
> but my lack of familiarity with the code is making this very
> challenging.  It seems that the RDP backend uses Pixman both for GL
> rendering and also to maintain its framebuffer in main memory
> (shadow_surface.)  Is that correct?  If so, then it seems that I would
> need to continue using the shadow surface but use gl_renderer instead of
> the Pixman renderer, then implement my own method of transferring pixels
> from the GL renderer to the shadow surface at the end of every frame (?)
>  I've been trying to work from compositor-wayland.c as a template, but
> it's unclear how everything connects, which parts of that code I need in
> order to implement hardware acceleration, and which parts are
> unnecessary.  I would appreciate it if someone who has familiarity with
> the RDP backend could give me some targeted advice.

This has been done a quite long time ago, here =>
https://gitorious.org/weston/jonseverinsson-weston/?p=weston:jonseverinsson-weston.git;a=commit;h=9e26d9356255f4af1723700272805f6d356c7d7a

It's clearly outdated, and IIRC people here didn't like the way it was
implemented, but you have the idea. It's using DRI render nodes to do
the rendering.

Best regards.
-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH] scanner: Fix building on musl

[Hardening]

Le 23/06/2016 01:48, Kylie McClain a écrit :
> From: Kylie McClain 
> 
> `uint` is defined in sys/types.h on musl libc.
> 
> Signed-off-by: Kylie McClain 
> ---
>  src/scanner.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/scanner.c b/src/scanner.c
> index 4708cae..48d6014 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #if HAVE_LIBXML
>  #include 
> 
Reviewed-By: David Fort 

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] Make config.h inclusion consistent

[Hardening]

Le 16/06/2016 03:13, Bryce Harrington a écrit :
> Signed-off-by: Bryce Harrington 

Reviewed-by: David Fort 

> ---
>  clients/multi-resource.c  | 2 +-
>  clients/presentation-shm.c| 2 +-
>  clients/simple-damage.c   | 2 +-
>  clients/simple-dmabuf-intel.c | 2 +-
>  clients/simple-dmabuf-v4l.c   | 2 +-
>  clients/simple-shm.c  | 2 +-
>  clients/simple-touch.c| 2 +-
>  clients/terminal.c| 2 +-
>  clients/weston-simple-im.c| 2 +-
>  src/cms-colord.c  | 4 +---
>  xwayland/hash.c   | 2 +-
>  11 files changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/clients/multi-resource.c b/clients/multi-resource.c
> index b061e68..c283022 100644
> --- a/clients/multi-resource.c
> +++ b/clients/multi-resource.c
> @@ -22,7 +22,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   */
>  
> -#include 
> +#include "config.h"
>  
>  #include 
>  #include 
> diff --git a/clients/presentation-shm.c b/clients/presentation-shm.c
> index 2d9b885..998ce8b 100644
> --- a/clients/presentation-shm.c
> +++ b/clients/presentation-shm.c
> @@ -23,7 +23,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   */
>  
> -#include 
> +#include "config.h"
>  
>  #include 
>  #include 
> diff --git a/clients/simple-damage.c b/clients/simple-damage.c
> index 82091d5..bb81902 100644
> --- a/clients/simple-damage.c
> +++ b/clients/simple-damage.c
> @@ -23,7 +23,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   */
>  
> -#include 
> +#include "config.h"
>  
>  #include 
>  #include 
> diff --git a/clients/simple-dmabuf-intel.c b/clients/simple-dmabuf-intel.c
> index 2ac2200..fa2bfc4 100644
> --- a/clients/simple-dmabuf-intel.c
> +++ b/clients/simple-dmabuf-intel.c
> @@ -22,7 +22,7 @@
>   * OF THIS SOFTWARE.
>   */
>  
> -#include 
> +#include "config.h"
>  
>  #include 
>  #include 
> diff --git a/clients/simple-dmabuf-v4l.c b/clients/simple-dmabuf-v4l.c
> index a73556c..7ee5cce 100644
> --- a/clients/simple-dmabuf-v4l.c
> +++ b/clients/simple-dmabuf-v4l.c
> @@ -20,7 +20,7 @@
>   * OF THIS SOFTWARE.
>   */
>  
> -#include 
> +#include "config.h"
>  
>  #include 
>  #include 
> diff --git a/clients/simple-shm.c b/clients/simple-shm.c
> index 1aa26ce..c442d88 100644
> --- a/clients/simple-shm.c
> +++ b/clients/simple-shm.c
> @@ -22,7 +22,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   */
>  
> -#include 
> +#include "config.h"
>  
>  #include 
>  #include 
> diff --git a/clients/simple-touch.c b/clients/simple-touch.c
> index 446f2ca..8fd0b0a 100644
> --- a/clients/simple-touch.c
> +++ b/clients/simple-touch.c
> @@ -22,7 +22,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   */
>  
> -#include 
> +#include "config.h"
>  
>  #include 
>  #include 
> diff --git a/clients/terminal.c b/clients/terminal.c
> index a70fef3..66bdeec 100644
> --- a/clients/terminal.c
> +++ b/clients/terminal.c
> @@ -21,7 +21,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   */
>  
> -#include 
> +#include "config.h"
>  
>  #include 
>  #include 
> diff --git a/clients/weston-simple-im.c b/clients/weston-simple-im.c
> index 4c1d7cf..426fec7 100644
> --- a/clients/weston-simple-im.c
> +++ b/clients/weston-simple-im.c
> @@ -21,7 +21,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   */
>  
> -#include 
> +#include "config.h"
>  
>  #include 
>  #include 
> diff --git a/src/cms-colord.c b/src/cms-colord.c
> index c88eb11..b9bc9e3 100644
> --- a/src/cms-colord.c
> +++ b/src/cms-colord.c
> @@ -23,9 +23,7 @@
>   * SOFTWARE.
>   */
>  
> -#ifdef HAVE_CONFIG_H
> -#include 
> -#endif
> +#include "config.h"
>  
>  #include 
>  #include 
> diff --git a/xwayland/hash.c b/xwayland/hash.c
> index 54f3de9..820e51f 100644
> --- a/xwayland/hash.c
> +++ b/xwayland/hash.c
> @@ -32,7 +32,7 @@
>   *Keith Packard 
>   */
>  
> -#include 
> +#include "config.h"
>  
>  #include 
>  #include 
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] terminal: Document console codes less cryptically

[Hardening]

Le 16/06/2016 03:36, Bryce Harrington a écrit :
> C.f. http://man7.org/linux/man-pages/man4/console_codes.4.html
> 
> Signed-off-by: Bryce Harrington 
Definitely an improvement.

Reviewed-by: David Fort 

> ---
>  clients/terminal.c | 72 
> +++---
>  1 file changed, 36 insertions(+), 36 deletions(-)
> 
> diff --git a/clients/terminal.c b/clients/terminal.c
> index a70fef3..01dc2d2 100644
> --- a/clients/terminal.c
> +++ b/clients/terminal.c
> @@ -1333,12 +1333,12 @@ handle_escape(struct terminal *terminal)
>   }
>  
>   switch (*p) {
> - case '@':/* ICH */
> + case '@':/* ICH - Insert  blank characters */
>   count = set[0] ? args[0] : 1;
>   if (count == 0) count = 1;
>   terminal_shift_line(terminal, count);
>   break;
> - case 'A':/* CUU */
> + case 'A':/* CUU - Move cursor up  rows */
>   count = set[0] ? args[0] : 1;
>   if (count == 0) count = 1;
>   if (terminal->row - count >= terminal->margin_top)
> @@ -1346,7 +1346,7 @@ handle_escape(struct terminal *terminal)
>   else
>   terminal->row = terminal->margin_top;
>   break;
> - case 'B':/* CUD */
> + case 'B':/* CUD - Move cursor down  rows */
>   count = set[0] ? args[0] : 1;
>   if (count == 0) count = 1;
>   if (terminal->row + count <= terminal->margin_bottom)
> @@ -1354,7 +1354,7 @@ handle_escape(struct terminal *terminal)
>   else
>   terminal->row = terminal->margin_bottom;
>   break;
> - case 'C':/* CUF */
> + case 'C':/* CUF - Move cursor right by  columns */
>   count = set[0] ? args[0] : 1;
>   if (count == 0) count = 1;
>   if ((terminal->column + count) < terminal->width)
> @@ -1362,7 +1362,7 @@ handle_escape(struct terminal *terminal)
>   else
>   terminal->column = terminal->width - 1;
>   break;
> - case 'D':/* CUB */
> + case 'D':/* CUB - Move cursor left  columns */
>   count = set[0] ? args[0] : 1;
>   if (count == 0) count = 1;
>   if ((terminal->column - count) >= 0)
> @@ -1370,7 +1370,7 @@ handle_escape(struct terminal *terminal)
>   else
>   terminal->column = 0;
>   break;
> - case 'E':/* CNL */
> + case 'E':/* CNL - Move cursor down  rows, to column 1 */
>   count = set[0] ? args[0] : 1;
>   if (terminal->row + count <= terminal->margin_bottom)
>   terminal->row += count;
> @@ -1378,7 +1378,7 @@ handle_escape(struct terminal *terminal)
>   terminal->row = terminal->margin_bottom;
>   terminal->column = 0;
>   break;
> - case 'F':/* CPL */
> + case 'F':/* CPL - Move cursour up  rows, to column 1 */
>   count = set[0] ? args[0] : 1;
>   if (terminal->row - count >= terminal->margin_top)
>   terminal->row -= count;
> @@ -1386,14 +1386,14 @@ handle_escape(struct terminal *terminal)
>   terminal->row = terminal->margin_top;
>   terminal->column = 0;
>   break;
> - case 'G':/* CHA */
> + case 'G':/* CHA - Move cursor to column  in current row */
>   y = set[0] ? args[0] : 1;
>   y = y <= 0 ? 1 : y > terminal->width ? terminal->width : y;
>  
>   terminal->column = y - 1;
>   break;
> - case 'f':/* HVP */
> - case 'H':/* CUP */
> + case 'f':/* HVP - Move cursor to  */
> + case 'H':/* CUP - Move cursor to  (origin at 1,1) */
>   x = (set[1] ? args[1] : 1) - 1;
>   x = x < 0 ? 0 :
>   (x >= terminal->width ? terminal->width - 1 : x);
> @@ -1420,7 +1420,7 @@ handle_escape(struct terminal *terminal)
>   }
>   terminal->column--;
>   break;
> - case 'J':/* ED */
> + case 'J':/* ED - Erase display */
>   row = terminal_get_row(terminal, terminal->row);
>   attr_row = terminal_get_attr_row(terminal, terminal->row);
>   if (!set[0] || args[0] == 0 || args[0] > 2) {
> @@ -1449,7 +1449,7 @@ handle_escape(struct terminal *terminal)
>  terminal->end - terminal->start);
>   }
>   break;
> - case 'K':/* EL */
> + case 'K':/* EL - Erase line */
>   row = terminal_get_row(terminal, terminal->row);
>   attr_row = terminal_get_attr_row(terminal, terminal->row);
>   if (!set[0] || args[0] == 0 || args[0] > 2) {
> @@ -1465,7 +1465,7 @@ handle_escape(struct terminal *terminal)
>   attr_init(attr_r

Re: [PATCH weston] main: report presentation clock resolution

[Hardening]

Le 13/06/2016 13:34, Pekka Paalanen a écrit :
> From: Pekka Paalanen 
> 
> For debugging weird timing issues. If your clock resolution is
> unexpectedly e.g. 10 ms, you can be sure you will have strange timing
> issues. This is almost certainly caused by kernel misconfiguration.
> 
> We rely on clock_getres() being available by the same thing that gets us
> clock_gettime(), so that no new configure.ac check is needed.
> 
> Signed-off-by: Pekka Paalanen 
> ---
>  src/main.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/src/main.c b/src/main.c
> index 193a845..28f6969 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -647,6 +647,7 @@ weston_compositor_log_capabilities(struct 
> weston_compositor *compositor)
>  {
>   unsigned i;
>   int yes;
> + struct timespec res;
>  
>   weston_log("Compositor capabilities:\n");
>   for (i = 0; i < ARRAY_LENGTH(capability_strings); i++) {
> @@ -659,6 +660,14 @@ weston_compositor_log_capabilities(struct 
> weston_compositor *compositor)
>   weston_log_continue(STAMP_SPACE "presentation clock: %s, id %d\n",
>   clock_name(compositor->presentation_clock),
>   compositor->presentation_clock);
> +
> + if (clock_getres(compositor->presentation_clock, &res) == 0)
> + weston_log_continue(STAMP_SPACE
> + "presentation clock resolution: %d.%09ld s\n",
> + (int)res.tv_sec, res.tv_nsec);
> + else
> + weston_log_continue(STAMP_SPACE
> + "presentation clock resolution: N/A\n");
>  }
>  
>  static void
> 
Reviewed-By: David Fort 

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Collaborative window resize

[Hardening]

Hi wayland list,

Yeah I know the title sounds a lot like marketing bullshit. Anyway I was
playing with the RDP compositor with my daughter (haven't you notice how
many bugs you find when you let your children play with your programs
?), we were on 2 different computers, so 2 seats, and we have tried to
resize a window by dragging both edges with the 2 pointers. It happened
that it doesn't work and only the first one to click does resize its
side of the window.

So I wanted to know if it was a weston limitation, or if the xdg-shell
was not allowing this by design.

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 0/6] RDP compositor needs love v2

[Hardening]

Le 26/04/2016 23:34, David Fort a écrit :
> Compared to the first version:
> * compilation with FreeRDP 2.0 is now prefered;
> * trivial patch using constant instead of hard coded value has its own commit;
> * I have splitted the output resized patch so that the shell and the core 
> weston 
> part are separated. I have also reworked the shell part so that only the 
> right surface
> is reconfigured;
> * I've dropped the presentation fix hack.
> 
> David Fort (6):
>   rdp: allow to compile against FreeRDP 2.0
>   rdp: don't release the seat until it is safe
>   rdp: Fix the ContextNew callback with recent FreeRDP versions
>   compositor: use generated constant instead of hardcoded value
>   compositor: recompute output position on mode switch
>   desktop-shell: resize background, panel and lock surface on output
> resize
> 
>  configure.ac  |  8 +-
>  desktop-shell/shell.c | 60 +
>  desktop-shell/shell.h |  7 +
>  src/compositor-rdp.c  | 74 
> ---
>  src/compositor.c  | 36 +
>  src/compositor.h  |  1 +
>  6 files changed, 153 insertions(+), 33 deletions(-)
> 

Patch 1 and 3 have been integrated.

I really think patch 2 (don't release the seat until it is safe) should
be integrated.

And the 2 last ones have received no feedback even if they fix a bug
that is there from years.

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH] rdp: don't release the seat until it is safe v2

[Hardening]

Le 20/05/2016 11:58, Sam Spilsbury a écrit :
> On Fri, May 20, 2016 at 5:33 PM, David Fort  wrote:
>> Releasing a seat is not safe, so let's just announce it without keyboard
>> and mouse until this is fixed. Without this patch we just can't reconnect on
>> the RDP compositor as it crashes.
>>
>> v2: fixed the leak of the xkb_keymap
>>
>> Signed-off-by: David Fort 
>> ---
>>  src/compositor-rdp.c | 33 -
>>  1 file changed, 20 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
>> index 4fc7c74..52cf426 100644
>> --- a/src/compositor-rdp.c
>> +++ b/src/compositor-rdp.c
>> @@ -109,7 +109,7 @@ enum peer_item_flags {
>>  struct rdp_peers_item {
>> int flags;
>> freerdp_peer *peer;
>> -   struct weston_seat seat;
>> +   struct weston_seat *seat;
>>
>> struct wl_list link;
>>  };
>> @@ -640,9 +640,9 @@ rdp_peer_context_free(freerdp_peer* client, 
>> RdpPeerContext* context)
>> }
>>
>> if (context->item.flags & RDP_PEER_ACTIVATED) {
>> -   weston_seat_release_keyboard(&context->item.seat);
>> -   weston_seat_release_pointer(&context->item.seat);
>> -   weston_seat_release(&context->item.seat);
>> +   weston_seat_release_keyboard(context->item.seat);
>> +   weston_seat_release_pointer(context->item.seat);
>> +   /*weston_seat_release(context->item.seat);*/
>> }
> 
> I think instead of just having commented out code, put the reasons why
> the seat cannot be released safely at the moment. Just having it
> commented out will confuse future maintainers.
> 

Well, future maintainers actually means me. The explanation is quite
long, I don't think a comment in the code is the right place for this.
And BTW it's not something that is RDP compositor specific, all the
weston compositors have it.

>>
>> Stream_Free(context->encode_stream, TRUE);
>> @@ -911,9 +911,16 @@ xf_peer_activate(freerdp_peer* client)
>> else
>> snprintf(seat_name, sizeof(seat_name), "RDP peer @%s", 
>> settings->ClientAddress);
>>
>> -   weston_seat_init(&peersItem->seat, b->compositor, seat_name);
>> -   weston_seat_init_keyboard(&peersItem->seat, keymap);
>> -   weston_seat_init_pointer(&peersItem->seat);
>> +   peersItem->seat = zalloc(sizeof(*peersItem->seat));
>> +   if (!peersItem->seat) {
>> +   xkb_keymap_unref(keymap);
>> +   weston_log("unable to create a weston_seat\n");
>> +   return FALSE;
>> +   }
>> +
>> +   weston_seat_init(peersItem->seat, b->compositor, seat_name);
>> +   weston_seat_init_keyboard(peersItem->seat, keymap);
>> +   weston_seat_init_pointer(peersItem->seat);
> 
> Any reason to make this dynamically allocated memory? It seems to me
> like it is adding an additional point of failure for little added
> benefit. If it needs to be dynamically allocated, I think such a
> change should come in a separate patch, since it seems unrelated to
> this one.
> 

I have already answered this in a previous mail to Bryce. To do it
short, it's because the seat has to live longer than the RdpPeerContext.
So when the RDP peer disconnects, the RdpPeerContext will be destroyed
immediately, while the seat is supposed to live until all wayland client
have released it.


> Reviewed-by: Sam Spilsbury 
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 2/6] rdp: don't release the seat until it is safe

[Hardening]

Le 20/05/2016 00:51, Bryce Harrington a écrit :
> On Tue, Apr 26, 2016 at 11:34:04PM +0200, David Fort wrote:
>> Releasing a seat is not safe, so let's just announce it without keyboard
>> and mouse until this is fixed. Without this patch we just can't reconnect on
>> the RDP compositor as it crashes.
>>
>> Signed-off-by: David Fort 
> 
> I see that this patch disables the weston_seat_release() call (which
> sounds from the changelog works around the issue rather than fixes it).
> 
> I'm not spotting the need for making the seat dynamically allocated, is
> that part of the fix or just refactoring?  Regardless, shouldn't it get
> a corresponding free() 
> 

It's just a workaround. And the need to make it dynamic is that the
RdpPeerContext will be freed by FreeRDP, and we need the seat to live
longer (as it is supposed to live as long as a client is binding it).
For now we're just leaking the seat, but I guess that once seat
releasing will work, we will still need to have the seat dynamically
allocated, as the seat will live longer than the RdpPeerContext.

>> ---
>>  src/compositor-rdp.c | 32 +++-
>>  1 file changed, 19 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
>> index f6778b6..862eedc 100644
>> --- a/src/compositor-rdp.c
>> +++ b/src/compositor-rdp.c
>> @@ -109,7 +109,7 @@ enum peer_item_flags {
>>  struct rdp_peers_item {
>>  int flags;
>>  freerdp_peer *peer;
>> -struct weston_seat seat;
>> +struct weston_seat *seat;
>>  
>>  struct wl_list link;
>>  };
>> @@ -623,9 +623,9 @@ rdp_peer_context_free(freerdp_peer* client, 
>> RdpPeerContext* context)
>>  }
>>  
>>  if (context->item.flags & RDP_PEER_ACTIVATED) {
>> -weston_seat_release_keyboard(&context->item.seat);
>> -weston_seat_release_pointer(&context->item.seat);
>> -weston_seat_release(&context->item.seat);
>> +weston_seat_release_keyboard(context->item.seat);
>> +weston_seat_release_pointer(context->item.seat);
>> +/*weston_seat_release(context->item.seat);*/
>>  }
>>  
>>  Stream_Free(context->encode_stream, TRUE);
>> @@ -894,9 +894,15 @@ xf_peer_activate(freerdp_peer* client)
>>  else
>>  snprintf(seat_name, sizeof(seat_name), "RDP peer @%s", 
>> settings->ClientAddress);
>>  
>> -weston_seat_init(&peersItem->seat, b->compositor, seat_name);
>> -weston_seat_init_keyboard(&peersItem->seat, keymap);
>> -weston_seat_init_pointer(&peersItem->seat);
>> +peersItem->seat = zalloc(sizeof(*peersItem->seat));
>> +if (!peersItem->seat) {
>> +weston_log("unable to create a weston_seat\n");
>> +return FALSE;
> 
> Does the xkbContext need freed in this error condition?

Indeed, good catch I'm posting a fix for this.

> 
>> +}
>> +
>> +weston_seat_init(peersItem->seat, b->compositor, seat_name);
>> +weston_seat_init_keyboard(peersItem->seat, keymap);
>> +weston_seat_init_pointer(peersItem->seat);
>>  
>>  peersItem->flags |= RDP_PEER_ACTIVATED;
>>  
>> @@ -935,7 +941,7 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
>> UINT16 y)
>>  if (flags & PTR_FLAGS_MOVE) {
>>  output = peerContext->rdpBackend->output;
>>  if (x < output->base.width && y < output->base.height) {
>> -notify_motion_absolute(&peerContext->item.seat, 
>> weston_compositor_get_time(),
>> +notify_motion_absolute(peerContext->item.seat, 
>> weston_compositor_get_time(),
>>  x, y);
>>  need_frame = true;
>>  }
>> @@ -949,7 +955,7 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
>> UINT16 y)
>>  button = BTN_MIDDLE;
>>  
>>  if (button) {
>> -notify_button(&peerContext->item.seat, 
>> weston_compositor_get_time(), button,
>> +notify_button(peerContext->item.seat, 
>> weston_compositor_get_time(), button,
>>  (flags & PTR_FLAGS_DOWN) ? 
>> WL_POINTER_BUTTON_STATE_PRESSED : WL_POINTER_BUTTON_STATE_RELEASED
>>  );
>>  need_frame = true;
>> @@ -974,13 +980,13 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
>> UINT16 y)
>>  weston_event.discrete = (int)value;
>>  weston_event.has_discrete = true;
>>  
>> -notify_axis(&peerContext->item.seat, 
>> weston_compositor_get_time(),
>> +notify_axis(peerContext->item.seat, 
>> weston_compositor_get_time(),
>>  &weston_event);
>>  need_frame = true;
>>  }
>>  
>>  if (need_frame)
>> -notify_pointer_frame(&peerContext->item.seat);
>> +notify_pointer_frame(peerContext->item.seat);
>>  
>>  FREERDP_CB_RETURN(TRUE);
>>  }
>> @@ -993,7 +999,7 @@ xf_extendedMouseEvent(rdpInput *input, UINT16 flags, 
>> UINT16 x, UINT16 y)
>>  
>>  output

Re: [ANNOUNCE] wayland 1.10.91

[Hardening]

Le 11/05/2016 21:11, Bryce Harrington a écrit :
> On Fri, May 06, 2016 at 02:17:23PM +0300, Pekka Paalanen wrote:
>> On Wed, 4 May 2016 11:46:23 -0700
>> Bryce Harrington  wrote:
>>
>>> On Wed, May 04, 2016 at 12:55:16AM -0700, Bryce Harrington wrote:
 Here's the alpha for the upcoming 1.11 release.  I'll summarize the
 major features for this release in the beta announcement, but see below
 for the detailed listing.

 The schedule going forward is:

   √ 1.11-alpha on May 3rd.  Major features done by this point.
> 
> It looks like someone (pq?) has marked some patches we decided to leave
> for post-1.11 as deferred in patchwork.  I've followed suit and moved
> other patchsets there which are new APIs or that sound like feature
> work.
> 
> Following are what remains.  Most of these I think should be deferred
> but am not 100% certain, so would appreciate hearing other people's
> thoughts:
> 
> 
> 1. Detect keyboard capabilities, refactor seat capability [Derek]
>- Awaiting review by jadahl
>- Over a year old now, probably needs rebased too...
> 
> 2. xdg_popup behavior of input devices [Carlos]
>- Protocol additions for xdg-shell, needs review by xdg devels
>- Been in the queue a long time, but no reviews to date
>- No idea about disposition for this
> 
> 3. xwayland drag-and-drop window creation [Carlos]
>- Looks ok to be but xwayland isn't my area
>- Been in the queue a long time, but no reviews to date
>- From the commit description sounds WIP-ish and that there was
>  planned some followup work, but not sure if that happened?
> 
> 4. Pointer locking (3 patches) [Jonas]
>- Was planned to land this feature for 1.11
>- Reviewers requested changes, but I'm not spotting a v2 for this
>- At a minimum needs updated for trunk, since the protocol files are
>  now in wayland-protocols
>- I'll mark it 'Changes Requested' and hope it will return for
>  consideration for 1.12.
> 
> 5. V2 for text input protocol [Jan Arne]
>- This is intended for wayland-protocols so not really pertinent to
>  the release.  But is on v6 and hasn't received further reviews,
>  perhaps it's time to land it?
> 
> 6. FreeRDP fixes (6 patches) [David]
>- Build fixes are suitable for landing now, so I consider at least
>  the first 3 patches here good candidates for including in 1.11
>- No R-b's other than my own; I'd be more comfortable landing if we
>  had another set of R-b's on this.

Just a note: the last 2 patches fix a bug that has been there for year
with output mode switch. As the RDP compositor is the only one that can
use permanent mode switching, it exposes the bug, but the correction
works for all others.

> 
> 7. compositor-drm clone mode + fixes (8 patches) [Emmanuel]
>- The fixes look straightforward and probably ok to land
>- I haven't reviewed the clone mode feature, but offhand judging by
>  the length of the patch it looks like post-1.11 stuff.
> 
> 8. get_subsurface double-buffered protocol [pq]
>- Is getting strong reviews, but also requests for tests &tc.
>- There is debate on its thread as to whether to land vs. leave for
>  1.12
> 
> 9. Don't set_fullscreen on already fullscreen surfaces [Emmanuel]
>- Short fix, might be worth including in 1.11
>- Needs another R-b or two, but may be an easy thing to land
> 
> 10. compositor fixes (2 patches) [pq]
> 11. eventdemo fixes (3 patches) [pq]
>- These sound landable for 1.11 offhand, but I haven't reviewed.
>- Needs R-b's
> 
> 12. ivi_layout_surface API
>- Straightforward patch, looks fine to me
>- Not sure about landing new API during feature freeze though
>- Needs R-b's
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [GSoC] Some questions about wayland clients with no outputs present

[Hardening]

Le 03/05/2016 09:52, Pekka Paalanen a écrit :
> On Mon, 2 May 2016 17:33:14 -0700
> Bryce Harrington  wrote:
> 
>> On Mon, May 02, 2016 at 12:49:04PM +0200, Armin Krezović wrote:
>>> On 30.04.2016 22:14, Bryce Harrington wrote:  
 On Sat, Apr 30, 2016 at 05:20:09PM +0200, Armin Krezović wrote:
 But virtual outputs is not a bad idea, it could be useful for testing or
 perhaps to extend one's rendering beyond ordinary hardware capabilities
 or something.  But it should be user-controlled via commandline options
 or config file options.  
>>>
>>> I was thinking about using the virtual outputs when no physical outputs
>>> are present, and keep them out of the way otherwise. Sure, a command
>>> line switch/config option is useful, especially for the test suite (Pekka
>>> proposed something similar).  
>>
>> I wonder what situation would arise where the user would want to use the
>> drm backend when there weren't any physical outputs.  I can see that for
>> testing purposes but am drawing a blank for use cases other than that.
> 
> Say, you have your system running, and you want swap the monitor. Or
> re-route the cable better. Or just close the laptop lid (I hear that
> might cause the LVDS to disconnect). Or have a mechanical video switch
> which causes the display to appear disconnected when not selected.
> 
> But none of that is a reason in itself to have a fake output.
> 

Funny, back 3 years ago I had the same questions with the RDP
compositor. My idea was to create the output (and the seat) when the
first client would connect (because the output would have the size
requested by the RDP peer). So if you manage to have 0 output working
everywhere else (I mean shell plugins), I'll probably consider have the
RDP compositor start with 0 outputs.

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 1/6] rdp: allow to compile against FreeRDP 2.0

[Hardening]

Le 01/05/2016 23:32, David Fort a écrit :
> FreeRDP 2.0 is about to be released, this allows to compile against this 
> version.
> The detection is adjusted to prefer FreeRDP 2 against version 1.x.
> 
> Signed-off-by: David Fort 
> ---
>  configure.ac |  5 -
>  src/compositor-rdp.c | 23 ---
>  2 files changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 4199616..6ab9c99 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -238,7 +238,10 @@ AM_CONDITIONAL([ENABLE_RDP_COMPOSITOR],
> [test x$enable_rdp_compositor = xyes])
>  if test x$enable_rdp_compositor = xyes; then
>AC_DEFINE([BUILD_RDP_COMPOSITOR], [1], [Build the RDP compositor])
> -  PKG_CHECK_MODULES(RDP_COMPOSITOR, [freerdp >= 1.1.0])
> +  PKG_CHECK_MODULES(RDP_COMPOSITOR, [freerdp2 >= 2.0.0],
> +[],
> +[PKG_CHECK_MODULES(RDP_COMPOSITOR, [freerdp >= 1.1.0],[])]
> +  )

So this way it should not bug Quentin Glidic ;)

>  
>SAVED_CPPFLAGS="$CPPFLAGS"
>CPPFLAGS="$CPPFLAGS $RDP_COMPOSITOR_CFLAGS"
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index 2860556..f6778b6 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -42,15 +42,24 @@
>  #define FREERDP_VERSION_NUMBER ((FREERDP_VERSION_MAJOR * 0x1) + \
>   (FREERDP_VERSION_MINOR * 0x100) + FREERDP_VERSION_REVISION)
>  
> +
>  #if FREERDP_VERSION_NUMBER >= 0x10201
>  #define HAVE_SKIP_COMPRESSION
>  #endif
>  
>  #if FREERDP_VERSION_NUMBER < 0x10202
> -#define FREERDP_CB_RET_TYPE void
> -#define FREERDP_CB_RETURN(V) return
> +#define FREERDP_CB_RET_TYPE void
> +#define FREERDP_CB_RETURN(V) return
> +#define NSC_RESET(C, W, H)
> +#define RFX_RESET(C, W, H) do { rfx_context_reset(C); C->width = W; 
> C->height = H; } while(0)
> +#else
> +#if FREERDP_VERSION_MAJOR >= 2
> +#define NSC_RESET(C, W, H) nsc_context_reset(C, W, H)
> +#define RFX_RESET(C, W, H) rfx_context_reset(C, W, H)
>  #else
> -#define HAVE_NSC_RESET
> +#define NSC_RESET(C, W, H) do { nsc_context_reset(C); C->width = W; 
> C->height = H; } while(0)
> +#define RFX_RESET(C, W, H) do { rfx_context_reset(C); C->width = W; 
> C->height = H; } while(0)
> +#endif
>  #define FREERDP_CB_RET_TYPE BOOL
>  #define FREERDP_CB_RETURN(V) return TRUE
>  #endif
> @@ -795,6 +804,7 @@ xf_peer_activate(freerdp_peer* client)
>   struct xkb_context *xkbContext;
>   struct xkb_rule_names xkbRuleNames;
>   struct xkb_keymap *keymap;
> + struct weston_output *weston_output;
>   int i;
>   pixman_box32_t box;
>   pixman_region32_t damage;
> @@ -843,10 +853,9 @@ xf_peer_activate(freerdp_peer* client)
>   }
>   }
>  
> - rfx_context_reset(peerCtx->rfx_context);
> -#ifdef HAVE_NSC_RESET
> - nsc_context_reset(peerCtx->nsc_context);
> -#endif
> + weston_output = &output->base;
> + RFX_RESET(peerCtx->rfx_context, weston_output->width, 
> weston_output->height);
> + NSC_RESET(peerCtx->nsc_context, weston_output->width, 
> weston_output->height);
>  
>   if (peersItem->flags & RDP_PEER_ACTIVATED)
>   return TRUE;
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 1/5] rdp: allow to compile against FreeRDP 2.0

[Hardening]

Le 23/04/2016 11:50, Quentin Glidic a écrit :
> On 22/04/2016 15:19, David Fort wrote:
>> FreeRDP 2.0 is about to be released, this allows to compile against
>> this version.
>>
>> Signed-off-by: David Fort 
>> ---
>>  configure.ac |  8 +++-
>>  src/compositor-rdp.c | 23 ---
>>  2 files changed, 23 insertions(+), 8 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 670200c..9c70b2e 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -242,12 +242,18 @@ AM_CONDITIONAL([ENABLE_RDP_COMPOSITOR],
>> [test x$enable_rdp_compositor = xyes])
>>  if test x$enable_rdp_compositor = xyes; then
>>AC_DEFINE([BUILD_RDP_COMPOSITOR], [1], [Build the RDP compositor])
>> -  PKG_CHECK_MODULES(RDP_COMPOSITOR, [freerdp >= 1.1.0])
>> +  PKG_CHECK_MODULES(FreeRDP, [freerdp >= 1.1.0],
>> +[RDP_COMPOSITOR_CFLAGS=$FreeRDP_CFLAGS;
>> RDP_COMPOSITOR_LIBS=$FreeRDP_LIBS;],
>> +[PKG_CHECK_MODULES(FreeRDP2, [freerdp2 >=
>> 2.0.0],[RDP_COMPOSITOR_CFLAGS=$FreeRDP2_CFLAGS;
>> RDP_COMPOSITOR_LIBS=$FreeRDP2_LIBS;])]
>> +  )
> 
> Just use the same prefix ("RDP_COMPOSITOR") in both, it’s safe, and
> easier to read.
> 
It's just that doing so the printed message is "checking RDP_COMPOSITOR"
twice...

> Also, here, you prefer FreeRDP 1 over FreeRDP 2, is that what you want?
> 
> 
Well probably not, I'll change the order.

>>SAVED_CPPFLAGS="$CPPFLAGS"
>>CPPFLAGS="$CPPFLAGS $RDP_COMPOSITOR_CFLAGS"
>>AC_CHECK_HEADERS([freerdp/version.h])
>>CPPFLAGS="$SAVED_CPPFLAGS"
>> +
>> +  AC_SUBST(RDP_COMPOSITOR_CFLAGS)
>> +  AC_SUBST(RDP_COMPOSITOR_LIBS)
> 
> Then you can remove that.
> 
> 
>>  fi
>> [snip]
> 
> Cheers,
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH v1] refactor configuration API of rdp-backend

[Hardening]

Le 22/04/2016 17:05, Benoit Gschwind a écrit :
> Implement a "well" defined API to configure the rdp backend.
> Following according to discution about libweston API.
> ---
> v1:
>  - Fix the patch log
> v0:
>   - Nothing particular.
> 
> Signed-off-by: Benoit Gschwind 
> 
>  Makefile.am  |  1 +
>  src/compositor-rdp.c | 71 
> +---
>  src/compositor-rdp.h | 54 +++
>  src/main.c   | 56 +++--
>  4 files changed, 137 insertions(+), 45 deletions(-)
>  create mode 100644 src/compositor-rdp.h
> 
> diff --git a/Makefile.am b/Makefile.am
> index c042c68..a4dcd57 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -73,6 +73,7 @@ weston_SOURCES =\
>   src/compositor.c\
>   src/compositor.h\
>   src/compositor-headless.h   \
> + src/compositor-rdp.h\
>   src/input.c \
>   src/data-device.c   \
>   src/screenshooter.c \
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index 773b6b5..2860556 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -67,23 +67,13 @@
>  
>  #include "shared/helpers.h"
>  #include "compositor.h"
> +#include "compositor-rdp.h"
>  #include "pixman-renderer.h"
>  
>  #define MAX_FREERDP_FDS 32
>  #define DEFAULT_AXIS_STEP_DISTANCE 10
>  #define RDP_MODE_FREQ 60 * 1000
>  
> -struct rdp_backend_config {
> - int width;
> - int height;
> - char *bind_address;
> - int port;
> - char *rdp_key;
> - char *server_cert;
> - char *server_key;
> - int env_socket;
> - int no_clients_resize;
> -};
>  
>  struct rdp_output;
>  
> @@ -138,20 +128,6 @@ struct rdp_peer_context {
>  typedef struct rdp_peer_context RdpPeerContext;
>  
>  static void
> -rdp_backend_config_init(struct rdp_backend_config *config)
> -{
> - config->width = 640;
> - config->height = 480;
> - config->bind_address = NULL;
> - config->port = 3389;
> - config->rdp_key = NULL;
> - config->server_cert = NULL;
> - config->server_key = NULL;
> - config->env_socket = 0;
> - config->no_clients_resize = 0;
> -}
> -
> -static void
>  rdp_peer_refresh_rfx(pixman_region32_t *damage, pixman_image_t *image, 
> freerdp_peer *peer)
>  {
>   int width, height, nrects, i;
> @@ -1195,8 +1171,7 @@ rdp_incoming_peer(freerdp_listener *instance, 
> freerdp_peer *client)
>  
>  static struct rdp_backend *
>  rdp_backend_create(struct weston_compositor *compositor,
> -struct rdp_backend_config *config,
> -int *argc, char *argv[], struct weston_config *wconfig)
> +struct weston_rdp_backend_config *config)
>  {
>   struct rdp_backend *b;
>   char *fd_str;
> @@ -1274,39 +1249,49 @@ err_free_strings:
>   return NULL;
>  }
>  
> +static void
> +config_init_to_defaults(struct weston_rdp_backend_config *config)
> +{
> + config->width = 640;
> + config->height = 480;
> + config->bind_address = NULL;
> + config->port = 3389;
> + config->rdp_key = NULL;
> + config->server_cert = NULL;
> + config->server_key = NULL;
> + config->env_socket = 0;
> + config->no_clients_resize = 0;
> +}
> +
>  WL_EXPORT int
>  backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
>struct weston_config *wconfig,
>struct weston_backend_config *config_base)
>  {
>   struct rdp_backend *b;
> - struct rdp_backend_config config;
> - rdp_backend_config_init(&config);
> + struct weston_rdp_backend_config config = {{ 0, }};
>   int major, minor, revision;
>  
>   freerdp_get_version(&major, &minor, &revision);
>   weston_log("using FreeRDP version %d.%d.%d\n", major, minor, revision);
>  
> - const struct weston_option rdp_options[] = {
> - { WESTON_OPTION_BOOLEAN, "env-socket", 0, &config.env_socket },
> - { WESTON_OPTION_INTEGER, "width", 0, &config.width },
> - { WESTON_OPTION_INTEGER, "height", 0, &config.height },
> - { WESTON_OPTION_STRING,  "address", 0, &config.bind_address },
> - { WESTON_OPTION_INTEGER, "port", 0, &config.port },
> - { WESTON_OPTION_BOOLEAN, "no-clients-resize", 0, 
> &config.no_clients_resize },
> - { WESTON_OPTION_STRING,  "rdp4-key", 0, &config.rdp_key },
> - { WESTON_OPTION_STRING,  "rdp-tls-cert", 0, &config.server_cert 
> },
> - { WESTON_OPTION_STRING,  "rdp-tls-key", 0, &config.server_key }
> - };
> -
> - parse_options(rdp_options, ARRAY_LENGTH(rdp_options), argc, argv);
> + if (config_base == NULL ||
> + config_base->struct_version != WESTON_RDP_BACKEND_CONFIG_VERSION ||
> + config_base->str

Re: [PATCH 5/5] desktop shell: resize background and panel when an output switches mode

[Hardening]

Le 22/04/2016 16:18, Pekka Paalanen a écrit :
> On Fri, 22 Apr 2016 15:19:06 +0200
> David Fort  wrote:
> 
>> When an output permanently switches mode, the desktop shell must be notified 
>> so
>> that the misc components can resize to the new size of the output. This 
>> patch also
>> fixes the coodinates of "other" outputs when the resize occurs.
>>
>> Signed-off-by: David Fort 
>> ---
>>  desktop-shell/shell.c | 34 ++
>>  desktop-shell/shell.h |  1 +
>>  src/compositor.c  | 33 ++---
>>  src/compositor.h  |  1 +
>>  4 files changed, 58 insertions(+), 11 deletions(-)
>>
>> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
>> index cd269a8..1c1c993 100644
>> --- a/desktop-shell/shell.c
>> +++ b/desktop-shell/shell.c
>> @@ -6368,11 +6368,43 @@ handle_output_destroy(struct wl_listener *listener, 
>> void *data)
>>  shell_for_each_layer(shell, shell_output_destroy_move_layer, output);
>>  
>>  wl_list_remove(&output_listener->destroy_listener.link);
>> +wl_list_remove(&output_listener->resized_listener.link);
>>  wl_list_remove(&output_listener->link);
>>  free(output_listener);
>>  }
>>  
>>  static void
>> +shell_output_resize_layer(struct desktop_shell *shell,
>> +struct weston_layer *layer,
>> +void *data)
>> +{
>> +struct weston_output *output = data;
>> +struct weston_view *view;
>> +
>> +wl_list_for_each(view, &layer->view_list.link, layer_link.link) {
>> +if (view->output != output)
>> +continue;
>> +
>> +weston_desktop_shell_send_configure(shell->child.desktop_shell, 
>> 0,
>> +view->surface->resource,
>> +output->width,
>> +output->height);
> 
> Hi,
> 
> where do you check that the views you are handling are strictly only
> the wallpaper and panel surfaces created by the weston-desktop-shell
> client?
> 
> I have suspicion that this send call can use desktop_shell resource of
> one client with the wl_surface resource of a different client, which is
> illegal. Unfortunately, libwayland-server does not catch that, I
> believe. The result will be messages sent to clients referring random
> object ids that may not even be wl_surfaces.
> 
> I'm surprise this doesn't crash random clients - or does it?
> 
> Hmm... oh, I see. All the messages are sent to the weston-desktop-shell
> client, but rather than referring only the relevant wl_surfaces, they
> are sent for *all* mapped wl_surfaces also from other clients.
> 
> Are you sure weston-desktop-shell doesn't crash? The crash recovery may
> be fast enough that you can only see it in Weston's logs.
> 

It doesn't crash, but adding a breakpoint with the debugger it looks
like you're right and all surfaces are notified. I will change this.

>> +}
>> +}
>> +
>> +
>> +static void
>> +handle_output_resized(struct wl_listener *listener, void *data)
>> +{
>> +struct shell_output *output_listener =
>> +container_of(listener, struct shell_output, resized_listener);
>> +struct weston_output *output = output_listener->output;
>> +struct desktop_shell *shell = output_listener->shell;
>> +
>> +shell_for_each_layer(shell, shell_output_resize_layer, output);
>> +}
>> +
>> +static void
>>  create_shell_output(struct desktop_shell *shell,
>>  struct weston_output *output)
>>  {
>> @@ -6387,6 +6419,8 @@ create_shell_output(struct desktop_shell *shell,
>>  shell_output->destroy_listener.notify = handle_output_destroy;
>>  wl_signal_add(&output->destroy_signal,
>>&shell_output->destroy_listener);
>> +shell_output->resized_listener.notify = handle_output_resized;
>> +wl_signal_add(&output->compositor->output_resized_signal, 
>> &shell_output->resized_listener);
>>  wl_list_insert(shell->output_list.prev, &shell_output->link);
>>  }
>>  
>> diff --git a/desktop-shell/shell.h b/desktop-shell/shell.h
>> index b430fa2..5457923 100644
>> --- a/desktop-shell/shell.h
>> +++ b/desktop-shell/shell.h
>> @@ -112,6 +112,7 @@ struct shell_output {
>>  struct desktop_shell  *shell;
>>  struct weston_output  *output;
>>  struct exposay_output eoutput;
>> +struct wl_listenerresized_listener;
>>  struct wl_listenerdestroy_listener;
>>  struct wl_listlink;
>>  };
>> diff --git a/src/compositor.c b/src/compositor.c
>> index 5500197..a747945 100644
>> --- a/src/compositor.c
>> +++ b/src/compositor.c
>> @@ -143,6 +143,11 @@ static void weston_mode_switch_finish(struct 
>> weston_output *output,
>>  }
>>  }
>>  
>> +
>> +static void
>> +weston_compositor_resize_output(struct weston_compositor *compositor,
>> +struct weston_output *resized_output, int 
>> delta_width);
>> +
>>  WL_EXPORT int
>>  weston_output_mode_set_native(struct westo

Re: [PATCH 3/5] rdp: fix presentation for the RDP compositor

[Hardening]

Le 22/04/2016 15:55, Pekka Paalanen a écrit :
> On Fri, 22 Apr 2016 15:19:04 +0200
> David Fort  wrote:
> 
>> Set an update delay that is a multiple of the output frequency, or we may do
>> incorrect weston_output_finish_frame calls.
>> ---
>>  src/compositor-rdp.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
>> index 9274674..4cbc1c3 100644
>> --- a/src/compositor-rdp.c
>> +++ b/src/compositor-rdp.c
>> @@ -378,7 +378,7 @@ rdp_output_repaint(struct weston_output *output_base, 
>> pixman_region32_t *damage)
>>  pixman_region32_subtract(&ec->primary_plane.damage,
>>   &ec->primary_plane.damage, damage);
>>  
>> -wl_event_source_timer_update(output->finish_frame_timer, 16);
>> +wl_event_source_timer_update(output->finish_frame_timer, 10);
>>  return 0;
>>  }
>>  
> 
> Hi,
> 
> I'm worried that there are more things wrong. This does not look like a
> fix, it just improves the odds of not failing if any.
> 
> So, you have a 100 Hz output update frequency on RDP?
> 

I think you're right, the frequency is supposed to be 60Hz (as announced
in the output settings), unfortunately 6 is a multiple of both 10
and 16 so that's how you said, it just hides the real bug. I'll have a
deeper look.

Best regards

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 1/5] rdp: allow to compile against FreeRDP 2.0

[Hardening]

Le 22/04/2016 15:19, David Fort a écrit :
> FreeRDP 2.0 is about to be released, this allows to compile against this 
> version.
> 
> Signed-off-by: David Fort 
> ---
>  configure.ac |  8 +++-
>  src/compositor-rdp.c | 23 ---
>  2 files changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 670200c..9c70b2e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -242,12 +242,18 @@ AM_CONDITIONAL([ENABLE_RDP_COMPOSITOR],
> [test x$enable_rdp_compositor = xyes])
>  if test x$enable_rdp_compositor = xyes; then
>AC_DEFINE([BUILD_RDP_COMPOSITOR], [1], [Build the RDP compositor])
> -  PKG_CHECK_MODULES(RDP_COMPOSITOR, [freerdp >= 1.1.0])
> +  PKG_CHECK_MODULES(FreeRDP, [freerdp >= 1.1.0],
> +[RDP_COMPOSITOR_CFLAGS=$FreeRDP_CFLAGS; 
> RDP_COMPOSITOR_LIBS=$FreeRDP_LIBS;],
> +[PKG_CHECK_MODULES(FreeRDP2, [freerdp2 >= 
> 2.0.0],[RDP_COMPOSITOR_CFLAGS=$FreeRDP2_CFLAGS; 
> RDP_COMPOSITOR_LIBS=$FreeRDP2_LIBS;])]
> +  )
>  
>SAVED_CPPFLAGS="$CPPFLAGS"
>CPPFLAGS="$CPPFLAGS $RDP_COMPOSITOR_CFLAGS"
>AC_CHECK_HEADERS([freerdp/version.h])
>CPPFLAGS="$SAVED_CPPFLAGS"
> +
> +  AC_SUBST(RDP_COMPOSITOR_CFLAGS)
> +  AC_SUBST(RDP_COMPOSITOR_LIBS)
>  fi
>  
>  AC_ARG_ENABLE([screen-sharing], [  --enable-screen-sharing],,
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index 773b6b5..0649bee 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -42,15 +42,24 @@
>  #define FREERDP_VERSION_NUMBER ((FREERDP_VERSION_MAJOR * 0x1) + \
>   (FREERDP_VERSION_MINOR * 0x100) + FREERDP_VERSION_REVISION)
>  
> +
>  #if FREERDP_VERSION_NUMBER >= 0x10201
>  #define HAVE_SKIP_COMPRESSION
>  #endif
>  
>  #if FREERDP_VERSION_NUMBER < 0x10202
> -#define FREERDP_CB_RET_TYPE void
> -#define FREERDP_CB_RETURN(V) return
> +#define FREERDP_CB_RET_TYPE void
> +#define FREERDP_CB_RETURN(V) return
> +#define NSC_RESET(C, W, H)
> +#define RFX_RESET(C, W, H) do { rfx_context_reset(C); C->width = W; 
> C->height = H; } while(0)
> +#else
> +#if FREERDP_VERSION_MAJOR >= 2
> +#define NSC_RESET(C, W, H) nsc_context_reset(C, W, H)
> +#define RFX_RESET(C, W, H) rfx_context_reset(C, W, H)
>  #else
> -#define HAVE_NSC_RESET
> +#define NSC_RESET(C, W, H) do { nsc_context_reset(C); C->width = W; 
> C->height = H; } while(0)
> +#define RFX_RESET(C, W, H) do { rfx_context_reset(C); C->width = W; 
> C->height = H; } while(0)
> +#endif
>  #define FREERDP_CB_RET_TYPE BOOL
>  #define FREERDP_CB_RETURN(V) return TRUE
>  #endif
> @@ -819,6 +828,7 @@ xf_peer_activate(freerdp_peer* client)
>   struct xkb_context *xkbContext;
>   struct xkb_rule_names xkbRuleNames;
>   struct xkb_keymap *keymap;
> + struct weston_output *weston_output;
>   int i;
>   pixman_box32_t box;
>   pixman_region32_t damage;
> @@ -867,10 +877,9 @@ xf_peer_activate(freerdp_peer* client)
>   }
>   }
>  
> - rfx_context_reset(peerCtx->rfx_context);
> -#ifdef HAVE_NSC_RESET
> - nsc_context_reset(peerCtx->nsc_context);
> -#endif
> + weston_output = &output->base;
> + RFX_RESET(peerCtx->rfx_context, weston_output->width, 
> weston_output->height);
> + NSC_RESET(peerCtx->nsc_context, weston_output->width, 
> weston_output->height);
>  
>   if (peersItem->flags & RDP_PEER_ACTIVATED)
>   return TRUE;
> 


I forgot to specify that this one superseeds
https://patchwork.freedesktop.org/patch/76168/.

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH wayland 2/3] server: move include directives before extern "C" wrapper

[Hardening]

Le 17/04/2016 13:29, Emil Velikov a écrit :
> Analogous to previous commit but for the server(-core) header.
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/wayland-server-core.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
> index e8e1e9c..fa7f394 100644
> --- a/src/wayland-server-core.h
> +++ b/src/wayland-server-core.h
> @@ -26,15 +26,15 @@
>  #ifndef WAYLAND_SERVER_CORE_H
>  #define WAYLAND_SERVER_CORE_H
>  
> -#ifdef  __cplusplus
> -extern "C" {
> -#endif
> -
>  #include 
>  #include 
>  #include "wayland-util.h"
>  #include "wayland-version.h"
>  
> +#ifdef  __cplusplus
> +extern "C" {
> +#endif
> +
>  enum {
>   WL_EVENT_READABLE = 0x01,
>   WL_EVENT_WRITABLE = 0x02,
> 

Shouldn't the extern declaration be moved to surround only the functions
declarations (and so not including type defines) ?
That's just a question, if a C++ specialist have an answer...

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] input: Implement wl_seat.release

[Hardening]

Le 13/03/2016 17:49, Quentin Glidic a écrit :
> From: Quentin Glidic 
> 
> Avoid a crash because listener is NULL.
> 
> Signed-off-by: Quentin Glidic 
> ---
>  src/input.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/input.c b/src/input.c
> index 8c106dd..5d13b08 100644
> --- a/src/input.c
> +++ b/src/input.c
> @@ -2230,10 +2230,17 @@ seat_get_touch(struct wl_client *client, struct 
> wl_resource *resource,
>  seat, unbind_resource);
>  }
>  
> +static void
> +seat_release(struct wl_client *client, struct wl_resource *resource)
> +{
> + wl_resource_destroy(resource);
> +}
> +
>  static const struct wl_seat_interface seat_interface = {
>   seat_get_pointer,
>   seat_get_keyboard,
>   seat_get_touch,
> + seat_release,
>  };
>  
>  static void
> 
Reviewed-By: David Fort 

Definitely my fault, strange that we have not seen this before (I can't
imagine that seats were never released ;) ).

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH wayland] scanner: Print filename on DTD validation error

[Hardening]

Le 25/01/2016 10:28, Jonas Ådahl a écrit :
> Don't just print prefix the errors with "protocol", but the actual file
> name, if wayland-scanner was passed with the filename of the protocol
> file. If wayland-scanner is reading from stdin, errors will be prefixed
> with "" instead of "protocol".
> 
> Signed-off-by: Jonas Ådahl 
> ---
>  src/scanner.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)

Reviewed-by: David Fort 

> 
> diff --git a/src/scanner.c b/src/scanner.c
> index 1d626f4..dda5473 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -71,7 +71,7 @@ usage(int ret)
>  }
>  
>  static bool
> -is_dtd_valid(FILE *input)
> +is_dtd_valid(FILE *input, const char *filename)
>  {
>   bool rc = true;
>  #if HAVE_LIBXML
> @@ -101,7 +101,7 @@ is_dtd_valid(FILE *input)
>   abort();
>   }
>  
> - doc = xmlCtxtReadFd(ctx, fd, "protocol", NULL, 0);
> + doc = xmlCtxtReadFd(ctx, fd, filename, NULL, 0);
>   if (!doc) {
>   fprintf(stderr, "Failed to read XML\n");
>   abort();
> @@ -1623,6 +1623,7 @@ int main(int argc, char *argv[])
>   struct parse_context ctx;
>   struct protocol protocol;
>   FILE *input = stdin;
> + char *input_filename = NULL;
>   int len;
>   void *buf;
>   bool help = false, core_headers = false;
> @@ -1678,7 +1679,8 @@ int main(int argc, char *argv[])
>   usage(EXIT_FAILURE);
>  
>   if (argc == 3) {
> - input = fopen(argv[1], "r");
> + input_filename = argv[1];
> + input = fopen(input_filename, "r");
>   if (input == NULL) {
>   fprintf(stderr, "Could not open input file: %s\n",
>   strerror(errno));
> @@ -1700,9 +1702,12 @@ int main(int argc, char *argv[])
>   /* initialize context */
>   memset(&ctx, 0, sizeof ctx);
>   ctx.protocol = &protocol;
> - ctx.loc.filename = "";
> + if (input == stdin)
> + ctx.loc.filename = "";
> + else
> + ctx.loc.filename = input_filename;
>  
> - if (!is_dtd_valid(input)) {
> + if (!is_dtd_valid(input, ctx.loc.filename)) {
>   fprintf(stderr,
>   "***\n"
>   "* *\n"
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

wayalnd client wants to know the keyboard layout

[Hardening]

Hello,

I have worked on having the FreeRDP client have a decent wayland
support. On the graphical part everything is quite straight forward
anyway, I'm hitting some troubles with keyboard support (someone could
say as usual when you code something around keyboard).

In X11, xfreerdp queries X about the keyboard layout using XI. That
allows to announce a RDP keyboard layout to the remote server (using a
map table between xkb files and RDP layout) and get the correct virtual
RDP keycode.

But in wayland, I only get the mmaped xkb file, I can't see a robust and
easy way to discover to which xkb file it corresponds. If someone has an
idea...

Best regards.

PS: I guess I will not be the only one to have the problem, yes VNC I'm
talking of you ;)
-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH] clients: Fix compositor version check for WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION

[Hardening]

Le 20/12/2015 13:41, Chris Michael a écrit :
> Signed-off-by: Chris Michael 
> ---
>  clients/simple-damage.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/clients/simple-damage.c b/clients/simple-damage.c
> index 37a81f5..24c67cc 100644
> --- a/clients/simple-damage.c
> +++ b/clients/simple-damage.c
> @@ -262,7 +262,8 @@ create_window(struct display *display, int width, int 
> height,
>   exit(1);
>   }
>  
> - if (display->compositor_version < 4 &&
> + if (display->compositor_version <
> +WL_SURFACE_DAMAGE_BUFFER_SINCE_VERSION &&
>   (flags & WINDOW_FLAG_USE_DAMAGE_BUFFER)) {
>   fprintf(stderr, "wl_surface.damage_buffer unsupported in "
>   "wl_surface version %d\n",
> 
Reviewed-By: David Fort 

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH v4] xwm: let the shells decide the position of X windows

[Hardening]

Le 11/12/2015 19:57, Giulio Camuffo a écrit :
> The xwm used to automatically send to Xwayland the position of X windows
> when that changed, using the x,y of the primary view of the surface.
> This works fine for the desktop shell but less so for others.
> This patch adds a 'send_position' vfunc to the weston_shell_client that
> the shell will call when it wants to let Xwayland know what the position
> of a window is.
> The logic used by the desktop-shell for that is exactly the same the xwm
> used to have.
> Reviewed-by: Derek Foreman 
> ---
> v4: changed pos_dirty to bool instead of int
> 
>  desktop-shell/shell.c | 40 +++---
>  desktop-shell/shell.h |  1 +
>  src/compositor.h  |  4 +--
>  xwayland/window-manager.c | 72 
> +--
>  xwayland/xwayland.h   |  1 -
>  5 files changed, 64 insertions(+), 54 deletions(-)
> 
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index 780902d..85664c6 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -1813,7 +1813,8 @@ send_configure(struct weston_surface *surface, int32_t 
> width, int32_t height)
>  }
>  
>  static const struct weston_shell_client shell_client = {
> - send_configure
> + send_configure,
> + NULL
>  };
>  
>  static void
> @@ -3704,12 +3705,6 @@ create_shell_surface(void *shell, struct 
> weston_surface *surface,
>   return create_common_surface(NULL, shell, surface, client);
>  }
>  
> -static struct weston_view *
> -get_primary_view(void *shell, struct shell_surface *shsurf)
> -{
> - return shsurf->view;
> -}
> -
>  static void
>  shell_get_shell_surface(struct wl_client *client,
>   struct wl_resource *resource,
> @@ -3995,7 +3990,8 @@ xdg_send_configure(struct weston_surface *surface,
>  }
>  
>  static const struct weston_shell_client xdg_client = {
> - xdg_send_configure
> + xdg_send_configure,
> + NULL
>  };
>  
>  static void
> @@ -4119,7 +4115,8 @@ xdg_popup_send_configure(struct weston_surface *surface,
>  }
>  
>  static const struct weston_shell_client xdg_popup_client = {
> - xdg_popup_send_configure
> + xdg_popup_send_configure,
> + NULL
>  };
>  
>  static struct shell_surface *
> @@ -5412,6 +5409,27 @@ wake_handler(struct wl_listener *listener, void *data)
>  }
>  
>  static void
> +transform_handler(struct wl_listener *listener, void *data)
> +{
> + struct weston_surface *surface = data;
> + struct shell_surface *shsurf = get_shell_surface(surface);
> + struct weston_view *view;;
> + int x, y;
> +
> + if (!shsurf || !shsurf->client->send_position)
> + return;
> +
> + view = shsurf->view;
> + if (!view || !weston_view_is_mapped(view))
> + return;
> +
> + x = view->geometry.x;
> + y = view->geometry.y;
> +
> + shsurf->client->send_position(surface, x, y);
> +}
> +
> +static void
>  center_on_output(struct weston_view *view, struct weston_output *output)
>  {
>   int32_t surf_x, surf_y, width, height;
> @@ -6379,6 +6397,7 @@ shell_destroy(struct wl_listener *listener, void *data)
>  
>   wl_list_remove(&shell->idle_listener.link);
>   wl_list_remove(&shell->wake_listener.link);
> + wl_list_remove(&shell->transform_listener.link);
>  
>   text_backend_destroy(shell->text_backend);
>   input_panel_destroy(shell);
> @@ -6520,10 +6539,11 @@ module_init(struct weston_compositor *ec,
>   wl_signal_add(&ec->idle_signal, &shell->idle_listener);
>   shell->wake_listener.notify = wake_handler;
>   wl_signal_add(&ec->wake_signal, &shell->wake_listener);
> + shell->transform_listener.notify = transform_handler;
> + wl_signal_add(&ec->transform_signal, &shell->transform_listener);
>  
>   ec->shell_interface.shell = shell;
>   ec->shell_interface.create_shell_surface = create_shell_surface;
> - ec->shell_interface.get_primary_view = get_primary_view;
>   ec->shell_interface.set_toplevel = set_toplevel;
>   ec->shell_interface.set_transient = set_transient;
>   ec->shell_interface.set_fullscreen = shell_interface_set_fullscreen;
> diff --git a/desktop-shell/shell.h b/desktop-shell/shell.h
> index 2ef23f4..c55a225 100644
> --- a/desktop-shell/shell.h
> +++ b/desktop-shell/shell.h
> @@ -121,6 +121,7 @@ struct desktop_shell {
>  
>   struct wl_listener idle_listener;
>   struct wl_listener wake_listener;
> + struct wl_listener transform_listener;
>   struct wl_listener destroy_listener;
>   struct wl_listener show_input_panel_listener;
>   struct wl_listener hide_input_panel_listener;
> diff --git a/src/compositor.h b/src/compositor.h
> index 8a5aa91..a427088 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -86,6 +86,7 @@ struct weston_mode {
>  
>  struct weston_shell_client {
>   void (*send_configure)(struct weston_surface *surface, int32_t width, 
> int32_t height);
> + void (*send_position)(struct

Re: [PATCH weston] compositor-fbdev: Drop intermediate shadow buffer

[Hardening]

Le 05/12/2015 02:20, Derek Foreman a écrit :
> From: Sjoerd Simons 
> 
> Currently the fbdev compositor has its own shadow buffer when rendering
> with pixman, causing the following copies to occur:
> 
> [pixman shadow buffer] -> [fbdev shadow buffer] -> [fbdev hardware]
> 
> As the pixman render already does all output translation when
> compositing the intermediate shadow buffer really isn't needed, so drop
> it.
> 
> As a side-effect this fixes updating the fbdev hardware for outputs not
> starting at 0x0.
> 
> Signed-off-by: Sjoerd Simons 
> ---
> 

Reviewed-by David FORT 

I haven't test it either.


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: Process for implementing a double buffer on Wayland

[Hardening]

Le 25/11/2015 17:18, Daniel Stone a écrit :
> Hi Mike,
> 
> On 25 November 2015 at 16:06, Mike Johnson  wrote:
>> I've created 2 buffers of the same size (800x600 pixels).  So I want the
>> input buffer to get filled off-screen, while the output buffer will show the
>> content on-screen.
>>
>> First of all what sort of content could be used to illustrate this
>> technique, and secondly, what mechanisms are available to:
>>
>> a) Notify that the input buffer is full
>> b) Copy the content to the output buffer so that it shows on-screen
> 
> It's quite simple. wl_surface_attach(surf, buf) +
> wl_surface_commit(surf) will display 'buf' for that surface. At that
> point, the compositor owns that buffer, so you should stop drawing on
> it. When the compositor has finished with a buffer, it will send you a
> wl_buffer.release event. You can sync your paint clock to the
> compositor's repaint loop with wl_surface_frame.
> 
> So, the normal workflow is:
>   - create surface S, buffer A, buffer B
>   - draw first frame into buffer A
>   - call wl_surface_frame(S) + wl_surface_attach(S, A) +
> wl_surface_commit(S) + wl_display_flush()
>   - go to sleep
>   - receive completion for wl_surface_frame callback
>   - draw second frame into buffer B
>   - call wl_surface_frame(S) + wl_surface_attach(S, B) +
> wl_surface_commit(S) + wl_display_flush()
>   - compositor now owns both buffers, so don't touch any
>   - receive wl_buffer.release event for buffer A - now unused
>   - receive completion for wl_surface_frame callback
>   - draw third frame into buffer A
>   - ...
> 

I may be wrong, but there's no guaranty that the compositor sends
wl_buffer.release event on buffer A. I think I have experimented this
when the renderer in weston is the pixman renderer.
IIRC I have been told on IRC that the compositor decides when the buffer
is not used, so you may not receive the release message immediately. I
have hit that kind of bug when coding libUWAC.

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston 03/10] Use presentation timing protocol from wayland-protocols

[Hardening]

Le 04/11/2015 09:49, Jonas Ådahl a écrit :
> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am  |  21 ++-
>  clients/presentation-shm.c   |  65 +-
>  clients/weston-info.c|  19 +--
>  protocol/presentation_timing.xml | 274 
> ---
>  src/compositor-drm.c |  14 +-
>  src/compositor-fbdev.c   |   2 +-
>  src/compositor-headless.c|   2 +-
>  src/compositor-rpi.c |   6 +-
>  src/compositor-wayland.c |   2 +-
>  src/compositor-x11.c |   2 +-
>  src/compositor.c |  29 +++--
>  tests/presentation-test.c|  34 ++---
>  12 files changed, 101 insertions(+), 369 deletions(-)
>  delete mode 100644 protocol/presentation_timing.xml
> 

As stated on IRC, in fact no changes are needed for the RDP compositor.
Sorry for the noise.


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston 03/10] Use presentation timing protocol from wayland-protocols

[Hardening]

Le 04/11/2015 09:49, Jonas Ådahl a écrit :
> Signed-off-by: Jonas Ådahl 
> ---
>  Makefile.am  |  21 ++-
>  clients/presentation-shm.c   |  65 +-
>  clients/weston-info.c|  19 +--
>  protocol/presentation_timing.xml | 274 
> ---
>  src/compositor-drm.c |  14 +-
>  src/compositor-fbdev.c   |   2 +-
>  src/compositor-headless.c|   2 +-
>  src/compositor-rpi.c |   6 +-
>  src/compositor-wayland.c |   2 +-
>  src/compositor-x11.c |   2 +-
>  src/compositor.c |  29 +++--
>  tests/presentation-test.c|  34 ++---
>  12 files changed, 101 insertions(+), 369 deletions(-)
>  delete mode 100644 protocol/presentation_timing.xml
> 

The RDP compositor is not treated by this patch.


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH] weston: implement inert objects for keyboard/pointer/touch

[Hardening]

Le 20/10/2015 17:12, Bryce Harrington a écrit :
> On Tue, Oct 20, 2015 at 10:39:51AM +0200, Hardening wrote:
>> Le 20/10/2015 10:24, Bryce Harrington a écrit :
>>> On Mon, Oct 19, 2015 at 03:47:19PM +0200, David FORT wrote:
>>>> This patch implements inert objects for wl_keyboard, wl_pointer and 
>>>> wl_touch.
>>>> The target case is when the server has just send a capability event about a
>>>> disappearing object, and the client binds the corresponding object. We 
>>>> bind an
>>>> inert object: an object does nothing when it is requested. If the client 
>>>> behave
>>>> correctly, this object should be released when the capability event is 
>>>> received
>>>> and treated (calling the corresponding release request).
>>>> As a consequence, we can rely on seat->[keyboard|pointer|touch]_state to 
>>>> know
>>>> if the seat has the corresponding object.
>>>
>>> This is a big patch but it looks like the vast bulk is merely adding in
>>> pointer checks for keyboard, pointer, etc. everywhere and subsequent
>>> retabbing.  If you broke that refactoring step out as a preliminary
>>> patch, it may make reviewing the pertinent changes (i.e. tracking and
>>> checking state for the input devices rather than just testing the
>>> reference count) a bit easier.
>>
>> I'm not sure to understand, what should I do then ?
> 
> Create two patches, the first of which just adds all the "if
> (keyboard)..." checks, and the second (much smaller) patch which adds
> the inert_pointer_interface, inert_keyboard_interface, etc. parts which
> are what you actually need the review on.  The pointer checking is
> obviously a safe refactoring that can be landed with minimal review.
> 

Well I can do this way but the 2 patches are linked. In the current
code, once a keyboard has been created, you can't have a null
seat->keyboard_state. So in the current situation, I'm not sure the
checks are really needed .

>>> Thanks for tending to the test code too in the refactor; it would be
>>> grand to see a test case added to keyboard-test or devices-test to
>>> exercise the case of handling inert input objects.
>>>
>>
>> Such a test is already there in the existing tests. In
>> get_device_after_destroy of devices-test.c, we already exercise inert
>> objects.
> 
> Apparently it is not exercised sufficiently, because it passes already
> without your fix.
> 

Well you're right: in the current code input objects are never released,
so the calls are done on used objects without any visible side effect.
In fact, there's a side effect when calling wl_pointer.set_cursor on a
released pointer: the surface is given the mouse pointer role. Using
inert objects, you're just sure that there will be no side effect at
all. As I said It think it's also the first step to make it possible to
safely release the full seat.

> But you're right that this test case looks like a good place for you to
> add more coverage for this bug.  Does the current test pass without your
> fix because it is not making deep enough wayland calls?  I.e. does it
> need to do more than merely a wl_pointer_set_cursor call?
> 
> Also, it appears this test isn't doing the same checking for keyboard
> and touch as it does for pointer; even though internally all three are
> implemented the same way, there are three different protocol routines
> involved here (wl_seat_get_pointer, wl_seat_get_keyboard, and
> wl_seat_get_touch), any of which could present their own bugs, so proper
> test coverage should methodically check all three.
> 

+1 for testing all input objects.

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH] weston: implement inert objects for keyboard/pointer/touch

[Hardening]

Le 20/10/2015 10:24, Bryce Harrington a écrit :
> On Mon, Oct 19, 2015 at 03:47:19PM +0200, David FORT wrote:
>> This patch implements inert objects for wl_keyboard, wl_pointer and wl_touch.
>> The target case is when the server has just send a capability event about a
>> disappearing object, and the client binds the corresponding object. We bind 
>> an
>> inert object: an object does nothing when it is requested. If the client 
>> behave
>> correctly, this object should be released when the capability event is 
>> received
>> and treated (calling the corresponding release request).
>> As a consequence, we can rely on seat->[keyboard|pointer|touch]_state to know
>> if the seat has the corresponding object.
> 
> This is a big patch but it looks like the vast bulk is merely adding in
> pointer checks for keyboard, pointer, etc. everywhere and subsequent
> retabbing.  If you broke that refactoring step out as a preliminary
> patch, it may make reviewing the pertinent changes (i.e. tracking and
> checking state for the input devices rather than just testing the
> reference count) a bit easier.

I'm not sure to understand, what should I do then ?

> 
> Thanks for tending to the test code too in the refactor; it would be
> grand to see a test case added to keyboard-test or devices-test to
> exercise the case of handling inert input objects.
> 

Such a test is already there in the existing tests. In
get_device_after_destroy of devices-test.c, we already exercise inert
objects.

Best regards

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [RFC] weston: implement inert objects for keyboard/pointer/touch

[Hardening]

Le 16/10/2015 11:53, David FORT a écrit :
> This patch implements inert objects for wl_keyboard, wl_pointer and wl_touch.
> The target case is when the server has just send a capability event about a
> disappearing object, and the client binds the corresponding object. We bind an
> inert object: an object does nothing when it is requested. If the client 
> behave
> correctly, this object should be released when the capability event is 
> received
> and treated (calling the corresponding release request).
> As a consequence, we can rely on seat->[keyboard|pointer|touch]_state to know
> if the seat has the corresponding object.
> Weston doesn't really handle multiple mice for one wl_pointer, so I have 
> removed
> the corresponding code and tests (it was quite a weston_test hack BTW).
> Finally I have fixed a wrong behaviour: the capabilities event's 
> documentation states
> that the capabilities should be sent when a new capability is set on the 
> seat. So
> attaching a second mouse to an existing wl_pointer should not broadcast seat
> capabilities (and the same for keyboard and touch).
> ---
>  desktop-shell/exposay.c  |  16 ++--
>  desktop-shell/shell.c|  21 +++--
>  src/compositor-wayland.c |  10 +-
>  src/compositor-x11.c |  12 ++-
>  src/compositor.h |   3 -
>  src/input.c  | 235 
> ++-
>  src/libinput-device.c|   2 +-
>  src/screen-share.c   |   2 +
>  src/text-backend.c   |  44 +
>  src/zoom.c   |   7 +-
>  tests/devices-test.c |  20 
>  tests/weston-test.c  |  18 ++--
>  xwayland/dnd.c   |   3 +-
>  13 files changed, 216 insertions(+), 177 deletions(-)
> 
> diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
> index 08b86a3..d6919b3 100644
> --- a/desktop-shell/exposay.c
> +++ b/desktop-shell/exposay.c
> @@ -574,21 +574,23 @@ exposay_transition_active(struct desktop_shell *shell)
>   bool animate = false;
>  
>   shell->exposay.workspace = get_current_workspace(shell);
> - shell->exposay.focus_prev = get_default_view(keyboard->focus);
> - shell->exposay.focus_current = get_default_view(keyboard->focus);
> + if (keyboard) {
> + shell->exposay.focus_prev = get_default_view(keyboard->focus);
> + shell->exposay.focus_current = 
> get_default_view(keyboard->focus);
> + }
>   shell->exposay.clicked = NULL;
>   wl_list_init(&shell->exposay.surface_list);
>  
>   lower_fullscreen_layer(shell, NULL);
>   shell->exposay.grab_kbd.interface = &exposay_kbd_grab;
> - weston_keyboard_start_grab(keyboard,
> -&shell->exposay.grab_kbd);
> - weston_keyboard_set_focus(keyboard, NULL);
> + if (keyboard) {
> + weston_keyboard_start_grab(keyboard, &shell->exposay.grab_kbd);
> + weston_keyboard_set_focus(keyboard, NULL);
> + }
>  
>   shell->exposay.grab_ptr.interface = &exposay_ptr_grab;
>   if (pointer) {
> - weston_pointer_start_grab(pointer,
> -   &shell->exposay.grab_ptr);
> + weston_pointer_start_grab(pointer, &shell->exposay.grab_ptr);
>   weston_pointer_clear_focus(pointer);
>   }
>   wl_list_for_each(shell_output, &shell->output_list, link) {
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index 3eb3f5c..cdddf09 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -380,7 +380,8 @@ shell_grab_start(struct shell_grab *grab,
>   struct desktop_shell *shell = shsurf->shell;
>   struct weston_touch *touch = weston_seat_get_touch(pointer->seat);
>  
> - popup_grab_end(pointer);
> + if (pointer)
> + popup_grab_end(pointer);
>   if (touch)
>   touch_popup_grab_end(touch);
>  
> @@ -391,11 +392,13 @@ shell_grab_start(struct shell_grab *grab,
> &grab->shsurf_destroy_listener);
>  
>   shsurf->grabbed = 1;
> - weston_pointer_start_grab(pointer, &grab->grab);
> + if (pointer)
> + weston_pointer_start_grab(pointer, &grab->grab);
>   if (shell->child.desktop_shell) {
>   desktop_shell_send_grab_cursor(shell->child.desktop_shell,
>  cursor);
> - weston_pointer_set_focus(pointer,
> + if (pointer)
> + weston_pointer_set_focus(pointer,
>get_default_view(shell->grab_surface),
>wl_fixed_from_int(0),
>wl_fixed_from_int(0));
> @@ -925,12 +928,10 @@ restore_focus_state(struct desktop_shell *shell, struct 
> workspace *ws)
>   wl_list_insert(&shell->compositor->seat_list,
>  &state->seat->link);
>  
> - if (!keyboard)
> - continue;
> -
>   surface = state->keybo

Re: [RFC] weston: implement inert objects for keyboard/pointer/touch

[Hardening]

Le 16/10/2015 11:53, David FORT a écrit :
> This patch implements inert objects for wl_keyboard, wl_pointer and wl_touch.
> The target case is when the server has just send a capability event about a
> disappearing object, and the client binds the corresponding object. We bind an
> inert object: an object does nothing when it is requested. If the client 
> behave
> correctly, this object should be released when the capability event is 
> received
> and treated (calling the corresponding release request).
> As a consequence, we can rely on seat->[keyboard|pointer|touch]_state to know
> if the seat has the corresponding object.
> Weston doesn't really handle multiple mice for one wl_pointer, so I have 
> removed
> the corresponding code and tests (it was quite a weston_test hack BTW).
> Finally I have fixed a wrong behaviour: the capabilities event's 
> documentation states
> that the capabilities should be sent when a new capability is set on the 
> seat. So
> attaching a second mouse to an existing wl_pointer should not broadcast seat
> capabilities (and the same for keyboard and touch).
> ---
>  desktop-shell/exposay.c  |  16 ++--
>  desktop-shell/shell.c|  21 +++--
>  src/compositor-wayland.c |  10 +-
>  src/compositor-x11.c |  12 ++-
>  src/compositor.h |   3 -
>  src/input.c  | 235 
> ++-
>  src/libinput-device.c|   2 +-
>  src/screen-share.c   |   2 +
>  src/text-backend.c   |  44 +
>  src/zoom.c   |   7 +-
>  tests/devices-test.c |  20 
>  tests/weston-test.c  |  18 ++--
>  xwayland/dnd.c   |   3 +-
>  13 files changed, 216 insertions(+), 177 deletions(-)
> 
> diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
> index 08b86a3..d6919b3 100644
> --- a/desktop-shell/exposay.c
> +++ b/desktop-shell/exposay.c
> @@ -574,21 +574,23 @@ exposay_transition_active(struct desktop_shell *shell)
>   bool animate = false;
>  
>   shell->exposay.workspace = get_current_workspace(shell);
> - shell->exposay.focus_prev = get_default_view(keyboard->focus);
> - shell->exposay.focus_current = get_default_view(keyboard->focus);
> + if (keyboard) {
> + shell->exposay.focus_prev = get_default_view(keyboard->focus);
> + shell->exposay.focus_current = 
> get_default_view(keyboard->focus);
> + }
>   shell->exposay.clicked = NULL;
>   wl_list_init(&shell->exposay.surface_list);
>  
>   lower_fullscreen_layer(shell, NULL);
>   shell->exposay.grab_kbd.interface = &exposay_kbd_grab;
> - weston_keyboard_start_grab(keyboard,
> -&shell->exposay.grab_kbd);
> - weston_keyboard_set_focus(keyboard, NULL);
> + if (keyboard) {
> + weston_keyboard_start_grab(keyboard, &shell->exposay.grab_kbd);
> + weston_keyboard_set_focus(keyboard, NULL);
> + }
>  
>   shell->exposay.grab_ptr.interface = &exposay_ptr_grab;
>   if (pointer) {
> - weston_pointer_start_grab(pointer,
> -   &shell->exposay.grab_ptr);
> + weston_pointer_start_grab(pointer, &shell->exposay.grab_ptr);
>   weston_pointer_clear_focus(pointer);
>   }
>   wl_list_for_each(shell_output, &shell->output_list, link) {
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index 3eb3f5c..cdddf09 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -380,7 +380,8 @@ shell_grab_start(struct shell_grab *grab,
>   struct desktop_shell *shell = shsurf->shell;
>   struct weston_touch *touch = weston_seat_get_touch(pointer->seat);
>  
> - popup_grab_end(pointer);
> + if (pointer)
> + popup_grab_end(pointer);
>   if (touch)
>   touch_popup_grab_end(touch);
>  
> @@ -391,11 +392,13 @@ shell_grab_start(struct shell_grab *grab,
> &grab->shsurf_destroy_listener);
>  
>   shsurf->grabbed = 1;
> - weston_pointer_start_grab(pointer, &grab->grab);
> + if (pointer)
> + weston_pointer_start_grab(pointer, &grab->grab);
>   if (shell->child.desktop_shell) {
>   desktop_shell_send_grab_cursor(shell->child.desktop_shell,
>  cursor);
> - weston_pointer_set_focus(pointer,
> + if (pointer)
> + weston_pointer_set_focus(pointer,
>get_default_view(shell->grab_surface),
>wl_fixed_from_int(0),
>wl_fixed_from_int(0));
> @@ -925,12 +928,10 @@ restore_focus_state(struct desktop_shell *shell, struct 
> workspace *ws)
>   wl_list_insert(&shell->compositor->seat_list,
>  &state->seat->link);
>  
> - if (!keyboard)
> - continue;
> -
>   surface = state->keybo

Re: [weston] xkbcommon library is not optional.

[Hardening]

Le 16/10/2015 10:34, Joaquim Duran a écrit :
> Disable xkbcommon library could be useful in devices based on
> touchscreen, like smartphones, but if you have USB connectors, you
> could connect an external keyboard. if xkbcommon is a small library,
> just change the documentation.
> 
> Joaquim Duran
> 


Don't get me wrong, I'm not saying it's not useful. I'm saying that
probably nobody's using it as otherwise it doesn't compile.


> 2015-10-16 10:27 GMT+02:00 Hardening :
>> Le 16/10/2015 03:28, Bryce Harrington a écrit :
>>> On Tue, Oct 13, 2015 at 01:59:13PM +0200, Joaquim Duran wrote:
>>>> Hello,
>>>>
>>>> When configuring the Weston project, it is possible to disable (don't
>>>> include) the library libxkbcommon. To compile Weston successfully,
>>>> even if the option --disable-xkbcommon is specified, the library must
>>>> be installed because the file src/compositor.h requires it.
>>>
>>> Joaquim, good find.
>>>
>>> From the comments in configure.ac:
>>>
>>>   AS_HELP_STRING([--disable-xkbcommon], [Disable libxkbcommon
>>>   support: This is only useful in environments
>>>   where you do not have a hardware keyboard. If
>>>   libxkbcommon support is disabled clients will not
>>>   be sent a keymap and and must know how to
>>>   interpret the keycode sent for any key event.]),,
>>>
>>> So it sounds like this is a special case that is intended to work.
>>>
>>> The header include was from commit 855028fe three years ago, while the
>>> --disable-xkbcommon was added by 382ff46f just two years ago.  That
>>> makes me think that your situation was simply overlooked.
>>>
>>> If that's true, then presumably the fix would involve peppering
>>> compositor.* and other files with tests like,
>>>
>>> #ifdef ENABLE_XKBCOMMON
>>> ...
>>> #endif
>>>
>>> For example it looks like the weston_xkb_info struct would need to
>>> either be removed or stubbed out, and users of it be disabled.  There
>>> are also some weston calls that use xkb_keymap, xkb_rule_names,
>>> etc. structures for params that'd need addressed.
>>>
>>> On the face of it, seems like it could be a fair amount of work, and a
>>> bit invasive, but maybe there's some tricks to make it simpler
>>> (typedeffing the unsupported struct args and so on.)
>>>
>>> Alternatively, --disable-xkbcommon could be dropped.  However I get the
>>> sense it actually solves a real world need, and functional regression is
>>> rarely a good idea.
>>>
>>
>> I'm to fix the bug. Anyway it's almost sure that there's no real usage
>> of this flag as otherwise weston does not compile...
>>
>> Best regards
>>
>>
>> --
>> David FORT
>> website: http://www.hardening-consulting.com/
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [weston] xkbcommon library is not optional.

[Hardening]

Le 16/10/2015 03:28, Bryce Harrington a écrit :
> On Tue, Oct 13, 2015 at 01:59:13PM +0200, Joaquim Duran wrote:
>> Hello,
>>
>> When configuring the Weston project, it is possible to disable (don't
>> include) the library libxkbcommon. To compile Weston successfully,
>> even if the option --disable-xkbcommon is specified, the library must
>> be installed because the file src/compositor.h requires it.
> 
> Joaquim, good find.
> 
> From the comments in configure.ac:
> 
>   AS_HELP_STRING([--disable-xkbcommon], [Disable libxkbcommon
>   support: This is only useful in environments
>   where you do not have a hardware keyboard. If
>   libxkbcommon support is disabled clients will not
>   be sent a keymap and and must know how to
>   interpret the keycode sent for any key event.]),,
> 
> So it sounds like this is a special case that is intended to work.
> 
> The header include was from commit 855028fe three years ago, while the
> --disable-xkbcommon was added by 382ff46f just two years ago.  That
> makes me think that your situation was simply overlooked.
> 
> If that's true, then presumably the fix would involve peppering
> compositor.* and other files with tests like,
> 
> #ifdef ENABLE_XKBCOMMON
> ...
> #endif
> 
> For example it looks like the weston_xkb_info struct would need to
> either be removed or stubbed out, and users of it be disabled.  There
> are also some weston calls that use xkb_keymap, xkb_rule_names,
> etc. structures for params that'd need addressed.
> 
> On the face of it, seems like it could be a fair amount of work, and a
> bit invasive, but maybe there's some tricks to make it simpler
> (typedeffing the unsupported struct args and so on.)
> 
> Alternatively, --disable-xkbcommon could be dropped.  However I get the
> sense it actually solves a real world need, and functional regression is
> rarely a good idea.
> 

I'm to fix the bug. Anyway it's almost sure that there's no real usage
of this flag as otherwise weston does not compile...

Best regards


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] clients: track seat_version per seat, not per display

[Hardening]

Le 14/10/2015 16:39, Derek Foreman a écrit :
> Apparently it's possible for a compositor to advertise seats with
> different versions on the same connection, so this makes us more robust
> against that dubious behaviour.
> 
> This also tracks the seat version we requested instead of the advertised
> maximum.
> 
> Signed-off-by: Derek Foreman 
> ---
> 
> As penance for my sass, I've gone ahead and "fixed" this - I think
> tracking the version we requested instead of the one advertised is
> more robust against catching a failure to increment the requested
> version though. However, it does seem like the correct thing to do.
> 
>  clients/window.c | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/clients/window.c b/clients/window.c
> index 6d3e944..d8f2ee2 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -140,7 +140,6 @@ struct display {
>   void *dummy_surface_data;
>  
>   int has_rgb565;
> - int seat_version;
>   int data_device_manager_version;
>  };
>  
> @@ -362,6 +361,7 @@ struct input {
>   uint32_t repeat_sym;
>   uint32_t repeat_key;
>   uint32_t repeat_time;
> + int seat_version;
>  };
>  
>  struct output {
> @@ -3256,7 +3256,7 @@ seat_handle_capabilities(void *data, struct wl_seat 
> *seat,
>   wl_pointer_add_listener(input->pointer, &pointer_listener,
>   input);
>   } else if (!(caps & WL_SEAT_CAPABILITY_POINTER) && input->pointer) {
> - if (input->display->seat_version >= 
> WL_POINTER_RELEASE_SINCE_VERSION)
> + if (input->seat_version >= WL_POINTER_RELEASE_SINCE_VERSION)
>   wl_pointer_release(input->pointer);
>   else
>   wl_pointer_destroy(input->pointer);
> @@ -3269,7 +3269,7 @@ seat_handle_capabilities(void *data, struct wl_seat 
> *seat,
>   wl_keyboard_add_listener(input->keyboard, &keyboard_listener,
>input);
>   } else if (!(caps & WL_SEAT_CAPABILITY_KEYBOARD) && input->keyboard) {
> - if (input->display->seat_version >= 
> WL_KEYBOARD_RELEASE_SINCE_VERSION)
> + if (input->seat_version >= WL_KEYBOARD_RELEASE_SINCE_VERSION)
>   wl_keyboard_release(input->keyboard);
>   else
>   wl_keyboard_destroy(input->keyboard);
> @@ -3281,7 +3281,7 @@ seat_handle_capabilities(void *data, struct wl_seat 
> *seat,
>   wl_touch_set_user_data(input->touch, input);
>   wl_touch_add_listener(input->touch, &touch_listener, input);
>   } else if (!(caps & WL_SEAT_CAPABILITY_TOUCH) && input->touch) {
> - if (input->display->seat_version >= 
> WL_TOUCH_RELEASE_SINCE_VERSION)
> + if (input->seat_version >= WL_TOUCH_RELEASE_SINCE_VERSION)
>   wl_touch_release(input->touch);
>   else
>   wl_touch_destroy(input->touch);
> @@ -5218,17 +5218,20 @@ fini_xkb(struct input *input)
>  }
>  
>  static void
> -display_add_input(struct display *d, uint32_t id)
> +display_add_input(struct display *d, uint32_t id, int display_seat_version)
>  {
>   struct input *input;
> + int seat_version = MIN(display_seat_version, 4);
>  
>   input = xzalloc(sizeof *input);
>   input->display = d;
>   input->seat = wl_registry_bind(d->registry, id, &wl_seat_interface,
> -MIN(d->seat_version, 4));
> +seat_version);
>   input->touch_focus = NULL;
>   input->pointer_focus = NULL;
>   input->keyboard_focus = NULL;
> + input->seat_version = seat_version;
> +
>   wl_list_init(&input->touch_point_list);
>   wl_list_insert(d->input_list.prev, &input->link);
>  
> @@ -5278,7 +5281,7 @@ input_destroy(struct input *input)
>   else
>   wl_data_device_destroy(input->data_device);
>   }
> - if (input->display->seat_version >= WL_POINTER_RELEASE_SINCE_VERSION) {
> + if (input->seat_version >= WL_POINTER_RELEASE_SINCE_VERSION) {
>   if (input->touch)
>   wl_touch_release(input->touch);
>   if (input->pointer)
> @@ -5365,8 +5368,7 @@ registry_handle_global(void *data, struct wl_registry 
> *registry, uint32_t id,
>   } else if (strcmp(interface, "wl_output") == 0) {
>   display_add_output(d, id);
>   } else if (strcmp(interface, "wl_seat") == 0) {
> - d->seat_version = version;
> - display_add_input(d, id);
> + display_add_input(d, id, version);
>   } else if (strcmp(interface, "wl_shm") == 0) {
>   d->shm = wl_registry_bind(registry, id, &wl_shm_interface, 1);
>   wl_shm_add_listener(d->shm, &shm_listener, d);
> 

I had noticed that too, I can't see in which situation this could
happen, perhaps a subcompositor advertising it

Re: [PATCH] weston: release keyboard/touch/pointer objects

[Hardening]

Le 08/10/2015 05:14, Jonas Ådahl a écrit :
> On Tue, Oct 06, 2015 at 10:59:32AM +0200, David FORT wrote:
>> This patch adds the missing calls to release when the seat has capabilities
>> changes. It also fixes a missing release of the touch object.
>> ---
>>  clients/window.c | 23 +++
>>  1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/clients/window.c b/clients/window.c
>> index 47a79aa..7469259 100644
>> --- a/clients/window.c
>> +++ b/clients/window.c
>> @@ -79,6 +79,10 @@ typedef void *EGLContext;
>>  #include "ivi-application-client-protocol.h"
>>  #define IVI_SURFACE_ID 9000
>>  
>> +#define WL_KEYBOARD_RELEASE_SINCE_VERSION 3
>> +#define WL_POINTER_RELEASE_SINCE_VERSION 3
>> +#define WL_TOUCH_RELEASE_SINCE_VERSION 3
> 
> The code below looks good, but I don't think we should define macros
> prefixed with WL_ since that'd be something wayland might do.
> I just sent a patch (CC:ed you on it) that makes scanner.c generate
> these for us, just sa we do with events. If we don't go with generating
> the _SINCE_VERSION macros for requests, then you should probably prefix
> them in some way.
> 

Totally agree. Right now, there's several places where it's magic
numbers that are used.

So if people could review the straightforward patch here:
http://lists.freedesktop.org/archives/wayland-devel/2015-October/024742.html
so that it lands quickly.



-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH wayland] scanner: Generate 'since' macros for requests as well

[Hardening]

Le 08/10/2015 05:10, Jonas Ådahl a écrit :
> We already generate WL_[INTERFACE]_[REQUEST]_SINCE_VERSION macros for
> events in the server protocol headers. Lets do the same for requests in
> the client protocol headers as well.
> 
> Signed-off-by: Jonas Ådahl 
> ---
>  src/scanner.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/scanner.c b/src/scanner.c
> index 9b41ae4..2d5a0d8 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -1270,6 +1270,7 @@ emit_header(struct protocol *protocol, enum side side)
>   } else {
>   emit_structs(&i->event_list, i, side);
>   emit_opcodes(&i->request_list, i);
> + emit_opcode_versions(&i->request_list, i);
>   emit_stubs(&i->request_list, i);
>   }
>  
> 
I hit the case this week, this patch is definitely a must-have.

Reviewed-by: David FORT 

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH] weston-input: Reformat weston_log line to add missing space between words

[Hardening]

Le 07/10/2015 18:33, Derek Foreman a écrit :
> On 07/10/15 10:59 AM, Chris Michael wrote:
>> Signed-off-by: Chris Michael 
> 
> Reviewed-by: Derek Foreman 
> 
>> ---
>>  src/input.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/input.c b/src/input.c
>> index e230c83..2e5cd04 100644
>> --- a/src/input.c
>> +++ b/src/input.c
>> @@ -1571,7 +1571,7 @@ notify_touch(struct weston_seat *seat, uint32_t time, 
>> int touch_id,
>>  /* Unexpected condition: We have non-initial touch but
>>   * there is no focused surface.
>>   */
>> -weston_log("touch event received with %d points down"
>> +weston_log("touch event received with %d points down "
>> "but no surface focused\n", touch->num_tp);
>>  return;
>>  }
>>
> 
I hit the case today, so...

Reviewed-by: David FORT 

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 4/4] compositor-rdp: Add missing '\n' in weston_log usage

[Hardening]

Le 01/10/2015 16:51, Chris Michael a écrit :
> Signed-off-by: Chris Michael 
> ---
>  src/compositor-rdp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index c221eb9..7272f41 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -1241,7 +1241,7 @@ rdp_backend_create(struct weston_compositor *compositor,
>   /* get the socket from RDP_FD var */
>   fd_str = getenv("RDP_FD");
>   if (!fd_str) {
> - weston_log("RDP_FD env variable not set");
> + weston_log("RDP_FD env variable not set\n");
>   goto err_output;
>   }
>  
> 
Reviewed-by: David FORT 

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH wayland v2] scanner: Close input resource when done to prevent leak

[Hardening]

Le 02/10/2015 03:13, Bryce Harrington a écrit :
> Addresses this error reported by Denis Denisov:
> 
>   [src/scanner.c:1415]: (error) Resource leak: input
> 
> Signed-off-by: Bryce Harrington 
> 
> v2: Also close input for other exit points in main.
> Signed-off-by: Bryce Harrington 

Reviewed-by: David FORT 

> ---
>  src/scanner.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/scanner.c b/src/scanner.c
> index 9b41ae4..5504fce 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -1531,6 +1531,7 @@ int main(int argc, char *argv[])
>   if (freopen(argv[2], "w", stdout) == NULL) {
>   fprintf(stderr, "Could not open output file: %s\n",
>   strerror(errno));
> + fclose(input);
>   exit(EXIT_FAILURE);
>   }
>   }
> @@ -1550,6 +1551,7 @@ int main(int argc, char *argv[])
>   XML_SetUserData(ctx.parser, &ctx);
>   if (ctx.parser == NULL) {
>   fprintf(stderr, "failed to create parser\n");
> + fclose(input);
>   exit(EXIT_FAILURE);
>   }
>  
> @@ -1561,6 +1563,7 @@ int main(int argc, char *argv[])
>   len = fread(buf, 1, XML_BUFFER_SIZE, input);
>   if (len < 0) {
>   fprintf(stderr, "fread: %m\n");
> + fclose(input);
>   exit(EXIT_FAILURE);
>   }
>   if (XML_ParseBuffer(ctx.parser, len, len == 0) == 0) {
> @@ -1569,6 +1572,7 @@ int main(int argc, char *argv[])
>   XML_GetCurrentLineNumber(ctx.parser),
>   XML_GetCurrentColumnNumber(ctx.parser),
>   XML_ErrorString(XML_GetErrorCode(ctx.parser)));
> + fclose(input);
>   exit(EXIT_FAILURE);
>   }
>   } while (len > 0);
> @@ -1588,6 +1592,7 @@ int main(int argc, char *argv[])
>   }
>  
>   free_protocol(&protocol);
> + fclose(input);
>  
>   return 0;
>  }
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH] wayland: add release request on wl_seat

[Hardening]

Le 29/09/2015 09:58, Jonas Ådahl a écrit :
> On Tue, Sep 29, 2015 at 09:43:01AM +0200, David FORT wrote:
>> This is required if we want to correctly remove a wl_seat compositor-side. A
>> wl_seat is announced as a global object, then it is bound by the client. When
>> the compositor wants to remove the seat, it shall announce the global 
>> removal of
>> the object. The client can then call the release request on the wl_seat 
>> (which
>> means it won't use that object anymore). When all clients have released the
>> wl_seat, it can be destroyed by the compositor.
>> ---
>>  protocol/wayland.xml | 12 +++-
>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
>> index 42c9309..2c7a675 100644
>> --- a/protocol/wayland.xml
>> +++ b/protocol/wayland.xml
>> @@ -1329,7 +1329,7 @@
>>  
>> 
>>  
>> -  
>> +  
> 
> Could you bump the other interfaces that will get this version anyway
> as well? As mentioned, they will have this version anyway, when created.

Perhaps I missed something but I have just discussed this with Pekka,
and he told me not to bump the version from wl_pointer and al...

> 
>>  
>>A seat is a group of keyboards, pointer and touch devices. This
>>object is published as a global during start up, or when such a
>> @@ -1400,6 +1400,16 @@
>>
>>  
>>  
>> +
>> +
>> +
>> +  
>> +  This request is called by the client to inform that it will not 
>> address the seat
>> +  object. The compositor can destroy this seat when all clients have 
>> called
>> +  this request.
> 
> I don't think we should dictate how the implementation should look like.
> The compositor may have destroyed the seat already, leaving only defunct
> wl_seat objects around.
> 
I didn't mean to dictate the implementation, I'll try to find something
more neutral.


> Not sure what "address" means here. "Use" might be more clear, since we
> use that terminology elsewhere. Also using "this" instead of "the" to
> address the object might be more clear as well.

Ok I will change the description this way.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 3/3] Add a release request on wl_seat

[Hardening]

Le 24/09/2015 01:59, Jonas Ådahl a écrit :
> On Wed, Sep 23, 2015 at 11:17:33AM -0500, Derek Foreman wrote:
>> On 25/02/15 08:03 AM, David FORT wrote:
>>> This is required if we want to correctly remove a wl_seat server-side.
>>> ---
>>>  protocol/wayland.xml | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>

Sorry very late reply.

[...]

>>> +
>>> +
>>> +
>>> +  
>>> +
>>> +
>>
>> wl_seat appears to currently be version="4", so I guess we'd have to
>> bump the since= and the version in the comment... (and probably the
>> version of wl_seat as well)
> 
> Yes. And we should bump the version of wl_pointer, wl_touch and
> wl_keyboard as part of it, just to make things clearer.
> 

Does it mean that that wl_pointer, wl_touch and wl_keyboard should all
have the same version as wl_seat ?

>>
>> Unfortunately, I don't think this is necessary or sufficient to solve
>> the problem at hand (RDP compositor connections are new seats, once apps
>> bind these seats they're essentially leaked forever even after RDP
>> client disconnect)
>>

[...]
>>
>> That is, there's a difference between a disconnected RDP client and a
>> libinput backed seat with no devices left in it.
>>
>> Would a new seat event (say, "removed") solve this sufficiently?
> 
> Wouldn't the global advertisement being removed be enough? Every seat is
> advertised individually in the registry, and removing it there should
> IMO be interpreted as there no longer any use for objects that was bound
> to the that global.
> 

Nope because the client can send a request on the seat while the
compositor is announcing the global removal. The release request is
there so that the client can say tto he compositor "understood I won't
use that object anymore". That allows the compositor to ref count users
and free it at the end.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] RDP compositor: make the seat dynamic and don't destroy it on removal

[Hardening]

Le 25/09/2015 19:15, Derek Foreman a écrit :
> On 25/09/15 08:19 AM, Hardening wrote:
>> Le 25/09/2015 11:31, Pekka Paalanen a écrit :
>>> On Thu, 24 Sep 2015 23:40:26 +0200
>>> David FORT  wrote:
>>>
>>>> This patch makes the seat dynamic and leak it on purpose during seat 
>>>> removal to
>>>> prevent the ghost object case.
>>>> ---

[...]

>>
>> Hello Pekka,
>> you're right I've not elaborated much.
>>
>> So the general problem was that wl_seat doesn't have a release request,
>> so we can't track the usage of a wl_seat by wayland clients. And as we
>> can't track the usage, we can't release it safely or we take the risk
>> that clients could address a released object. In the current situation
>> we can't safely release a seat object.
> 
> Should we move forward with your patch to add seat release protocol first?
> 
> Does that change this implementation at all?

Yeah this could be an idea. Once the "release seat patch" is passed, the
goal would be to not leak the seat at all, so the present patch would be
useless.

> 
>> So in my patch I'm mallocating a seat (not having it static with the RDP
>> context), an I took the parts of weston_seat_release() that only do
>> things internally to weston (so that I release as much as I can).
>>
>>

[...]
>>
>>
>> Anyway without the patch, valgrind complains during seat releasing (for
>> example when a RDP peer disconnects).
> 
> Sigh.  There's a lot of multi-seat related problems in the
> text-backend/input-method bits.  I've got a bunch of patches I need to
> sort through and post. :/
> 
> I don't think you've added this problem, I think it's already there (and
> I may have fixed it already...)
> 

I can test with these patches to see if things get better, any reference ?


Best regards.
-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] RDP compositor: make the seat dynamic and don't destroy it on removal

[Hardening]

Le 25/09/2015 11:31, Pekka Paalanen a écrit :
> On Thu, 24 Sep 2015 23:40:26 +0200
> David FORT  wrote:
> 
>> This patch makes the seat dynamic and leak it on purpose during seat removal 
>> to
>> prevent the ghost object case.
>> ---
>>  src/compositor-rdp.c | 39 +++
>>  1 file changed, 27 insertions(+), 12 deletions(-)
> 
> Hi David,
> 
> this patch is still missing the whole explanation of what is going on in
> here. My questions from
> http://lists.freedesktop.org/archives/wayland-devel/2015-May/022055.html
> are still unanswered, and today I understand even less than then. :-)
> 
> Or is there already a comment in the code explaining why rdp-backend
> does funny stuff with seats? I couldn't find it on a quick look.
> 
> Why leak it?
> What is the ghost object problem?
> Why you must use only part of weston_seat_release()?
> 
> I have some very vague memories of wl_seat missing destructor protocol
> or something, is this related?


Hello Pekka,
you're right I've not elaborated much.

So the general problem was that wl_seat doesn't have a release request,
so we can't track the usage of a wl_seat by wayland clients. And as we
can't track the usage, we can't release it safely or we take the risk
that clients could address a released object. In the current situation
we can't safely release a seat object.

So in my patch I'm mallocating a seat (not having it static with the RDP
context), an I took the parts of weston_seat_release() that only do
things internally to weston (so that I release as much as I can).


Perhaps I'm not cleaning up correctly because with my patch applied, if I:
* open a terminal;
* connect with 2 RDP clients (so 2 seats);
* take the focus in the terminal;
* stop weston with a Ctrl-C

I get the following valgrind traceback during weston's shutdown, related
to the input method:
^C[14:35:47.687] caught signal 2
==21909== Invalid read of size 8
==21909==at 0x4173B9: unbind_input_method (text-backend.c:834)
==21909==by 0x4E3D37B: destroy_resource (wayland-server.c:537)
==21909==by 0x4E42255: for_each_helper.isra.0 (wayland-util.c:359)
==21909==by 0x4E4279E: wl_map_for_each (wayland-util.c:365)
==21909==by 0x4E3DF57: wl_client_destroy (wayland-server.c:675)
==21909==by 0x418401: text_backend_destroy (text-backend.c:1046)
==21909==by 0x93542F2: shell_destroy (shell.c:6473)
==21909==by 0x4109C6: weston_compositor_destroy
(wayland-server-core.h:264)
==21909==by 0x40897D: main (main.c:829)
==21909==  Address 0x9b9e6f0 is 112 bytes inside a block of size 120 free'd
==21909==at 0x4C2BDEC: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21909==by 0x6A468AE: rdp_peer_context_free (wayland-server-core.h:264)
==21909==by 0x6D520DA: freerdp_peer_context_free (peer.c:738)
==21909==by 0x6A469B7: rdp_client_activity (compositor-rdp.c:674)
==21909==by 0x4E3FE51: wl_event_loop_dispatch (event-loop.c:422)
==21909==by 0x4E3E6B4: wl_display_run (wayland-server.c:1004)
==21909==by 0x408D35: main (main.c:818)
==21909==


Anyway without the patch, valgrind complains during seat releasing (for
example when a RDP peer disconnects).

Regards.
-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston v3] compositor-rdp: rdp_destroy() double free error #91457

[Hardening]

Le 05/08/2015 22:20, Derek Foreman a écrit :
> On 05/08/15 03:21 PM, Dawid Gajownik wrote:
>> When something goes wrong during weston initialization,
>> weston_compositor_destroy() is executed. It destroys the backend and
>> then frees compositor memory. Unfortunately RDP backend is not correctly
>> destroyed. It frees compositor instead of a backend memory. This causes
>> later a double free error. The easiest way to reproduce a problem is to
>> run weston with an invalid option.
>>
>> Additionally some other objects of rdp_backend structure are not
>> destroyed/freed. The patch fixes both issues.
>>
>> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91457
>>
>> v3: comply with Weston coding style, this time for real
>> v2: comply with Weston coding style
>>
>> Signed-off-by: Dawid Gajownik 
> 
> Reviewed-by: Derek Foreman 

Looks good to me too

Reviewed-by: David FORT 

> 
>> ---
>>  src/compositor-rdp.c | 13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
>> index 6eac7f9..869c3f3 100644
>> --- a/src/compositor-rdp.c
>> +++ b/src/compositor-rdp.c
>> @@ -541,9 +541,20 @@ rdp_restore(struct weston_compositor *ec)
>>  static void
>>  rdp_destroy(struct weston_compositor *ec)
>>  {
>> +struct rdp_backend *b = (struct rdp_backend *) ec->backend;
>> +int i;
>> +
>>  weston_compositor_shutdown(ec);
>> +for (i = 0; i < MAX_FREERDP_FDS; i++)
>> +if (b->listener_events[i])
>> +wl_event_source_remove(b->listener_events[i]);
>> +
>> +freerdp_listener_free(b->listener);
>>  
>> -free(ec);
>> +free(b->server_cert);
>> +free(b->server_key);
>> +free(b->rdp_key);
>> +free(b);
>>  }
>>  
>>  static
>>
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] compositor-rdp: free() can handle NULL pointers

[Hardening]

Le 01/08/2015 16:02, Dawid Gajownik a écrit :
> There's no need to check if a pointer exists before passing it to free().
> free() can handle NULL pointers.
> 
> Signed-off-by: Dawid Gajownik 

Reviewed-By: David FORT 

> ---
>  src/compositor-rdp.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index a83948b..b5169a8 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -1244,12 +1244,9 @@ err_output:
>  err_compositor:
>   weston_compositor_shutdown(compositor);
>  err_free_strings:
> - if (b->rdp_key)
> - free(b->rdp_key);
> - if (b->server_cert)
> - free(b->server_cert);
> - if (b->server_key)
> - free(b->server_key);
> + free(b->rdp_key);
> + free(b->server_cert);
> + free(b->server_key);
>   free(b);
>   return NULL;
>  }
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH wayland 3/3] shm: wl_shm_buffer_get_data() requires a valid pool.

[Hardening]

Le 01/07/2015 12:52, Marek Chalupa a écrit :
> 
> 
> On Wed, Jul 1, 2015 at 11:25 AM, Marek Chalupa  > wrote:
> 
> 
> 
> On Fri, Jun 26, 2015 at 6:35 PM, Derek Foreman
> mailto:der...@osg.samsung.com>> wrote:
> 
> There's no situation where a shm buffer without a pool makes sense,
> so we enforce the pool's existence a little more rigidly.
> 
> Signed-off-by: Derek Foreman  >
> ---
>  src/wayland-shm.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/src/wayland-shm.c b/src/wayland-shm.c
> index da11743..79b3886 100644
> --- a/src/wayland-shm.c
> +++ b/src/wayland-shm.c
> @@ -353,10 +353,12 @@ wl_shm_buffer_get_stride(struct
> wl_shm_buffer *buffer)
>  WL_EXPORT void *
>  wl_shm_buffer_get_data(struct wl_shm_buffer *buffer)
>  {
> -   if (buffer->pool)
> -   return buffer->pool->data + buffer->offset;
> -   else
> -   return buffer + 1;
> +   assert(buffer->pool);
> +
> +   if (!buffer->pool)
> +   return NULL;
> 
> 
> This condition is never true if the assert passed
> 
>  
> Yeah, but in non-debug build we do not have the assert, so it may make
> sense to have this doubled. Ok.
>  

I find it a little strange, that something that abort() in debug mode,
just "silently" return NULL in production mode...

Checking with the Eclipse "Call hierarchy" tool, none of the callers of
wl_shm_buffer_get_data() check the return value, so we may detect the
bug quite far from the real source.

So my suggestion is either wl_shm_buffer_get_data is a "succeed or kill
program" function (like xyzalloc functions), or the callers have to be
updated if we can live with buffer->pool == NULL.

Best regards.
-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH wayland] shm: add getters for the fd and offset

[Hardening]

Le 01/07/2015 10:25, Giulio Camuffo a écrit :
> This allows to share the buffer data by mmapping the fd again.
> ---
>  src/wayland-server-core.h |  6 ++
>  src/wayland-shm.c | 16 +++-
>  2 files changed, 21 insertions(+), 1 deletion(-)
> 

Reviewed-by: David FORT 

> diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
> index 7d03789..938cdf7 100644
> --- a/src/wayland-server-core.h
> +++ b/src/wayland-server-core.h
> @@ -396,6 +396,12 @@ wl_shm_buffer_create(struct wl_client *client,
>uint32_t id, int32_t width, int32_t height,
>int32_t stride, uint32_t format);
>  
> +int
> +wl_shm_buffer_get_offset(struct wl_shm_buffer *buffer);
> +
> +int
> +wl_shm_buffer_get_fd(struct wl_shm_buffer *buffer);
> +
>  void wl_log_set_handler_server(wl_log_func_t handler);
>  
>  #ifdef  __cplusplus
> diff --git a/src/wayland-shm.c b/src/wayland-shm.c
> index b6b31d6..c85e839 100644
> --- a/src/wayland-shm.c
> +++ b/src/wayland-shm.c
> @@ -52,6 +52,7 @@ struct wl_shm_pool {
>   int refcount;
>   char *data;
>   int32_t size;
> + int fd;
>  };
>  
>  struct wl_shm_buffer {
> @@ -77,6 +78,7 @@ shm_pool_unref(struct wl_shm_pool *pool)
>   return;
>  
>   munmap(pool->data, pool->size);
> + close(pool->fd);
>   free(pool);
>  }
>  
> @@ -250,7 +252,7 @@ shm_create_pool(struct wl_client *client, struct 
> wl_resource *resource,
>  "failed mmap fd %d", fd);
>   goto err_close;
>   }
> - close(fd);
> + pool->fd = fd;
>  
>   pool->resource =
>   wl_resource_create(client, &wl_shm_pool_interface, 1, id);
> @@ -409,6 +411,18 @@ wl_shm_buffer_get_height(struct wl_shm_buffer *buffer)
>   return buffer->height;
>  }
>  
> +WL_EXPORT int
> +wl_shm_buffer_get_offset(struct wl_shm_buffer *buffer)
> +{
> + return buffer->offset;
> +}
> +
> +WL_EXPORT int
> +wl_shm_buffer_get_fd(struct wl_shm_buffer *buffer)
> +{
> + return buffer->pool->fd;
> +}
> +
>  static void
>  reraise_sigbus(void)
>  {
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston 11/11] configure: add an option to allow building only the libraries

[Hardening]

Le 22/06/2015 22:02, Giulio Camuffo a écrit :
> the --enable/disable-weston-binaries enables or disables the creation
> of 'weston', 'weston-launch' and all the binaries that are
> installed in $prefix/lib/libexec. This allows, together with
> --enable-clients, to only build the libraries, making possible to
> build and install different libweston versions at the same time.
> ---
>  Makefile.am  | 15 +++
>  configure.ac |  8 
>  2 files changed, 23 insertions(+)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 2d24bcc..43b69ad 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -106,6 +106,8 @@ nodist_libweston_@ABI_VERSION@_la_SOURCES =   
> \
>  
>  BUILT_SOURCES += $(nodist_libweston_@ABI_VERSION@_la_SOURCES)
>  
> +
> +if BUILD_WESTON_BINARIES
>  bin_PROGRAMS += weston
>  
>  weston_LDFLAGS = -export-dynamic
> @@ -135,6 +137,7 @@ nodist_weston_SOURCES =   
> \
>   protocol/text-server-protocol.h \
>   protocol/input-method-protocol.c\
>   protocol/input-method-server-protocol.h
> +endif
>  
>  BUILT_SOURCES += $(nodist_weston_SOURCES)
>  
> @@ -178,6 +181,7 @@ endif
>  .FORCE :
>  
>  if BUILD_WESTON_LAUNCH
> +if BUILD_WESTON_BINARIES
>  bin_PROGRAMS += weston-launch
>  weston_launch_SOURCES = src/weston-launch.c src/weston-launch.h
>  weston_launch_CPPFLAGS = -DBINDIR='"$(bindir)"'
> @@ -200,6 +204,7 @@ install-exec-hook:
>   false; \
>   fi
>  endif
> +endif # BUILD_WESTON_BINARIES
>  
>  endif # BUILD_WESTON_LAUNCH
>  
> @@ -445,6 +450,7 @@ if BUILD_CLIENTS
>  
>  bin_PROGRAMS += weston-terminal weston-info
>  
> +if BUILD_WESTON_BINARIES
>  libexec_PROGRAMS +=  \
>   weston-desktop-shell\
>   weston-screenshooter\
> @@ -455,6 +461,7 @@ if ENABLE_IVI_SHELL
>  libexec_PROGRAMS +=  \
>   weston-ivi-shell-user-interface
>  endif
> +endif
>  
>  demo_clients =   \
>   weston-flower   \
> @@ -574,6 +581,7 @@ weston_flower_SOURCES = clients/flower.c
>  weston_flower_LDADD = libtoytoolkit.la
>  weston_flower_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  
> +if BUILD_WESTON_BINARIES
>  weston_screenshooter_SOURCES =   \
>   clients/screenshot.c
>  nodist_weston_screenshooter_SOURCES =\
> @@ -581,6 +589,7 @@ nodist_weston_screenshooter_SOURCES = 
> \
>   protocol/screenshooter-client-protocol.h
>  weston_screenshooter_LDADD = $(CLIENT_LIBS) libshared.la
>  weston_screenshooter_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
> +endif
>  
>  weston_terminal_SOURCES =\
>   clients/terminal.c  \
> @@ -692,6 +701,7 @@ weston_editor_LDADD = libtoytoolkit.la $(PANGO_LIBS)
>  weston_editor_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) $(PANGO_CFLAGS)
>  endif
>  
> +if BUILD_WESTON_BINARIES
>  weston_keyboard_SOURCES = clients/keyboard.c
>  nodist_weston_keyboard_SOURCES = \
>   protocol/desktop-shell-client-protocol.h\
> @@ -707,6 +717,7 @@ nodist_weston_simple_im_SOURCES = \
>   protocol/input-method-client-protocol.h
>  weston_simple_im_LDADD = $(CLIENT_LIBS)
>  weston_simple_im_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
> +endif
>  
>  weston_info_SOURCES =\
>   clients/weston-info.c   \
> @@ -717,6 +728,7 @@ nodist_weston_info_SOURCES =  
> \
>  weston_info_LDADD = $(WESTON_INFO_LIBS) libshared.la
>  weston_info_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  
> +if BUILD_WESTON_BINARIES
>  weston_desktop_shell_SOURCES =   \
>   clients/desktop-shell.c \
>   shared/helpers.h
> @@ -725,7 +737,9 @@ nodist_weston_desktop_shell_SOURCES = 
> \
>   protocol/desktop-shell-protocol.c
>  weston_desktop_shell_LDADD = libtoytoolkit.la
>  weston_desktop_shell_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
> +endif
>  
> +if BUILD_WESTON_BINARIES
>  if ENABLE_IVI_SHELL
>  weston_ivi_shell_user_interface_SOURCES =\
>   clients/ivi-shell-user-interface.c  \
> @@ -738,6 +752,7 @@ nodist_weston_ivi_shell_user_interface_SOURCES =  
> \
>  weston_ivi_shell_user_interface_LDADD = libtoytoolkit.la
>  weston_ivi_shell_user_interface_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  endif
> +endif
>  
>  if BUILD_FULL_GL_CLIENTS
>  demo_clients += weston-gears
> diff --git a/configure.ac b/configure.ac
> index f6780e8..3578811 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -357,6 +357,12 @@ PKG_CHECK_MODULES(SYSTEMD_LOGIN_209, [libsystemd-login 
> >= 209],
>  AS_IF([test "x$have_systemd_login_209" = "xyes"],
>[AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [

Re: [PATCH weston 09/17] src: Update boilerplate from MIT X11 license to MIT Expat license

[Hardening]

Le 13/06/2015 00:04, Bryce Harrington a écrit :
> Signed-off-by: Bryce Harrington 
> ---
>  src/animation.c   | 35 +++
>  src/bindings.c| 35 +++
>  src/clipboard.c   | 35 +++
>  src/cms-colord.c  | 35 +++
>  src/cms-helper.c  | 35 +++
>  src/cms-helper.h  | 35 +++
>  src/cms-static.c  | 35 +++
>  src/compositor-drm.c  | 35 +++

Reviewed-By: David FORT 

I agree with the changes in the compositor-rdp.c file.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] Add config option to disable input method

[Hardening]

Le 06/06/2015 12:18, Murray Calavera a écrit :
> When building a shell-plugin the developer might not want to implement
> an input method. Nevertheless weston will look for one, print errors
> complaining that the input method died and then give up.
> 
> Signed-off-by: Murray Calavera 
> ---
>  man/weston.ini.man | 9 -
>  src/compositor.c   | 6 +-
>  weston.ini.in  | 1 +

I have hit the case. So +1.


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: Wayland not MIT-licensed / FAQ wrong

[Hardening]

Le 28/05/2015 23:15, Kristian Høgsberg a écrit :
> Yes, it appears you're correct. The HPND license is widely used in X
> (even new additions such as
> http://cgit.freedesktop.org/xorg/xserver/tree/dri3/dri3.c) and I think
> I assumed it was the most recent/modern version of the MIT license. It
> was certainly the intention to change the license to MIT and that's
> what all contributors acknowledged when we relicensed. Let's wait a
> few days and see if anybody objects, but otherwise I think it'd be
> fine to just change the Wayland and Weston licenses to the actual MIT
> license.
> 
> Kristian
> 

No problem for the license change and my contributions on the RDP
compositor.

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 2/2] RDP compositor: enforce certificate and key

[Hardening]

Le 21/05/2015 09:02, Pekka Paalanen a écrit :
> On Tue, 19 May 2015 10:07:40 +0200
> David FORT  wrote:
> 
>> The RDP compositor is usable without certificates and key in a very limited
>> number of cases (local usage using xfreerdp), so let's force the presence of
>> keys and certificates.

[...]
> 
> Hi,
> 
> do you want to push this one with my Acked-by already given before RC2
> comes out tomorrow? I'd recommend it. :-)
> 

Pushed:
b7e70af..ab3298a  master -> master

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 2/2] RDP compositor: enforce certificate and key

[Hardening]

Le 21/05/2015 09:02, Pekka Paalanen a écrit :
> On Tue, 19 May 2015 10:07:40 +0200
> David FORT  wrote:
> 
>> The RDP compositor is usable without certificates and key in a very limited
>> number of cases (local usage using xfreerdp), so let's force the presence of
>> keys and certificates.
>> ---
>>  src/compositor-rdp.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
>> index f1dcda0..261fa4b 100644
>> --- a/src/compositor-rdp.c
>> +++ b/src/compositor-rdp.c
>> @@ -1278,5 +1278,11 @@ backend_init(struct wl_display *display, int *argc, 
>> char *argv[],
>>  };
>>  
>>  parse_options(rdp_options, ARRAY_LENGTH(rdp_options), argc, argv);
>> +if (!config.rdp_key && (!config.server_cert || !config.server_key)) {
>> +weston_log("the RDP compositor requires keys and an optional 
>> certificate for RDP or TLS security ("
>> +"--rdp4-key or 
>> --rdp-tls-cert/--rdp-tls-key)\n");
>> +return NULL;
>> +}
>> +
>>  return rdp_compositor_create(display, &config, argc, argv, wconfig);
>>  }
> 
> Hi,
> 
> do you want to push this one with my Acked-by already given before RC2
> comes out tomorrow? I'd recommend it. :-)
> 

Nice, I was about to send a mail in that sense.


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] compositor-wayland: Handle window close events more gracefully

[Hardening]

Le 20/05/2015 01:41, Bryce Harrington a écrit :
> On Mon, May 18, 2015 at 11:14:16PM -0700, Dima Ryazanov wrote:
>> When a compositor window is closed, remove the output instead of just 
>> exiting.
>>
>> (The "if (!input->output)" checks are kind of ugly - but I couldn't find
>> a better way to handle the output going away.)
>>
>> Signed-off-by: Dima Ryazanov 
> Reviewed-by: Bryce Harrington 
> 
>> ---
>>  src/compositor-wayland.c | 22 +++---
>>  1 file changed, 19 insertions(+), 3 deletions(-)
>>
[...]

>>  
>>  if (frame_status(input->output->frame) & FRAME_STATUS_REPAINT)
>>  weston_output_schedule_repaint(&input->output->base);
>> @@ -1521,7 +1537,7 @@ input_handle_keyboard_leave(void *data,
>>  
>>  focus = input->keyboard_focus;
>>  if (!focus)
>> -return; /* This shouldn't happen */
>> +return;

Just a remark, if it's something that shouldn't happen it's a failing
assert not a silent return, isn't it ?

Regards

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 1/2] RDP compositor: make the seat dynamic and don't destroy it on removal

[Hardening]

Le 19/05/2015 11:20, Pekka Paalanen a écrit :
> On Tue, 19 May 2015 10:07:39 +0200
> David FORT  wrote:
> 
>> This patch makes the seat dynamic and leak it on purpose during seat removal 
>> to
>> prevent the ghost object case.
>> ---
>>  src/compositor-rdp.c | 39 +++
>>  1 file changed, 27 insertions(+), 12 deletions(-)
>>
>> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
>> index 3185141..f1dcda0 100644
>> --- a/src/compositor-rdp.c
>> +++ b/src/compositor-rdp.c
>> @@ -105,7 +105,7 @@ enum peer_item_flags {
>>  struct rdp_peers_item {

[...]
>> +weston_seat_release_pointer(seat);
>> +
>> +/* picked from weston_seat_release(context->item.seat); */
>> +wl_list_remove(&seat->link);
>> +if (seat->saved_kbd_focus)
>> +wl_list_remove(&seat->saved_kbd_focus_listener.link);
>> +wl_global_destroy(seat->global);
> 
> Hi,
> 
> are you sure destroying the global is ok? Ah, but the thing you want to
> keep are the *existing* protocol objects.
> 

I have picked code weston_seat_release() from that was releasing things
in the seat without freeing it, but...

Thinking of it, it's really a bad idea to destroy the global, it could
cause clients to be disconnected if they try to do anything with the
seat. We're really lacking the release event...

I will modify this to try to handle this more nicely.

Thanks.
-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] compositor-drm: disable hardware cursors

[Hardening]

Le 19/05/2015 09:26, Pekka Paalanen a écrit :
> From: Pekka Paalanen 
> 
> With the recent universal plane and atomic modeset / nuclear pageflip
> development in the kernel, cursor content updates on Intel are currently 
> causing
> an extra wait for vblank. This drops Weston's framerate to a fraction by
> 2 when cursor contents update. This combined with the damage tracking
> bug in Weston which causes cursor content updates on every frame the
> cursor moves makes using hw cursors really bad.
> 
> It is possible that the Intel DRM driver will get fixed and cursor
> updates there revert to their old behaviour on the contemporary KMS API.
> However, it is hardware dependant whether cursor updates can happen
> immediately.  Some other hardware, especially ARM-related, may not be
> able to do immediate updates. Therefore it is better to just not even
> try - we should rely only on the lowest common denominator behaviour
> between hardware and drivers as there is no and will not be any way to
> reliably detect it.
> 
> Note, that while having different drivers do different things (immediate
> update vs. update that gets latched on the next vblank), we cannot
> rearrange the contemporary KMS API calls such that it would always work
> fine. Either some hardware would update the cursor too early, or other
> hardware would update the cursor too late and perhaps cause the
> framerate decimation.
> 
> Mark hardware cursors broken by default. This avoids using them, and
> works around the immediate problem of framerate issues in Weston. This
> follows the same reasoning why hardware overlay planes have been
> disabled by default for a long time.
> 
> This disablement will be removed once the current code for hardware
> planes and cursors is replaced with code using the atomic KMS API.
> 
> The Intel driver change that exposed this problem is
> https://github.com/torvalds/linux/commit/38f3ce3af5742eb5a3e9b01997f5ab85109c5762
> which is first included in Linux 4.0-rc1.
> 
> Signed-off-by: Pekka Paalanen 
> Cc: nerdopolis 
> Cc: Daniel Stone 
> Cc: Giulio Camuffo 
> ---
> 
> There are no bug reports or emails to be referenced here, are there?
> At least I couldn't find any.
> 
> Thanks,
> pq
> 
>  src/compositor-drm.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 313860b..0a9af5d 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -2817,9 +2817,17 @@ drm_compositor_create(struct wl_display *display,
>   if (ec == NULL)
>   return NULL;
>  
> - /* KMS support for sprites is not complete yet, so disable the
> -  * functionality for now. */
> + /*
> +  * KMS support for hardware planes cannot properly synchronize
> +  * without nuclear page flip. Without nuclear/atomic, hw plane
> +  * and cursor plane updates would either tear or cause extra
> +  * waits for vblanks which means dropping the compositor framerate
> +  * to a fraction.
> +  *
> +  * These can be enabled again when nuclear/atomic support lands.
> +  */
>   ec->sprites_are_broken = 1;
> + ec->cursors_are_broken = 1;
>  
>   section = weston_config_get_section(config, "core", NULL, NULL);
>   if (get_gbm_format_from_section(section,
> 
Perhaps it would be nice if the most adventurous of us could re-enable
the cursors using a configuration file option...

Except this non blocking remark,
Reviewed-By: David FORT 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH] RDP compositor: fixes for multiple connections, mstsc and FreeRDP master compilation

[Hardening]

Le 11/05/2015 15:06, Pekka Paalanen a écrit :
> On Wed,  6 May 2015 10:59:42 +0200
> David FORT  wrote:
> 
>> From: Hardening 
>>
>> This patch fixes the problem reported on the mailing list
>> (http://lists.freedesktop.org/archives/wayland-devel/2015-January/019575.html).
>> All certificate and key paths were not copied when given to FreeRDP, so they
>> were freed when the peer was disconnecting. And so the next connection was 
>> failing.
>>
>> All the initialization stuffs have been moved to the activate callback, as 
>> when it is
>> called the peer is ready for graphics.
>>
>> We also differ the creation of the seat, so that a seat is initialized only 
>> the
>> peer really do the activation sequence. That helps when mstsc just connects 
>> to see
>> the certificate, ask if the certificate should be trusted, and then 
>> reconnects.
>>
>> This patch also adds configuration settings for recent versions of FreeRDP 
>> that
>> comes with everything disabled. This makes remoteFx functionnal again.
>>
>> The patch also handles the skipCompression flag for last FreeRDP versions, 
>> that
>> allows to skip bulk compression for surfaces that have been already 
>> compressed by
>> the remoteFx or NS codec.
>>
>> This also fixes the compilation against FreeRDP master with callback that 
>> now return
>> BOOL.
>> ---
>>  src/compositor-rdp.c | 127 
>> +++
>>  1 file changed, 97 insertions(+), 30 deletions(-)
> 
> Hi,
> 
> reading the description, this sounds like it should be 4-5 separate
> patches, but you're the RDP-backend maintainer, so if you think it's
> fine, I'm not going to argue.
> 
> I can only check that the changes are confined to the RDP-backend and
> they are not obviously bad, so in that sense:
> Acked-by: Pekka Paalanen 
> 
> Feel free to push, IIRC you have the rights.
> 
Yes Pekka, you're right the patch could have been split as it's
different changes touching the same file.

Anyway pushed:

e4df9ee..0c944b0  master -> master


Thank you.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH weston] compositor-drm: Open drm device with CLOEXEC

[Hardening]

Le 01/05/2015 16:59, Derek Foreman a écrit :
> Signed-off-by: Derek Foreman 
> ---
>  src/compositor-drm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 43197a8..6a2dbd9 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -1329,7 +1329,8 @@ init_drm(struct drm_compositor *ec, struct udev_device 
> *device)
>   }
>  
>   filename = udev_device_get_devnode(device);
> - fd = weston_launcher_open(ec->base.launcher, filename, O_RDWR);
> + fd = weston_launcher_open(ec->base.launcher, filename,
> +   O_RDWR | O_CLOEXEC);
>   if (fd < 0) {
>   /* Probably permissions error */
>   weston_log("couldn't open %s, skipping\n",
> 
Reviewed-By: David FORT 

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: Weston RDP on ARM

[Hardening]

Le 26/03/2015 15:45, Heikki Sarkanen a écrit :
> Hi,
> 
> I am trying to use the RDP backend on custom Freescale iMX6 based ARM
> board where the only supported fbdev-backend is heavily patched:
> https://github.com/Freescale/meta-fsl-arm/tree/master/recipes-graphics/wayland/weston.
> I am using Yocto build system, Weston 1.7 and freerdp version:
> 3f371b22ad67033c366e41f459747796a95633b8 which was working on some ARM
> board: 
> http://lists.freedesktop.org/archives/wayland-devel/2015-February/020088.html.
> Probably I am doing something wrong because I have tried three
> different approaches with no luck yet:
> 
> 1. Use fullscreen shell to show contents of other fbdev/desktop-shell
> compositor.
> Currently fullscreen shell works and I can connect RDP client which
> shows blank image:
> weston --no-config --backend=rdp-backend.so
> --shell=fullscreen-shell.so --no-clients-resize
> --rdp-tls-cert=/home/root/test.crt --rdp-tls-key=/home/root/test.key
> 
> How can I show desktop-shell contents running on fbdev-backend on this
> fullscreen shell compositor?
> 
> 2. Use desktop-shell on RDP-backend like they use on Tizen:
> https://wiki.tizen.org/wiki/Weston_RDP_access This fails to
> get_shell_surface and quits:
> weston --no-config --backend=rdp-backend.so --shell=desktop-shell.so
> --no-clients-resize --rdp-tls-cert=/home/root/test.crt
> --rdp-tls-key=/home/root/test.key --socket=wayland-1
> [12:12:17.884] weston 1.7.0
>http://wayland.freedesktop.org
>Bug reports to:
> https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.7.0
>Build: 1.6.93-9-gdbd8606 configure.ac: bump to version
> 1.7.0 for release (2015-02-13 20:47:09 -0800)
> [12:12:17.885] OS: Linux, 3.10.53-alpha1.1, #1 SMP PREEMPT Tue Mar 3
> 23:09:53 EET 2015, armv7l
> [12:12:17.886] Starting with no config file.
> [12:12:17.888] Loading module '/usr/lib/weston/rdp-backend.so'
> [12:12:17.983] using FreeRDP version 1.2.1
> [12:12:17.986] TLS support activated
> [12:12:17:471] [969:1992478720] [INFO][com.freerdp.core.listener] -
> Listening on 0.0.0.0:3389
> [12:12:17.988] Compositor capabilities:
>arbitrary surface rotation: yes
>screen capture uses y-flip: yes
>presentation clock: CLOCK_MONOTONIC_RAW, id 4
> [12:12:17.990] Loading module '/usr/lib/weston/desktop-shell.so'
> [12:12:17.998] launching '/usr/lib/weston/weston-desktop-shell'
> [12:12:18.072] Error: /usr/lib/weston/weston-desktop-shell apparently
> cannot run at all.
>Quitting...
> 
> Does RDP backend work with desktop shell?

Yes it does, on x86_64 I can run your command and it works nicely. Note:
you don't need FreeScale patches for the headless RDP compositor.

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [RFC wayland 1/2] server: implement intact resources

[Hardening]

Le 19/03/2015 09:11, Marek Chalupa a écrit :
> When server looses some capability (like pointer or keyboard),
> it takes some time to get this information to clients.
> When client sends request with new_id argument to the object
> that has been just destroyed on server-side (client
> does not know about it yet), we still have to create the resource.
> If we wouldn't do it then the client will get invalid id error once it
> tries to use the new object. But if we create it, then we have to
> take care that all the requests but destructor are ignored,
> because we do not have the server-side object anymore.
> (eventually, client will destroy the resource, because
> it will get the information about server-side object destruction)
> 
> This patch solves this ugly race by adding wl_resource_set_intact()
> function that marks the resource as intact. When resource is intact
> it ignores all requests and events but destructors. The trick is in
> adding flag into the request's siganture that says: "hey! I'm
> destructor". Server then can skip non-destructor actions on intact
> resource.
> 

Hello Marek,
nice to have some feedback on this subject. I like your implementation
(and you have a unitary test which is really nice), anyway I feel like
it doesn't handle the case of inert objects that are requested with a
method that "return" an object. For example an inert seat that is
requested for get_keyboard(), in this case I think should we should bind
an inert keyboard. I have worked on this subject to solve that exact
problem. Today the seat can't be released because: we don't have the
method to do it, and we have the race problem that prevent us from
freeing the seat.

Regards.

-- 
David FORT
website: http://www.hardening-consulting.com/



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

Re: [PATCH wayland] scanner: Fail on empty enumerations

[Hardening]

Le 19/03/2015 09:58, Jonas Ådahl a écrit :
> Without this patch, the scanner would generate invalid C which wouldn't
> compile anyway, so lets be nice and fail earlier and point out where the
> error is.
> 
> Signed-off-by: Jonas Ådahl 

+1

Reviewed-By: David FORT 

> ---
>  src/scanner.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/scanner.c b/src/scanner.c
> index 1f1e59a..64431a1 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -551,6 +551,10 @@ end_element(void *data, const XML_Char *name)
>  strcmp(name, "event") == 0) {
>   ctx->message = NULL;
>   } else if (strcmp(name, "enum") == 0) {
> + if (wl_list_empty(&ctx->enumeration->entry_list)) {
> + fail(&ctx->loc, "enumeration %s was empty",
> +  ctx->enumeration->name);
> + }
>   ctx->enumeration = NULL;
>   }
>  }
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 1/3] Extend WAYLAND_DISPLAY and name parameter semantics to support absolute paths. For example WAYLAND_DISPLAY="/my/path/wayland-2" or connect_to_socket("/my/path/wayland-2").

[Hardening]

Le 03/03/2015 13:49, Davide Bettio a écrit :
> Signed-off-by: Davide Bettio 
> ---
>  doc/man/wl_display_connect.xml |  8 
>  src/wayland-client.c   | 22 +-
>  src/wayland-server.c   | 23 ++-
>  3 files changed, 39 insertions(+), 14 deletions(-)
> 

Your patch would produce an horrible git log, can you reformat so that
there's a summary and log content ?

Regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH wayland v3] Add support for direct file reading and writing in wayland-scanner.

[Hardening]

Le 03/03/2015 09:11, Pekka Paalanen a écrit :
> On Mon,  2 Mar 2015 16:08:00 +0200
> Jussi Pakkanen  wrote:
> 
>> Add support for direct file reading and writing in wayland-scanner.
>>
>> Signed-off-by: Jussi Pakkanen 
>>
>> ---
>>  src/scanner.c | 26 +-
>>  1 file changed, 21 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/scanner.c b/src/scanner.c
>> index 1f1e59a..efdc69c 100644
>> --- a/src/scanner.c
>> +++ b/src/scanner.c
>> @@ -39,11 +39,12 @@ enum side {
>>  static int
>>  usage(int ret)

[...]

> 
> However, Bill and Bryce had a point. I wonder if we are happy with this
> kind of ad-hoc extension of the CLI, after all it is "stable ABI" in a
> sense. Would anyone want to do this with proper command line option
> parsing, using options instead of adding more "anonymous" position
> dependent arguments? Or would it become just even more weird?
> 
> Personally I don't really care. There is still room for hacking more
> features in if needed, and if we find ourselves in a corner, we could
> build another binary with a different name and a new CLI.
> 
> Thoughts, anyone?
> 
> If no-one objects, I'm inclined to merge this patch with my R-b, say,
> next week?
> 
+1 too.

I don't like very much the requirement for both input and output file,
but I can live with it.

Best regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: Experiment: compiling Wayland and Weston with Meson

[Hardening]

Le 21/02/2015 22:16, Jussi Pakkanen a écrit :
> Hi all
> 
> I'm working on a new build system called Meson. As part of development I
> take open source projects and rewrite their build systems to ensure it
> fulfils real world requirement. This time I took Wayland and Weston.
> 

[...]

> 
> For more information, just go to the github project
> page: https://github.com/jpakkane/meson
> 
> The presentation "Making build systems not suck" from LCA2015 is a good
> overview of Meson: https://www.youtube.com/watch?v=KPi0AuVpxLI
> 
> That's about it. I hope you find it interesting,

A big +1 for the patch on src/scanner.c that allows to specify the input
and output file on the command line. Without it you can't debug the
scanner in eclipse...

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: Weston 1.7 memleaks

[Hardening]

Le 19/02/2015 03:41, Titus Johnson a écrit :
> Just checking mem leaks.
> Is this normal or are we shooting for zero leaks?
> 
> [21:32:52.432] weston 1.7.0
>http://wayland.freedesktop.org
>Bug reports to:
> https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.7.0
> 
>Build: 1.6.93-9-gdbd8606 configure.ac: bump to version
> 1.7.0 for release (2015-02-13 20:47:09 -0800)
> [21:32:52.484] OS: Linux, 3.18.6-1-ARCH, #1 SMP PREEMPT Sat Feb 7
> 08:44:05 CET 2015, x86_64
> [21:32:52.495] Starting with no config file.
> [21:32:52.508] Loading module '/usr/lib/weston/x11-backend.so'
> [21:32:52.621] initializing x11 backend
> [21:32:52.722] Loading module '/usr/lib/weston/gl-renderer.so'
> [21:32:53.301] warning: EGL_EXT_buffer_age not supported. Performance
> could be affected.
> [21:32:53.301] warning: EGL_EXT_swap_buffers_with_damage not supported.
> Performance could be affected.
> [21:32:53.302] Using gl renderer
> [21:32:53.304] launching '/usr/lib/weston/weston-keyboard'
> [21:32:53.939] EGL version: 1.4 (DRI2)
> [21:32:53.939] EGL vendor: Mesa Project
> [21:32:53.940] EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3
> [21:32:53.940] EGL extensions: EGL_MESA_drm_image
> EGL_MESA_configless_context
>EGL_WL_bind_wayland_display EGL_KHR_image_base
>EGL_KHR_image_pixmap EGL_KHR_image
> EGL_KHR_gl_texture_2D_image
>EGL_KHR_gl_texture_cubemap_image
> EGL_KHR_gl_renderbuffer_image
>EGL_KHR_surfaceless_context EGL_KHR_create_context
>EGL_NOK_swap_region EGL_NOK_texture_from_pixmap
>EGL_CHROMIUM_sync_control EGL_EXT_create_context_robustness
>EGL_EXT_image_dma_buf_import EGL_NV_post_sub_buffer
> [21:32:53.943] GL version: OpenGL ES 3.0 Mesa 10.4.4
> [21:32:53.943] GLSL version: OpenGL ES GLSL ES 3.0
> [21:32:53.943] GL vendor: Intel Open Source Technology Center
> [21:32:53.946] GL renderer: Mesa DRI Intel(R) Haswell Mobile
> [21:32:53.946] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
>GL_EXT_texture_filter_anisotropic
>GL_EXT_texture_compression_dxt1
> GL_EXT_texture_format_BGRA
>GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24
>GL_OES_element_index_uint GL_OES_fbo_render_mipmap
>GL_OES_mapbuffer GL_OES_rgb8_rgba8
> GL_OES_standard_derivatives
>GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_npot
>GL_OES_EGL_image GL_OES_depth_texture
>GL_OES_packed_depth_stencil
> GL_EXT_texture_type_2_10_10_10_REV
>GL_OES_get_program_binary GL_APPLE_texture_max_level
>GL_EXT_discard_framebuffer GL_EXT_read_format_bgra
>GL_NV_fbo_color_attachments GL_OES_EGL_image_external
>GL_OES_vertex_array_object GL_ANGLE_texture_compression_dxt3
>GL_ANGLE_texture_compression_dxt5 GL_EXT_texture_rg
>GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer
>GL_EXT_map_buffer_range GL_OES_depth_texture_cube_map
>GL_OES_surfaceless_context GL_EXT_color_buffer_float
>GL_EXT_separate_shader_objects GL_EXT_shader_integer_mix
>GL_KHR_context_flush_control
> [21:32:53.948] GL ES 2 renderer features:
>read-back format: BGRA
>wl_shm sub-image to texture: yes
>EGL Wayland extension: yes
> [21:32:53.949] Chosen EGL config details:
>RGBA bits: 8 8 8 8
>swap interval range: 0 - 1000
> [21:32:53.952] x11 output 1024x640, window id 62914565
> [21:32:53.954] Compositor capabilities:
>arbitrary surface rotation: yes
>screen capture uses y-flip: yes
>presentation clock: CLOCK_MONOTONIC_RAW, id 4
> [21:32:53.963] Loading module '/usr/lib/weston/desktop-shell.so'
> [21:32:55.718] launching '/usr/lib/weston/weston-desktop-shell'
> ==16517== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised
> byte(s)
> ==16517==at 0x5D41330: __sendmsg_nocancel (in /usr/lib/libc-2.21.so)
> ==16517==by 0x4E3F780: ??? (in /usr/lib/libwayland-server.so.0.1.0)
> ==16517==by 0x4E3D92E: wl_display_flush_clients (in
> /usr/lib/libwayland-server.so.0.1.0)
> ==16517==by 0x4E3D987: wl_display_run (in
> /usr/lib/libwayland-server.so.0.1.0)
> ==16517==by 0x4086FA: ??? (in /usr/bin/weston)
> ==16517==by 0x5C787FF: (below main) (in /usr/lib/libc-2.21.so)
> ==16517==  Address 0xeacd996 is 4,134 bytes inside a block of size
> 16,424 alloc'd
> ==16517==at 0x4C29F90: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==16517==by 0x4E3F8B1: ??? (in /usr/lib/libwayland-server.so.0.1.0)
> ==16517==by 0x4E3DD12: wl_client_create (in
> /usr/lib/libwayland-server.so.0.1.0)
> ==16517==by 0x40AA40: weston_client_la

Re: RDP connection to wayland compositor

[Hardening]

Le 09/02/2015 13:18, Vasyl Vavrychuk a écrit :
> Hi,
> 
> Weston supports RDP protocol via rdp-backend. Its use is for example
> described here https://wiki.tizen.org/wiki/Weston_RDP_access.
> 
> Current implementation works in the way that weston compositor launched
> with wayland backend and weston compositor launched with RDP backend are
> independent of each other. This means if we open some window direct on
> the machine, this window will not be accessible via RDP.
> 
> This is similar how VNC operates in "Virtual Mode"
> here http://www.realvnc.com/products/vnc/wayland/
> 
> I am interesting in another way of RDP access that I will not create new
> session but connect to existing session of wayland compositor. It is
> similar to "User Mode" described
> here http://www.realvnc.com/products/vnc/wayland/
> 
> Is it feasible to implement?
> 

It think you can perform that kind of things with the fullscreen shell,
but IIRC you're limited to one fullscreen surface.

Regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

[PATCH] RDP compositor: v2 fixes for multiple connections and mstsc

[Hardening]

This patch fixes the problem reported on the mailing list
(http://lists.freedesktop.org/archives/wayland-devel/2015-January/019575.html).
All certificate and key paths were not copied when given to FreeRDP, so they
were freed when the peer was disconnecting. And so the next connection was 
failing.

All the initialization stuffs have been moved to the activate callback, as when 
it is
called the peer is ready for graphics.

We also differ the creation of the seat, so that a seat is initialized only the
peer really do the activation sequence. That helps when mstsc just connects to 
see
the certificate, ask if the certificate should be trusted, and then reconnects.

This patch also adds configuration settings for recent versions of FreeRDP that
comes with everything disabled. This makes remoteFx functionnal again.

The patch also handles the skipCompression flag for last FreeRDP versions, that
allows to skip bulk compression for surfaces that have been already compressed 
by
the remoteFx or NS codec.

This v2 fixes the detection of skipCompression support.
---
 src/compositor-rdp.c | 86 +++-
 1 file changed, 65 insertions(+), 21 deletions(-)

diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index 1c3f988..f443dce 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -33,6 +33,13 @@
 /* assume it's a early 1.1 version */
 #define FREERDP_VERSION_MAJOR 1
 #define FREERDP_VERSION_MINOR 1
+#define FREERDP_VERSION_RELEASE 0
+#endif
+
+#define FREERDP_FULL_VERSION (FREERDP_VERSION_MAJOR * 0x1000 + \
+   FREERDP_VERSION_MINOR * 0x100 + FREERDP_VERSION_RELEASE)
+#if FREERDP_FULL_VERSION >= 0x10201
+#define HAVE_SKIP_COMPRESSION
 #endif
 
 #include 
@@ -145,6 +152,11 @@ rdp_peer_refresh_rfx(pixman_region32_t *damage, 
pixman_image_t *image, freerdp_p
width = (damage->extents.x2 - damage->extents.x1);
height = (damage->extents.y2 - damage->extents.y1);
 
+#ifdef HAVE_SKIP_COMPRESSION
+   cmd->skipCompression = TRUE;
+#else
+   memset(cmd, 0, sizeof(*cmd));
+#endif
cmd->destLeft = damage->extents.x1;
cmd->destTop = damage->extents.y1;
cmd->destRight = damage->extents.x2;
@@ -197,6 +209,11 @@ rdp_peer_refresh_nsc(pixman_region32_t *damage, 
pixman_image_t *image, freerdp_p
width = (damage->extents.x2 - damage->extents.x1);
height = (damage->extents.y2 - damage->extents.y1);
 
+#ifdef HAVE_SKIP_COMPRESSION
+   cmd->skipCompression = TRUE;
+#else
+   memset(cmd, 0, sizeof(*cmd));
+#endif
cmd->destLeft = damage->extents.x1;
cmd->destTop = damage->extents.y1;
cmd->destRight = damage->extents.x2;
@@ -248,6 +265,11 @@ rdp_peer_refresh_raw(pixman_region32_t *region, 
pixman_image_t *image, freerdp_p
marker->frameAction = SURFACECMD_FRAMEACTION_BEGIN;
update->SurfaceFrameMarker(peer->context, marker);
 
+#ifdef HAVE_SKIP_COMPRESSION
+   cmd->skipCompression = FALSE;
+#else
+   memset(cmd, 0, sizeof(*cmd));
+#endif
cmd->bpp = 32;
cmd->codecID = 0;
 
@@ -592,6 +614,7 @@ rdp_peer_context_free(freerdp_peer* client, RdpPeerContext* 
context)
weston_seat_release_pointer(&context->item.seat);
weston_seat_release(&context->item.seat);
}
+
Stream_Free(context->encode_stream, TRUE);
nsc_context_free(context->nsc_context);
rfx_context_free(context->rfx_context);
@@ -757,23 +780,26 @@ static char *rdp_keyboard_types[] = {
 };
 
 static BOOL
-xf_peer_post_connect(freerdp_peer* client)
+xf_peer_activate(freerdp_peer* client)
 {
RdpPeerContext *peerCtx;
struct rdp_compositor *c;
struct rdp_output *output;
rdpSettings *settings;
rdpPointerUpdate *pointer;
+   struct rdp_peers_item *peersItem;
struct xkb_context *xkbContext;
struct xkb_rule_names xkbRuleNames;
struct xkb_keymap *keymap;
int i;
pixman_box32_t box;
pixman_region32_t damage;
+   char seat_name[50];
 
 
peerCtx = (RdpPeerContext *)client->context;
c = peerCtx->rdpCompositor;
+   peersItem = &peerCtx->item;
output = c->output;
settings = client->settings;
 
@@ -813,7 +839,14 @@ xf_peer_post_connect(freerdp_peer* client)
}
}
 
-   weston_log("kbd_layout:%x kbd_type:%x kbd_subType:%x 
kbd_functionKeys:%x\n",
+   rfx_context_reset(peerCtx->rfx_context);
+   nsc_context_reset(peerCtx->nsc_context);
+
+   if (peersItem->flags & RDP_PEER_ACTIVATED)
+   return TRUE;
+
+   /* when here it's the first reactivation, we need to setup a little 
more */
+   weston_log("kbd_layout:0x%x kbd_type:0x%x kbd_subType:0x%x 
kbd_functionKeys:0x%x\n",
settings->KeyboardLayout, settings->KeyboardType, 
settings->KeyboardSubType,
settings->KeyboardFunctionKey);
 
@@ -840,10 +873,17 @@ xf_peer_post_c

Re: [PATCH] RDP compositor: fixes for multiple connections and mstsc

[Hardening]

Le 02/02/2015 21:03, John Obaterspok a écrit :
> Hello,
> 
> I had a bit problem to apply the patch. I tried both 1.6.0 and weston git. 
> Finally I went to patch the 1.6.0 version I have in Fedora 21.
> 
> I needed to comment out the cmd->skipCompression = FALSE;

I have a patch for this.

> 
> freerdp-devel-1.2.0-0.2.beta.1.fc21.x86_64
> #define FREERDP_VERSION_MAJOR 1
> #define FREERDP_VERSION_MINOR 2
> #define FREERDP_VERSION_REVISION 0
> #define FREERDP_VERSION_SUFFIX "beta1"
> #define FREERDP_API_VERSION "1.2"
> #define FREERDP_VERSION "1.2.0"
> #define FREERDP_VERSION_FULL "1.2.0-beta1"
> #define GIT_REVISION "n/a"
> 
> Then I needed to comment out the below line which had undefined function
> for me:
> nsc_context_reset(peerCtx->nsc_context);
> 
Hum I don't know what's wrong withe the version of FreeRdp shipped with
fedora 21, as nsc_context_reset() is there from a really long time. I'll
try to workaround that but without promise (got to install a fedora 21
to see what's going no). Using FreeRDP master could be a good option.


> I tried to run "weston -Brdp-backend.so" with these modifications.
> Weston started, I failed to connect (mstsc client just waited for ever),
> but no crash occured in weston.
> 
Have you certificates configured ? any relevant logs ?

Regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH v2 weston] input: Don't test keyboard/pointer/touch pointers

[Hardening]

Le 02/02/2015 22:24, Derek Foreman a écrit :
> Thanks for looking at this rather cumbersome patch! :)
> 
> On 02/02/15 01:40 PM, Bill Spitzak wrote:
>> Is there a reason it does not just clear the pointer when
>> keyboard_device_count is changed to zero? That would seem like a smaller
>> patch.
> 
> Pulled Jonas Ådahl in on the CC for that question...  I understand why
> weston_pointer isn't freed when released, but is there a need for the
> same behavior for weston_keyboard and weston_touch?
> 

I had a discussion on this on IRC, and the reason is that we wanna save
the last position of the pointer. I'm not sure it's a valid argument, as
the counter part is that the cleaning of pointer, keyboard and touch is
not done, or done partially. Not so nice for weston, a reference
implementation, the code should be straightforward and here it's not.

My opinion is that this last position should be stored in the seat, and
restored when a new pointer is bound to the seat.

I will propose patches on seat releasing, that appears to be hard if not
impossible to do safely right now.

Regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

[PATCH] RDP compositor: fixes for multiple connections and mstsc

[Hardening]

This patch fixes the problem reported on the mailing list
(http://lists.freedesktop.org/archives/wayland-devel/2015-January/019575.html).
All certificate and key paths were not copied when given to FreeRDP, so they
were freed when the peer was disconnecting. And so the next connection was 
failing.

All the initialization stuffs have been moved to the activate callback, as when 
it is
called the peer is ready for graphics.

We also differ the creation of the seat, so that a seat is initialized only the
peer really do the activation sequence. That helps when mstsc just connects to 
see
the certificate, ask if the certificate should be trusted, and then reconnects.

This patch also adds configuration settings for recent versions of FreeRDP that
comes with everything disabled. This makes remoteFx functionnal again.

The patch also handles the skipCompression flag for last FreeRDP versions, that
allows to skip bulk compression for surfaces that have been already compressed 
by
the remoteFx or NS codec.
---
 src/compositor-rdp.c | 78 ++--
 1 file changed, 57 insertions(+), 21 deletions(-)

diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index 1c3f988..555b19d 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -35,6 +35,10 @@
 #define FREERDP_VERSION_MINOR 1
 #endif
 
+#if (FREERDP_VERSION_MAJOR * 0x100 + FREERDP_VERSION_MINOR) >= 0x102
+#define HAVE_SKIP_COMPRESSION
+#endif
+
 #include 
 #include 
 #include 
@@ -153,6 +157,9 @@ rdp_peer_refresh_rfx(pixman_region32_t *damage, 
pixman_image_t *image, freerdp_p
cmd->codecID = peer->settings->RemoteFxCodecId;
cmd->width = width;
cmd->height = height;
+#ifdef HAVE_SKIP_COMPRESSION
+   cmd->skipCompression = TRUE;
+#endif
 
ptr = pixman_image_get_data(image) + damage->extents.x1 +
damage->extents.y1 * 
(pixman_image_get_stride(image) / sizeof(uint32_t));
@@ -205,6 +212,9 @@ rdp_peer_refresh_nsc(pixman_region32_t *damage, 
pixman_image_t *image, freerdp_p
cmd->codecID = peer->settings->NSCodecId;
cmd->width = width;
cmd->height = height;
+#ifdef HAVE_SKIP_COMPRESSION
+   cmd->skipCompression = TRUE;
+#endif
 
ptr = pixman_image_get_data(image) + damage->extents.x1 +
damage->extents.y1 * 
(pixman_image_get_stride(image) / sizeof(uint32_t));
@@ -250,6 +260,10 @@ rdp_peer_refresh_raw(pixman_region32_t *region, 
pixman_image_t *image, freerdp_p
 
cmd->bpp = 32;
cmd->codecID = 0;
+#ifdef HAVE_SKIP_COMPRESSION
+   cmd->skipCompression = FALSE;
+#endif
+
 
for (i = 0; i < nrects; i++, rect++) {
/*weston_log("rect(%d,%d, %d,%d)\n", rect->x1, rect->y1, 
rect->x2, rect->y2);*/
@@ -592,6 +606,7 @@ rdp_peer_context_free(freerdp_peer* client, RdpPeerContext* 
context)
weston_seat_release_pointer(&context->item.seat);
weston_seat_release(&context->item.seat);
}
+
Stream_Free(context->encode_stream, TRUE);
nsc_context_free(context->nsc_context);
rfx_context_free(context->rfx_context);
@@ -757,23 +772,26 @@ static char *rdp_keyboard_types[] = {
 };
 
 static BOOL
-xf_peer_post_connect(freerdp_peer* client)
+xf_peer_activate(freerdp_peer* client)
 {
RdpPeerContext *peerCtx;
struct rdp_compositor *c;
struct rdp_output *output;
rdpSettings *settings;
rdpPointerUpdate *pointer;
+   struct rdp_peers_item *peersItem;
struct xkb_context *xkbContext;
struct xkb_rule_names xkbRuleNames;
struct xkb_keymap *keymap;
int i;
pixman_box32_t box;
pixman_region32_t damage;
+   char seat_name[50];
 
 
peerCtx = (RdpPeerContext *)client->context;
c = peerCtx->rdpCompositor;
+   peersItem = &peerCtx->item;
output = c->output;
settings = client->settings;
 
@@ -813,7 +831,14 @@ xf_peer_post_connect(freerdp_peer* client)
}
}
 
-   weston_log("kbd_layout:%x kbd_type:%x kbd_subType:%x 
kbd_functionKeys:%x\n",
+   rfx_context_reset(peerCtx->rfx_context);
+   nsc_context_reset(peerCtx->nsc_context);
+
+   if (peersItem->flags & RDP_PEER_ACTIVATED)
+   return TRUE;
+
+   /* when here it's the first reactivation, we need to setup a little 
more */
+   weston_log("kbd_layout:0x%x kbd_type:0x%x kbd_subType:0x%x 
kbd_functionKeys:0x%x\n",
settings->KeyboardLayout, settings->KeyboardType, 
settings->KeyboardSubType,
settings->KeyboardFunctionKey);
 
@@ -840,10 +865,17 @@ xf_peer_post_connect(freerdp_peer* client)
 
keymap = xkb_keymap_new_from_names(xkbContext, &xkbRuleNames, 
0);
}
-   weston_seat_init_keyboard(&peerCtx->item.seat, keymap);
-   weston_seat_init_pointer(&peerCtx->item.seat);
 
-   peerCtx->item.flags |= RDP_PEER_ACTIVAT

Re: [PATCH weston] input: Don't test keyboard/pointer/touch pointers

[Hardening]

Le 29/01/2015 18:39, Derek Foreman a écrit :
> Keyboards and pointers aren't freed when devices are removed,
> so we should really be testing keyboard_device_count and
> pointer_device_count in most cases, not the actual pointers.
> Otherwise we end up with different behaviour after removing a
> device than we had before it was inserted.
> 
> There are some cases (new device setup) where the pointers still
> need to be tested directly.
> 

Hello Derek,
I have tested your patch and for me it doesn't solve the problem of
disappearing seats. I have a quite simple test case to reproduce seat
arrival / leaving:
* launch weston with valgrind (to have it really slow) => valgrind
./weston --backend=rdp-backend.so --port=3389 --rdp-tls-cert=cert.pem
--rdp-tls-key=private.pem --width=800 --height=600 ;
* launch a lot of xfreerdp connections => for x in `seq 0 10`; do
xfreerdp `hostname` & done ;
* when a new xfreerdp window appears kill a previous one, and...

crash !!!

I have added some weston_log(), printing when a seat is freed and when a
seat is retrieved using wl_resource_get_user_data(). And for me the
problem is that we retrieve a released seat pointer, so IMHO accessing
seat->keyboard_device_count instead of seat->keyboard will not solve the
root cause of the problem. On IRC people seemed to confirm this.

Anyway I don't really see how to fix that !

Regards

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: Is the RDP backend suppose to work?

[Hardening]

Le 24/01/2015 20:00, John Obaterspok a écrit :
> Hello,
> 
> I've tried for quite some time to get the RDP backend going. Perhaps
> it's just me that's not setting things up correctly. I'm trying this on
> a updated 64-bit Fedora 21 box that has Wayland 1.6 and
> freerdp-1.2.0-0.2.beta.1.fc21.x86_64.
> 
Yes it is supposed to work, I will give it a try with mstsc. I'm
suspecting the "scan certificate connexion" to have corrupted things.

Regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [RFC weston 00/15] libweston

[Hardening]

Le 13/11/2014 21:07, Giulio Camuffo a écrit :
> 2014-11-13 21:56 GMT+02:00 Bryce Harrington :
>> On Thu, Nov 06, 2014 at 10:41:19PM +0200, Giulio Camuffo wrote:
>>> This patchset makes a libweston.so out of the compositor core, thought
>>> to be used by many different users.
>>
>> Who are thought be the users for this?
> 
> Well, my compositor for sure
> (https://github.com/giucam/orbital/tree/libwestonv2), and anything
> looking to be a Wayland compositor without too much hassle. I guess
> stuff like the more minimal X11 window managers like openbox and the
> like would be a user of this.
> While they could be also a shell plugin for weston, that's quite
> suboptimal. They don't have their own executable, they can't use stuff
> like Qt since they don't have a place to start its event loop, and
> they have in general less control.
> 
> 

The RDP part looks good to me.

Regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 2/4] event-loop.c: Use correct OS abstraction function for dupfd()

[Hardening]

Le 01/11/2014 18:06, Philip Withnall a écrit :
> Signed-off-by: Philip Withnall 
> Signed-off-by: Karsten Otto 
> ---
>  src/event-loop.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/event-loop.c b/src/event-loop.c
> index a149db9..1f571ba 100644
> --- a/src/event-loop.c
> +++ b/src/event-loop.c
> @@ -134,7 +134,7 @@ wl_event_loop_add_fd(struct wl_event_loop *loop,
>   return NULL;
>  
>   source->base.interface = &fd_source_interface;
> - source->base.fd = fcntl(fd, F_DUPFD_CLOEXEC, 0);
> + source->base.fd = wl_os_dupfd_cloexec(fd, 0);
>   source->func = func;
>   source->fd = fd;
>  
Reviewed-by: David Fort 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH] shell: fix weston_output_mode_switch() usage

[Hardening]

Le 23/09/2014 09:37, Pekka Paalanen a écrit :
> On Mon, 22 Sep 2014 11:01:10 -0500
> Derek Foreman  wrote:
> 
>> On 22/09/14 06:41 AM, Pekka Paalanen wrote:
>>> On Fri, 19 Sep 2014 14:43:23 -0500
>>> Derek Foreman  wrote:
>>>
>>>> Calling weston_output_mode_switch() with WESTON_MODE_SWITCH_RESTORE_NATIVE
>>>> will result in the mode being set "back" to the passed in mode - so the

[...]

> No, its really all clients. Even the fullscreen client does not know if
> the temporary mode change it requested actually happened.
> 
>>> Therefore: pushed. Feel free to refactor the code in a follow-up,
>>> IMHO. ;-)
>>
>> Ok, I'll try to get to that in the next couple of days.
> 
> Thank you.
> 
> Hardening, could you keep an eye here and make sure we don't break
> anything for the RDP backend or such?
> 

Yes of course. IIRC at the time we had already suggested to split and
rework the function.

> I believe some of the details here are only to cater for RDP, like
> non-enumerable modes.
> 
I may be wrong but I remember a conversation where someone was telling
that DRM also have arbitrary modes...

Regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: Keysym event in the text protocol

[Hardening]

Le 25/07/2014 22:08, Bill Spitzak a écrit :
> On 07/25/2014 11:59 AM, Daniel Stone wrote:
>> Since you're just repeating yourself without taking on anything that's
>> been said, so will I: that won't work.
> 
> This I am finding hard to believe.
> 
> My proposal is that the compositor maintain a xkb_state, and keystroke
> events have the result of xkb_state_key_get_syms(),
> xkb_state_key_get_consumed_mods(), etc added to them. Note the keycode
> is still there in the event.
> 
> For RDP this would be run on the actual machine that has the keyboard
> hardware and thus has access to the keyboard layout information.

Not sure to understand about RDP. In RDP the the client sends some
informations describing the layout, and sent keycodes are in fact
"virtual keycodes" that are to be interpreted regarding the layout (not
even talking of different kind of keyboards mac / pc). That's why in the
RDP compositor we try to find a nice xkb file for a given RDP layout (so
keycodes will be translated to evdev layout at the end).

Regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH V2] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

[Hardening]

Le 25/06/2014 16:09, Alvaro Fernando García a écrit :
> Init cursor size to 64x64 if drmGetCap() fails.
> 
> Use Mesa GBM_BO_USE_CURSOR define (which removes 64x64 restriction)
> 
> Signed-off-by: Alvaro Fernando García 
> ---
>  src/compositor-drm.c | 43 ---
>  1 file changed, 36 insertions(+), 7 deletions(-)
> 
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 7d514e4..61ddea1 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -55,6 +55,14 @@
>  #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
>  #endif
>  
> +#ifndef DRM_CAP_CURSOR_WIDTH
> +#define DRM_CAP_CURSOR_WIDTH 0x8
> +#endif
> +
> +#ifndef DRM_CAP_CURSOR_HEIGHT
> +#define DRM_CAP_CURSOR_HEIGHT 0x9
> +#endif
> +
>  static int option_current_mode = 0;
>  
>  enum output_config {
> @@ -108,6 +116,9 @@ struct drm_compositor {
>  
>   clockid_t clock;
>   struct udev_input input;
> +
> + uint32_t cursor_width;
> + uint32_t cursor_height;
>  };
>  
>  struct drm_mode {
> @@ -987,7 +998,7 @@ drm_output_set_cursor(struct drm_output *output)
>   (struct drm_compositor *) output->base.compositor;
>   EGLint handle, stride;
>   struct gbm_bo *bo;
> - uint32_t buf[64 * 64];
> + uint32_t buf[c->cursor_width * c->cursor_height];

I didn't check, just asking:
are we sure that cursor_width and cursor_height are controlled values ?
Because if they're coming from the user without checks, we could have a
nice stack or int overflow here.

Regards
-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH] weston: Fix memleak issue in compositor.c

[Hardening]

Le 27/05/2014 11:00, Srivardhan Hebbar a écrit :
> This fix is upon "Hardening " patch. [PATCH 2/2] Handle 
> OOM with signal events.
> 
LGTM

Reviewed-by: Hardening 

> Signed-off-by: Srivardhan Hebbar 
> ---
>  src/compositor.c |   23 +--
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/src/compositor.c b/src/compositor.c
> index 574db2d..f233101 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -4207,6 +4207,11 @@ int main(int argc, char *argv[])
>   signals[3] = wl_event_loop_add_signal(loop, SIGCHLD, sigchld_handler,
> NULL);
>  
> + if (!signals[0] || !signals[1] || !signals[2] || !signals[3]) {
> + ret = EXIT_FAILURE;
> + goto out_signals;
> + }
> +
>   if (noconfig == 0)
>   config = weston_config_parse("weston.ini");
>   if (config != NULL) {
> @@ -4234,13 +4239,16 @@ int main(int argc, char *argv[])
>  
>   backend_init = weston_load_module(backend, "backend_init");
>   free(backend);
> - if (!backend_init)
> - exit(EXIT_FAILURE);
> + if (!backend_init) {
> + ret = EXIT_FAILURE;
> + goto out_signals;
> + }
>  
>   ec = backend_init(display, &argc, argv, config);
>   if (ec == NULL) {
>   weston_log("fatal: failed to create compositor\n");
> - exit(EXIT_FAILURE);
> + ret = EXIT_FAILURE;
> + goto out_signals;
>   }
>  
>   catch_signals();
> @@ -4321,12 +4329,15 @@ int main(int argc, char *argv[])
>  
>   wl_signal_emit(&ec->destroy_signal, ec);
>  
> - for (i = ARRAY_LENGTH(signals); i;)
> - wl_event_source_remove(signals[--i]);
> -
>   weston_compositor_xkb_destroy(ec);
>  
>   ec->destroy(ec);
> +
> +out_signals:
> + for (i = ARRAY_LENGTH(signals) - 1; i >= 0; i--)
> + if (signals[i])
> + wl_event_source_remove(signals[i]);
> +
>   wl_display_destroy(display);
>  
>   weston_log_file_close();
> 


-- 
David FORT
website: http://www.hardening-consulting.com/

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

Re: [PATCH 0/2] RDP Keyboard

[Hardening]

Le 26/05/2014 17:22, Hardening a écrit :
> I'm resending this serie of patches that are related to keyboard with the RDP
> compositor. The first one make weston support more RDP keyboard (RDP to Xkb
> convertion). The second make use of buildin FreeRDP functions instead of 
> reinventing
> the wheel.
> 
> I didn't had many feedback for these at the last sending, so if nobody's 
> against I 
> will commit them.
> 
> Hardening (2):
>   Add more keyboards for the RDP compositor
>   Use FreeRDP buildin functions to get scancodes
> 
>  src/compositor-rdp.c | 156 
> +--
>  1 file changed, 126 insertions(+), 30 deletions(-)
> 

I have commited these two.

Regards.

-- 
David FORT
website: http://www.hardening-consulting.com/

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

[PATCH 2/2] Use FreeRDP buildin functions to get scancodes

[Hardening]

This patch make use of the functions available in FreeRDP to retrieve
the scancode to inject.
---
 src/compositor-rdp.c | 24 ++--
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index 437954f..b749129 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -822,6 +822,8 @@ xf_peer_post_connect(freerdp_peer* client)
if (rdp_keyboards[i].rdpLayoutCode == settings->KeyboardLayout) 
{
xkbRuleNames.layout = rdp_keyboards[i].xkbLayout;
xkbRuleNames.variant = rdp_keyboards[i].xkbVariant;
+   weston_log("%s: matching layout=%s variant=%s\n", 
__FUNCTION__,
+   xkbRuleNames.layout, 
xkbRuleNames.variant);
break;
}
}
@@ -952,17 +954,6 @@ xf_input_synchronize_event(rdpInput *input, UINT32 flags)
pixman_region32_fini(&damage);
 }
 
-extern DWORD KEYCODE_TO_VKCODE_EVDEV[];
-static uint32_t vk_to_keycode[256];
-static void
-init_vk_translator(void)
-{
-   int i;
-
-   memset(vk_to_keycode, 0, sizeof(vk_to_keycode));
-   for(i = 0; i < 256; i++)
-   vk_to_keycode[KEYCODE_TO_VKCODE_EVDEV[i] & 0xff] = i-8;
-}
 
 static void
 xf_input_keyboard_event(rdpInput *input, UINT16 flags, UINT16 code)
@@ -986,17 +977,15 @@ xf_input_keyboard_event(rdpInput *input, UINT16 flags, 
UINT16 code)
full_code |= KBD_FLAGS_EXTENDED;
 
vk_code = GetVirtualKeyCodeFromVirtualScanCode(full_code, 4);
-   if (vk_code > 0xff) {
-   weston_log("invalid vk_code %x", vk_code);
-   return;
-   }
-   scan_code = vk_to_keycode[vk_code];
+   if(flags & KBD_FLAGS_EXTENDED)
+   vk_code |= KBDEXT;
 
+   scan_code = GetKeycodeFromVirtualKeyCode(vk_code, 
KEYCODE_TYPE_EVDEV);
 
/*weston_log("code=%x ext=%d vk_code=%x scan_code=%x\n", code, 
(flags & KBD_FLAGS_EXTENDED) ? 1 : 0,
vk_code, scan_code);*/
notify_key(&peerContext->item.seat, 
weston_compositor_get_time(),
-   scan_code, keyState, 
STATE_UPDATE_AUTOMATIC);
+   scan_code - 8, keyState, 
STATE_UPDATE_AUTOMATIC);
}
 }
 
@@ -1188,7 +1177,6 @@ backend_init(struct wl_display *display, int *argc, char 
*argv[],
 
freerdp_get_version(&major, &minor, &revision);
weston_log("using FreeRDP version %d.%d.%d\n", major, minor, revision);
-   init_vk_translator();
 
const struct weston_option rdp_options[] = {
{ WESTON_OPTION_BOOLEAN, "env-socket", 0, &config.env_socket },
-- 
1.8.1.2

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

[PATCH 0/2] RDP Keyboard

[Hardening]

I'm resending this serie of patches that are related to keyboard with the RDP
compositor. The first one make weston support more RDP keyboard (RDP to Xkb
convertion). The second make use of buildin FreeRDP functions instead of 
reinventing
the wheel.

I didn't had many feedback for these at the last sending, so if nobody's 
against I 
will commit them.

Hardening (2):
  Add more keyboards for the RDP compositor
  Use FreeRDP buildin functions to get scancodes

 src/compositor-rdp.c | 156 +--
 1 file changed, 126 insertions(+), 30 deletions(-)

-- 
1.8.1.2

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

[PATCH 1/2] Add more keyboards for the RDP compositor

[Hardening]

This patch complements the table that contains matches between RDP
and xkb keyboard layouts. We now handle variants too.
---
 src/compositor-rdp.c | 132 ++-
 1 file changed, 120 insertions(+), 12 deletions(-)

diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index aecc0a8..437954f 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "compositor.h"
@@ -618,21 +619,127 @@ xf_peer_capabilities(freerdp_peer* client)
return TRUE;
 }
 
-
 struct rdp_to_xkb_keyboard_layout {
UINT32 rdpLayoutCode;
-   char *xkbLayout;
+   const char *xkbLayout;
+   const char *xkbVariant;
 };
 
-/* picked from http://technet.microsoft.com/en-us/library/cc766503(WS.10).aspx 
*/
-static struct rdp_to_xkb_keyboard_layout rdp_keyboards[] = {
-   {0x0406, "dk"},
-   {0x0407, "de"},
-   {0x0409, "us"},
-   {0x040c, "fr"},
-   {0x0410, "it"},
-   {0x0813, "be"},
-   {0x, 0},
+/* table reversed from
+   
https://github.com/awakecoding/FreeRDP/blob/master/libfreerdp/locale/xkb_layout_ids.c#L811
 */
+static
+struct rdp_to_xkb_keyboard_layout rdp_keyboards[] = {
+   {KBD_ARABIC_101, "ara", 0},
+   {KBD_BULGARIAN, 0, 0},
+   {KBD_CHINESE_TRADITIONAL_US, 0},
+   {KBD_CZECH, "cz", 0},
+   {KBD_CZECH_PROGRAMMERS, "cz", "bksl"},
+   {KBD_CZECH_QWERTY, "cz", "qwerty"},
+   {KBD_DANISH, "dk", 0},
+   {KBD_GERMAN, "de", 0},
+   {KBD_GERMAN_NEO, "de", "neo"},
+   {KBD_GERMAN_IBM, "de", "qwerty"},
+   {KBD_GREEK, "gr", 0},
+   {KBD_GREEK_220, "gr", "simple"},
+   {KBD_GREEK_319, "gr", "extended"},
+   {KBD_GREEK_POLYTONIC, "gr", "polytonic"},
+   {KBD_US, "us", 0},
+   {KBD_US_ENGLISH_TABLE_FOR_IBM_ARABIC_238_L, "ara", "buckwalter"},
+   {KBD_SPANISH, "es", 0},
+   {KBD_SPANISH_VARIATION, "es", "nodeadkeys"},
+   {KBD_FINNISH, "fi", 0},
+   {KBD_FRENCH, "fr", 0},
+   {KBD_HEBREW, "il", 0},
+   {KBD_HUNGARIAN, "hu", 0},
+   {KBD_HUNGARIAN_101_KEY, "hu", "standard"},
+   {KBD_ICELANDIC, "is", 0},
+   {KBD_ITALIAN, "it", 0},
+   {KBD_ITALIAN_142, "it", "nodeadkeys"},
+   {KBD_JAPANESE, "jp", 0},
+   {KBD_JAPANESE_INPUT_SYSTEM_MS_IME2002, "jp", "kana"},
+   {KBD_KOREAN, "kr", 0},
+   {KBD_KOREAN_INPUT_SYSTEM_IME_2000, "kr", "kr104"},
+   {KBD_DUTCH, "nl", 0},
+   {KBD_NORWEGIAN, "no", 0},
+   {KBD_POLISH_PROGRAMMERS, "pl", 0},
+   {KBD_POLISH_214, "pl", "qwertz"},
+   // {KBD_PORTUGUESE_BRAZILIAN_ABN0416, 0},
+   {KBD_ROMANIAN, "ro", 0},
+   {KBD_RUSSIAN, "ru", 0},
+   {KBD_RUSSIAN_TYPEWRITER, "ru", "typewriter"},
+   {KBD_CROATIAN, "hr", 0},
+   {KBD_SLOVAK, "sk", 0},
+   {KBD_SLOVAK_QWERTY, "sk", "qwerty"},
+   {KBD_ALBANIAN, 0, 0},
+   {KBD_SWEDISH, "se", 0},
+   {KBD_THAI_KEDMANEE, "th", 0},
+   {KBD_THAI_KEDMANEE_NON_SHIFTLOCK, "th", "tis"},
+   {KBD_TURKISH_Q, "tr", 0},
+   {KBD_TURKISH_F, "tr", "f"},
+   {KBD_URDU, "in", "urd-phonetic3"},
+   {KBD_UKRAINIAN, "ua", 0},
+   {KBD_BELARUSIAN, "by", 0},
+   {KBD_SLOVENIAN, "si", 0},
+   {KBD_ESTONIAN, "ee", 0},
+   {KBD_LATVIAN, "lv", 0},
+   {KBD_LITHUANIAN_IBM, "lt", "ibm"},
+   {KBD_FARSI, "af", 0},
+   {KBD_VIETNAMESE, "vn", 0},
+   {KBD_ARMENIAN_EASTERN, "am", 0},
+   {KBD_AZERI_LATIN, 0, 0},
+   {KBD_FYRO_MACEDONIAN, "mk", 0},
+   {KBD_GEORGIAN, "ge", 0},
+   {KBD_FAEROESE, 0, 0},
+   {KBD_DEVANAGARI_INSCRIPT, 0, 0},
+   {KBD_MALTESE_47_KEY, 0, 0},
+   {KBD_NORWEGIAN_WITH_SAMI, "no", "smi"},
+   {KBD_KAZAKH, "kz", 0},
+   {KBD_KYRGYZ_CYRILLIC, "kg", "phonetic"},
+   {KBD_TATAR, "ru", "tt"},
+   {KBD_BENGALI, "bd", 0},
+   {KBD_BENGALI_INSCRIPT, "bd", "probhat"},
+   {KBD_PUNJABI, 0, 0},
+   {KBD_GUJARATI, "in", "guj"},
+   {KBD_TAMIL, "in", "tam"},
+   {KBD_TELUGU, "in", "tel"},
+   {KBD_KANNADA, "in", "kan"},
+   {KBD_MALAYALAM, "in", "mal"},
+   {KBD_HINDI_TRADITIONAL, "in", 0},
+   {KBD_MARATHI, 0, 0},
+   {KBD_MONGOLIAN_CYRILLIC, "mn", 0},
+   {KBD_UNITED_KINGDOM_EXTENDED, "gb", "intl"},
+   {KBD_SYRIAC, "syc", 0},
+   {KBD_SYRIAC_PHONETIC, "syc", "syc_phonetic"},
+   {KBD_NEPALI, "np", 0},
+   {KBD_PASHTO, "af", "ps"},
+   {KBD_DIVEHI_PHONETIC, 0, 0},
+   {KBD_LUXEMBOURGISH, 0, 0},
+   {KBD_MAORI, "mao", 0},
+   {KBD_CHINESE_SIMPLIFIED_US, 0, 0},
+   {KBD_SWISS_GERMAN, "ch", "de_nodeadkeys"},
+   {KBD_UNITED_KINGDOM, "gb", 0},
+   {KBD_LATIN_AMERICAN, "latam", 0},
+   {KBD_BELGIAN_FRENCH, "be", 0},
+   {KBD_BELGIAN_PERIOD, "be", "oss_sundeadkeys"},
+   {KBD_PORTUGUESE, "pt", 0},
+   {KBD_SERBIAN_LATIN, "rs", 0},
+   {KBD_AZERI_CYRILLIC, "az", "cyrillic"},
+   {KBD_SWEDISH_WITH_SA

Re: [PATCH] protocol: remove redundant 'the' in description

[Hardening]

Le 23/05/2014 09:14, Pekka Paalanen a écrit :

On Fri, 23 May 2014 03:04:29 -0400
"Jasper St. Pierre"  wrote:


On Fri, May 23, 2014 at 2:49 AM, Pekka Paalanen  wrote:



[...]



This is obviously correct.

Can I push this, or shall we reserve the right to push to libwayland
for Kristian only, even for "obviously trivial" patches?



If you received permissions to push, I don't see why you shouldn't.
Kristian trusts you enough to add you to the list of committers, so I think
he can trust your judgement on stuff like this.


The talk was only about Weston AFAIU. I don't know if libwayland is
actually open for the group 'wayland' to push. Even if it was open
by access permissions on the server, I still want to be sure that I am
allowed (in the social sense) to push.

Like I have access to the Mesa repo from years ago, but I'm still not
allowed to push without proper review process which is defined by the
Mesa project.

The process for libwayland is still unclear to me, hence my question.



Hello Pekka,

quotes from the 1.5 release mail:
Being able to review *and* commit a patch will hopefully increase the
incentive to review and I won't need to be around all the time for
things to move forwards.  I think everybody has enough common sense to
decide when something is a quick fix that can be committed right away
and when something needs wider discussion and concensus.  For anything
that touches core weston and in particular, anything that adds
protocol, we still want to see patches, reviews and discussion the
list before committing.

So I think you can go with this trivial fix.

Regards.

PS: does someone know how to check if write access to a git repo is 
effective without doing some changes in it ?


--
David FORT
website: http://www.hardening-consulting.com/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Wayland and Weston 1.5.0 is released

[Hardening]

Le 20/05/2014 22:12, Kristian Høgsberg a écrit :

Hi,



[...]



Going forward, for master, I'd like to change the work flow a bit.
The biggest problem with how we work today is me being a bottleneck at
best or flat out dropping patches.  So I'd like to open up commit
access to some of the key contributors.  Either people that have their
corner of weston that they maintain (for example Pekka and the
Raspberry Pi backend or Hardening and the RDP backend) or contributors
who have been part of the project for a while and understands the code
base well - or both.



Hi,

congratulations for the release. Thank you for trusting me as a RDP 
compositor maintainer. Just like Pekka, I will be happy to handle RDP 
oriented patches after review on the list.


Best regards.
--
David FORT
website: http://www.hardening-consulting.com/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH V2] event: assert wl_event_source pointer is NULL.

[Hardening]

Le 12/05/2014 07:56, Srivardhan Hebbar a écrit :

Signed-off-by: Srivardhan Hebbar 
---
  src/event-loop.c |6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/event-loop.c b/src/event-loop.c
index 9790cde..57e3fed 100644
--- a/src/event-loop.c
+++ b/src/event-loop.c
@@ -312,7 +312,11 @@ wl_event_source_check(struct wl_event_source *source)
  WL_EXPORT int
  wl_event_source_remove(struct wl_event_source *source)
  {
-   struct wl_event_loop *loop = source->loop;
+   struct wl_event_loop *loop;
+
+   assert(!source);


Isn't it the opposite ?


+
+   loop = source->loop;

/* We need to explicitly remove the fd, since closing the fd
 * isn't enough in case we've dup'ed the fd. */



Regards
--
David FORT
website: http://www.hardening-consulting.com/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 2/2] Handle OOM with signal events

[Hardening]

This patch handles the case where a signal event source can not be created.
---
 src/compositor.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/src/compositor.c b/src/compositor.c
index 6ad3387..047df8a 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -4197,6 +4197,7 @@ int main(int argc, char *argv[])
display = wl_display_create();
 
loop = wl_display_get_event_loop(display);
+   memset(signals, 0, sizeof(signals));
signals[0] = wl_event_loop_add_signal(loop, SIGTERM, on_term_signal,
  display);
signals[1] = wl_event_loop_add_signal(loop, SIGINT, on_term_signal,
@@ -4208,6 +4209,9 @@ int main(int argc, char *argv[])
signals[3] = wl_event_loop_add_signal(loop, SIGCHLD, sigchld_handler,
  NULL);
 
+   if (!signals[0] || !signals[1] || !signals[2] || !signals[3])
+   goto out_signals;
+
config = weston_config_parse("weston.ini");
if (config != NULL) {
weston_log("Using config file '%s'\n",
@@ -4321,8 +4325,11 @@ int main(int argc, char *argv[])
 
wl_signal_emit(&ec->destroy_signal, ec);
 
-   for (i = ARRAY_LENGTH(signals); i;)
-   wl_event_source_remove(signals[--i]);
+ out_signals:
+   for (i = ARRAY_LENGTH(signals); i; i--) {
+   if (signals[i-1])
+   wl_event_source_remove(signals[i-1]);
+   }
 
weston_compositor_xkb_destroy(ec);
 
-- 
1.8.1.2

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

[PATCH 1/2] Set to NULL event source after a call to wl_event_source_remove

[Hardening]

This patch sets to NULL event sources after a call to wl_event_source_remove()
has been made.
---
 src/clipboard.c  | 3 ++-
 src/compositor-drm.c | 3 +++
 src/compositor-rpi.c | 1 +
 src/compositor-x11.c | 2 ++
 src/compositor.c | 6 +-
 src/evdev-touchpad.c | 1 +
 src/evdev.c  | 4 +++-
 src/libinput-seat.c  | 1 +
 src/logind-util.c| 2 ++
 xwayland/launcher.c  | 6 +-
 xwayland/selection.c | 9 +++--
 11 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/src/clipboard.c b/src/clipboard.c
index 5a3a02d..0e25dc1 100644
--- a/src/clipboard.c
+++ b/src/clipboard.c
@@ -61,6 +61,7 @@ clipboard_source_unref(struct clipboard_source *source)
 
if (source->event_source) {
wl_event_source_remove(source->event_source);
+   source->event_source = NULL;
close(source->fd);
}
wl_signal_emit(&source->base.destroy_signal,
@@ -90,8 +91,8 @@ clipboard_source_data(int fd, uint32_t mask, void *data)
len = read(fd, p, size);
if (len == 0) {
wl_event_source_remove(source->event_source);
-   close(fd);
source->event_source = NULL;
+   close(fd);
} else if (len < 0) {
clipboard_source_unref(source);
clipboard->source = NULL;
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 5f59789..0110f41 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -2379,7 +2379,9 @@ drm_destroy(struct weston_compositor *ec)
udev_input_destroy(&d->input);
 
wl_event_source_remove(d->udev_drm_source);
+   d->udev_drm_source = NULL;
wl_event_source_remove(d->drm_source);
+   d->drm_source = NULL;
 
destroy_sprites(d);
 
@@ -2849,6 +2851,7 @@ drm_compositor_create(struct wl_display *display,
 
 err_udev_monitor:
wl_event_source_remove(ec->udev_drm_source);
+   ec->udev_drm_source = NULL;
udev_monitor_unref(ec->udev_monitor);
 err_drm_source:
wl_event_source_remove(ec->drm_source);
diff --git a/src/compositor-rpi.c b/src/compositor-rpi.c
index 287451d..cbfb770 100644
--- a/src/compositor-rpi.c
+++ b/src/compositor-rpi.c
@@ -213,6 +213,7 @@ static void
 rpi_flippipe_release(struct rpi_flippipe *flippipe)
 {
wl_event_source_remove(flippipe->source);
+   flippipe->source = NULL;
close(flippipe->readfd);
close(flippipe->writefd);
 }
diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 56b3228..9f171e7 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -485,6 +485,7 @@ x11_output_destroy(struct weston_output *output_base)
(struct x11_compositor *)output->base.compositor;
 
wl_event_source_remove(output->finish_frame_timer);
+   output->finish_frame_timer = NULL;
 
if (compositor->use_pixman) {
pixman_renderer_output_destroy(output_base);
@@ -1424,6 +1425,7 @@ x11_destroy(struct weston_compositor *ec)
struct x11_compositor *compositor = (struct x11_compositor *)ec;
 
wl_event_source_remove(compositor->xcb_source);
+   compositor->xcb_source = NULL;
x11_input_destroy(compositor);
 
weston_compositor_shutdown(ec); /* destroys outputs, too */
diff --git a/src/compositor.c b/src/compositor.c
index cd1ca9a..6ad3387 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -3736,8 +3736,12 @@ weston_compositor_shutdown(struct weston_compositor *ec)
struct weston_output *output, *next;
 
wl_event_source_remove(ec->idle_source);
-   if (ec->input_loop_source)
+   ec->idle_source = NULL;
+
+   if (ec->input_loop_source) {
wl_event_source_remove(ec->input_loop_source);
+   ec->input_loop_source = NULL;
+   }
 
/* Destroy all outputs associated with this compositor */
wl_list_for_each_safe(output, next, &ec->output_list, link)
diff --git a/src/evdev-touchpad.c b/src/evdev-touchpad.c
index 69f913a..360f87f 100644
--- a/src/evdev-touchpad.c
+++ b/src/evdev-touchpad.c
@@ -663,6 +663,7 @@ touchpad_destroy(struct evdev_dispatch *dispatch)
 
touchpad->filter->interface->destroy(touchpad->filter);
wl_event_source_remove(touchpad->fsm.timer_source);
+   touchpad->fsm.timer_source = NULL;
free(dispatch);
 }
 
diff --git a/src/evdev.c b/src/evdev.c
index 888dfbd..a1bce2c 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -697,8 +697,10 @@ evdev_device_destroy(struct evdev_device *device)
if (dispatch)
dispatch->interface->destroy(dispatch);
 
-   if (device->source)
+   if (device->source) {
wl_event_source_remove(device->source);
+   device->source = NULL;
+   }
if (device->output)
wl_list_remove(&device->output_destroy_listener.link);
wl_list_remove(&device->link);
diff --git a/src/libinput-seat.c b/src/libinput-seat.c
index a38d470..34f1aab 100644
--

Re: [PATCH] event: Cheking for NULL before dereferencing the pointer.

[Hardening]

Le 09/05/2014 12:20, Pekka Paalanen a écrit :

On Fri, 09 May 2014 15:21:51 +0530
Srivardhan  wrote:





-Original Message-
From: Pekka Paalanen [mailto:ppaala...@gmail.com]
Sent: Friday, May 09, 2014 3:09 PM
To: Srivardhan
Cc: 'Hardening'; wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH] event: Cheking for NULL before dereferencing the
pointer.

On Fri, 09 May 2014 14:56:14 +0530
Srivardhan  wrote:



[...]



Checking is one thing, silently hiding bugs is another thing.

If NULL is a legal input, then of course it needs to be checked.

If NULL can happen, but is a runtime error, the program needs to be
vocal about it, e.g. relay the error back to the caller.

If API specification says NULL is not a valid input, putting an
assert() would be fine, since violating that is a programmer error in
the caller.

I think wl_event_source_remove() falls into the last category. All
functions in wayland-util.h belong to this category, too.



IMHO wl_event_source_remove() should take a wl_event_source ** as 
parameter and set to NULL the event_source pointer (preventing anyone 
to use it). Using eclipse call hierarchy, I've seen many places where 
this extra precaution is not taken.
I don't know if wl_event_source_remove() can be considered as part of 
the libwayland API and so fixed in stone ?


Regards.

--
David FORT
website: http://www.hardening-consulting.com/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] event: Cheking for NULL before dereferencing the pointer.

[Hardening]

Le 09/05/2014 08:43, Srivardhan Hebbar a écrit :

Checking for NULL before dereferencing the wl_event_source
pointer so as to avoid crash.

Signed-off-by: Srivardhan Hebbar 
---
  src/event-loop.c |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/event-loop.c b/src/event-loop.c
index 9790cde..b62d16e 100644
--- a/src/event-loop.c
+++ b/src/event-loop.c
@@ -312,7 +312,12 @@ wl_event_source_check(struct wl_event_source *source)
  WL_EXPORT int
  wl_event_source_remove(struct wl_event_source *source)
  {
-   struct wl_event_loop *loop = source->loop;
+   struct wl_event_loop *loop;
+
+   if (source == NULL)
+   return 0;
+
+   loop = source->loop;

/* We need to explicitly remove the fd, since closing the fd
 * isn't enough in case we've dup'ed the fd. */



Hello Srivardhan,

do you have a case where this check is hit ? I may be wrong but having 
no loop associated with a source event is not supposed to happen. So my 
guess is that a caller of wl_event_source_remove has forgotten to 
nullify the event source after the call.


Regards.

--
David FORT
website: http://www.hardening-consulting.com/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] connection: Don't write past the end of the connection buffer

[Hardening]

Le 17/04/2014 17:20, Ander Conselvan de Oliveira a écrit :

From: Ander Conselvan de Oliveira 

If a message was too big to fit in the connection buffer, the code
in wl_buffer_put would just write past the end of it.

I haven't seen any real world use case that would trigger this bug, but
it was possible to trigger it by sending a long enough string to the
wl_data_source.offer request.

https://bugs.freedesktop.org/show_bug.cgi?id=69267


Perhaps this should be marked as a security issue. If a wayland client 
can control an answer generated by the server, it would be able to 
overflow the buffer and corrupt the compositor's memory. I haven't check 
if it's not feasible.


Regards.

--
David FORT
website: http://www.hardening-consulting.com/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel