Re: [PATCH 00/15] weston scaling support

[Pekka Paalanen]

On Mon, 3 Jun 2013 16:21:48 +0200
John Kåre Alsaker  wrote:

> On Mon, Jun 3, 2013 at 2:22 PM, Pekka Paalanen  wrote:
> 
> > On Tue, 28 May 2013 19:27:35 +0200
> > John Kåre Alsaker  wrote:
> >
> > > + Conceptually simple to implement. Compositors doesn't have to deal with
> > > scaling for subsurfaces and they are probably already able to resize
> > whole
> > > windows.
> >
> > Why would sub-surfaces have any effect here?
> >
> I have absolutely no idea how subsurfaces trees with different scaling
> factors on surfaces would work in Alexander's proposal. I simply don't
> allow specifying it on anything other than top level surfaces, which it
> uses for the whole surface tree.

The answer is: sub-surfaces do not interact with other surface's buffer
scaling AT ALL.

Everything except buffer sizes in the protocol are in pels. Sub-surface
positions are in pels. Sub-surface sizes are in pels. Whether a parent
surface or a sub-surface has some buffer scaling applied or not, does
not have ANY effect to anything else.

That's the trivial and obvious design. A buffer scale affects only that
one particular surface in how its buffer content is interpreted.
Nothing more.

It's the same with buffer_transform. If the parent had a transformed
buffer attached, it does not transform anything else.

This is actually quite vital. If there were any interactions, the use
of sub-surfaces would suddenly become extremely painful.


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

Re: [PATCH 00/15] weston scaling support

[John Kåre Alsaker]

 On Mon, Jun 3, 2013 at 10:21 PM, Bill Spitzak  wrote:

> + Clients get input in exact pixels (no rounding errors).
>> + Clients doesn't have to transform input events in order to match the
>>  sizes used by buffers.
>
> You said "pels" don't match buffer pixels. Therefore a transformation is
> needed to get to buffer pixels.

Clients can choose if this transformation is used.


> And I'm worried that high-resolution pointing devices will be ignored by
> clients that immediately round to the nearest buffer pixel.

Presumably they wouldn't use the high-resolution for anything then. I'm not
sure how this relates to the topic either.


>
>  - Clients changing scaling factors will have older input reported in the
>>> old size. This will be quite rare although clients can deal with it if
>>> desired.
>>> - Requires an implementation <:)
>>>
>>
> This seems to be the biggest actual objection, other than apparent
> misunderstanding of the proposal.
>
> However the same problem applies for when a buffer attach is done with an
> x and y offset. The client does not know exactly what mouse events are
> pointing at unless it knows whether they are before or after the commit.
>
> So I now think a better solution is to have the compositor echo the commit
> in the event stream, so the client can easily tell whether events are
> before or after it. It is possible that existing events can be used to
> determine this.
>
I believe the frame callback event can be used to tell when you get the
events from the new frame.

On Mon, Jun 3, 2013 at 11:56 PM, Jason Ekstrand wrote:

> I think I'm begining to see what you and John have been suggesting.  While
> I think Alexander's proposal will work well enough for the standard case, I
> think this also has merit.  If I were to sum up, I'd say I was "cautiously
> supportive" of the above.  It does seem to solve some of the edge-cases.
> That said, there are a few things I'd like to note.
>
> 1. This requires a concept of a "window" which is one we currently don't
> have.  If we put it in wl_surface, we have to define how it works for
> subsurfaces.  We could say that the scale factor on subsurfaces gets
> ignored.  However, this means that we have defined an extension-specific
> exception.  What happens if we add another future extension that alters the
> window's size or orientation?  This will get messy.  We could put this in
> wl_shell_surface but then we are mixing the global (wl_output) with the
> desktop-specific (wl_shell_surface).
>
The concept of window I refer to is just regular a wl_surface really. With
the subsurface extension added in it breaks this concept so an exception in
this extension is required. This is just a side effect of adding
subsurfaces as an afterthought and not having a separate window object in
the protocol. I'm sure there's quite a few other things we can't do with
subsurfaces already.


> 2. This restricts subsurfaces to the same scaling factor as the original
> surface.  Probably not a huge problem, but I'm not convinced it's a smaller
> restriction than requiring subsurfaces on pel-boundaries.
>
I don't think that's going to be a problem. If the client for some reason
want to mix scaling factors, it can resize the subsurface itself.


>
> 3. This makes the subsurface case of handing off to a library more
> complicated.  In Alexander's implementation, the library would simply
> render at native resolution or not.  With this, the client has to tell the
> library what surface scale to use and the library has to *EXACTLY* match.
> Maybe this isn't a huge issue, but there's no opportunity for a client to
> embed an older library.
>
The client can always resize the output of the library. It's just another
side of thing 2 really.


> 4. If a client presents a scale_factor to the compositor that is not an
> integer multiple of one of the ouput_scale factors provided by the
> compositor, it should not expect the compositor to do anything
> intelligent.  There are similar problems with integer proposal, but this
> one makes it more interesting.
>
It should expect the compositor to resize the window accordingly to it's
policies. The client remains blissfully unaware of whatever that has been
done. I don't see how this is a issue with either proposal.


>
> Food for thought,
> --Jason Ekstrand
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Avoid unnecessarily re-allocating texture buffer when the size hasn't changed.

[Kristian Høgsberg]

On Tue, May 28, 2013 at 05:28:49PM -0700, Sinclair Yeh wrote:
> v3:
> * Removed unnecessary parentheses
> * Added check for switching from EGL image to SHM buffer
> * Moved shader assignment out of IF condition
> 
> v2:
> Fixed the wrong comparison
> 
> v1:
> Depending on specific DRI driver implementation, glTexImage2D() with data
> set to NULL may or may not re-allocate the texture buffer each time it is
> called.  Unintended consequences happen if later glTexSubImage2D() is called
> to only update a sub-region of the texture buffer.
> 
> I've explored moving glTexImage2D() from gl_renderer_attach() and simply
> mark the texture dirty, but the current implemention seems cleaner because
> I won't have to worry about calling ensure_textures() and re-assigning
> gs->shader unnecessarily.
> ---
>  src/gl-renderer.c |   31 +++
>  1 files changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/src/gl-renderer.c b/src/gl-renderer.c
> index be74eba..aa8f581 100644
> --- a/src/gl-renderer.c
> +++ b/src/gl-renderer.c
> @@ -68,6 +68,7 @@ struct gl_surface_state {
>  
>   struct weston_buffer_reference buffer_ref;
>   int pitch; /* in pixels */
> + int height;
>  };
>  
>  struct gl_renderer {
> @@ -1213,18 +1214,31 @@ gl_renderer_attach(struct weston_surface *es, struct 
> wl_buffer *buffer)
>   }
>  
>   if (wl_buffer_is_shm(buffer)) {
> - gs->pitch = wl_shm_buffer_get_stride(buffer) / 4;
> - gs->target = GL_TEXTURE_2D;
> + /* Only allocate a texture if it doesn't match existing one.
> +  * If gs->num_images is not 0, then a switch from DRM allocated
> +  * buffer to a SHM buffer is happening, and we need to allocate
> +  * a new texture buffer.
> +  */
> + if (wl_shm_buffer_get_stride(buffer) / 4 != gs->pitch ||
> + buffer->height != gs->height ||
> + gs->num_images > 0) {
> + gs->pitch = wl_shm_buffer_get_stride(buffer) / 4;
> + gs->height = buffer->height;
> + gs->target = GL_TEXTURE_2D;
> +
> + ensure_textures(gs, 1);
> + glBindTexture(GL_TEXTURE_2D, gs->textures[0]);
> + glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
> +  gs->pitch, buffer->height, 0,
> +  GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);

Looking better now, but we still need to make sure we do a full upload
before we repaint.  If a client is clever about it's resizing and only
posts a partial damage request after attaching the new buffer, we end
up reallocating the texture storage but not uploading the full
contents.

However, weird behavior #1: This shouldn't happen with any of the
clients I have (they all post full damage on resize), yet, I still see
flicker when resizing.

Weird behavior #2: The fix should be something like this:

+   pixman_region32_union_rect(&gs->texture_damage,
+  &gs->texture_damage,
+  0, 0,
+  es->geometry.width,
+  es->geometry.height);

after the glTexImage2D call, to make sure we upload all of the
texture.  Instead of always uploading the contents (which would upload
twice: immediately and then when we flush damage), we add the new
surface rectangle to texture_damage.  However, when I add that, the
window contents just sometimes completely disappears...

This is what's holding up the patch - I don't have a lot of time to
look into it right now, but it is something I want to get in this week
so any help is apprecaited.

Kristian

> + }
>  
> - ensure_textures(gs, 1);
> - glBindTexture(GL_TEXTURE_2D, gs->textures[0]);
> - glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
> -  gs->pitch, buffer->height, 0,
> -  GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);
> - if (wl_shm_buffer_get_format(buffer) == WL_SHM_FORMAT_XRGB)
> + if (wl_shm_buffer_get_format(buffer) ==
> + WL_SHM_FORMAT_XRGB)
>   gs->shader = &gr->texture_shader_rgbx;
>   else
>   gs->shader = &gr->texture_shader_rgba;
> +
>   } else if (gr->query_buffer(gr->egl_display, buffer,
>   EGL_TEXTURE_FORMAT, &format)) {
>   for (i = 0; i < gs->num_images; i++)
> @@ -1279,6 +1293,7 @@ gl_renderer_attach(struct weston_surface *es, struct 
> wl_buffer *buffer)
>   }
>  
>   gs->pitch = buffer->width;
> + gs->height = buffer->height;
>   } else {
>   weston_log("unhandled buffer type!\n");
>   weston_buffer_reference(&gs->buf

[PATCH wfits] weston-wfits: Allow user to configure the input emulator

[U. Artie Eoff]

From: "U. Artie Eoff" 

The available emulators are "uinput" and "notify".  To choose
which emulator to use, define the environment variable:

WESTON_WFITS_INPUT_EMULATOR

equal to the name of the desired emulator before loading the
weston-wfits.so module into Weston.

For example:

 $ export WESTON_WFITS_INPUT_EMULATOR="notify"
 $ weston --modules=weston-wfits.so

If WESTON_WFITS_INPUT_EMULATOR is not defined in the environment
and Weston is using the headless-backend then weston-wfits.so will
choose "notify" by default.  Otherwise, it chooses "uinput" by
default.

Signed-off-by: U. Artie Eoff 
---
 src/extensions/weston/Makefile.am   |  1 +
 src/extensions/weston/input-emulator-notify.cpp |  2 +
 src/extensions/weston/input-emulator-notify.h   |  3 ++
 src/extensions/weston/input-emulator-uinput.cpp | 14 +--
 src/extensions/weston/input-emulator-uinput.h   |  2 +
 src/extensions/weston/input-emulator.cpp| 50 +
 src/extensions/weston/input-emulator.h  | 25 +
 src/extensions/weston/weston-wfits-input.cpp| 31 +++
 src/extensions/weston/weston-wfits.cpp  | 10 +
 9 files changed, 120 insertions(+), 18 deletions(-)
 create mode 100644 src/extensions/weston/input-emulator.cpp

diff --git a/src/extensions/weston/Makefile.am 
b/src/extensions/weston/Makefile.am
index a5447d3..9c13376 100644
--- a/src/extensions/weston/Makefile.am
+++ b/src/extensions/weston/Makefile.am
@@ -20,6 +20,7 @@ weston_wfits_la_SOURCES = 
\
weston-wfits-init.cpp   \
weston-wfits-query.cpp  \
weston-wfits-input.cpp  \
+   input-emulator.cpp  \
input-emulator-uinput.cpp   \
input-emulator-notify.cpp   \
$(top_srcdir)/src/extensions/protocol/wayland-fits-protocol.c
diff --git a/src/extensions/weston/input-emulator-notify.cpp 
b/src/extensions/weston/input-emulator-notify.cpp
index daf9b43..24920ad 100644
--- a/src/extensions/weston/input-emulator-notify.cpp
+++ b/src/extensions/weston/input-emulator-notify.cpp
@@ -30,6 +30,8 @@
 namespace wfits {
 namespace weston {
 
+/*static*/ bool InputEmulatorNotify::registered_ = 
InputEmulatorFactory::registerEmulator("notify", Create());
+
 InputEmulatorNotify::InputEmulatorNotify()
: InputEmulator::InputEmulator()
 {
diff --git a/src/extensions/weston/input-emulator-notify.h 
b/src/extensions/weston/input-emulator-notify.h
index d23eaac..4b13c3b 100644
--- a/src/extensions/weston/input-emulator-notify.h
+++ b/src/extensions/weston/input-emulator-notify.h
@@ -36,6 +36,9 @@ public:
 
/*virtual*/ void movePointer(const int32_t x, const int32_t y) const;
/*virtual*/ void keySend(const uint32_t key, const uint32_t state) 
const;
+
+private:
+   static bool registered_;
 };
 
 } // namespace weston
diff --git a/src/extensions/weston/input-emulator-uinput.cpp 
b/src/extensions/weston/input-emulator-uinput.cpp
index e6bf591..b850411 100644
--- a/src/extensions/weston/input-emulator-uinput.cpp
+++ b/src/extensions/weston/input-emulator-uinput.cpp
@@ -56,6 +56,8 @@ struct x11_output {
 namespace wfits {
 namespace weston {
 
+/*static*/ bool InputEmulatorUInput::registered_ = 
InputEmulatorFactory::registerEmulator("uinput", Create());
+
 /**
  * Get the width and height (size) of the current display output.  If Weston is
  * using the x11 backend then the result is the size of the X screen.
@@ -127,10 +129,10 @@ InputEmulatorUInput::InputEmulatorUInput()
, fd_(-1)
 {
struct uinput_user_dev device;
-   struct weston_output *output(Globals::output());
-   int32_t width, height;
 
-   weston_log("weston-wfits: creating uinput device\n");
+   weston_log("weston-wfits: %s\n", BOOST_CURRENT_FUNCTION);
+
+   assert(not Globals::isHeadless());
 
fd_ = open("/dev/uinput", O_WRONLY | O_NDELAY);
if (fd_ < 0) {
@@ -182,6 +184,7 @@ InputEmulatorUInput::InputEmulatorUInput()
/*
* TODO: Need to handle multidisplay, eventually.
*/
+   int32_t width, height;
screenSize(&width, &height);
device.absmin[ABS_X] = 0;
device.absmax[ABS_X] = width - 1;
@@ -195,6 +198,11 @@ InputEmulatorUInput::InputEmulatorUInput()
if (ioctl(fd_, UI_DEV_CREATE) < 0) {
exit(EXIT_FAILURE);
}
+
+   /* sync our input pointer device with weston */
+   wl_fixed_t cx, cy;
+   Globals::pointerXY(&cx, &cy);
+   movePointer(wl_fixed_to_int(cx), wl_fixed_to_int(cy));
 }
 
 /*virtual*/
diff --git a/src/extensions/weston/input-emulator-uinput.h 
b/src/extensions/weston/input-emulator-uinput.h
index 2d34ab6..75a78e0 100644
--- a/src/extensions/weston/input-emulator-

Re: [PATCH] weston.pc: Added libexecdir and pkglibexecdir variables

[Kristian Høgsberg]

On Mon, Jun 03, 2013 at 12:24:09PM -0300, Eduardo Lima (Etrunko) wrote:
> From: "Eduardo Lima (Etrunko)" 
> 
> These can be used by external clients to check the installation path

Makes sense, patch applied.

Kristian

> Signed-off-by: Eduardo Lima (Etrunko) 
> ---
>  src/weston.pc.in | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/weston.pc.in b/src/weston.pc.in
> index 537cc89..828cb1f 100644
> --- a/src/weston.pc.in
> +++ b/src/weston.pc.in
> @@ -2,6 +2,8 @@ prefix=@prefix@
>  exec_prefix=@exec_prefix@
>  libdir=@libdir@
>  includedir=@includedir@
> +libexecdir=@libexecdir@
> +pkglibexecdir=${libexecdir}/@PACKAGE@
>  
>  Name: Weston Plugin API
>  Description: Header files for Weston plugin development
> -- 
> 1.8.1.4
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] udev-seat: Fail input setup only if no devices are found

[Kristian Høgsberg]

On Mon, Jun 03, 2013 at 06:46:13PM +0100, Rob Bradford wrote:
> From: Rob Bradford 
> 
> Rather than failing if we cannot open any single device fail the input
> setup if there are no input devices added.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=64506

Thanks Rob, patch applied.

Kristian

> ---
>  src/udev-seat.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/src/udev-seat.c b/src/udev-seat.c
> index 7e62429..12a531c 100644
> --- a/src/udev-seat.c
> +++ b/src/udev-seat.c
> @@ -58,7 +58,7 @@ device_added(struct udev_device *udev_device, struct 
> udev_seat *master)
>   fd = weston_launcher_open(c, devnode, O_RDWR | O_NONBLOCK);
>   if (fd < 0) {
>   weston_log("opening input device '%s' failed.\n", devnode);
> - return -1;
> + return 0;
>   }
>  
>   device = evdev_device_create(&master->base, devnode, fd);
> @@ -69,7 +69,7 @@ device_added(struct udev_device *udev_device, struct 
> udev_seat *master)
>   } else if (device == NULL) {
>   close(fd);
>   weston_log("failed to create input device '%s'.\n", devnode);
> - return -1;
> + return 0;
>   }
>  
>   calibration_values =
> @@ -140,6 +140,7 @@ udev_seat_add_devices(struct udev_seat *seat, struct udev 
> *udev)
>   "\t- seats misconfigured "
>   "(Weston backend option 'seat', "
>   "udev device property ID_SEAT)\n");
> + return -1;
>   }
>  
>   return 0;
> -- 
> 1.8.1.4
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/5] Fix some bugs in editor example

[Kristian Høgsberg]

On Thu, May 30, 2013 at 01:57:00PM +0200, Jan Arne Petersen wrote:
> From: Jan Arne Petersen 
> 
> Fix some bugs I noticed when testing the editor example with
> latest Wayland enabled Maliit.

Thanks Jan, all committed.

Kristian

> Jan Arne Petersen (5):
>   editor: Fix text selection
>   editor: Support deleting text in preedit_string
>   editor: Properly adjust cursor on delete
>   editor: Improve checks on delete add asserts
>   editor: Do not commit/preedit after invalid delete
> 
>  clients/editor.c | 157 
> +--
>  1 file changed, 106 insertions(+), 51 deletions(-)
> 
> -- 
> 1.8.1.4
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] Don't fail if colord or libunwind are not present

[Kristian Høgsberg]

On Thu, May 30, 2013 at 03:16:40PM +0200, Armin K wrote:
> This patch adds auto detection for presence of
> the colord and libunwind packages.
> ---
>  configure.ac | 43 +++
>  1 file changed, 31 insertions(+), 12 deletions(-)

That is better, thanks Armin.

Kristian

> diff --git a/configure.ac b/configure.ac
> index 323bd87..ba1fcac 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -291,11 +291,19 @@ AM_CONDITIONAL(ENABLE_TABLET_SHELL,
>  AC_ARG_ENABLE(colord,
>AS_HELP_STRING([--disable-colord],
>   [do not build colord CMS support]),,
> -   enable_colord=yes)
> -AM_CONDITIONAL(ENABLE_COLORD,
> -test "x$enable_colord" = "xyes")
> -if test x$enable_colord = xyes; then
> -  PKG_CHECK_MODULES(COLORD, colord >= 0.1.27)
> +   enable_colord=auto)
> +AM_CONDITIONAL(ENABLE_COLORD, test "x$enable_colord" = "xyes")
> +if test "x$enable_colord" != "xno"; then
> + PKG_CHECK_MODULES(COLORD,
> +   colord >= 0.1.27,
> +   have_colord=yes,
> +   have_colord=no)
> + if test "x$have_colord" = "xno" -a "x$enable_colord" = "xyes"; then
> +   AC_MSG_ERROR([colord support explicitly requested, but colord 
> couldn't be found])
> + fi
> + if test "x$have_colord" = "xyes"; then
> +  enable_colord=yes
> + fi
>  fi
>  
>  AC_ARG_ENABLE(wcap-tools, [  --disable-wcap-tools],, enable_wcap_tools=yes)
> @@ -319,14 +327,25 @@ if test "x$GCC" = "xyes"; then
>  fi
>  AC_SUBST(GCC_CFLAGS)
>  
> -AC_ARG_ENABLE(libunwind, AS_HELP_STRING([  --disable-libunwind],
> -[Disable libunwind usage for 
> backtraces]),,
> -  enable_libunwind=yes)
> -if test "x$enable_libunwind" = xyes; then
> -PKG_CHECK_MODULES(LIBUNWIND, libunwind)
> -AC_DEFINE(HAVE_LIBUNWIND, 1, [Have libunwind support])
> -fi
> +AC_ARG_ENABLE(libunwind,
> +  AS_HELP_STRING([--disable-libunwind],
> + [Disable libunwind usage for backtraces]),,
> +  enable_libunwind=auto)
>  AM_CONDITIONAL(HAVE_LIBUNWIND, [test "x$enable_libunwind" = xyes])
> +if test "x$enable_libunwind" != "xno"; then
> +PKG_CHECK_MODULES(LIBUNWIND,
> +  libunwind,
> +  have_libunwind=yes,
> +  have_libunwind=no)
> +if test "x$have_libunwind" = "xno" -a "x$enable_libunwind" = "xyes"; 
> then
> +  AC_MSG_ERROR([libunwind support explicitly requested, but 
> libunwind couldn't be found])
> +fi
> +if test "x$have_libunwind" = "xyes"; then
> + enable_libunwind=yes
> + AC_DEFINE(HAVE_LIBUNWIND, 1, [Have libunwind support])
> +fi
> +fi
> +
>  
>  if test "x$WESTON_NATIVE_BACKEND" = "x"; then
>   WESTON_NATIVE_BACKEND="drm-backend.so"
> -- 
> 1.8.3
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Handle mouse wheel (corrected version)

[Kristian Høgsberg]

On Mon, Jun 03, 2013 at 10:55:47PM +0200, Hardening wrote:
> The RDP compositor was ignoring mouse wheel events, this patch adds
> support for it.

Committed, thanks.

Kristian

> ---
>  src/compositor-rdp.c | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index e855ba6..b81d789 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -42,6 +42,7 @@
>  #include "pixman-renderer.h"
>  
>  #define MAX_FREERDP_FDS 32
> +#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
>  
>  struct rdp_compositor_config {
>   int width;
> @@ -758,7 +759,7 @@ xf_peer_activate(freerdp_peer *client)
>  
>  static void
>  xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, UINT16 y) {
> - wl_fixed_t wl_x, wl_y;
> + wl_fixed_t wl_x, wl_y, axis;
>   RdpPeerContext *peerContext = (RdpPeerContext *)input->context;
>   struct rdp_output *output;
>   uint32_t button = 0;
> @@ -785,6 +786,22 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
> UINT16 y) {
>   (flags & PTR_FLAGS_DOWN) ? 
> WL_POINTER_BUTTON_STATE_PRESSED : WL_POINTER_BUTTON_STATE_RELEASED
>   );
>   }
> +
> + if (flags & PTR_FLAGS_WHEEL) {
> + /* DEFAULT_AXIS_STEP_DISTANCE is stolen from compositor-x11.c
> +  * The RDP specs says the lower bits of flags contains the "the 
> number of rotation
> +  * units the mouse wheel was rotated".
> +  *
> +  * 
> http://blogs.msdn.com/b/oldnewthing/archive/2013/01/23/10387366.aspx explains 
> the 120 value
> +  */
> + axis = (DEFAULT_AXIS_STEP_DISTANCE * (flags & 0xff)) / 120;
> + if (flags & PTR_FLAGS_WHEEL_NEGATIVE)
> + axis = -axis;
> +
> + notify_axis(&peerContext->item.seat, 
> weston_compositor_get_time(),
> + WL_POINTER_AXIS_VERTICAL_SCROLL,
> + axis);
> + }
>  }
>  
>  static void
> -- 
> 1.8.1.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] use _exit instead of exit if client fails to exec

[Kristian Høgsberg]

On Mon, Jun 03, 2013 at 04:22:31PM -0700, U. Artie Eoff wrote:
> From: "U. Artie Eoff" 
> 
> exit() calls atexit() handlers and C++ destructors (e.g. a C++
> weston module) which could destroy state that the main process
> depends on (e.g. ioctl's, tmpfiles, sockets, etc...).  If an exec
> fails, call _exit() instead of exit().
> 
> v2: prefer _exit over _Exit

Thanks, committed.  Will pick up for 1.1.

Kristian

> Signed-off-by: U. Artie Eoff 
> ---
>  src/compositor.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/compositor.c b/src/compositor.c
> index f382340..37fce0a 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -221,7 +221,7 @@ weston_client_launch(struct weston_compositor *compositor,
>  
>   if (pid == 0) {
>   child_client_exec(sv[1], path);
> - exit(-1);
> + _exit(-1);
>   }
>  
>   close(sv[1]);
> -- 
> 1.7.11.7
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 00/15] weston scaling support

[Bill Spitzak]

Jason Ekstrand wrote:

I think I'm begining to see what you and John have been suggesting.  
While I think Alexander's proposal will work well enough for the 
standard case, I think this also has merit.  If I were to sum up, I'd 
say I was "cautiously supportive" of the above.  It does seem to solve 
some of the edge-cases.  That said, there are a few things I'd like to note.


1. This requires a concept of a "window" which is one we currently don't 
have.  If we put it in wl_surface, we have to define how it works for 
subsurfaces.  We could say that the scale factor on subsurfaces gets 
ignored.  However, this means that we have defined an extension-specific 
exception.  What happens if we add another future extension that alters 
the window's size or orientation?  This will get messy.  We could put 
this in wl_shell_surface but then we are mixing the global (wl_output) 
with the desktop-specific (wl_shell_surface).


I always figured that the transformation of a subsurface is multiplied 
by the transformation of the parent surface. For the scaler proposal 
this means the output rectangle is in parent-surface buffer pixels.


2. This restricts subsurfaces to the same scaling factor as the original 
surface.  Probably not a huge problem, but I'm not convinced it's a 
smaller restriction than requiring subsurfaces on pel-boundaries.


I saw the scaling factor as a scale by 1/N (followed by a scale of N 
inside the compositor to the output pixels so it is 1:1). If this is on 
a subsurface it would be multiplied by the parent's scaling factor. This 
is probably pointless unless one of the two scales is 1.


3. This makes the subsurface case of handing off to a library more 
complicated.  In Alexander's implementation, the library would simply 
render at native resolution or not.  With this, the client has to tell 
the library what surface scale to use and the library has to *EXACTLY* 
match.  Maybe this isn't a huge issue, but there's no opportunity for a 
client to embed an older library.


This is true already for any third-party software called by a client 
that can draw directly into the client's output buffer.


It seemed the primary use of this is to display videos which will likely 
scale to whatever rectangle is asked for, regardless of output scale.


4. If a client presents a scale_factor to the compositor that is not an 
integer multiple of one of the output_scale factors provided by the 
compositor, it should not expect the compositor to do anything 
intelligent.  There are similar problems with integer proposal, but this 
one makes it more interesting.


I think the compositor can adjust it to a scale the hardware can handle. 
It looks like there is hardware that can only handle 1, or integers, or 
for a source buffer of width W it can only do integer/W.

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

RE: [PATCH weston v2] use _exit instead of exit if client fails to exec

[Eoff, Ullysses A]

Can we make sure this gets backported to 1.1, too?

> -Original Message-
> From: Eoff, Ullysses A
> Sent: Monday, June 03, 2013 4:23 PM
> To: wayland-devel@lists.freedesktop.org
> Cc: Eoff, Ullysses A
> Subject: [PATCH weston v2] use _exit instead of exit if client fails to exec
> 
> From: "U. Artie Eoff" 
> 
> exit() calls atexit() handlers and C++ destructors (e.g. a C++
> weston module) which could destroy state that the main process
> depends on (e.g. ioctl's, tmpfiles, sockets, etc...).  If an exec
> fails, call _exit() instead of exit().
> 
> v2: prefer _exit over _Exit
> 
> Signed-off-by: U. Artie Eoff 
> ---
>  src/compositor.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/compositor.c b/src/compositor.c
> index f382340..37fce0a 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -221,7 +221,7 @@ weston_client_launch(struct weston_compositor *compositor,
> 
>   if (pid == 0) {
>   child_client_exec(sv[1], path);
> - exit(-1);
> + _exit(-1);
>   }
> 
>   close(sv[1]);
> --
> 1.7.11.7

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

[PATCH weston v2] use _exit instead of exit if client fails to exec

[U. Artie Eoff]

From: "U. Artie Eoff" 

exit() calls atexit() handlers and C++ destructors (e.g. a C++
weston module) which could destroy state that the main process
depends on (e.g. ioctl's, tmpfiles, sockets, etc...).  If an exec
fails, call _exit() instead of exit().

v2: prefer _exit over _Exit

Signed-off-by: U. Artie Eoff 
---
 src/compositor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compositor.c b/src/compositor.c
index f382340..37fce0a 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -221,7 +221,7 @@ weston_client_launch(struct weston_compositor *compositor,
 
if (pid == 0) {
child_client_exec(sv[1], path);
-   exit(-1);
+   _exit(-1);
}
 
close(sv[1]);
-- 
1.7.11.7

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

[PATCH weston] use _Exit instead of exit if client fails to exec

[U. Artie Eoff]

From: "U. Artie Eoff" 

exit() calls atexit() handlers and C++ destructors (e.g. a C++
weston module) which could destroy state that the main process
depends on (e.g. ioctl's, tmpfiles, sockets, etc...).  If an exec
fails, call _Exit() instead of exit().

Signed-off-by: U. Artie Eoff 
---
 src/compositor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compositor.c b/src/compositor.c
index f382340..45a87d4 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -221,7 +221,7 @@ weston_client_launch(struct weston_compositor *compositor,
 
if (pid == 0) {
child_client_exec(sv[1], path);
-   exit(-1);
+   _Exit(-1);
}
 
close(sv[1]);
-- 
1.7.11.7

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

Re: [PATCH 00/15] weston scaling support

[Jason Ekstrand]

On Mon, Jun 3, 2013 at 3:21 PM, Bill Spitzak  wrote:

> It appears John Alsaker is proposing exactly the same change I have been
> proposing. I think we are having a hard time explaining it however.
>
>
> Pekka Paalanen wrote:
>
>> On Tue, 28 May 2013 19:27:35 +0200
>> John Kåre Alsaker  wrote:
>>
>>  My proposal is simply to let the compositor tell the client how much
>>> larger
>>> it wants the client to render content. The client can then tell the
>>> compositor how much larger it made content in the window. Armed with this
>>> information the compositor can size the window accordingly.
>>>
>>
>> How would this look in protocol? Just roughly, what requests and events
>> would be involved. Especially, how does the compositor know to suggest
>> a size?
>>
>
> It would look *EXACTLY* the same as how the compositor currently tells
> clients about the output scale.
>
>
>  I think they may have issues. A surface pel may not cover an integer
>> amount of pixels in both buffer and output. Or how do you arrange that?
>>
>
> In John's proposal a "pel" *EQUALS* a buffer pixel. It is always an
> integer number of pixels in buffer space, no matter what scale is chosen.
> The fact that you don't see this means that somehow John is not explaining
> his design well enough, and perhaps that is why there is resistance to it?
> But it seems pretty obvious to me.
>
> The current scale proposal allows a "pel" to be a non-integer in both
> buffer and output space. The easiest way is to put a surface with a scale
> of 3 on an output with a scale of 2.
>
>
>  + Output sizes do not have to be a multiple of the scaling factor.
>>>
>>
> I think this may be useful for tablets? But it turns out that large
> monitor sizes have been designed to allow integer scales of smaller sizes.
> For instance 1920x1080 has common factors of 2,2,2,3,5, meaning any integer
> scale that is a multiple of any set of those factors will work.
>
> However if there is any kind of "panel" on the edge of the monitor there
> are going to be problems with maximized windows because the reduced size is
> going to have much fewer factors, or the panel is going to be restricted to
> large increments in size that may mean only ugly sizes are possible.
>
>
>  + Clients can specify their size in pixels exactly.
>>>
>>
> The biggest problem with the scale proposal is that the sizes and
> positions of windows are restricted to visibly large steps, thus defeating
> the whole point of high-dpi displays.
>
>
>  + Clients get input in exact pixels (no rounding errors).
>>> + Clients doesn't have to transform input events in order to match the
>>> sizes used by buffers.
>>>
>>
> You said "pels" don't match buffer pixels. Therefore a transformation is
> needed to get to buffer pixels. And I'm worried that high-resolution
> pointing devices will be ignored by clients that immediately round to the
> nearest buffer pixel.
>
>
>  I don't really get the above.
>>
>
>  There are however some downsides:
>>> - Clients may need to transform input events in order to match the
>>> coordinates used by applications.
>>>
>>
>> So this is a minus here, but the same wrt. buffers was a plus. And it's
>> the application that first deals with input events, and then decides
>> what to draw. I don't think input goes directly to drawing machinery.
>>
>
> I think the assumption that the application is working in "pels" is
> simplistic. We *KNOW* that part of the application is working in buffer
> pixels (ie the drawing code). It should use a coordinate system that is
> known to mean something to the application.
>
>
>  - Clients changing scaling factors will have older input reported in the
>>> old size. This will be quite rare although clients can deal with it if
>>> desired.
>>> - Requires an implementation <:)
>>>
>>
> This seems to be the biggest actual objection, other than apparent
> misunderstanding of the proposal.
>
> However the same problem applies for when a buffer attach is done with an
> x and y offset. The client does not know exactly what mouse events are
> pointing at unless it knows whether they are before or after the commit.
>
> So I now think a better solution is to have the compositor echo the commit
> in the event stream, so the client can easily tell whether events are
> before or after it. It is possible that existing events can be used to
> determine this.
>
>
>  I don't expect GTK or other (ancient) toolkits to do fractional scaling
>>> and
>>> reap all the benefits listed here. I don't want anything in the core
>>> protocol blocking the ability for clients to scale smoothly up though
>>> when
>>> clients will actually be able to do this.
>>>
>>
>> You listed some features, but I still have no idea what you are
>> suggesting.
>>
>
> I think is is incredibly obvious what the advantages of his scheme are.
> The fact that you cannot see it is really mystifying.
>
> __**_
> wayland-devel mailing list
> wayland-devel@lists.**freed

[PATCH] Handle mouse wheel (corrected version)

[Hardening]

The RDP compositor was ignoring mouse wheel events, this patch adds
support for it.
---
 src/compositor-rdp.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index e855ba6..b81d789 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -42,6 +42,7 @@
 #include "pixman-renderer.h"
 
 #define MAX_FREERDP_FDS 32
+#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
 
 struct rdp_compositor_config {
int width;
@@ -758,7 +759,7 @@ xf_peer_activate(freerdp_peer *client)
 
 static void
 xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, UINT16 y) {
-   wl_fixed_t wl_x, wl_y;
+   wl_fixed_t wl_x, wl_y, axis;
RdpPeerContext *peerContext = (RdpPeerContext *)input->context;
struct rdp_output *output;
uint32_t button = 0;
@@ -785,6 +786,22 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
UINT16 y) {
(flags & PTR_FLAGS_DOWN) ? 
WL_POINTER_BUTTON_STATE_PRESSED : WL_POINTER_BUTTON_STATE_RELEASED
);
}
+
+   if (flags & PTR_FLAGS_WHEEL) {
+   /* DEFAULT_AXIS_STEP_DISTANCE is stolen from compositor-x11.c
+* The RDP specs says the lower bits of flags contains the "the 
number of rotation
+* units the mouse wheel was rotated".
+*
+* 
http://blogs.msdn.com/b/oldnewthing/archive/2013/01/23/10387366.aspx explains 
the 120 value
+*/
+   axis = (DEFAULT_AXIS_STEP_DISTANCE * (flags & 0xff)) / 120;
+   if (flags & PTR_FLAGS_WHEEL_NEGATIVE)
+   axis = -axis;
+
+   notify_axis(&peerContext->item.seat, 
weston_compositor_get_time(),
+   WL_POINTER_AXIS_VERTICAL_SCROLL,
+   axis);
+   }
 }
 
 static void
-- 
1.8.1.2

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

Re: [PATCH] [rdp compositor] handle mouse wheel

[Hardening]

Le 03/06/2013 22:41, Bill Spitzak a écrit :

Hardening wrote:


+#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)



+axis = DEFAULT_AXIS_STEP_DISTANCE * ((flags & 0xff) / 120);


This can only make the fixed numbers 0, 10.0, and 20.0. Is this correct?

A wild guess is that this is actually what is wanted:

 axis = (DEFAULT_AXIS_STEP_DISTANCE * (flags & 0xff)) / 120;


You were faster to notice than me to correct.
Patch in a next mail.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] [rdp compositor] handle mouse wheel

[Bill Spitzak]

Hardening wrote:


+#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)



+   axis = DEFAULT_AXIS_STEP_DISTANCE * ((flags & 0xff) / 120);


This can only make the fixed numbers 0, 10.0, and 20.0. Is this correct?

A wild guess is that this is actually what is wanted:

axis = (DEFAULT_AXIS_STEP_DISTANCE * (flags & 0xff)) / 120;
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 00/15] weston scaling support

[Bill Spitzak]

It appears John Alsaker is proposing exactly the same change I have been 
proposing. I think we are having a hard time explaining it however.


Pekka Paalanen wrote:

On Tue, 28 May 2013 19:27:35 +0200
John Kåre Alsaker  wrote:


My proposal is simply to let the compositor tell the client how much larger
it wants the client to render content. The client can then tell the
compositor how much larger it made content in the window. Armed with this
information the compositor can size the window accordingly.


How would this look in protocol? Just roughly, what requests and events
would be involved. Especially, how does the compositor know to suggest
a size?


It would look *EXACTLY* the same as how the compositor currently tells 
clients about the output scale.



I think they may have issues. A surface pel may not cover an integer
amount of pixels in both buffer and output. Or how do you arrange that?


In John's proposal a "pel" *EQUALS* a buffer pixel. It is always an 
integer number of pixels in buffer space, no matter what scale is 
chosen. The fact that you don't see this means that somehow John is not 
explaining his design well enough, and perhaps that is why there is 
resistance to it? But it seems pretty obvious to me.


The current scale proposal allows a "pel" to be a non-integer in both 
buffer and output space. The easiest way is to put a surface with a 
scale of 3 on an output with a scale of 2.



+ Output sizes do not have to be a multiple of the scaling factor.


I think this may be useful for tablets? But it turns out that large 
monitor sizes have been designed to allow integer scales of smaller 
sizes. For instance 1920x1080 has common factors of 2,2,2,3,5, meaning 
any integer scale that is a multiple of any set of those factors will work.


However if there is any kind of "panel" on the edge of the monitor there 
are going to be problems with maximized windows because the reduced size 
is going to have much fewer factors, or the panel is going to be 
restricted to large increments in size that may mean only ugly sizes are 
possible.



+ Clients can specify their size in pixels exactly.


The biggest problem with the scale proposal is that the sizes and 
positions of windows are restricted to visibly large steps, thus 
defeating the whole point of high-dpi displays.



+ Clients get input in exact pixels (no rounding errors).
+ Clients doesn't have to transform input events in order to match the
sizes used by buffers.


You said "pels" don't match buffer pixels. Therefore a transformation is 
needed to get to buffer pixels. And I'm worried that high-resolution 
pointing devices will be ignored by clients that immediately round to 
the nearest buffer pixel.



I don't really get the above.



There are however some downsides:
- Clients may need to transform input events in order to match the
coordinates used by applications.


So this is a minus here, but the same wrt. buffers was a plus. And it's
the application that first deals with input events, and then decides
what to draw. I don't think input goes directly to drawing machinery.


I think the assumption that the application is working in "pels" is 
simplistic. We *KNOW* that part of the application is working in buffer 
pixels (ie the drawing code). It should use a coordinate system that is 
known to mean something to the application.



- Clients changing scaling factors will have older input reported in the
old size. This will be quite rare although clients can deal with it if
desired.
- Requires an implementation <:)


This seems to be the biggest actual objection, other than apparent 
misunderstanding of the proposal.


However the same problem applies for when a buffer attach is done with 
an x and y offset. The client does not know exactly what mouse events 
are pointing at unless it knows whether they are before or after the commit.


So I now think a better solution is to have the compositor echo the 
commit in the event stream, so the client can easily tell whether events 
are before or after it. It is possible that existing events can be used 
to determine this.



I don't expect GTK or other (ancient) toolkits to do fractional scaling and
reap all the benefits listed here. I don't want anything in the core
protocol blocking the ability for clients to scale smoothly up though when
clients will actually be able to do this.


You listed some features, but I still have no idea what you are
suggesting.


I think is is incredibly obvious what the advantages of his scheme are. 
The fact that you cannot see it is really mystifying.

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

[PATCH] [rdp compositor] handle mouse wheel

[Hardening]

The RDP compositor was ignoring mouse wheel events, this patch adds
support for it.
---
 src/compositor-rdp.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index e855ba6..e234816 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -42,6 +42,7 @@
 #include "pixman-renderer.h"
 
 #define MAX_FREERDP_FDS 32
+#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
 
 struct rdp_compositor_config {
int width;
@@ -758,7 +759,7 @@ xf_peer_activate(freerdp_peer *client)
 
 static void
 xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, UINT16 y) {
-   wl_fixed_t wl_x, wl_y;
+   wl_fixed_t wl_x, wl_y, axis;
RdpPeerContext *peerContext = (RdpPeerContext *)input->context;
struct rdp_output *output;
uint32_t button = 0;
@@ -785,6 +786,22 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, 
UINT16 y) {
(flags & PTR_FLAGS_DOWN) ? 
WL_POINTER_BUTTON_STATE_PRESSED : WL_POINTER_BUTTON_STATE_RELEASED
);
}
+
+   if (flags & PTR_FLAGS_WHEEL) {
+   /* DEFAULT_AXIS_STEP_DISTANCE is stolen from compositor-x11.c
+* The RDP specs says the lower bits of flags contains the "the 
number of rotation
+* units the mouse wheel was rotated".
+*
+* 
http://blogs.msdn.com/b/oldnewthing/archive/2013/01/23/10387366.aspx explains 
the 120 value
+*/
+   axis = DEFAULT_AXIS_STEP_DISTANCE * ((flags & 0xff) / 120);
+   if (flags & PTR_FLAGS_WHEEL_NEGATIVE)
+   axis = -axis;
+
+   notify_axis(&peerContext->item.seat, 
weston_compositor_get_time(),
+   WL_POINTER_AXIS_VERTICAL_SCROLL,
+   axis);
+   }
 }
 
 static void
-- 
1.8.1.2

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

Re: [PATCH] configure.ac: Do not make missing colord or libunwind a hard failure

[Othman, Ossama]

Hi Daniel,

On Mon, Jun 3, 2013 at 11:45 AM, Daniel Stone  wrote:
>
> The usual pattern here is to set the default to 'auto', which will
> check whether or not the dependency is installed and select yes or no
> accordingly.  If someone explicitly passes --enable-colord and it's
> not installed, we want the configure run to fail, rather than doing
> something other than what they told us to.
>

Good point.  Armin's patch - which I missed before posting mine - is in a
better position to do just that.

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

Re: Compiling weston now needs colord

[Armin K.]

http://lists.freedesktop.org/archives/wayland-devel/2013-May/009554.html

Next time check list before taking time to duplicate the effort. 

- Original Message -
From: Othman, Ossama
Sent: 06/03/13 08:44 PM
To: sardemff7+wayl...@sardemff7.net
Subject: Re: Compiling weston now needs colord
 Hi, On Thu, May 30, 2013 at 12:42 AM,  
wrote:On 30/05/2013 08:24, Michael Hasselmann wrote:On Tue, 2013-05-28 at 22:16 
-0700, Bill Spitzak wrote:Running autogen.sh in weston with --disable-colord 
works to avoid this,
I suspect nothing I care about is lost this way.
I ran into the very same problems. I would have preferred if such new
dependencies were optional or if someone would explain what we will miss
if we disable them. For colord, trying to build the latest required
version from git just pulls in more dependencies that you also have to
build from git (as Bill mentioned).

It's kind of frustrating, even if weston is meant to be a playground and
thus new dependencies have to be expected.

http://wayland.freedesktop.org/building.html should be updated I guess?

ciao Michael
colord is an optional dependency: you just need to pass --disable-colord to 
./configure (or ./autogen.sh), and it is gone. Making the configure script have 
a hard failure by default if colord is unavailable is not consistent with the 
dependency being optional.  Even if --disable-colord is added to the 
configure/autogen.sh command line "make distcheck" will still fail on platforms 
without colord installed since the configure script flags are not passed down.  
One could tweak the flags passed to the distcheck target using 
AM_DISTCHECK_CONFIGURE_FLAGS and DISTCHECK_CONFIGURE_FLAGS but that would be 
hack. I think it would be better to issue a warning if colord wasn't found 
rather than error out, or flip the logic so that the user must enable colord 
support, and only then error out.  The same goes for libunwind. I just 
submitted a patch that causes a missing colord or libunwind to issue a warning 
rather than error out. It is not an automagic dependency (which automatically 
detect the package’s presence), because it is more work for the developer to 
add the autotools logic to do so. Also, it is much more work to make packagers 
happy (packagers hate automagic dependencies, it makes either more work by 
patching or hard-dependency on optional features).

A little configure switch, and you are done, nothing to complain about. :-) The 
configure switch in question doesn't appear to be enough to keep some of us 
from complaining.  :) Thanks,-Ossama  
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] configure.ac: Do not make missing colord or libunwind a hard failure

[Daniel Stone]

Hi,

On 3 June 2013 19:41, Ossama Othman  wrote:
> -AM_CONDITIONAL(ENABLE_COLORD,
> -  test "x$enable_colord" = "xyes")
>  if test x$enable_colord = xyes; then
> -  PKG_CHECK_MODULES(COLORD, colord >= 0.1.27)
> +  PKG_CHECK_MODULES([COLORD],
> +[colord >= 0.1.27],
> +   [],
> +   [enable_colord=no
> + AC_MSG_WARN([Colord support won't be enabled.  Desired 
> version not found.])])

The usual pattern here is to set the default to 'auto', which will
check whether or not the dependency is installed and select yes or no
accordingly.  If someone explicitly passes --enable-colord and it's
not installed, we want the configure run to fail, rather than doing
something other than what they told us to.

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

Re: Compiling weston now needs colord

[Othman, Ossama]

Hi,

On Thu, May 30, 2013 at 12:42 AM,  wrote:

> On 30/05/2013 08:24, Michael Hasselmann wrote:
>
>> On Tue, 2013-05-28 at 22:16 -0700, Bill Spitzak wrote:
>>
>>> Running autogen.sh in weston with --disable-colord works to avoid this,
>>> I suspect nothing I care about is lost this way.
>>>
>>
>> I ran into the very same problems. I would have preferred if such new
>> dependencies were optional or if someone would explain what we will miss
>> if we disable them. For colord, trying to build the latest required
>> version from git just pulls in more dependencies that you also have to
>> build from git (as Bill mentioned).
>>
>> It's kind of frustrating, even if weston is meant to be a playground and
>> thus new dependencies have to be expected.
>>
>> http://wayland.freedesktop.**org/building.htmlshould
>>  be updated I guess?
>>
>> ciao Michael
>>
>
> colord is an optional dependency: you just need to pass --disable-colord
> to ./configure (or ./autogen.sh), and it is gone.
>

Making the configure script have a hard failure by default if colord is
unavailable is not consistent with the dependency being optional.  Even if
--disable-colord is added to the configure/autogen.sh command line "make
distcheck" will still fail on platforms without colord installed since the
configure script flags are not passed down.  One could tweak the flags
passed to the distcheck target using AM_DISTCHECK_CONFIGURE_FLAGS and
DISTCHECK_CONFIGURE_FLAGS but that would be hack. I think it would be
better to issue a warning if colord wasn't found rather than error out, or
flip the logic so that the user must enable colord support, and only then
error out.  The same goes for libunwind.

I just submitted a patch that causes a missing colord or libunwind to issue
a warning rather than error out.

It is not an automagic dependency (which automatically detect the package’s
> presence), because it is more work for the developer to add the autotools
> logic to do so. Also, it is much more work to make packagers happy
> (packagers hate automagic dependencies, it makes either more work by
> patching or hard-dependency on optional features).
>
> A little configure switch, and you are done, nothing to complain about. :-)


The configure switch in question doesn't appear to be enough to keep some
of us from complaining.  :)

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

[PATCH] configure.ac: Do not make missing colord or libunwind a hard failure

[Ossama Othman]

Both colord and libunwind are optional dependencies.  As such, the
configure script should not exit with a failure if they are missing.
Issue warnings instead if either colord or libunwind is missing and
wasn't found.

This also allows "make distcheck" to succeed on platforms that don't
have colord and libunwind installed since configure script command
line flags are not passed down to the "distcheck" target without
AM_DISTCHECK_CONFIGURE_FLAGS and DISTCHECK_CONFIGURE_FLAGS - use of
which is discouraged.

Signed-off-by: Ossama Othman 
---
 configure.ac |   17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 323bd87..3046a16 100644
--- a/configure.ac
+++ b/configure.ac
@@ -292,11 +292,15 @@ AC_ARG_ENABLE(colord,
   AS_HELP_STRING([--disable-colord],
  [do not build colord CMS support]),,
  enable_colord=yes)
-AM_CONDITIONAL(ENABLE_COLORD,
-  test "x$enable_colord" = "xyes")
 if test x$enable_colord = xyes; then
-  PKG_CHECK_MODULES(COLORD, colord >= 0.1.27)
+  PKG_CHECK_MODULES([COLORD],
+[colord >= 0.1.27],
+   [],
+   [enable_colord=no
+ AC_MSG_WARN([Colord support won't be enabled.  Desired 
version not found.])])
 fi
+AM_CONDITIONAL(ENABLE_COLORD,
+  test "x$enable_colord" = "xyes")
 
 AC_ARG_ENABLE(wcap-tools, [  --disable-wcap-tools],, enable_wcap_tools=yes)
 AM_CONDITIONAL(BUILD_WCAP_TOOLS, test x$enable_wcap_tools = xyes)
@@ -323,8 +327,11 @@ AC_ARG_ENABLE(libunwind, AS_HELP_STRING([  
--disable-libunwind],
 [Disable libunwind usage for 
backtraces]),,
   enable_libunwind=yes)
 if test "x$enable_libunwind" = xyes; then
-PKG_CHECK_MODULES(LIBUNWIND, libunwind)
-AC_DEFINE(HAVE_LIBUNWIND, 1, [Have libunwind support])
+PKG_CHECK_MODULES([LIBUNWIND],
+  [libunwind],
+ [AC_DEFINE(HAVE_LIBUNWIND, 1, [Have libunwind support])],
+ [enable_libunwind=no
+   AC_MSG_WARN([Libunwind support won't be enabled since 
it was not found.])])
 fi
 AM_CONDITIONAL(HAVE_LIBUNWIND, [test "x$enable_libunwind" = xyes])
 
-- 
1.7.10.4

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

[PATCH weston] udev-seat: Fail input setup only if no devices are found

[Rob Bradford]

From: Rob Bradford 

Rather than failing if we cannot open any single device fail the input
setup if there are no input devices added.

https://bugs.freedesktop.org/show_bug.cgi?id=64506
---
 src/udev-seat.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/udev-seat.c b/src/udev-seat.c
index 7e62429..12a531c 100644
--- a/src/udev-seat.c
+++ b/src/udev-seat.c
@@ -58,7 +58,7 @@ device_added(struct udev_device *udev_device, struct 
udev_seat *master)
fd = weston_launcher_open(c, devnode, O_RDWR | O_NONBLOCK);
if (fd < 0) {
weston_log("opening input device '%s' failed.\n", devnode);
-   return -1;
+   return 0;
}
 
device = evdev_device_create(&master->base, devnode, fd);
@@ -69,7 +69,7 @@ device_added(struct udev_device *udev_device, struct 
udev_seat *master)
} else if (device == NULL) {
close(fd);
weston_log("failed to create input device '%s'.\n", devnode);
-   return -1;
+   return 0;
}
 
calibration_values =
@@ -140,6 +140,7 @@ udev_seat_add_devices(struct udev_seat *seat, struct udev 
*udev)
"\t- seats misconfigured "
"(Weston backend option 'seat', "
"udev device property ID_SEAT)\n");
+   return -1;
}
 
return 0;
-- 
1.8.1.4

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

[PATCH] weston.pc: Added libexecdir and pkglibexecdir variables

[Eduardo Lima (Etrunko)]

From: "Eduardo Lima (Etrunko)" 

These can be used by external clients to check the installation path

Signed-off-by: Eduardo Lima (Etrunko) 
---
 src/weston.pc.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/weston.pc.in b/src/weston.pc.in
index 537cc89..828cb1f 100644
--- a/src/weston.pc.in
+++ b/src/weston.pc.in
@@ -2,6 +2,8 @@ prefix=@prefix@
 exec_prefix=@exec_prefix@
 libdir=@libdir@
 includedir=@includedir@
+libexecdir=@libexecdir@
+pkglibexecdir=${libexecdir}/@PACKAGE@
 
 Name: Weston Plugin API
 Description: Header files for Weston plugin development
-- 
1.8.1.4

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

Re: [PATCH wayland 2/4] Add support for flags in the wl_map API and add a WL_MAP_ENTRY_LEGACY flag

[Jason Ekstrand]

On Mon, Jun 3, 2013 at 4:36 AM, Ander Conselvan de Oliveira <
conselv...@gmail.com> wrote:

> On 06/02/2013 01:40 AM, Jason Ekstrand wrote:
>
>> The implementation in this commit allows for one bit worth of flags.  If
>> more flags are desired at a future date, then the wl_map implementation
>> will have to change but the wl_map API will not.
>>
>
> I couldn't find a description of what WL_MAP_ENTRY_LEGACY is supposed to
> mean anywhere in the patch. Would be good to document that in the commit
> message and/or near the enum definition. And maybe this explanation would
> also make clear why flags are necessary.
>

The purpose is so that we can deprecate the internals of wl_resource.  We
need a way (that doesn't involve changing wl_resource) to flag a resource
as being a legacy version 1.0 resource so we can special-case it.  We can
do this by building it into wl_map.  Perhaps there should be a comment in
there to that effect.

--Jason Ekstrand


>
> Cheers,
> Ander
>
>
>
>  Signed-off-by: Jason Ekstrand 
>> ---
>>   src/wayland-client.c  | 12 ++--
>>   src/wayland-private.h | 13 +++--
>>   src/wayland-server.c  | 12 ++--
>>   src/wayland-util.c| 41 ++**+--
>>   4 files changed, 58 insertions(+), 20 deletions(-)
>>
>> diff --git a/src/wayland-client.c b/src/wayland-client.c
>> index 0f5e093..bea73e0 100644
>> --- a/src/wayland-client.c
>> +++ b/src/wayland-client.c
>> @@ -226,7 +226,7 @@ wl_proxy_create(struct wl_proxy *factory, const
>> struct wl_interface *interface)
>> proxy->refcount = 1;
>>
>> pthread_mutex_lock(&display->**mutex);
>> -   proxy->object.id = wl_map_insert_new(&display->**objects, proxy);
>> +   proxy->object.id = wl_map_insert_new(&display->**objects, 0,
>> proxy);
>> pthread_mutex_unlock(&display-**>mutex);
>>
>> return proxy;
>> @@ -252,7 +252,7 @@ wl_proxy_create_for_id(struct wl_proxy *factory,
>> proxy->flags = 0;
>> proxy->refcount = 1;
>>
>> -   wl_map_insert_at(&display->**objects, id, proxy);
>> +   wl_map_insert_at(&display->**objects, 0, id, proxy);
>>
>> return proxy;
>>   }
>> @@ -273,10 +273,10 @@ wl_proxy_destroy(struct wl_proxy *proxy)
>> if (proxy->flags & WL_PROXY_FLAG_ID_DELETED)
>> wl_map_remove(&proxy->display-**>objects, proxy->
>> object.id);
>> else if (proxy->object.id < WL_SERVER_ID_START)
>> -   wl_map_insert_at(&proxy->**display->objects,
>> +   wl_map_insert_at(&proxy->**display->objects, 0,
>>  proxy->object.id, WL_ZOMBIE_OBJECT);
>> else
>> -   wl_map_insert_at(&proxy->**display->objects,
>> +   wl_map_insert_at(&proxy->**display->objects, 0,
>>  proxy->object.id, NULL);
>>
>>
>> @@ -522,11 +522,11 @@ wl_display_connect_to_fd(int fd)
>> wl_list_init(&display->event_**queue_list);
>> pthread_mutex_init(&display->**mutex, NULL);
>>
>> -   wl_map_insert_new(&display->**objects, NULL);
>> +   wl_map_insert_new(&display->**objects, 0, NULL);
>>
>> display->proxy.object.**interface = &wl_display_interface;
>> display->proxy.object.id =
>> -   wl_map_insert_new(&display->**objects, display);
>> +   wl_map_insert_new(&display->**objects, 0, display);
>> display->proxy.display = display;
>> display->proxy.object.**implementation = (void(**)(void))
>> &display_listener;
>> display->proxy.user_data = display;
>> diff --git a/src/wayland-private.h b/src/wayland-private.h
>> index 270b470..a648538 100644
>> --- a/src/wayland-private.h
>> +++ b/src/wayland-private.h
>> @@ -41,6 +41,14 @@
>>   #define WL_SERVER_ID_START 0xff00
>>   #define WL_CLOSURE_MAX_ARGS 20
>>
>> +/* Flags for wl_map_insert_new and wl_map_insert_at.  Flags can be
>> queried with
>> + * wl_map_lookup_flags.  The current implementation has room for 1 bit
>> worth of
>> + * flags.  If more flags are ever added, the implementation of wl_map
>> will have
>> + * to change to allow for new flags */
>> +enum wl_map_entry_flags {
>> +   WL_MAP_ENTRY_LEGACY = (1 << 0)
>> +};
>> +
>>   struct wl_map {
>> struct wl_array client_entries;
>> struct wl_array server_entries;
>> @@ -52,11 +60,12 @@ typedef void (*wl_iterator_func_t)(void *element,
>> void *data);
>>
>>   void wl_map_init(struct wl_map *map, uint32_t side);
>>   void wl_map_release(struct wl_map *map);
>> -uint32_t wl_map_insert_new(struct wl_map *map, void *data);
>> -int wl_map_insert_at(struct wl_map *map, uint32_t i, void *data);
>> +uint32_t wl_map_insert_new(struct wl_map *map, uint32_t flags, void
>> *data);
>> +int wl_map_insert_at(struct wl_map *map, uint32_t flags, uint32_t i,
>> void *data);
>>   int wl_map_reserve_new(struct wl_map *map, uint32_t i);
>>   void wl_map_remove(struct wl_map *map, uint32_t i);
>>   void *wl_map_lookup(struct wl_map *

Re: [PATCH 00/15] weston scaling support

[John Kåre Alsaker]

On Mon, Jun 3, 2013 at 2:22 PM, Pekka Paalanen  wrote:

> On Tue, 28 May 2013 19:27:35 +0200
> John Kåre Alsaker  wrote:
>
> > My proposal is simply to let the compositor tell the client how much
> larger
> > it wants the client to render content. The client can then tell the
> > compositor how much larger it made content in the window. Armed with this
> > information the compositor can size the window accordingly.
>
> How would this look in protocol? Just roughly, what requests and events
> would be involved. Especially, how does the compositor know to suggest
> a size?
>
We add a new event to wl_output to tell clients how much larger they should
create their windows for optimal display on that output. Clients should
then create larger windows and indicate so by a new request on wl_surface
where they state how much they enlarged the window. This differs from
Alexander's implementation in that the window itself is larger rather than
the buffer.


>
> > Note that this implies no further change in the protocol or concepts.
> > Surface coordinates are still of the same size as buffer coordinates.
>
> Alright.
>
> > This has a number of benefits over the current implementation:
> > + Rational scaling factors has no issues (the most important benefit).
>
> I think they may have issues. A surface pel may not cover an integer
> amount of pixels in both buffer and output. Or how do you arrange that?
>
A surface pel would correspond exactly with a pixel in the buffer, although
it might be flipped or rotated. There's no guaranteed correspondence with
an output pixel in either proposal.

>
> For crisp pel-sized graphics (pixel-sized in apps that do not
> understand the output scale), a pel should be an integer amount of
> pixels in both output and buffer.
>
How the compositor resizes surfaces is not defined by either proposal. It
may not do it at all or it may only upsize with a integer multiple.


> > + Output sizes do not have to be a multiple of the scaling factor.
>
Clients won't be able to fill the output exactly when the output size is
not a multiple of the scale factor. With a scaling factor of 3, 2560x1600
would be 853.3... x 533.3 This can't be represented in the protocol so
it will need to be cropped or padding added.

> + Clients can specify their size in pixels exactly.
>
Client doesn't have to round to the nearest multiple of the scaling factor.


> > + Clients get input in exact pixels (no rounding errors).
>
With a scaling factor of 3, you're suddenly unable to address individual
pixels.


> > + Clients doesn't have to transform input events in order to match the
> > sizes used by buffers.
>
Toolkits may store geometry in actual pixels and need events to match
pixels and not some virtual unit. That's how I'd design one.


>
> I don't really get the above.
>
> > + Conceptually simple to implement. Compositors doesn't have to deal with
> > scaling for subsurfaces and they are probably already able to resize
> whole
> > windows.
>
> Why would sub-surfaces have any effect here?
>
I have absolutely no idea how subsurfaces trees with different scaling
factors on surfaces would work in Alexander's proposal. I simply don't
allow specifying it on anything other than top level surfaces, which it
uses for the whole surface tree.

>
> > + Can support clients with integer scaling factors, although these raises
> > the same edge cases as the current implementation (they may not be able
> to
> > fit the screen exactly).
> >
> > There are however some downsides:
> > - Clients may need to transform input events in order to match the
> > coordinates used by applications.
>
> So this is a minus here, but the same wrt. buffers was a plus. And it's
> the application that first deals with input events, and then decides
> what to draw. I don't think input goes directly to drawing machinery.
>
It will depends on how the toolkits interprets events. If you want to hack
a toolkit by multiplying all buffer sizes by an integer (which Alexander is
plotting with GTK) yet keep everything else the same this proposal will
require transforming the input events too. The comparison with buffers was
because normally toolkits store element sizes as the size in rendered
pixels.


>
> > - Clients changing scaling factors will have older input reported in the
> > old size. This will be quite rare although clients can deal with it if
> > desired.
> > - Requires an implementation <:)
> >
> > I don't expect GTK or other (ancient) toolkits to do fractional scaling
> and
> > reap all the benefits listed here. I don't want anything in the core
> > protocol blocking the ability for clients to scale smoothly up though
> when
> > clients will actually be able to do this.
>
> You listed some features, but I still have no idea what you are
> suggesting.
>
> It also seems the integer output scale proposal and implementation are
> maturing nicely, so now there would need to be obvious reasons for
> changing it. I just don't see it based on this descrip

Re: [PATCH wayland-web] raspberrypi: mention Raspbian packages

[Emilio Pozuelo Monfort]

On 03/06/13 15:50, ppaala...@gmail.com wrote:
> From: Pekka Paalanen 
> 
> Signed-off-by: Pekka Paalanen 
> Cc: Daniel Stone 
> Cc: Alex Bradbury 
> 
> ---
> 
> Darxus, could you wait till tomorrow until pushing this, so Daniel and
> Alex can comment, if there's anything to add?
> 
> Thanks,
> pq
> ---
>  raspberrypi.html | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/raspberrypi.html b/raspberrypi.html
> index b1c2a87..620a0a8 100644
> --- a/raspberrypi.html
> +++ b/raspberrypi.html
> @@ -16,6 +16,31 @@
>  http://www.raspberrypi.org/";>Raspberry Pi. All commands and
>  compiling are done directly on the Pi.
>  
> +However, if you just want to try Weston and not build it, there are
> +packages.
> +
> +
> +Raspbian packages
> +
> +There are pre-built Wayland and Weston packages for the
> +http://www.raspbian.org/";>Raspbian distribution.
> +
> +Add the following line to /etc/apt/sources.list file:
> +deb http://raspberrypi.collabora.com wheezy rpi
> +
> +Then just issue:

There should be a `sudo apt-get update' here.

> +sudo apt-get install weston
> +
> +This will install also a script called weston-launch
> +(not the real weston-launch program), which will automatically
> +set up XDG_RUNTIME_DIR for you and run weston.
> +Running Weston with this package is as simple as:
> +weston-launch
> +No need to manually set up environment variables. The firmware notes
> +below are still worth checking, though.
> +
> +
> +
>  Build dependencies
>  
>  Assuming you are using the Raspbian distribution, install the
> 

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

Re: [PATCH wayland-web] raspberrypi: mention Raspbian packages

[Daniel Stone]

Hi,
Looks good to me (pending getting our key in the keyring), but you
probably want to mention that this only works when running as 'pi'.

Cheers,
Daniel

On 3 June 2013 14:50,   wrote:
> From: Pekka Paalanen 
>
> Signed-off-by: Pekka Paalanen 
> Cc: Daniel Stone 
> Cc: Alex Bradbury 
>
> ---
>
> Darxus, could you wait till tomorrow until pushing this, so Daniel and
> Alex can comment, if there's anything to add?
>
> Thanks,
> pq
> ---
>  raspberrypi.html | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/raspberrypi.html b/raspberrypi.html
> index b1c2a87..620a0a8 100644
> --- a/raspberrypi.html
> +++ b/raspberrypi.html
> @@ -16,6 +16,31 @@
>  http://www.raspberrypi.org/";>Raspberry Pi. All commands and
>  compiling are done directly on the Pi.
>
> +However, if you just want to try Weston and not build it, there are
> +packages.
> +
> +
> +Raspbian packages
> +
> +There are pre-built Wayland and Weston packages for the
> +http://www.raspbian.org/";>Raspbian distribution.
> +
> +Add the following line to /etc/apt/sources.list file:
> +deb http://raspberrypi.collabora.com wheezy rpi
> +
> +Then just issue:
> +sudo apt-get install weston
> +
> +This will install also a script called weston-launch
> +(not the real weston-launch program), which will automatically
> +set up XDG_RUNTIME_DIR for you and run weston.
> +Running Weston with this package is as simple as:
> +weston-launch
> +No need to manually set up environment variables. The firmware notes
> +below are still worth checking, though.
> +
> +
> +
>  Build dependencies
>
>  Assuming you are using the Raspbian distribution, install the
> --
> 1.8.1.5
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland-web] raspberrypi: mention Raspbian packages

[ppaalanen]

From: Pekka Paalanen 

Signed-off-by: Pekka Paalanen 
Cc: Daniel Stone 
Cc: Alex Bradbury 

---

Darxus, could you wait till tomorrow until pushing this, so Daniel and
Alex can comment, if there's anything to add?

Thanks,
pq
---
 raspberrypi.html | 25 +
 1 file changed, 25 insertions(+)

diff --git a/raspberrypi.html b/raspberrypi.html
index b1c2a87..620a0a8 100644
--- a/raspberrypi.html
+++ b/raspberrypi.html
@@ -16,6 +16,31 @@
 http://www.raspberrypi.org/";>Raspberry Pi. All commands and
 compiling are done directly on the Pi.
 
+However, if you just want to try Weston and not build it, there are
+packages.
+
+
+Raspbian packages
+
+There are pre-built Wayland and Weston packages for the
+http://www.raspbian.org/";>Raspbian distribution.
+
+Add the following line to /etc/apt/sources.list file:
+deb http://raspberrypi.collabora.com wheezy rpi
+
+Then just issue:
+sudo apt-get install weston
+
+This will install also a script called weston-launch
+(not the real weston-launch program), which will automatically
+set up XDG_RUNTIME_DIR for you and run weston.
+Running Weston with this package is as simple as:
+weston-launch
+No need to manually set up environment variables. The firmware notes
+below are still worth checking, though.
+
+
+
 Build dependencies
 
 Assuming you are using the Raspbian distribution, install the
-- 
1.8.1.5

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

Re: [PATCH wayland-web] raspberrypi: more accurate on dependencies

[Pekka Paalanen]

On Mon, 3 Jun 2013 13:24:23 +0100
Alex Bradbury  wrote:

> On 3 June 2013 12:58,   wrote:
> > From: Pekka Paalanen 
> > It's not strictly necessary to use rpi-update, but I don't know how old
> > firmware and libs are in the Raspbian packages, so recommend it still.
> 
> They currently contain firmware as of 2013-05-24.
> 
> I don't know if it's worth noting in this doc page (is it intended to
> *only* contain instructions for those building from source?) but
> prebuilt binaries are available at http://raspberrypi.collabora.com/,
> and are in fact already included on the most recent Raspbian image.

Hi Alex,

ooh, excellent they got into the image!

As far as I know, all the existing the Raspbian packages are still
based on an older branch of Weston. They also have patches that are
waiting for review.

I'll add something about the prebuilt packages.


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

Re: [PATCH wayland-web] raspberrypi: more accurate on dependencies

[Alex Bradbury]

On 3 June 2013 12:58,   wrote:
> From: Pekka Paalanen 
> It's not strictly necessary to use rpi-update, but I don't know how old
> firmware and libs are in the Raspbian packages, so recommend it still.

They currently contain firmware as of 2013-05-24.

I don't know if it's worth noting in this doc page (is it intended to
*only* contain instructions for those building from source?) but
prebuilt binaries are available at http://raspberrypi.collabora.com/,
and are in fact already included on the most recent Raspbian image.

Regards,

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

Re: [PATCH 00/15] weston scaling support

[Pekka Paalanen]

On Tue, 28 May 2013 19:27:35 +0200
John Kåre Alsaker  wrote:

> My proposal is simply to let the compositor tell the client how much larger
> it wants the client to render content. The client can then tell the
> compositor how much larger it made content in the window. Armed with this
> information the compositor can size the window accordingly.

How would this look in protocol? Just roughly, what requests and events
would be involved. Especially, how does the compositor know to suggest
a size?

> Note that this implies no further change in the protocol or concepts.
> Surface coordinates are still of the same size as buffer coordinates.

Alright.

> This has a number of benefits over the current implementation:
> + Rational scaling factors has no issues (the most important benefit).

I think they may have issues. A surface pel may not cover an integer
amount of pixels in both buffer and output. Or how do you arrange that?

For crisp pel-sized graphics (pixel-sized in apps that do not
understand the output scale), a pel should be an integer amount of
pixels in both output and buffer.

> + Output sizes do not have to be a multiple of the scaling factor.
> + Clients can specify their size in pixels exactly.
> + Clients get input in exact pixels (no rounding errors).
> + Clients doesn't have to transform input events in order to match the
> sizes used by buffers.

I don't really get the above.

> + Conceptually simple to implement. Compositors doesn't have to deal with
> scaling for subsurfaces and they are probably already able to resize whole
> windows.

Why would sub-surfaces have any effect here?

> + Can support clients with integer scaling factors, although these raises
> the same edge cases as the current implementation (they may not be able to
> fit the screen exactly).
> 
> There are however some downsides:
> - Clients may need to transform input events in order to match the
> coordinates used by applications.

So this is a minus here, but the same wrt. buffers was a plus. And it's
the application that first deals with input events, and then decides
what to draw. I don't think input goes directly to drawing machinery.

> - Clients changing scaling factors will have older input reported in the
> old size. This will be quite rare although clients can deal with it if
> desired.
> - Requires an implementation <:)
> 
> I don't expect GTK or other (ancient) toolkits to do fractional scaling and
> reap all the benefits listed here. I don't want anything in the core
> protocol blocking the ability for clients to scale smoothly up though when
> clients will actually be able to do this.

You listed some features, but I still have no idea what you are
suggesting.

It also seems the integer output scale proposal and implementation are
maturing nicely, so now there would need to be obvious reasons for
changing it. I just don't see it based on this description.

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

[PATCH wayland] protocol: Add a name event to give seat name

[Rob Bradford]

From: Rob Bradford 

This provides the ability for a client to differentiate events from
different seats in a multiple seat environment.

v2: handled versioning correctly based on feedback from Daniel and Ander
---
 protocol/wayland.xml | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index f3ba296..3d4ec9b 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -1172,7 +1172,7 @@
 

 
-  
+  
 
   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
@@ -1231,6 +1231,18 @@
   
   
 
+
+
+
+
+  
+   In a multiseat configuration this can be used by the client to help
+   identify which physical devices the seat represents. Based on
+   the seat configuration used by the compositor.
+  
+  
+
+
   
 
   
-- 
1.8.1.4

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

Re: [PATCH wayland-web] raspberrypi: more accurate on dependencies

[darxus]

Thanks, committed.  (HTML validates.)

On 06/03, ppaala...@gmail.com wrote:
> From: Pekka Paalanen 
> 
> Either libraspberrypi-dev package or running rpi-update is needed to get
> the display API libraries.
> 
> It's not strictly necessary to use rpi-update, but I don't know how old
> firmware and libs are in the Raspbian packages, so recommend it still.
> ---
>  raspberrypi.html | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/raspberrypi.html b/raspberrypi.html
> index d77a9e1..b1c2a87 100644
> --- a/raspberrypi.html
> +++ b/raspberrypi.html
> @@ -22,14 +22,17 @@ compiling are done directly on the Pi.
>  build dependencies:
>  $ sudo apt-get install build-essential automake libtool bison flex \
>  xutils-dev libcairo2-dev libffi-dev libmtdev-dev libjpeg-dev \
> -libudev-dev libxcb-xfixes0-dev libxcursor-dev
> +libudev-dev libxcb-xfixes0-dev libxcursor-dev libraspberrypi-dev
>  
>  
>  Firmware
>  
> -Make sure you have the latest Raspberry Pi firmware with the
> +You may need the latest Raspberry Pi firmware, which you can get with the
>  https://github.com/Hexxeh/rpi-update";>rpi-update tool. A too
> -old firmware may cause rpi-backend to malfunction on Raspberry Pi.
> +old firmware may cause rpi-backend to malfunction on Raspberry Pi. Running
> +rpi-update will overwrite files installed by some raspbian packages
> +like libraspberrypi-dev. You can safely try Weston without 
> rpi-update
> +first, but if you encounter graphics problems, see if it fixes them.
>  
>  You may want to tweak the following options in
>  /boot/config.txt:
> @@ -44,7 +47,7 @@ old firmware may cause rpi-backend to malfunction on 
> Raspberry Pi.
>   elements. With off-line enabled, an off-screen buffer
>   is allocated for compositing. When scene complexity
>   (number and sizes of elements) is high, compositing will
> - happen off-line into the buffer.
> + happen off-line into the buffer. Heavily recommended.
>  
>  
>  Setting up the environment
> -- 
> 1.8.1.5
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

-- 
"...Man had always assumed that he was more intelligent than dolphins
because he had achieved so much - the wheel, New York, wars and so on -
whilst all the dolphins had ever done was muck about in the water having
a good time. But conversely, the dolphins had always believed that they
were far more intelligent than man - for precisely the same reasons."
- the Hitchhiker's Guide To The Galaxy
http://www.ChaosReigns.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland-web] raspberrypi: more accurate on dependencies

[ppaalanen]

From: Pekka Paalanen 

Either libraspberrypi-dev package or running rpi-update is needed to get
the display API libraries.

It's not strictly necessary to use rpi-update, but I don't know how old
firmware and libs are in the Raspbian packages, so recommend it still.
---
 raspberrypi.html | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/raspberrypi.html b/raspberrypi.html
index d77a9e1..b1c2a87 100644
--- a/raspberrypi.html
+++ b/raspberrypi.html
@@ -22,14 +22,17 @@ compiling are done directly on the Pi.
 build dependencies:
 $ sudo apt-get install build-essential automake libtool bison flex \
 xutils-dev libcairo2-dev libffi-dev libmtdev-dev libjpeg-dev \
-libudev-dev libxcb-xfixes0-dev libxcursor-dev
+libudev-dev libxcb-xfixes0-dev libxcursor-dev libraspberrypi-dev
 
 
 Firmware
 
-Make sure you have the latest Raspberry Pi firmware with the
+You may need the latest Raspberry Pi firmware, which you can get with the
 https://github.com/Hexxeh/rpi-update";>rpi-update tool. A too
-old firmware may cause rpi-backend to malfunction on Raspberry Pi.
+old firmware may cause rpi-backend to malfunction on Raspberry Pi. Running
+rpi-update will overwrite files installed by some raspbian packages
+like libraspberrypi-dev. You can safely try Weston without rpi-update
+first, but if you encounter graphics problems, see if it fixes them.
 
 You may want to tweak the following options in
 /boot/config.txt:
@@ -44,7 +47,7 @@ old firmware may cause rpi-backend to malfunction on 
Raspberry Pi.
elements. With off-line enabled, an off-screen buffer
is allocated for compositing. When scene complexity
(number and sizes of elements) is high, compositing will
-   happen off-line into the buffer.
+   happen off-line into the buffer. Heavily recommended.
 
 
 Setting up the environment
-- 
1.8.1.5

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

Re: [PATCH wayland 2/4] Add support for flags in the wl_map API and add a WL_MAP_ENTRY_LEGACY flag

[Ander Conselvan de Oliveira]

On 06/02/2013 01:40 AM, Jason Ekstrand wrote:

The implementation in this commit allows for one bit worth of flags.  If
more flags are desired at a future date, then the wl_map implementation
will have to change but the wl_map API will not.


I couldn't find a description of what WL_MAP_ENTRY_LEGACY is supposed to 
mean anywhere in the patch. Would be good to document that in the commit 
message and/or near the enum definition. And maybe this explanation 
would also make clear why flags are necessary.


Cheers,
Ander



Signed-off-by: Jason Ekstrand 
---
  src/wayland-client.c  | 12 ++--
  src/wayland-private.h | 13 +++--
  src/wayland-server.c  | 12 ++--
  src/wayland-util.c| 41 +++--
  4 files changed, 58 insertions(+), 20 deletions(-)

diff --git a/src/wayland-client.c b/src/wayland-client.c
index 0f5e093..bea73e0 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -226,7 +226,7 @@ wl_proxy_create(struct wl_proxy *factory, const struct 
wl_interface *interface)
proxy->refcount = 1;

pthread_mutex_lock(&display->mutex);
-   proxy->object.id = wl_map_insert_new(&display->objects, proxy);
+   proxy->object.id = wl_map_insert_new(&display->objects, 0, proxy);
pthread_mutex_unlock(&display->mutex);

return proxy;
@@ -252,7 +252,7 @@ wl_proxy_create_for_id(struct wl_proxy *factory,
proxy->flags = 0;
proxy->refcount = 1;

-   wl_map_insert_at(&display->objects, id, proxy);
+   wl_map_insert_at(&display->objects, 0, id, proxy);

return proxy;
  }
@@ -273,10 +273,10 @@ wl_proxy_destroy(struct wl_proxy *proxy)
if (proxy->flags & WL_PROXY_FLAG_ID_DELETED)
wl_map_remove(&proxy->display->objects, proxy->object.id);
else if (proxy->object.id < WL_SERVER_ID_START)
-   wl_map_insert_at(&proxy->display->objects,
+   wl_map_insert_at(&proxy->display->objects, 0,
 proxy->object.id, WL_ZOMBIE_OBJECT);
else
-   wl_map_insert_at(&proxy->display->objects,
+   wl_map_insert_at(&proxy->display->objects, 0,
 proxy->object.id, NULL);


@@ -522,11 +522,11 @@ wl_display_connect_to_fd(int fd)
wl_list_init(&display->event_queue_list);
pthread_mutex_init(&display->mutex, NULL);

-   wl_map_insert_new(&display->objects, NULL);
+   wl_map_insert_new(&display->objects, 0, NULL);

display->proxy.object.interface = &wl_display_interface;
display->proxy.object.id =
-   wl_map_insert_new(&display->objects, display);
+   wl_map_insert_new(&display->objects, 0, display);
display->proxy.display = display;
display->proxy.object.implementation = (void(**)(void)) 
&display_listener;
display->proxy.user_data = display;
diff --git a/src/wayland-private.h b/src/wayland-private.h
index 270b470..a648538 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -41,6 +41,14 @@
  #define WL_SERVER_ID_START 0xff00
  #define WL_CLOSURE_MAX_ARGS 20

+/* Flags for wl_map_insert_new and wl_map_insert_at.  Flags can be queried with
+ * wl_map_lookup_flags.  The current implementation has room for 1 bit worth of
+ * flags.  If more flags are ever added, the implementation of wl_map will have
+ * to change to allow for new flags */
+enum wl_map_entry_flags {
+   WL_MAP_ENTRY_LEGACY = (1 << 0)
+};
+
  struct wl_map {
struct wl_array client_entries;
struct wl_array server_entries;
@@ -52,11 +60,12 @@ typedef void (*wl_iterator_func_t)(void *element, void 
*data);

  void wl_map_init(struct wl_map *map, uint32_t side);
  void wl_map_release(struct wl_map *map);
-uint32_t wl_map_insert_new(struct wl_map *map, void *data);
-int wl_map_insert_at(struct wl_map *map, uint32_t i, void *data);
+uint32_t wl_map_insert_new(struct wl_map *map, uint32_t flags, void *data);
+int wl_map_insert_at(struct wl_map *map, uint32_t flags, uint32_t i, void 
*data);
  int wl_map_reserve_new(struct wl_map *map, uint32_t i);
  void wl_map_remove(struct wl_map *map, uint32_t i);
  void *wl_map_lookup(struct wl_map *map, uint32_t i);
+uint32_t wl_map_lookup_flags(struct wl_map *map, uint32_t i);
  void wl_map_for_each(struct wl_map *map, wl_iterator_func_t func, void *data);

  struct wl_connection;
diff --git a/src/wayland-server.c b/src/wayland-server.c
index c96be56..2d13d9d 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -338,7 +338,7 @@ wl_client_create(struct wl_display *display, int fd)

wl_map_init(&client->objects, WL_MAP_SERVER_SIDE);

-   if (wl_map_insert_at(&client->objects, 0, NULL) < 0)
+   if (wl_map_insert_at(&client->objects, 0, 0, NULL) < 0)
goto err_map;

wl_signal_init(&client->destroy_signal);
@@ -379,8 +379,8 @@ wl_client_add_resource(struct wl_client *client,
  {
if (resource->object.id == 0

Re: Compiling weston now needs colord

[sardemff7+wayland]

On 30/05/2013 08:24, Michael Hasselmann wrote:

On Tue, 2013-05-28 at 22:16 -0700, Bill Spitzak wrote:

Running autogen.sh in weston with --disable-colord works to avoid this,
I suspect nothing I care about is lost this way.


I ran into the very same problems. I would have preferred if such new
dependencies were optional or if someone would explain what we will miss
if we disable them. For colord, trying to build the latest required
version from git just pulls in more dependencies that you also have to
build from git (as Bill mentioned).

It's kind of frustrating, even if weston is meant to be a playground and
thus new dependencies have to be expected.

http://wayland.freedesktop.org/building.html should be updated I guess?

ciao Michael


colord is an optional dependency: you just need to pass --disable-colord 
to ./configure (or ./autogen.sh), and it is gone.


It is not an automagic dependency (which automatically detect the 
package’s presence), because it is more work for the developer to add 
the autotools logic to do so. Also, it is much more work to make 
packagers happy (packagers hate automagic dependencies, it makes either 
more work by patching or hard-dependency on optional features).


A little configure switch, and you are done, nothing to complain about. :-)

--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] protocol: Add a name event to give seat name

[Ander Conselvan de Oliveira]

On 05/31/2013 08:40 PM, Daniel Stone wrote:

Hi,

On 31 May 2013 13:08, Rob Bradford  wrote:

+


This needs since="2".


And the new event needs to appear after all version 1 events and 
requests. The scanner expects the since field to be non-decreasing. It 
will throw an error if it finds a decrease in the value and assumes all 
fields have the same value as the last previous field that had the value 
set. For example:








In this case, request b also has since="2".







This would cause the scanner to fail with "since version not increasing".

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