Re: [PATCH wayland] wayland-server: Clarify included header dependencies

[Bryce Harrington]

On Tue, May 17, 2016 at 09:02:01PM -0600, Yong Bakos wrote:
> From: Yong Bakos 
> 
> wayland-server.c directly depends on wayland-util.h, and will include
> wayland-server-protocol.h via wayland-server.h.
> 
> Explicitly include wayland-util.h, making this dependency clear.
> Remove the redundant inclusion of wayland-server-protocol.h.
> 
> Signed-off-by: Yong Bakos 
Reviewed-by: Bryce Harrington 

Pushed:
To ssh://git.freedesktop.org/git/wayland/wayland
   972f1a2..d588efc  master -> master


> ---
>  src/wayland-server.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index f745e62..0fe532c 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -43,9 +43,9 @@
>  #include 
>  #include 
>  
> +#include "wayland-util.h"
>  #include "wayland-private.h"
>  #include "wayland-server.h"
> -#include "wayland-server-protocol.h"
>  #include "wayland-os.h"
>  
>  /* This is the size of the char array in struct sock_addr_un.
> -- 
> 2.7.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] event-loop: Make transitive include explicit

[Bryce Harrington]

On Tue, May 17, 2016 at 02:32:02PM +0800, Jonas Ådahl wrote:
> On Mon, May 16, 2016 at 12:05:39PM -0600, Yong Bakos wrote:
> > From: Yong Bakos 
> > 
> > The explicit inclusion of wayland-server.h hides the real dependency, which
> > is wayland-server-core.h.
> > 
> > Signed-off-by: Yong Bakos 
> 
> Reviewed-by: Jonas Ådahl 

Reviewed-by: Bryce Harrington 

Pushed:

To ssh://git.freedesktop.org/git/wayland/wayland
   a1bce0e..972f1a2  master -> master


> >  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 ea27b69..11a9bf2 100644
> > --- a/src/event-loop.c
> > +++ b/src/event-loop.c
> > @@ -37,7 +37,7 @@
> >  #include 
> >  #include 
> >  #include "wayland-private.h"
> > -#include "wayland-server.h"
> > +#include "wayland-server-core.h"
> >  #include "wayland-os.h"
> >  
> >  struct wl_event_loop {
> > -- 
> > 2.7.2
> > 
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] weston-launch: Handle invalid command line options

[Bryce Harrington]

On Mon, May 16, 2016 at 12:43:37PM -0600, Yong Bakos wrote:
> On May 7, 2016, at 5:57 AM, Otavio Salvador  wrote:
> > 
> > From: Tom Hochstein 
> > 
> > Exit the program if an unrecognized command line option is found.
> > 
> > Signed-off-by; Tom Hochstein 
> > Signed-off-by: Otavio Salvador 
> 
> Simple enough of a review, and I did test this. But the question is
> whether we want weston-launch to ignore invalid options or to quit in the
> event of their presence. I'm not experienced enough to judge, so others
> will have to chime in. So fwiw,
> 
> Reviewed-by: Yong Bakos 
> Tested-by: Yong Bakos 

Thanks, pushed:

Reviewed-by: Bryce Harrington 

To ssh://git.freedesktop.org/git/wayland/weston
   6657fda..e57056f  master -> master


> 
> > ---
> > 
> > src/weston-launch.c | 2 ++
> > 1 file changed, 2 insertions(+)
> > 
> > diff --git a/src/weston-launch.c b/src/weston-launch.c
> > index b8dfb17..9987d8e 100644
> > --- a/src/weston-launch.c
> > +++ b/src/weston-launch.c
> > @@ -703,6 +703,8 @@ main(int argc, char *argv[])
> > case 'h':
> > help("weston-launch");
> > exit(EXIT_FAILURE);
> > +   default:
> > +   exit(EXIT_FAILURE);
> > }
> > }
> > 
> > -- 
> > 2.8.2
> > 
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] Remove Raspberry Pi backend and renderer

[Jonas Ådahl]

On Wed, Jun 01, 2016 at 01:11:15PM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen 
> 
> This patch completely removes the Raspberry Pi backend and the renderer.
> 
> The backend and the renderer were written to use the proprietary
> DispmanX API available only on the Raspberry Pi, to demonstrate what the
> tiny computer is capable of graphics wise. They were also used to
> demonstrate how Wayland and Weston in particular could leverage hardware
> compositing capabilities that are not OpenGL. The backend was first
> added in e8de35c922871bc5b15fbf0436efa233a6db8e41, in 2012.
> 
> Since then, the major point has been proven. Over time, support for the
> rpi-backend diminished, it started to deteriorate and hinder Weston
> development. On May 11, I tried to ask if anyone actually cared about
> the rpi-backend, but did not get any votes for keeping it:
> https://lists.freedesktop.org/archives/wayland-devel/2016-May/028764.html
> 
> The rpi-backend is a good example of how using an API that is only
> available for specific hardware, even more so as it is only available
> with a proprietary driver stack, is not maintainable in the long run.
> Most developers working on Weston either just cannot, or cannot bother
> to test things also on the RPi. Breakage creeps in without anyone
> noticing. If someone actually notices it, fixing it will require a very
> specific environment to be able to test. Also the quality of the
> proprietary implementation fluctuated. There are reports that RPi
> firmware updates randomly broke Weston, and that nowadays it is very
> hard to find a RPi firmware version that you could expect to work with
> Weston if Weston itself was not broken. We are not even sure what is
> broken nowadays.
> 
> This removal does not leave Raspberry Pi users cold (for long), though.
> There is serious work going on in implementing a FOSS driver stack for
> Raspberry Pi, including modern kernel DRM drivers and Mesa drivers. It
> might not be fully there yet, but the plan is to be able to use the
> standard DRM-backend of Weston on the RPis. See:
> http://dri.freedesktop.org/wiki/VC4/
> 
> The rpi-backend had its moments. Now, it needs to go. Good riddance!
> 
> Signed-off-by: Pekka Paalanen 

FWIW, this one is Acked-by: Jonas Ådahl 


Jonas

> ---
>  Makefile.am  |   34 -
>  README   |2 -
>  configure.ac |   18 -
>  man/weston.ini.man   |1 -
>  src/compositor-rpi.c |  575 
>  src/main.c   |   19 -
>  src/rpi-bcm-stubs.h  |  327 -
>  src/rpi-renderer.c   | 1830 
> --
>  src/rpi-renderer.h   |   52 --
>  9 files changed, 2858 deletions(-)
>  delete mode 100644 src/compositor-rpi.c
>  delete mode 100644 src/rpi-bcm-stubs.h
>  delete mode 100644 src/rpi-renderer.c
>  delete mode 100644 src/rpi-renderer.h
> 
> diff --git a/Makefile.am b/Makefile.am
> index 00b74e5..8ee9c8d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -328,40 +328,6 @@ nodist_wayland_backend_la_SOURCES =  
> \
>   protocol/fullscreen-shell-unstable-v1-client-protocol.h
>  endif
>  
> -if ENABLE_RPI_COMPOSITOR
> -if INSTALL_RPI_COMPOSITOR
> -module_LTLIBRARIES += rpi-backend.la
> -else
> -noinst_LTLIBRARIES += rpi-backend.la
> -endif
> -
> -rpi_backend_la_LDFLAGS = -module -avoid-version
> -rpi_backend_la_LIBADD = $(COMPOSITOR_LIBS)   \
> - $(RPI_COMPOSITOR_LIBS)  \
> - $(RPI_BCM_HOST_LIBS)\
> - $(INPUT_BACKEND_LIBS)   \
> - libsession-helper.la\
> - libshared.la
> -rpi_backend_la_CFLAGS =  \
> - $(AM_CFLAGS)\
> - $(COMPOSITOR_CFLAGS)\
> - $(RPI_COMPOSITOR_CFLAGS)\
> - $(RPI_BCM_HOST_CFLAGS)
> -rpi_backend_la_SOURCES = \
> - src/compositor-rpi.c\
> - src/rpi-renderer.c  \
> - src/rpi-renderer.h  \
> - src/rpi-bcm-stubs.h \
> - shared/helpers.h\
> - $(INPUT_BACKEND_SOURCES)
> -
> -if ENABLE_EGL
> -rpi_backend_la_LIBADD += $(EGL_LIBS)
> -rpi_backend_la_CFLAGS += $(EGL_CFLAGS)
> -endif
> -
> -endif
> -
>  if ENABLE_HEADLESS_COMPOSITOR
>  module_LTLIBRARIES += headless-backend.la
>  headless_backend_la_LDFLAGS = -module -avoid-version
> diff --git a/README b/README
> index 3fdfb37..110a14b 100644
> --- a/README
> +++ b/README
> @@ -138,8 +138,6 @@ would be roughly like this:
>  
>  - xwayland (depends on X11/xcb libs)
>  
> -- rpi-backend (depends on DispmanX, libudev, ...)
> -
>  - fbdev-backend (depends on libudev...)
>  
>  - rdp-backend (depends on freerdp)
> diff --git a/configure.ac b/configure.ac
> index 87e67fe..525810f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -208,23 +208,6 @@ if test x$enable_headless_compositor = xyes; then
>  fi
>  
>  

Re: [PATCH RFC] xdg-shell: Add tiled states

[Jonas Ådahl]

On Wed, Jun 01, 2016 at 10:42:23AM -0400, Olivier Fourdan wrote:
> Hi Mike,
> 
> - Original Message -
> > I've read the ticket linked in the other mail, but your use of "tiled" here
> > is confusing to me since you (and the ticket) appear to be conflating two
> > separate-but-unrelated meanings.  "Tiled" is a type of window layout policy
> > which organizes windows into a tiled grid formation; this is in opposition
> > to "stacking".
> 
> Sure, I appreciate that.
>  
> > The ticket you linked seems to be primarily about positioning windows to
> > take up 50% of screen geometry, (e.g., left half of screen, top half of
> > screen, ...). This seems a lot more like a maximize state to me since it's
> > based on screen geometry. In X11 there's NETWM hints for
> > vertical/horizontal maximize: EFL uses these to handle partial
> > maximizations, and in Wayland we simply use the normal MAXIMIZE window
> > state since directionality is irrelevant.
> 
> This is the current use of "tiling" in gnome-shell and gtk+, but we should 
> not limit tiling to a single (very limited) implementation.
> 
> > I think MAXIMIZE fully covers
> > this case and there is no need for any further protocol to inform the
> > client.
> 
> I reckon using partial maximization from EWMH to achieve basic tiling in 
> gnome-shell/gtk+ was a hack, it leads to all sort of workarounds in gtk+:
> 
> https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n244
> 
> And it doesn't even take into account horizontal tiling, 
> https://bugzilla.gnome.org/show_bug.cgi?id=742525
> 
> I'd rather not mix up maximization and tiling again, given the chance...
> 
> > In the case of the real "tiled" state, (i.e., a tiling layout policy), I
> > think this is something which should be a single draw state. There's no
> > need to inform a client about its surface's relative position (e.g., any of
> > your proposed directional tiled values) since the result is the same in
> > every case--the client must obey configured geometry.
> 
> The client may chose to draw the border on the surface edged tiled 
> differently, to achieve seamless borders between tiled windows for example, 
> while keeping the other edges (not tiled) unchanged, that was the idea behind 
> the use of the edge values.
>  
> > The difference from the MAXIMIZE state here is mostly conceptual: MAXIMIZE
> > indicates to a client that a surface is taking up the entire screen's
> > geometry on at least one axis and thus it may choose to draw UI elements
> > differently (e.g., showing/hiding extra toolbars along the larger axis). A
> > TILED state simply informs the client that it must obey sizing policies and
> > draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's
> > implicitly "tiled" by being maximized), but a tiled surface can toggle
> > MAXIMIZE.
> 
> I see where you're coming from, if we consider a single "tiled" state then 
> it's similar in essence to the maximized state with a different geometry, so 
> we could get away with a "tiled" draw state instead that clients would use to 
> distinguish from the real "maximize" state when drawing their decorations 
> (including the "maximize" button in the title bar which can differ when 
> maximized or not).

I fail to see what makes tiling and maximized so significantly different
that one would require a predictable negotiation. This would just mean
that a tiling compositor can't properly tile surfaces that doesn't
support an optional draw state.

If the tiling compositor still would draw the surface tiled which didn't
support the tiled draw state, then I see no point what so ever having to
negotiate anything, since the end result for the compositor would be
100% the same.

So, what is the reason a tiled state an optional state that requires
negotiation, while maximized does not?


Jonas

> 
> Granted, I am not a tiling window manager aficionado myself, so it would be 
> great if those who design tiling window managers could chime in as well and 
> express their needs wrt. tiling.
> 
> Cheers,
> Olivier
> 
>  
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland 0/3] doc: Unpublish private objects and functions

[Bryce Harrington]

On Thu, May 12, 2016 at 03:52:36PM -0500, Yong Bakos wrote:
> From: Yong Bakos 
> 
> The Wayland docbook and the doxygen html docs had been presenting a number
> of private/inaccessible things as part of the public API, which is misleading.
> 
> For 1/3, a \private command was introduced since the function is a private
> wl_display member function. For the xsl rule, I did test both != 'private'
> and = 'public' (thinking of future flexibility) but the doc diff is the same
> and = 'public' is more direct. Note that I placed the \private marker between
> the \sa and \memberof to match the convention that \sa follows a long
> description and \memberof precedes the close of a doc comment.
> 
> In 2-3/3, using the \cond command was sufficient and preferred.
> 
> Yong Bakos (3):
>   doc: Unpublish wl_display_get_additional_shm_formats
>   doc: Unpublish wl_log* and wl_abort
>   doc: Unpublish global_zombie_object and wl_interface_equal
> 
>  doc/publican/doxygen-to-publican.xsl |  2 +-
>  src/wayland-server.c |  2 ++
>  src/wayland-util.c   | 34 +-
>  3 files changed, 20 insertions(+), 18 deletions(-)

In checking the doxygen documentation, these changes all look good, and
near as I can tell the routines in question are in fact private, so for
all three patches:

Reviewed-by: Bryce Harrington 

And as we're now post-release I've gone ahead and pushed them to trunk.

To ssh://git.freedesktop.org/git/wayland/wayland
   98d94b5..a1bce0e  master -> master

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

Re: [PATCH weston] Remove Raspberry Pi backend and renderer

[Bryce Harrington]

Given there's an all-FOSS alternative coming down the pike, I see little
reason to hold on to the proprietary-driver dependent backend.

Acked-by: Bryce Harrington 

On Wed, Jun 01, 2016 at 01:11:15PM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen 
> 
> This patch completely removes the Raspberry Pi backend and the renderer.
> 
> The backend and the renderer were written to use the proprietary
> DispmanX API available only on the Raspberry Pi, to demonstrate what the
> tiny computer is capable of graphics wise. They were also used to
> demonstrate how Wayland and Weston in particular could leverage hardware
> compositing capabilities that are not OpenGL. The backend was first
> added in e8de35c922871bc5b15fbf0436efa233a6db8e41, in 2012.
> 
> Since then, the major point has been proven. Over time, support for the
> rpi-backend diminished, it started to deteriorate and hinder Weston
> development. On May 11, I tried to ask if anyone actually cared about
> the rpi-backend, but did not get any votes for keeping it:
> https://lists.freedesktop.org/archives/wayland-devel/2016-May/028764.html
> 
> The rpi-backend is a good example of how using an API that is only
> available for specific hardware, even more so as it is only available
> with a proprietary driver stack, is not maintainable in the long run.
> Most developers working on Weston either just cannot, or cannot bother
> to test things also on the RPi. Breakage creeps in without anyone
> noticing. If someone actually notices it, fixing it will require a very
> specific environment to be able to test. Also the quality of the
> proprietary implementation fluctuated. There are reports that RPi
> firmware updates randomly broke Weston, and that nowadays it is very
> hard to find a RPi firmware version that you could expect to work with
> Weston if Weston itself was not broken. We are not even sure what is
> broken nowadays.
> 
> This removal does not leave Raspberry Pi users cold (for long), though.
> There is serious work going on in implementing a FOSS driver stack for
> Raspberry Pi, including modern kernel DRM drivers and Mesa drivers. It
> might not be fully there yet, but the plan is to be able to use the
> standard DRM-backend of Weston on the RPis. See:
> http://dri.freedesktop.org/wiki/VC4/
> 
> The rpi-backend had its moments. Now, it needs to go. Good riddance!
> 
> Signed-off-by: Pekka Paalanen 
> ---
>  Makefile.am  |   34 -
>  README   |2 -
>  configure.ac |   18 -
>  man/weston.ini.man   |1 -
>  src/compositor-rpi.c |  575 
>  src/main.c   |   19 -
>  src/rpi-bcm-stubs.h  |  327 -
>  src/rpi-renderer.c   | 1830 
> --
>  src/rpi-renderer.h   |   52 --
>  9 files changed, 2858 deletions(-)
>  delete mode 100644 src/compositor-rpi.c
>  delete mode 100644 src/rpi-bcm-stubs.h
>  delete mode 100644 src/rpi-renderer.c
>  delete mode 100644 src/rpi-renderer.h
> 
> diff --git a/Makefile.am b/Makefile.am
> index 00b74e5..8ee9c8d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -328,40 +328,6 @@ nodist_wayland_backend_la_SOURCES =  
> \
>   protocol/fullscreen-shell-unstable-v1-client-protocol.h
>  endif
>  
> -if ENABLE_RPI_COMPOSITOR
> -if INSTALL_RPI_COMPOSITOR
> -module_LTLIBRARIES += rpi-backend.la
> -else
> -noinst_LTLIBRARIES += rpi-backend.la
> -endif
> -
> -rpi_backend_la_LDFLAGS = -module -avoid-version
> -rpi_backend_la_LIBADD = $(COMPOSITOR_LIBS)   \
> - $(RPI_COMPOSITOR_LIBS)  \
> - $(RPI_BCM_HOST_LIBS)\
> - $(INPUT_BACKEND_LIBS)   \
> - libsession-helper.la\
> - libshared.la
> -rpi_backend_la_CFLAGS =  \
> - $(AM_CFLAGS)\
> - $(COMPOSITOR_CFLAGS)\
> - $(RPI_COMPOSITOR_CFLAGS)\
> - $(RPI_BCM_HOST_CFLAGS)
> -rpi_backend_la_SOURCES = \
> - src/compositor-rpi.c\
> - src/rpi-renderer.c  \
> - src/rpi-renderer.h  \
> - src/rpi-bcm-stubs.h \
> - shared/helpers.h\
> - $(INPUT_BACKEND_SOURCES)
> -
> -if ENABLE_EGL
> -rpi_backend_la_LIBADD += $(EGL_LIBS)
> -rpi_backend_la_CFLAGS += $(EGL_CFLAGS)
> -endif
> -
> -endif
> -
>  if ENABLE_HEADLESS_COMPOSITOR
>  module_LTLIBRARIES += headless-backend.la
>  headless_backend_la_LDFLAGS = -module -avoid-version
> diff --git a/README b/README
> index 3fdfb37..110a14b 100644
> --- a/README
> +++ b/README
> @@ -138,8 +138,6 @@ would be roughly like this:
>  
>  - xwayland (depends on X11/xcb libs)
>  
> -- rpi-backend (depends on DispmanX, libudev, ...)
> -
>  - fbdev-backend (depends on libudev...)
>  
>  - rdp-backend (depends on freerdp)
> diff --git a/configure.ac b/configure.ac
> index 87e67fe..525810f 100644
> --- a/confi

Re: [PATCH libinput] touchpad: warn if we have invalid touchpad ranges

[Peter Hutterer]

On Wed, Jun 01, 2016 at 08:41:17AM -0500, Yong Bakos wrote:
> On May 31, 2016, at 7:42 PM, Peter Hutterer  wrote:
> > 
> > Quite a few bugs are caused by touchpad ranges being out of whack. If we get
> > input events significantly outside the expected range (5% width/height as
> > error margin) print a warning to the log.
> > 
> > And add a new doc page to explain what is happening and how to fix it.
> > 
> > Signed-off-by: Peter Hutterer 
> 
> Hi Peter,
> FWIW, one minor nit (whildcard) I noticed, inline below.

fixed, thanks.

Cheers,
   Peter

> > ---
> > doc/Makefile.am|   1 +
> > doc/absolute-coordinate-ranges.dox | 120 
> > +
> > doc/page-hierarchy.dox |   1 +
> > src/evdev-mt-touchpad.c|  59 ++
> > src/evdev-mt-touchpad.h|   5 ++
> > 5 files changed, 186 insertions(+)
> > create mode 100644 doc/absolute-coordinate-ranges.dox
> > 
> > diff --git a/doc/Makefile.am b/doc/Makefile.am
> > index f2a47cb..1e501a8 100644
> > --- a/doc/Makefile.am
> > +++ b/doc/Makefile.am
> > @@ -11,6 +11,7 @@ header_files = \
> > $(top_srcdir)/src/libinput.h \
> > $(top_srcdir)/README.txt \
> > $(srcdir)/absolute-axes.dox \
> > +   $(srcdir)/absolute-coordinate-ranges.dox \
> > $(srcdir)/clickpad-softbuttons.dox \
> > $(srcdir)/device-configuration-via-udev.dox \
> > $(srcdir)/faqs.dox \
> > diff --git a/doc/absolute-coordinate-ranges.dox 
> > b/doc/absolute-coordinate-ranges.dox
> > new file mode 100644
> > index 000..f9d9e98
> > --- /dev/null
> > +++ b/doc/absolute-coordinate-ranges.dox
> > @@ -0,0 +1,120 @@
> > +/**
> > +@page absolute_coordinate_ranges Coordinate ranges for absolute axes
> > +
> > +libinput requires that all touchpads provide a correct axis range and
> > +resolution. These are used to enable or disable certain features or adapt
> > +the interaction with the touchpad. For example, the software button area is
> > +narrower on small touchpads to avoid reducing the interactive surface too
> > +much. Likewise, palm detection works differently on small touchpads as palm
> > +interference is less likely to happen.
> > +
> > +Touchpads with incorrect axis ranges generate error messages
> > +in the form:
> > +
> > +Axis 0x35 value 4000 is outside expected range [0, 3000]
> > +
> > +
> > +This error message indicates that the ABS_MT_POSITION_X axis (i.e. the x
> > +axis) generated an event outside the expected range of 0-3000. In this case
> > +the value was 4000.
> > +This discrepancy between the coordinate range the kernels advertises vs.
> > +what the touchpad sends can be the source of a number of perceived
> > +bugs in libinput.
> > +
> > +@section absolute_coordinate_ranges_fix Measuring and fixing touchpad 
> > ranges
> > +
> > +To fix the touchpad you need to:
> > +-# measure the physical size of your touchpad in mm
> > +-# run touchpad-edge-detector
> > +-# trim the udev match rule to something sensible
> > +-# replace the resolution with the calculated resolution based on physical
> > +  settings
> > +-# test locally
> > +-# send a patch to the systemd project
> > +
> > +Detailed explanations are below.
> > +
> > +[libevdev](http://freedesktop.org/wiki/Software/libevdev/) provides a tool
> > +called **touchpad-edge-detector** that allows measuring the touchpad's 
> > input
> > +ranges. Run the tool as root against the device node of your touchpad 
> > device
> > +and repeatedly move a finger around the whole outside area of the
> > +touchpad. Then control+c the process and note the output.
> > +An example output is below:
> > +
> > +@code
> > +$> sudo touchpad-edge-detector /dev/input/event4
> > +Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event4
> > +Move one finger around the touchpad to detect the actual edges
> > +Kernel says:   x [1024..3112], y [2024..4832]
> > +Touchpad sends:x [2445..4252], y [3464..4071]
> > +
> > +Touchpad size as listed by the kernel: 49x66mm
> > +Calculate resolution as:
> > +   x axis: 2088/
> > +   y axis: 2808/
> > +
> > +Suggested udev rule:
> > +# 
> > +evdev:name:SynPS/2 Synaptics 
> > TouchPad:dmi:bvnLENOVO:bvrGJET72WW(2.22):bd02/21/2014:svnLENOVO:pn20ARS25701:pvrThinkPadT440s:rvnLENOVO:rn20ARS25701:rvrSDK0E50512STD:cvnLENOVO:ct10:cvrNotAvailable:*
> > + EVDEV_ABS_00=2445:4252:
> > + EVDEV_ABS_01=3464:4071:
> > + EVDEV_ABS_35=2445:4252:
> > + EVDEV_ABS_36=3464:4071:
> > +
> > +@endcode
> > +
> > +Note the discrepancy between the coordinate range the kernels advertises 
> > vs.
> > +what the touchpad sends.
> > +To fix the advertised ranges, the udev rule should be taken and trimmed
> > +before being sent to the [systemd 
> > project](https://github.com/systemd/systemd).
> > +An example commit can be found
> > +[here](https://github.com/systemd/systemd/commit/26f667eac1c5e89b689aa0a1daef6a80f473e045).
> > +
> > +In most cases the match can and should be trimmed to the system vendor 
> > (svn)
> > +and the product version

[PATCH weston v2 4/8] compositor: remove the weston_config field in weston_compositor

[Giulio Camuffo]

The config can now be retrieved with a new function defined in weston.h,
weston_get_config(weston_compositor*).

Signed-off-by: Giulio Camuffo 
---
 desktop-shell/shell.c  | 2 +-
 ivi-shell/hmi-controller.c | 6 +++---
 ivi-shell/ivi-shell.c  | 3 ++-
 src/cms-static.c   | 3 ++-
 src/compositor.h   | 1 -
 src/libinput-device.c  | 4 +++-
 src/main.c | 9 +++--
 src/text-backend.c | 3 ++-
 src/weston.h   | 3 +++
 xwayland/launcher.c| 5 +++--
 10 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index ec71cd1..e32f61e 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -640,7 +640,7 @@ shell_configuration(struct desktop_shell *shell)
int ret;
int allow_zap;
 
-   section = weston_config_get_section(shell->compositor->config,
+   section = 
weston_config_get_section(weston_get_config(shell->compositor),
"shell", NULL, NULL);
ret = asprintf(&client, "%s/%s", weston_config_get_libexec_dir(),
   WESTON_SHELL_CLIENT);
diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index 094682c..b479bb3 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -678,7 +678,7 @@ static struct hmi_server_setting *
 hmi_server_setting_create(struct weston_compositor *ec)
 {
struct hmi_server_setting *setting = MEM_ALLOC(sizeof(*setting));
-   struct weston_config *config = ec->config;
+   struct weston_config *config = weston_get_config(ec);
struct weston_config_section *shell_section = NULL;
 
shell_section = weston_config_get_section(config, "ivi-shell",
@@ -1140,7 +1140,7 @@ ivi_hmi_controller_add_launchers(struct hmi_controller 
*hmi_ctrl,
if (0 == y_count)
y_count  = 1;
 
-   config = hmi_ctrl->compositor->config;
+   config = weston_get_config(hmi_ctrl->compositor);
if (!config)
return;
 
@@ -1881,7 +1881,7 @@ initialize(struct hmi_controller *hmi_ctrl)
uint32_t *dest;
};
 
-   struct weston_config *config = hmi_ctrl->compositor->config;
+   struct weston_config *config = weston_get_config(hmi_ctrl->compositor);
struct weston_config_section *section = NULL;
int result = 0;
int i = 0;
diff --git a/ivi-shell/ivi-shell.c b/ivi-shell/ivi-shell.c
index 59ffe0c..a312485 100644
--- a/ivi-shell/ivi-shell.c
+++ b/ivi-shell/ivi-shell.c
@@ -46,6 +46,7 @@
 #include "ivi-layout-export.h"
 #include "ivi-layout-shell.h"
 #include "shared/helpers.h"
+#include "weston.h"
 
 /* Representation of ivi_surface protocol object. */
 struct ivi_shell_surface
@@ -416,7 +417,7 @@ ivi_shell_setting_create(struct ivi_shell_setting *dest,
 int *argc, char *argv[])
 {
int result = 0;
-   struct weston_config *config = compositor->config;
+   struct weston_config *config = weston_get_config(compositor);
struct weston_config_section *section;
 
const struct weston_option ivi_shell_options[] = {
diff --git a/src/cms-static.c b/src/cms-static.c
index 0273ee3..1feb902 100644
--- a/src/cms-static.c
+++ b/src/cms-static.c
@@ -31,6 +31,7 @@
 #include "compositor.h"
 #include "cms-helper.h"
 #include "shared/helpers.h"
+#include "weston.h"
 
 struct cms_static {
struct weston_compositor*ec;
@@ -49,7 +50,7 @@ cms_output_created(struct cms_static *cms, struct 
weston_output *o)
 
if (o->name == NULL)
return;
-   s = weston_config_get_section(cms->ec->config,
+   s = weston_config_get_section(weston_get_config(cms->ec),
  "output", "name", o->name);
if (s == NULL)
return;
diff --git a/src/compositor.h b/src/compositor.h
index 4b006af..4600ae3 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -726,7 +726,6 @@ struct weston_compositor {
 
struct wl_display *wl_display;
struct weston_shell_interface shell_interface;
-   struct weston_config *config;
 
/* surface signals */
struct wl_signal create_surface_signal;
diff --git a/src/libinput-device.c b/src/libinput-device.c
index c5d3fd1..3443666 100644
--- a/src/libinput-device.c
+++ b/src/libinput-device.c
@@ -39,6 +39,7 @@
 #include "compositor.h"
 #include "libinput-device.h"
 #include "shared/helpers.h"
+#include "weston.h"
 
 void
 evdev_led_update(struct evdev_device *device, enum weston_led weston_leds)
@@ -528,10 +529,11 @@ configure_device(struct evdev_device *device)
 {
struct weston_compositor *compositor = device->seat->compositor;
struct weston_config_section *s;
+   struct weston_config *config = weston_get_config(compositor);
int enable_tap;
int enable_tap_default;
 
-   s = weston_config_get_section(compositor->config,
+   s = weston_config_get_se

[PATCH weston v2 6/8] allow compositors to define the logging behavior

[Giulio Camuffo]

Signed-off-by: Giulio Camuffo 
---
 src/compositor.h |  5 ++--
 src/log.c| 74 ++-
 src/main.c   | 80 
 3 files changed, 90 insertions(+), 69 deletions(-)

diff --git a/src/compositor.h b/src/compositor.h
index 4600ae3..de8a3b6 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -1545,10 +1545,9 @@ weston_compositor_xkb_destroy(struct weston_compositor 
*ec);
 /* String literal of spaces, the same width as the timestamp. */
 #define STAMP_SPACE "   "
 
+typedef int (*log_func_t)(const char *fmt, va_list ap);
 void
-weston_log_file_open(const char *filename);
-void
-weston_log_file_close(void);
+weston_log_set_handler(log_func_t log, log_func_t cont);
 int
 weston_vlog(const char *fmt, va_list ap);
 int
diff --git a/src/log.c b/src/log.c
index 0302c8c..dd01811 100644
--- a/src/log.c
+++ b/src/log.c
@@ -36,78 +36,20 @@
 
 #include "compositor.h"
 
-#include "os-compatibility.h"
+static log_func_t log_handler = 0;
+static log_func_t log_continue_handler = 0;
 
-static FILE *weston_logfile = NULL;
-
-static int cached_tm_mday = -1;
-
-static int weston_log_timestamp(void)
-{
-   struct timeval tv;
-   struct tm *brokendown_time;
-   char string[128];
-
-   gettimeofday(&tv, NULL);
-
-   brokendown_time = localtime(&tv.tv_sec);
-   if (brokendown_time == NULL)
-   return fprintf(weston_logfile, "[(NULL)localtime] ");
-
-   if (brokendown_time->tm_mday != cached_tm_mday) {
-   strftime(string, sizeof string, "%Y-%m-%d %Z", brokendown_time);
-   fprintf(weston_logfile, "Date: %s\n", string);
-
-   cached_tm_mday = brokendown_time->tm_mday;
-   }
-
-   strftime(string, sizeof string, "%H:%M:%S", brokendown_time);
-
-   return fprintf(weston_logfile, "[%s.%03li] ", string, tv.tv_usec/1000);
-}
-
-static void
-custom_handler(const char *fmt, va_list arg)
+WL_EXPORT void
+weston_log_set_handler(log_func_t log, log_func_t cont)
 {
-   weston_log_timestamp();
-   fprintf(weston_logfile, "libwayland: ");
-   vfprintf(weston_logfile, fmt, arg);
-}
-
-void
-weston_log_file_open(const char *filename)
-{
-   wl_log_set_handler_server(custom_handler);
-
-   if (filename != NULL) {
-   weston_logfile = fopen(filename, "a");
-   if (weston_logfile)
-   os_fd_set_cloexec(fileno(weston_logfile));
-   }
-
-   if (weston_logfile == NULL)
-   weston_logfile = stderr;
-   else
-   setvbuf(weston_logfile, NULL, _IOLBF, 256);
-}
-
-void
-weston_log_file_close()
-{
-   if ((weston_logfile != stderr) && (weston_logfile != NULL))
-   fclose(weston_logfile);
-   weston_logfile = stderr;
+   log_handler = log;
+   log_continue_handler = cont;
 }
 
 WL_EXPORT int
 weston_vlog(const char *fmt, va_list ap)
 {
-   int l;
-
-   l = weston_log_timestamp();
-   l += vfprintf(weston_logfile, fmt, ap);
-
-   return l;
+   return log_handler(fmt, ap);
 }
 
 WL_EXPORT int
@@ -126,7 +68,7 @@ weston_log(const char *fmt, ...)
 WL_EXPORT int
 weston_vlog_continue(const char *fmt, va_list argp)
 {
-   return vfprintf(weston_logfile, fmt, argp);
+   return log_continue_handler(fmt, argp);
 }
 
 WL_EXPORT int
diff --git a/src/main.c b/src/main.c
index e71fce9..2ecb4d9 100644
--- a/src/main.c
+++ b/src/main.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef HAVE_LIBUNWIND
 #define UNW_LOCAL_ONLY
@@ -61,6 +62,84 @@
 
 #define WINDOW_TITLE "Weston Compositor"
 
+static FILE *weston_logfile = NULL;
+
+static int cached_tm_mday = -1;
+
+static int weston_log_timestamp(void)
+{
+   struct timeval tv;
+   struct tm *brokendown_time;
+   char string[128];
+
+   gettimeofday(&tv, NULL);
+
+   brokendown_time = localtime(&tv.tv_sec);
+   if (brokendown_time == NULL)
+   return fprintf(weston_logfile, "[(NULL)localtime] ");
+
+   if (brokendown_time->tm_mday != cached_tm_mday) {
+   strftime(string, sizeof string, "%Y-%m-%d %Z", brokendown_time);
+   fprintf(weston_logfile, "Date: %s\n", string);
+
+   cached_tm_mday = brokendown_time->tm_mday;
+   }
+
+   strftime(string, sizeof string, "%H:%M:%S", brokendown_time);
+
+   return fprintf(weston_logfile, "[%s.%03li] ", string, tv.tv_usec/1000);
+}
+
+static void
+custom_handler(const char *fmt, va_list arg)
+{
+   weston_log_timestamp();
+   fprintf(weston_logfile, "libwayland: ");
+   vfprintf(weston_logfile, fmt, arg);
+}
+
+static void
+weston_log_file_open(const char *filename)
+{
+   wl_log_set_handler_server(custom_handler);
+
+   if (filename != NULL) {
+   weston_logfile = fopen(filename, "a");
+   if (weston_logfile)
+   os_fd_set_cloexec(fileno(weston_logfile));
+  

[PATCH weston v2 3/8] Move the functions launching clients to main.c

[Giulio Camuffo]

They belong in the compositor rather than libweston since they
set signals handlers, and a library should not do that behind its
user's back. Besides, they were using functions in main.c already
so they were not usable by other compositors.

Signed-off-by: Giulio Camuffo 
---
 ivi-shell/hmi-controller.c |   1 +
 src/compositor.c   | 144 
 src/compositor.h   |  22 ---
 src/main.c | 146 +
 src/text-backend.c |   1 +
 src/weston.h   |  22 +++
 tests/ivi_layout-test-plugin.c |   1 +
 tests/weston-test.c|   1 +
 xwayland/xwayland.h|   1 +
 9 files changed, 173 insertions(+), 166 deletions(-)

diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index 97f78af..094682c 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -62,6 +62,7 @@
 #include "ivi-hmi-controller-server-protocol.h"
 #include "shared/helpers.h"
 #include "shared/xalloc.h"
+#include "src/weston.h"
 
 /*
  *  structure, globals
diff --git a/src/compositor.c b/src/compositor.c
index b6ef7f3..2ec2f18 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -236,150 +236,6 @@ weston_output_mode_switch_to_temporary(struct 
weston_output *output,
 }
 
 static void
-child_client_exec(int sockfd, const char *path)
-{
-   int clientfd;
-   char s[32];
-   sigset_t allsigs;
-
-   /* do not give our signal mask to the new process */
-   sigfillset(&allsigs);
-   sigprocmask(SIG_UNBLOCK, &allsigs, NULL);
-
-   /* Launch clients as the user. Do not lauch clients with wrong euid.*/
-   if (seteuid(getuid()) == -1) {
-   weston_log("compositor: failed seteuid\n");
-   return;
-   }
-
-   /* SOCK_CLOEXEC closes both ends, so we dup the fd to get a
-* non-CLOEXEC fd to pass through exec. */
-   clientfd = dup(sockfd);
-   if (clientfd == -1) {
-   weston_log("compositor: dup failed: %m\n");
-   return;
-   }
-
-   snprintf(s, sizeof s, "%d", clientfd);
-   setenv("WAYLAND_SOCKET", s, 1);
-
-   if (execl(path, path, NULL) < 0)
-   weston_log("compositor: executing '%s' failed: %m\n",
-   path);
-}
-
-WL_EXPORT struct wl_client *
-weston_client_launch(struct weston_compositor *compositor,
-struct weston_process *proc,
-const char *path,
-weston_process_cleanup_func_t cleanup)
-{
-   int sv[2];
-   pid_t pid;
-   struct wl_client *client;
-
-   weston_log("launching '%s'\n", path);
-
-   if (os_socketpair_cloexec(AF_UNIX, SOCK_STREAM, 0, sv) < 0) {
-   weston_log("weston_client_launch: "
-   "socketpair failed while launching '%s': %m\n",
-   path);
-   return NULL;
-   }
-
-   pid = fork();
-   if (pid == -1) {
-   close(sv[0]);
-   close(sv[1]);
-   weston_log("weston_client_launch: "
-   "fork failed while launching '%s': %m\n", path);
-   return NULL;
-   }
-
-   if (pid == 0) {
-   child_client_exec(sv[1], path);
-   _exit(-1);
-   }
-
-   close(sv[1]);
-
-   client = wl_client_create(compositor->wl_display, sv[0]);
-   if (!client) {
-   close(sv[0]);
-   weston_log("weston_client_launch: "
-   "wl_client_create failed while launching '%s'.\n",
-   path);
-   return NULL;
-   }
-
-   proc->pid = pid;
-   proc->cleanup = cleanup;
-   weston_watch_process(proc);
-
-   return client;
-}
-
-struct process_info {
-   struct weston_process proc;
-   char *path;
-};
-
-static void
-process_handle_sigchld(struct weston_process *process, int status)
-{
-   struct process_info *pinfo =
-   container_of(process, struct process_info, proc);
-
-   /*
-* There are no guarantees whether this runs before or after
-* the wl_client destructor.
-*/
-
-   if (WIFEXITED(status)) {
-   weston_log("%s exited with status %d\n", pinfo->path,
-  WEXITSTATUS(status));
-   } else if (WIFSIGNALED(status)) {
-   weston_log("%s died on signal %d\n", pinfo->path,
-  WTERMSIG(status));
-   } else {
-   weston_log("%s disappeared\n", pinfo->path);
-   }
-
-   free(pinfo->path);
-   free(pinfo);
-}
-
-WL_EXPORT struct wl_client *
-weston_client_start(struct weston_compositor *compositor, const char *path)
-{
-   struct process_info *pinfo;
-   struct wl_client *client;
-
-   pinfo = zalloc(sizeof *pinfo);
-   if (!p

[PATCH weston v2 0/8] Create libweston.so, v2

[Giulio Camuffo]

This new version fixes the issues raised and adds two new patches to plug
a hole i didn't notice before. Now libweston should not use any functionality
that is part of weston-the-compositor.


Giulio Camuffo (8):
  Rename weston_compositor_xkb_init to
weston_compositor_set_xkb_rule_names
  Move part of screenshooter.c to weston-screenshooter.c
  Move the functions launching clients to main.c
  compositor: remove the weston_config field in weston_compositor
  libinput: don't use weston_config when configuring input devices
  allow compositors to define the logging behavior
  Split the modules and include files between weston and libweston
  Create a libweston-0.so

 Makefile.am|  66 +
 configure.ac   |   6 +
 desktop-shell/shell.c  |   3 +-
 ivi-shell/hmi-controller.c |   7 +-
 ivi-shell/ivi-layout.c |   3 +-
 ivi-shell/ivi-shell.c  |   3 +-
 src/cms-static.c   |   3 +-
 src/compositor-drm.c   |   3 +-
 src/compositor-drm.h   |  11 ++
 src/compositor-fbdev.c |   3 +-
 src/compositor-fbdev.h |  11 ++
 src/compositor-rpi.c   |   2 +-
 src/compositor.c   | 146 +--
 src/compositor.h   |  40 ++
 src/input.c|  12 +-
 src/libinput-device.c  |  29 +---
 src/libinput-device.h  |   2 +
 src/libinput-seat.c|   7 +-
 src/libinput-seat.h|   9 +-
 src/libweston.pc.in|  12 ++
 src/log.c  |  74 ++
 src/main.c | 311 -
 src/screenshooter.c| 187 +++--
 src/text-backend.c |   4 +-
 src/weston-screenshooter.c | 191 +
 src/weston.h   |  70 ++
 src/weston.pc.in   |   4 +-
 tests/ivi_layout-test-plugin.c |   1 +
 tests/weston-test.c|   1 +
 xwayland/launcher.c|   5 +-
 xwayland/xwayland.h|   1 +
 31 files changed, 739 insertions(+), 488 deletions(-)
 create mode 100644 src/libweston.pc.in
 create mode 100644 src/weston-screenshooter.c
 create mode 100644 src/weston.h

-- 
2.8.3

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

[PATCH weston v2 1/8] Rename weston_compositor_xkb_init to weston_compositor_set_xkb_rule_names

[Giulio Camuffo]

weston_compositor_xkb_destroy() is called automatically so having only
weston_compositor_xkb_init() to be called by the user was a bit weird.
So rename it so that it makes more sense.
Also export it, since libweston compositors need to call it.
---

v2: renamed xkb_init to set_xkb_rule_names

 src/compositor.h |  4 ++--
 src/input.c  | 12 ++--
 src/main.c   |  2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/compositor.h b/src/compositor.h
index 0bbf458..c19f991 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -1537,8 +1537,8 @@ weston_seat_update_keymap(struct weston_seat *seat, 
struct xkb_keymap *keymap);
 void
 weston_seat_release(struct weston_seat *seat);
 int
-weston_compositor_xkb_init(struct weston_compositor *ec,
-  struct xkb_rule_names *names);
+weston_compositor_set_xkb_rule_names(struct weston_compositor *ec,
+struct xkb_rule_names *names);
 void
 weston_compositor_xkb_destroy(struct weston_compositor *ec);
 
diff --git a/src/input.c b/src/input.c
index 8fe898c..08378d1 100644
--- a/src/input.c
+++ b/src/input.c
@@ -2277,9 +2277,9 @@ bind_seat(struct wl_client *client, void *data, uint32_t 
version, uint32_t id)
 }
 
 #ifdef ENABLE_XKBCOMMON
-int
-weston_compositor_xkb_init(struct weston_compositor *ec,
-  struct xkb_rule_names *names)
+WL_EXPORT int
+weston_compositor_set_xkb_rule_names(struct weston_compositor *ec,
+struct xkb_rule_names *names)
 {
ec->use_xkbcommon = 1;
 
@@ -2442,9 +2442,9 @@ weston_compositor_build_global_keymap(struct 
weston_compositor *ec)
return 0;
 }
 #else
-int
-weston_compositor_xkb_init(struct weston_compositor *ec,
-  struct xkb_rule_names *names)
+WL_EXPORT int
+weston_compositor_set_xkb_rule_names(struct weston_compositor *ec,
+struct xkb_rule_names *names)
 {
return 0;
 }
diff --git a/src/main.c b/src/main.c
index 3279ac6..bb1dd94 100644
--- a/src/main.c
+++ b/src/main.c
@@ -524,7 +524,7 @@ weston_compositor_init_config(struct weston_compositor *ec,
weston_config_section_get_string(s, "keymap_options",
 (char **) &xkb_names.options, NULL);
 
-   if (weston_compositor_xkb_init(ec, &xkb_names) < 0)
+   if (weston_compositor_set_xkb_rule_names(ec, &xkb_names) < 0)
return -1;
 
weston_config_section_get_int(s, "repeat-rate",
-- 
2.8.3

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

[PATCH weston v2 8/8] Create a libweston-0.so

[Giulio Camuffo]

This commit also adds a libweston-0.pc file. The -0 is the abi version
introduced in the previous patch.

Signed-off-by: Giulio Camuffo 
---
 Makefile.am | 45 +++--
 configure.ac|  4 
 src/libweston.pc.in | 12 
 src/weston.pc.in|  2 +-
 4 files changed, 44 insertions(+), 19 deletions(-)
 create mode 100644 src/libweston.pc.in

diff --git a/Makefile.am b/Makefile.am
index e90b3ba..7cc52cd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -51,7 +51,6 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/shared  \
-I$(top_builddir)/protocol  \
-DDATADIR='"$(datadir)"'\
-   -DMODULEDIR='"$(moduledir)"'\
-DLIBWESTON_MODULEDIR='"$(libweston_moduledir)"' \
-DLIBEXECDIR='"$(libexecdir)"'  \
-DBINDIR='"$(bindir)"'
@@ -62,18 +61,15 @@ CLEANFILES = weston.ini \
internal-screenshot-00.png  \
$(BUILT_SOURCES)
 
-bin_PROGRAMS += weston
-
-weston_LDFLAGS = -export-dynamic
-weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
-weston_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
-weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
-   $(DLOPEN_LIBS) -lm $(CLOCK_GETTIME_LIBS) \
-   $(LIBINPUT_BACKEND_LIBS) libshared.la
+lib_LTLIBRARIES = libweston.la
+libweston_la_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
+libweston_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
+libweston_la_LIBADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
+$(DLOPEN_LIBS) -lm libshared.la
+libweston_la_LDFLAGS = -release ${LIBWESTON_ABI_VERSION}
 
-weston_SOURCES =   \
+libweston_la_SOURCES = \
src/git-version.h   \
-   src/log.c   \
src/compositor.c\
src/compositor.h\
src/compositor-drm.h\
@@ -87,7 +83,7 @@ weston_SOURCES =  \
src/screenshooter.c \
src/clipboard.c \
src/zoom.c  \
-   src/text-backend.c  \
+   src/log.c   \
src/bindings.c  \
src/animation.c \
src/noop-renderer.c \
@@ -96,11 +92,8 @@ weston_SOURCES = \
src/timeline.c  \
src/timeline.h  \
src/timeline-object.h   \
-   src/main.c  \
src/linux-dmabuf.c  \
src/linux-dmabuf.h  \
-   src/weston.h\
-   src/weston-screenshooter.c  \
shared/helpers.h\
shared/matrix.c \
shared/matrix.h \
@@ -125,7 +118,7 @@ systemd_notify_la_SOURCES = \
src/compositor.h
 endif
 
-nodist_weston_SOURCES =\
+nodist_libweston_la_SOURCES =  \
protocol/weston-screenshooter-protocol.c\
protocol/weston-screenshooter-server-protocol.h \
protocol/text-cursor-position-protocol.c\
@@ -141,7 +134,23 @@ nodist_weston_SOURCES =
\
protocol/linux-dmabuf-unstable-v1-protocol.c\
protocol/linux-dmabuf-unstable-v1-server-protocol.h
 
-BUILT_SOURCES += $(nodist_weston_SOURCES)
+BUILT_SOURCES += $(nodist_libweston_la_SOURCES)
+
+bin_PROGRAMS += weston
+
+weston_LDFLAGS = -export-dynamic
+weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON   \
+-DMODULEDIR='"$(moduledir)"'
+weston_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
+weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
+   $(DLOPEN_LIBS) $(LIBINPUT_BACKEND_LIBS) \
+   -lm libshared.la libweston.la
+
+weston_SOURCES =   \
+   src/main.c  \
+   src/weston.h\
+   src/weston-screenshooter.c  \
+   src/text-backend.c
 
 # Track this dependency explicitly instead of using BUILT_SOURCES.  We
 # add BUILT_SOURCES to CLEANFILES, but we want to keep git-version.h
@@ -211,7 +220,7 @@ endif
 endif # BUILD_WESTON_LAUNCH
 
 pkgconfigdir = $(libdir

[PATCH weston v2 7/8] Split the modules and include files between weston and libweston

[Giulio Camuffo]

The backends are now installed in lib/libweston-0, and the include
files that will be used by libweston in include/libweston-0. The other
modules and weston-specific include files are kept in the old paths.
A new load_weston_module() is added to load plugins in the old path,
which is not part of libweston, but weston only and defined in main.c.
To allow that to be used by out of tree weston plugins, the function
is declared in a new weston.h, installed in include/weston.

The -0 in the paths is the abi version of libweston, and it will be
used by the libweston .so too. When the abi change the number will
be increased.

Signed-off-by: Giulio Camuffo 
---


v2: - don't remove MODULEDIR
- keep systemd-notify with the main.c side
- rename the new load function to load_weston_plugin

 Makefile.am| 24 +++-
 configure.ac   |  2 ++
 ivi-shell/ivi-layout.c |  3 ++-
 src/compositor.c   |  2 +-
 src/main.c | 47 ++-
 src/weston.h   |  3 +++
 src/weston.pc.in   |  2 +-
 7 files changed, 70 insertions(+), 13 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 2f81ec0..e90b3ba 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,8 @@ noinst_PROGRAMS =
 libexec_PROGRAMS =
 moduledir = $(libdir)/weston
 module_LTLIBRARIES =
+libweston_moduledir = $(libdir)/libweston-${LIBWESTON_ABI_VERSION}
+libweston_module_LTLIBRARIES =
 noinst_LTLIBRARIES =
 BUILT_SOURCES =
 
@@ -50,6 +52,7 @@ AM_CPPFLAGS = \
-I$(top_builddir)/protocol  \
-DDATADIR='"$(datadir)"'\
-DMODULEDIR='"$(moduledir)"'\
+   -DLIBWESTON_MODULEDIR='"$(libweston_moduledir)"' \
-DLIBEXECDIR='"$(libexecdir)"'  \
-DBINDIR='"$(bindir)"'
 
@@ -213,8 +216,8 @@ pkgconfig_DATA = src/weston.pc
 wayland_sessiondir = $(datadir)/wayland-sessions
 dist_wayland_session_DATA = src/weston.desktop
 
-westonincludedir = $(includedir)/weston
-westoninclude_HEADERS =\
+libwestonincludedir = $(includedir)/libweston-${LIBWESTON_ABI_VERSION}
+libwestoninclude_HEADERS = \
src/version.h   \
src/compositor.h\
src/compositor-drm.h\
@@ -229,13 +232,16 @@ westoninclude_HEADERS =   \
shared/zalloc.h \
shared/platform.h
 
+westonincludedir = $(includedir)/weston
+westoninclude_HEADERS = src/weston.h
+
 if ENABLE_IVI_SHELL
 westoninclude_HEADERS +=   \
ivi-shell/ivi-layout-export.h
 endif
 
 if ENABLE_EGL
-module_LTLIBRARIES += gl-renderer.la
+libweston_module_LTLIBRARIES += gl-renderer.la
 gl_renderer_la_LDFLAGS = -module -avoid-version
 gl_renderer_la_LIBADD = $(COMPOSITOR_LIBS) $(EGL_LIBS)
 gl_renderer_la_CFLAGS =\
@@ -252,7 +258,7 @@ gl_renderer_la_SOURCES =\
 endif
 
 if ENABLE_X11_COMPOSITOR
-module_LTLIBRARIES += x11-backend.la
+libweston_module_LTLIBRARIES += x11-backend.la
 x11_backend_la_LDFLAGS = -module -avoid-version
 x11_backend_la_LIBADD = $(COMPOSITOR_LIBS) $(X11_COMPOSITOR_LIBS) \
libshared-cairo.la
@@ -278,7 +284,7 @@ INPUT_BACKEND_SOURCES = \
shared/helpers.h
 
 if ENABLE_DRM_COMPOSITOR
-module_LTLIBRARIES += drm-backend.la
+libweston_module_LTLIBRARIES += drm-backend.la
 drm_backend_la_LDFLAGS = -module -avoid-version
 drm_backend_la_LIBADD =\
$(COMPOSITOR_LIBS)  \
@@ -309,7 +315,7 @@ endif
 endif
 
 if ENABLE_WAYLAND_COMPOSITOR
-module_LTLIBRARIES += wayland-backend.la
+libweston_module_LTLIBRARIES += wayland-backend.la
 wayland_backend_la_LDFLAGS = -module -avoid-version
 wayland_backend_la_LIBADD =\
$(COMPOSITOR_LIBS)  \
@@ -366,7 +372,7 @@ endif
 endif
 
 if ENABLE_HEADLESS_COMPOSITOR
-module_LTLIBRARIES += headless-backend.la
+libweston_module_LTLIBRARIES += headless-backend.la
 headless_backend_la_LDFLAGS = -module -avoid-version
 headless_backend_la_LIBADD = $(COMPOSITOR_LIBS) libshared.la
 headless_backend_la_CFLAGS = $(COMPOSITOR_CFLAGS) $(AM_CFLAGS)
@@ -377,7 +383,7 @@ headless_backend_la_SOURCES =   \
 endif
 
 if ENABLE_FBDEV_COMPOSITOR
-module_LTLIBRARIES += fbdev-backend.la
+libweston_module_LTLIBRARIES += fbdev-backend.la
 fbdev_backend_la_LDFLAGS = -module -avoid-version
 fbdev_backend_la_LIBADD =  \
$(COMPOSITOR_LIBS)  \
@@ -399,7 +405,7 @@ fbdev_backend_la_SOURCES =  \
 endif
 
 if ENABLE_RDP_COMPOSITOR
-module_LTLIBRARIES += rdp-backend.la
+libweston_module_LTLIBRARIES += rdp-backend.la
 rdp_backend_la_LDFLAGS = -module -avoid-version
 rdp_backend_la_LIBADD = $(COMPOSITOR_LI

[PATCH weston v2 5/8] libinput: don't use weston_config when configuring input devices

[Giulio Camuffo]

Instead add callbacks to the drm and fbdev backends and pass that to
the input backens so that when a new device needs to be configured
that is called and the compositor can configure it.

Signed-off-by: Giulio Camuffo 
---
 Makefile.am|  3 ++-
 src/compositor-drm.c   |  3 ++-
 src/compositor-drm.h   | 11 +++
 src/compositor-fbdev.c |  3 ++-
 src/compositor-fbdev.h | 11 +++
 src/compositor-rpi.c   |  2 +-
 src/libinput-device.c  | 31 +--
 src/libinput-device.h  |  2 ++
 src/libinput-seat.c|  7 ++-
 src/libinput-seat.h|  9 -
 src/main.c | 27 +++
 11 files changed, 73 insertions(+), 36 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index b32084f..2f81ec0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -65,7 +65,8 @@ weston_LDFLAGS = -export-dynamic
 weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
 weston_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
 weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
-   $(DLOPEN_LIBS) -lm $(CLOCK_GETTIME_LIBS) libshared.la
+   $(DLOPEN_LIBS) -lm $(CLOCK_GETTIME_LIBS) \
+   $(LIBINPUT_BACKEND_LIBS) libshared.la
 
 weston_SOURCES =   \
src/git-version.h   \
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 893877d..39d061b 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -3121,7 +3121,8 @@ drm_backend_create(struct weston_compositor *compositor,
create_sprites(b);
 
if (udev_input_init(&b->input,
-   compositor, b->udev, seat_id) < 0) {
+   compositor, b->udev, seat_id,
+   config->configure_device) < 0) {
weston_log("failed to create input devices\n");
goto err_sprite;
}
diff --git a/src/compositor-drm.h b/src/compositor-drm.h
index 3f150db..1266031 100644
--- a/src/compositor-drm.h
+++ b/src/compositor-drm.h
@@ -36,6 +36,8 @@ extern "C" {
 
 #define WESTON_DRM_BACKEND_CONFIG_VERSION 1
 
+struct libinput_device;
+
 enum weston_drm_backend_output_mode {
/** The output is disabled */
WESTON_DRM_BACKEND_OUTPUT_OFF,
@@ -117,6 +119,15 @@ struct weston_drm_backend_config {
bool use_current_mode,
const char *name,
struct weston_drm_backend_output_config 
*output_config);
+
+   /** Callback used to configure input devices.
+*
+* This function will be called by the backend when a new input device
+* needs to be configured.
+* If NULL the device will use the default configuration.
+*/
+   void (*configure_device)(struct weston_compositor *compositor,
+struct libinput_device *device);
bool use_current_mode;
 };
 
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index ee762e3..f66fe47 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -797,7 +797,8 @@ fbdev_backend_create(struct weston_compositor *compositor, 
int *argc, char *argv
if (fbdev_output_create(backend, param->device) < 0)
goto out_launcher;
 
-   udev_input_init(&backend->input, compositor, backend->udev, seat_id);
+   udev_input_init(&backend->input, compositor, backend->udev,
+   seat_id, param->configure_device);
 
compositor->backend = &backend->base;
return backend;
diff --git a/src/compositor-fbdev.h b/src/compositor-fbdev.h
index bd60bdc..450be5d 100644
--- a/src/compositor-fbdev.h
+++ b/src/compositor-fbdev.h
@@ -34,6 +34,8 @@ extern "C" {
 
 #define WESTON_FBDEV_BACKEND_CONFIG_VERSION 1
 
+struct libinput_device;
+
 struct weston_fbdev_backend_config {
struct weston_backend_config base;
 
@@ -42,6 +44,15 @@ struct weston_fbdev_backend_config {
int use_gl;
 
uint32_t output_transform;
+
+   /** Callback used to configure input devices.
+*
+* This function will be called by the backend when a new input device
+* needs to be configured.
+* If NULL the device will use the default configuration.
+*/
+   void (*configure_device)(struct weston_compositor *compositor,
+struct libinput_device *device);
 };
 
 #ifdef  __cplusplus
diff --git a/src/compositor-rpi.c b/src/compositor-rpi.c
index 75b808e..07e5d6a 100644
--- a/src/compositor-rpi.c
+++ b/src/compositor-rpi.c
@@ -514,7 +514,7 @@ rpi_backend_create(struct weston_compositor *compositor,
 
if (udev_input_init(&backend->input,
compositor,
-   backend->udev, "seat0") != 0) {
+   backend->udev, "seat0", NULL) != 0) {
weston_log("Failed to initialize udev input.\n");
goto out_launcher;
   

[PATCH weston v2 2/8] Move part of screenshooter.c to weston-screenshooter.c

[Giulio Camuffo]

This patch splits screensooter.c so that the code implementing
the private screenshooter protocol and launching the client is
moved to a weston specific file, leaving only the code that can
be shared between compositors in screenshooter.c.
Two exported functions are added in screenshooter.c to start and
stop the recorder.

Signed-off-by: Giulio Camuffo 
---

v2

 Makefile.am|   2 +
 desktop-shell/shell.c  |   1 +
 src/compositor.h   |   8 +-
 src/screenshooter.c| 187 +---
 src/weston-screenshooter.c | 191 +
 src/weston.h   |  42 ++
 6 files changed, 261 insertions(+), 170 deletions(-)
 create mode 100644 src/weston-screenshooter.c
 create mode 100644 src/weston.h

diff --git a/Makefile.am b/Makefile.am
index 00b74e5..b32084f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -95,6 +95,8 @@ weston_SOURCES =  \
src/main.c  \
src/linux-dmabuf.c  \
src/linux-dmabuf.h  \
+   src/weston.h\
+   src/weston-screenshooter.c  \
shared/helpers.h\
shared/matrix.c \
shared/matrix.h \
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 7d5bca9..ec71cd1 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -36,6 +36,7 @@
 #include 
 
 #include "shell.h"
+#include "weston.h"
 #include "weston-desktop-shell-server-protocol.h"
 #include "shared/config-parser.h"
 #include "shared/helpers.h"
diff --git a/src/compositor.h b/src/compositor.h
index c19f991..1eaa6bf 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -58,6 +58,7 @@ struct weston_output;
 struct input_method;
 struct weston_pointer;
 struct linux_dmabuf_buffer;
+struct weston_recorder;
 
 enum weston_keyboard_modifier {
MODIFIER_CTRL = (1 << 0),
@@ -1577,9 +1578,6 @@ tty_reset(struct tty *tty);
 int
 tty_activate_vt(struct tty *tty, int vt);
 
-void
-screenshooter_create(struct weston_compositor *ec);
-
 enum weston_screenshooter_outcome {
WESTON_SCREENSHOOTER_SUCCESS,
WESTON_SCREENSHOOTER_NO_MEMORY,
@@ -1591,6 +1589,10 @@ typedef void (*weston_screenshooter_done_func_t)(void 
*data,
 int
 weston_screenshooter_shoot(struct weston_output *output, struct weston_buffer 
*buffer,
   weston_screenshooter_done_func_t done, void *data);
+struct weston_recorder *
+weston_recorder_start(struct weston_output *output, const char *filename);
+void
+weston_recorder_stop(struct weston_recorder *recorder);
 
 struct clipboard *
 clipboard_create(struct weston_seat *seat);
diff --git a/src/screenshooter.c b/src/screenshooter.c
index e8b9090..fc14ad3 100644
--- a/src/screenshooter.c
+++ b/src/screenshooter.c
@@ -34,19 +34,10 @@
 #include 
 
 #include "compositor.h"
-#include "weston-screenshooter-server-protocol.h"
 #include "shared/helpers.h"
 
 #include "wcap/wcap-decode.h"
 
-struct screenshooter {
-   struct weston_compositor *ec;
-   struct wl_global *global;
-   struct wl_client *client;
-   struct weston_process process;
-   struct wl_listener destroy_listener;
-};
-
 struct screenshooter_frame_listener {
struct wl_listener listener;
struct weston_buffer *buffer;
@@ -216,98 +207,6 @@ weston_screenshooter_shoot(struct weston_output *output,
return 0;
 }
 
-static void
-screenshooter_done(void *data, enum weston_screenshooter_outcome outcome)
-{
-   struct wl_resource *resource = data;
-
-   switch (outcome) {
-   case WESTON_SCREENSHOOTER_SUCCESS:
-   weston_screenshooter_send_done(resource);
-   break;
-   case WESTON_SCREENSHOOTER_NO_MEMORY:
-   wl_resource_post_no_memory(resource);
-   break;
-   default:
-   break;
-   }
-}
-
-static void
-screenshooter_shoot(struct wl_client *client,
-   struct wl_resource *resource,
-   struct wl_resource *output_resource,
-   struct wl_resource *buffer_resource)
-{
-   struct weston_output *output =
-   wl_resource_get_user_data(output_resource);
-   struct weston_buffer *buffer =
-   weston_buffer_from_resource(buffer_resource);
-
-   if (buffer == NULL) {
-   wl_resource_post_no_memory(resource);
-   return;
-   }
-
-   weston_screenshooter_shoot(output, buffer, screenshooter_done, 
resource);
-}
-
-struct weston_screenshooter_interface screenshooter_implementation = {
-   screenshooter_shoot
-};
-
-static void
-bind_shooter(struct wl_client *client,
-void *data, uint32_t version, uint32_t id)
-{
-   struct screenshooter *shooter = data;

Re: array and enum attributes (Was: [PATCH] xdg-shell: add draw states for xdg_surface)

[Yong Bakos]

On May 30, 2016, at 3:54 AM, Pekka Paalanen  wrote:
> 
> On Sat, 28 May 2016 08:39:59 -0500
> Yong Bakos  wrote:
> 
>> Hi Mike,
>> Regarding the combination of type="array" enum="foo"...
>> 
>>> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
>>>  wrote:
>>> 
>>> I've inlined some replies below.
>>> 
>>> On Fri, May 27, 2016 at 1:13 PM Yong Bakos >> > wrote:
>>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz >> > wrote:
 
 this adds a method for compositors to change various draw attributes
 for a surface
 
 Signed-off-by: Mike Blumenkrantz >>> >
 Signed-off-by: Jonas Ådahl mailto:jad...@gmail.com>>
>>> 
>>> Hi Mike & Jonas,
>>> A question about communicating default state, and some
>>> minor nits you can certainly ignore, inline below.
>>> 
>>> 
 ---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 69 
 
 1 file changed, 69 insertions(+)
 
 diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
 b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
 index dfd7e84..0fa76d4 100644
 --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
 +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> 
 +
 +Calling this after an xdg_toplevel's first commit will raise a 
 client error.
 +  
 +  
>>> 
>>> Just a sanity check, since I haven't seen it in a protocol spec yet. Does 
>>> scanner handle
>>> this combination of array and enum correctly?
>>> 
>>> Good catch. This also affects the event above it.
>> 
>> As we discussed via IRC (27 May), the scanner will choke on this. While we 
>> talked about
>> making a change to the scanner to allow this, perhaps such a change doesn't 
>> make sense.
>> 
>> Given a type="array", scanner will generate a parameter of type wl_array.
>> 
>> Perhaps the short story here is to just remove the enum from this arg, and 
>> the similar
>> arg in the configure_draw_states event above. What do you think?
>> 
>> (I wonder if it's the DTD that can change, so the scanner's validation step
>> will catch the unsupported combination of type="array" enum="foo". My gut 
>> tells me that
>> DTDs don't support this logic, but I'll dig into this.)
> 
> Hi,
> 
> here is some background.
> 
> A type="array" argument is really just a binary blob of data. The XML
> description, human documentation aside, does not specify anything about
> the blob contents. Therefore adding an XML attribute pointing to an
> enum definition is half-useless. Generators could use it for creating
> automatic links in documentation, but it cannot be used for code
> generation, because you don't know the types contained in the blob.
> 
> We also do not want to add blob content type definitions to the XML
> language, because you might want to have everything C is able to
> express, including nested structs. There is also no requirement that
> the "array" is really an array - every "element" could be a different
> thing. It could be bitstream and whatnot. Only the use of
> wl_array_for_each() implies it is an array of similar elements,
> wl_array_add() does not.
> 
> The big point in adding enum annotations was that language bindings
> generators (other than wayland-scanner) could use the annotation for
> code generation. I don't think it is possible with the array type.
> 
> If we allow enum annotation with the array type, it will only be usable
> for doc links, unlike the other enum annotations.
> 
> OTOH, we have lots and lots of places in the documentation texts that
> refer to some request, event, interface, etc. that would be useful as a
> hyperlink in the generated docs. Enums could fall into that as well, so
> we would not need the attribute for only documentation.
> 
> Auke, Nils, what's your take on this matter?
> 
> We do have some documentation about enums in
> https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Basic-Principles
> 
> Thanks,
> pq

Pekka,
Thank you for the info. Just so I understand your points correctly, let
me assert that /just/ making a minor change to scanner to not error on
the presence of both array and enum together does not have any major
drawbacks.

Correct?

Thank you,
yong



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[RFC wayland 1/1] protocol: Add summary attributes to request params and enum entries

[Yong Bakos]

From: Yong Bakos 

Signed-off-by: Yong Bakos 
---
 protocol/wayland.xml | 334 ++-
 1 file changed, 172 insertions(+), 162 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 700ef03..d0db6cc 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -48,7 +48,8 @@

The callback_data passed in the callback is the event serial.
   
-  
+  
 

 
@@ -57,7 +58,8 @@
to list and bind the global objects available from the
compositor.
   
-  
+  
 

 
@@ -129,8 +131,8 @@
Binds a new, client-created object to the server using the
 specified name as the identifier.
   
-  
-  
+  
+  
 

 
@@ -187,14 +189,14 @@
   
Ask the compositor to create a new surface.
   
-  
+  
 

 
   
Ask the compositor to create a new region.
   
-  
+  
 
   

@@ -224,12 +226,12 @@
a buffer from it.
   

-  
-  
-  
-  
-  
-  
+  
+  
+  
+  
+  
+  
 

 
@@ -250,7 +252,7 @@
used to make the pool bigger.
   

-  
+  
 
   

@@ -289,62 +291,62 @@
   
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
 

 
@@ -356,9 +358,9 @@
 descriptor, to use as backing memory for the pool.
   

-  
-  
-  
+  
+  
+  
 

 
@@ -446,8 +448,8 @@
conjunction with wl_data_source.action for feedback.
   

-  
-  
+  
+  
 

 
@@ -468,8 +470,8 @@
clients may preemptively fetch data or examine it more closely to
determine acceptance.
   
-  
-  
+  
+  
 

 
@@ -539,8 +541,8 @@
This request can only be made on drag-and-drop offers, a protocol error
will be raised otherwise.
   
-  
-  
+  
+  
 

 
@@ -615,7 +617,7 @@
advertised to targets.  Can be called several times to offer
multiple types.
   
-  
+  
 

 
@@ -689,7 +691,7 @@
wl_data_device.start_drag. Attempting to use the source other than
for drag-and-drop will raise a protocol error.
   
-  
+  
 

 
@@ -792,10 +794,10 @@
as an icon ends, the current and pending input regions become
undefined, and the wl_surface is unmapped.
   
-  
-  
-  
-  
+  
+  
+  
+  
 

 
@@ -805,8 +807,8 @@

To unset the selection, set the source to NULL.
   
-  
-  
+  
+  
 

 
@@ -922,15 +924,15 @@
   
 Create a new data source.
   
-  
+  
 

 
   
 Create a new data device for a given seat.
   
-  
-  
+  
+  
 

 
@@ -961,10 +963,10 @@
or drags initiated with other buttons than BTN_LEFT to specific
actions (e.g. "ask").
   
-  
-  
-  
-  
+  
+  
+  
+  
 
   

@@ -989,8 +991,8 @@

Only one shell surface can be associated with a given surface.
   
-  
-  
+  
+  
 
   

@@ -1036,15 +1038,15 @@
use this information to adapt its behavior, e.g. choose
an appropriate cursor image.
   
-  
-  
-  
-  
-  
-  
-  
-  
-  
+  
+  
+  
+  
+  
+  
+  
+  
+  
 

 
@@ -1087,10 +1089,10 @@
The flags argument controls details of the transient behaviour.
   

-  
-  
-  
-  
+  
+  
+  
+  
 

 
@@ -1141,9 +1143,10 @@
with the dimensions for the output on which the surface will
be made fullscreen.
   
-  
-  
-  
+  
+  
+  
 

 
@@ -1171,10 +1174,10 @@

   
   
-  
-  
-  
-  
+  
+  
+  
+  
 

 
@@ -1198,7 +1201,8 @@

The details depend on the compositor implementation.
   
-  
+  
 

 
@@ -12

Re: [PATCH RFC] xdg-shell: Add tiled states

[Mike Blumenkrantz]

On Wed, Jun 1, 2016 at 10:42 AM Olivier Fourdan  wrote:

> Hi Mike,
>
> - Original Message -
> > I've read the ticket linked in the other mail, but your use of "tiled"
> here
> > is confusing to me since you (and the ticket) appear to be conflating two
> > separate-but-unrelated meanings.  "Tiled" is a type of window layout
> policy
> > which organizes windows into a tiled grid formation; this is in
> opposition
> > to "stacking".
>
> Sure, I appreciate that.
>
> > The ticket you linked seems to be primarily about positioning windows to
> > take up 50% of screen geometry, (e.g., left half of screen, top half of
> > screen, ...). This seems a lot more like a maximize state to me since
> it's
> > based on screen geometry. In X11 there's NETWM hints for
> > vertical/horizontal maximize: EFL uses these to handle partial
> > maximizations, and in Wayland we simply use the normal MAXIMIZE window
> > state since directionality is irrelevant.
>
> This is the current use of "tiling" in gnome-shell and gtk+, but we should
> not limit tiling to a single (very limited) implementation.
>

I'll ask you to clarify which "tiling" you're referring to in this case; I
don't believe that gtk's toolkit implementation of a single state for two
separate functionalities should dictate the protocol in this case.


>
> > I think MAXIMIZE fully covers
> > this case and there is no need for any further protocol to inform the
> > client.
>
> I reckon using partial maximization from EWMH to achieve basic tiling in
> gnome-shell/gtk+ was a hack, it leads to all sort of workarounds in gtk+:
>
> https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n244
>
> And it doesn't even take into account horizontal tiling,
> https://bugzilla.gnome.org/show_bug.cgi?id=742525
>
> I'd rather not mix up maximization and tiling again, given the chance...
>

You're conflating different issues again, I think. On client-side, maximize
is typically only initiated using a window decoration button. Other forms
of maximize (e.g., partial maximizes) are compositor maximizes, and I think
this is a significant difference to note.
I imagine that you aren't advocating adding enough buttons to your
application/toolkit UI to enact all the maximize/tile states that you've
proposed, so this is purely a question of compositor policy vs client-side
internals. What you've cited in your case looks to just be an
implementation bug in your toolkit; Enlightenment/EFL have handled both
tiling layout policies and partial maximize states since before the E17
release, so that's sufficient proof for me that it's doable.


>
> > In the case of the real "tiled" state, (i.e., a tiling layout policy), I
> > think this is something which should be a single draw state. There's no
> > need to inform a client about its surface's relative position (e.g., any
> of
> > your proposed directional tiled values) since the result is the same in
> > every case--the client must obey configured geometry.
>
> The client may chose to draw the border on the surface edged tiled
> differently, to achieve seamless borders between tiled windows for example,
> while keeping the other edges (not tiled) unchanged, that was the idea
> behind the use of the edge values.
>

I obviously don't have as much experience writing applications for your
desktop/toolkit UX standards, but it seems like having one side of a window
square and another side round is not going to look very good. Certainly
it's not something I plan on implementing in EFL at any point.


>
> > The difference from the MAXIMIZE state here is mostly conceptual:
> MAXIMIZE
> > indicates to a client that a surface is taking up the entire screen's
> > geometry on at least one axis and thus it may choose to draw UI elements
> > differently (e.g., showing/hiding extra toolbars along the larger axis).
> A
> > TILED state simply informs the client that it must obey sizing policies
> and
> > draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's
> > implicitly "tiled" by being maximized), but a tiled surface can toggle
> > MAXIMIZE.
>
> I see where you're coming from, if we consider a single "tiled" state then
> it's similar in essence to the maximized state with a different geometry,
> so we could get away with a "tiled" draw state instead that clients would
> use to distinguish from the real "maximize" state when drawing their
> decorations (including the "maximize" button in the title bar which can
> differ when maximized or not).
>
> Granted, I am not a tiling window manager aficionado myself, so it would
> be great if those who design tiling window managers could chime in as well
> and express their needs wrt. tiling.
>
> Cheers,
> Olivier
>
>
Enlightenment has a functioning tiling layout policy, so I've been chiming
in from that perspective as well.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-de

[RFC wayland 0/1] protocol: Add summary attributes to request params and enum entries

[Yong Bakos]

From: Yong Bakos 

This patch adds missing summary attributes to all request arg elements and
enum entry elements. I've marked this as RFC as I would like some feedback
before formalizing the patch. Specifically:

wl_shm.format enum: Are these summaries fine? Do we want them at all? Doing so
  gives us "completeness" but it feels a little cumbersome here.

wl_output.transform enum: Did I get clockwise/conter-clockwise right?

wl_region.add, wl_region.subtract: Are the x and y args are the upper-left
  corner of the region in surface-local coordinates, or in "region-local"
  coordinates?

If we can focus on the three above issues, I'll formalize a v1 patch to elicit
general feedback.

Thank you for your time,
yong


Yong Bakos (1):
  protocol: Add summary attributes to request params and enum entries

 protocol/wayland.xml | 334 ++-
 1 file changed, 172 insertions(+), 162 deletions(-)

--
2.7.2

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

Re: [PATCH weston] Remove support for the proprietary Raspberry Pi drivers

[Derek Foreman]

On 01/06/16 05:11 AM, Pekka Paalanen wrote:
> From: Pekka Paalanen 
> 
> Hi,
> 
> please see the commit message on the patch for the story.
> 
> The patch has been generated with -D to avoid listing the contents of the
> deleted files. You can find the proper, complete patch at:
> https://git.collabora.com/cgit/user/pq/weston.git/log/?h=rpi-removal
> 

So sorry to see it go. ;)

Reviewed-by: Derek Foreman 

for both.

> Thanks,
> pq
> 
> Pekka Paalanen (1):
>   Remove Raspberry Pi backend and renderer
> 
>  Makefile.am  |   34 -
>  README   |2 -
>  configure.ac |   18 -
>  man/weston.ini.man   |1 -
>  src/compositor-rpi.c |  575 
>  src/main.c   |   19 -
>  src/rpi-bcm-stubs.h  |  327 -
>  src/rpi-renderer.c   | 1830 
> --
>  src/rpi-renderer.h   |   52 --
>  9 files changed, 2858 deletions(-)
>  delete mode 100644 src/compositor-rpi.c
>  delete mode 100644 src/rpi-bcm-stubs.h
>  delete mode 100644 src/rpi-renderer.c
>  delete mode 100644 src/rpi-renderer.h
> 
> Pekka Paalanen (1):
>   Remove the special Raspberry Pi guide
> 
>  building.html|   4 +-
>  raspberrypi.html | 225 
> ---
>  2 files changed, 3 insertions(+), 226 deletions(-)
>  delete mode 100644 raspberrypi.html
> 

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

Re: [PATCH RFC] xdg-shell: Add tiled states

[Olivier Fourdan]

Hi Mike,

- Original Message -
> I've read the ticket linked in the other mail, but your use of "tiled" here
> is confusing to me since you (and the ticket) appear to be conflating two
> separate-but-unrelated meanings.  "Tiled" is a type of window layout policy
> which organizes windows into a tiled grid formation; this is in opposition
> to "stacking".

Sure, I appreciate that.
 
> The ticket you linked seems to be primarily about positioning windows to
> take up 50% of screen geometry, (e.g., left half of screen, top half of
> screen, ...). This seems a lot more like a maximize state to me since it's
> based on screen geometry. In X11 there's NETWM hints for
> vertical/horizontal maximize: EFL uses these to handle partial
> maximizations, and in Wayland we simply use the normal MAXIMIZE window
> state since directionality is irrelevant.

This is the current use of "tiling" in gnome-shell and gtk+, but we should not 
limit tiling to a single (very limited) implementation.

> I think MAXIMIZE fully covers
> this case and there is no need for any further protocol to inform the
> client.

I reckon using partial maximization from EWMH to achieve basic tiling in 
gnome-shell/gtk+ was a hack, it leads to all sort of workarounds in gtk+:

https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n244

And it doesn't even take into account horizontal tiling, 
https://bugzilla.gnome.org/show_bug.cgi?id=742525

I'd rather not mix up maximization and tiling again, given the chance...

> In the case of the real "tiled" state, (i.e., a tiling layout policy), I
> think this is something which should be a single draw state. There's no
> need to inform a client about its surface's relative position (e.g., any of
> your proposed directional tiled values) since the result is the same in
> every case--the client must obey configured geometry.

The client may chose to draw the border on the surface edged tiled differently, 
to achieve seamless borders between tiled windows for example, while keeping 
the other edges (not tiled) unchanged, that was the idea behind the use of the 
edge values.
 
> The difference from the MAXIMIZE state here is mostly conceptual: MAXIMIZE
> indicates to a client that a surface is taking up the entire screen's
> geometry on at least one axis and thus it may choose to draw UI elements
> differently (e.g., showing/hiding extra toolbars along the larger axis). A
> TILED state simply informs the client that it must obey sizing policies and
> draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's
> implicitly "tiled" by being maximized), but a tiled surface can toggle
> MAXIMIZE.

I see where you're coming from, if we consider a single "tiled" state then it's 
similar in essence to the maximized state with a different geometry, so we 
could get away with a "tiled" draw state instead that clients would use to 
distinguish from the real "maximize" state when drawing their decorations 
(including the "maximize" button in the title bar which can differ when 
maximized or not).

Granted, I am not a tiling window manager aficionado myself, so it would be 
great if those who design tiling window managers could chime in as well and 
express their needs wrt. tiling.

Cheers,
Olivier

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

Re: [PATCH RFC] xdg-shell: Add tiled states

[Mike Blumenkrantz]

Hi,

On Wed, Jun 1, 2016 at 5:19 AM Olivier Fourdan  wrote:

> When tiled, clients must obey the window geometry specified in the
> configure event and can choose to hide some of their decorations.
>
> Signed-off-by: Olivier Fourdan 
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 27
> +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index ce57153..550a0e5 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -343,6 +343,33 @@
>   active. Do not assume this means that the window actually has
>   keyboard or pointer focus.
> 
> +  
> +   
> + The top side of the surface is tiled, either to another surface
> + or a monitor edge. The window geometry specified in the configure
> + event must be obeyed by the client.
> +   
> +  
> +  
> +   
> + The bottom side of the surface is tiled, either to another
> surface
> + or a monitor edge. The window geometry specified in the configure
> + event must be obeyed by the client.
> +   
> +  
> +  
> +   
> + The left side of the surface is tiled, either to another surface
> + or a monitor edge. The window geometry specified in the configure
> + event must be obeyed by the client.
> +   
> +  
> +  
> +   
> + TThe right side of the surface is tiled, either to another
> surface
> + or a monitor edge. The window geometry specified in the configure
> + event must be obeyed by the client.
> +   
>
>  
>
> --
> 2.7.4
>
>
>
I've read the ticket linked in the other mail, but your use of "tiled" here
is confusing to me since you (and the ticket) appear to be conflating two
separate-but-unrelated meanings.  "Tiled" is a type of window layout policy
which organizes windows into a tiled grid formation; this is in opposition
to "stacking".

The ticket you linked seems to be primarily about positioning windows to
take up 50% of screen geometry, (e.g., left half of screen, top half of
screen, ...). This seems a lot more like a maximize state to me since it's
based on screen geometry. In X11 there's NETWM hints for
vertical/horizontal maximize: EFL uses these to handle partial
maximizations, and in Wayland we simply use the normal MAXIMIZE window
state since directionality is irrelevant. I think MAXIMIZE fully covers
this case and there is no need for any further protocol to inform the
client.

In the case of the real "tiled" state, (i.e., a tiling layout policy), I
think this is something which should be a single draw state. There's no
need to inform a client about its surface's relative position (e.g., any of
your proposed directional tiled values) since the result is the same in
every case--the client must obey configured geometry.

The difference from the MAXIMIZE state here is mostly conceptual: MAXIMIZE
indicates to a client that a surface is taking up the entire screen's
geometry on at least one axis and thus it may choose to draw UI elements
differently (e.g., showing/hiding extra toolbars along the larger axis). A
TILED state simply informs the client that it must obey sizing policies and
draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's
implicitly "tiled" by being maximized), but a tiled surface can toggle
MAXIMIZE.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] touchpad: warn if we have invalid touchpad ranges

[Yong Bakos]

On May 31, 2016, at 7:42 PM, Peter Hutterer  wrote:
> 
> Quite a few bugs are caused by touchpad ranges being out of whack. If we get
> input events significantly outside the expected range (5% width/height as
> error margin) print a warning to the log.
> 
> And add a new doc page to explain what is happening and how to fix it.
> 
> Signed-off-by: Peter Hutterer 

Hi Peter,
FWIW, one minor nit (whildcard) I noticed, inline below.


> ---
> doc/Makefile.am|   1 +
> doc/absolute-coordinate-ranges.dox | 120 +
> doc/page-hierarchy.dox |   1 +
> src/evdev-mt-touchpad.c|  59 ++
> src/evdev-mt-touchpad.h|   5 ++
> 5 files changed, 186 insertions(+)
> create mode 100644 doc/absolute-coordinate-ranges.dox
> 
> diff --git a/doc/Makefile.am b/doc/Makefile.am
> index f2a47cb..1e501a8 100644
> --- a/doc/Makefile.am
> +++ b/doc/Makefile.am
> @@ -11,6 +11,7 @@ header_files = \
>   $(top_srcdir)/src/libinput.h \
>   $(top_srcdir)/README.txt \
>   $(srcdir)/absolute-axes.dox \
> + $(srcdir)/absolute-coordinate-ranges.dox \
>   $(srcdir)/clickpad-softbuttons.dox \
>   $(srcdir)/device-configuration-via-udev.dox \
>   $(srcdir)/faqs.dox \
> diff --git a/doc/absolute-coordinate-ranges.dox 
> b/doc/absolute-coordinate-ranges.dox
> new file mode 100644
> index 000..f9d9e98
> --- /dev/null
> +++ b/doc/absolute-coordinate-ranges.dox
> @@ -0,0 +1,120 @@
> +/**
> +@page absolute_coordinate_ranges Coordinate ranges for absolute axes
> +
> +libinput requires that all touchpads provide a correct axis range and
> +resolution. These are used to enable or disable certain features or adapt
> +the interaction with the touchpad. For example, the software button area is
> +narrower on small touchpads to avoid reducing the interactive surface too
> +much. Likewise, palm detection works differently on small touchpads as palm
> +interference is less likely to happen.
> +
> +Touchpads with incorrect axis ranges generate error messages
> +in the form:
> +
> +Axis 0x35 value 4000 is outside expected range [0, 3000]
> +
> +
> +This error message indicates that the ABS_MT_POSITION_X axis (i.e. the x
> +axis) generated an event outside the expected range of 0-3000. In this case
> +the value was 4000.
> +This discrepancy between the coordinate range the kernels advertises vs.
> +what the touchpad sends can be the source of a number of perceived
> +bugs in libinput.
> +
> +@section absolute_coordinate_ranges_fix Measuring and fixing touchpad ranges
> +
> +To fix the touchpad you need to:
> +-# measure the physical size of your touchpad in mm
> +-# run touchpad-edge-detector
> +-# trim the udev match rule to something sensible
> +-# replace the resolution with the calculated resolution based on physical
> +  settings
> +-# test locally
> +-# send a patch to the systemd project
> +
> +Detailed explanations are below.
> +
> +[libevdev](http://freedesktop.org/wiki/Software/libevdev/) provides a tool
> +called **touchpad-edge-detector** that allows measuring the touchpad's input
> +ranges. Run the tool as root against the device node of your touchpad device
> +and repeatedly move a finger around the whole outside area of the
> +touchpad. Then control+c the process and note the output.
> +An example output is below:
> +
> +@code
> +$> sudo touchpad-edge-detector /dev/input/event4
> +Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event4
> +Move one finger around the touchpad to detect the actual edges
> +Kernel says: x [1024..3112], y [2024..4832]
> +Touchpad sends:  x [2445..4252], y [3464..4071]
> +
> +Touchpad size as listed by the kernel: 49x66mm
> +Calculate resolution as:
> + x axis: 2088/
> + y axis: 2808/
> +
> +Suggested udev rule:
> +# 
> +evdev:name:SynPS/2 Synaptics 
> TouchPad:dmi:bvnLENOVO:bvrGJET72WW(2.22):bd02/21/2014:svnLENOVO:pn20ARS25701:pvrThinkPadT440s:rvnLENOVO:rn20ARS25701:rvrSDK0E50512STD:cvnLENOVO:ct10:cvrNotAvailable:*
> + EVDEV_ABS_00=2445:4252:
> + EVDEV_ABS_01=3464:4071:
> + EVDEV_ABS_35=2445:4252:
> + EVDEV_ABS_36=3464:4071:
> +
> +@endcode
> +
> +Note the discrepancy between the coordinate range the kernels advertises vs.
> +what the touchpad sends.
> +To fix the advertised ranges, the udev rule should be taken and trimmed
> +before being sent to the [systemd 
> project](https://github.com/systemd/systemd).
> +An example commit can be found
> +[here](https://github.com/systemd/systemd/commit/26f667eac1c5e89b689aa0a1daef6a80f473e045).
> +
> +In most cases the match can and should be trimmed to the system vendor (svn)
> +and the product version (pvr), with everything else replaced by a wildcard
> +(*). In this case, a Lenovo T440s, a suitable match string would be: @code
> +evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO:*pvrThinkPadT440s*
> +@endcode
> +
> +@note hwdb match strings only allow for alphanumeric ascii characters. Use a
> +whildcard (* or ?, whichever appropri

[PATCH weston] Remove Raspberry Pi backend and renderer

[Pekka Paalanen]

From: Pekka Paalanen 

This patch completely removes the Raspberry Pi backend and the renderer.

The backend and the renderer were written to use the proprietary
DispmanX API available only on the Raspberry Pi, to demonstrate what the
tiny computer is capable of graphics wise. They were also used to
demonstrate how Wayland and Weston in particular could leverage hardware
compositing capabilities that are not OpenGL. The backend was first
added in e8de35c922871bc5b15fbf0436efa233a6db8e41, in 2012.

Since then, the major point has been proven. Over time, support for the
rpi-backend diminished, it started to deteriorate and hinder Weston
development. On May 11, I tried to ask if anyone actually cared about
the rpi-backend, but did not get any votes for keeping it:
https://lists.freedesktop.org/archives/wayland-devel/2016-May/028764.html

The rpi-backend is a good example of how using an API that is only
available for specific hardware, even more so as it is only available
with a proprietary driver stack, is not maintainable in the long run.
Most developers working on Weston either just cannot, or cannot bother
to test things also on the RPi. Breakage creeps in without anyone
noticing. If someone actually notices it, fixing it will require a very
specific environment to be able to test. Also the quality of the
proprietary implementation fluctuated. There are reports that RPi
firmware updates randomly broke Weston, and that nowadays it is very
hard to find a RPi firmware version that you could expect to work with
Weston if Weston itself was not broken. We are not even sure what is
broken nowadays.

This removal does not leave Raspberry Pi users cold (for long), though.
There is serious work going on in implementing a FOSS driver stack for
Raspberry Pi, including modern kernel DRM drivers and Mesa drivers. It
might not be fully there yet, but the plan is to be able to use the
standard DRM-backend of Weston on the RPis. See:
http://dri.freedesktop.org/wiki/VC4/

The rpi-backend had its moments. Now, it needs to go. Good riddance!

Signed-off-by: Pekka Paalanen 
---
 Makefile.am  |   34 -
 README   |2 -
 configure.ac |   18 -
 man/weston.ini.man   |1 -
 src/compositor-rpi.c |  575 
 src/main.c   |   19 -
 src/rpi-bcm-stubs.h  |  327 -
 src/rpi-renderer.c   | 1830 --
 src/rpi-renderer.h   |   52 --
 9 files changed, 2858 deletions(-)
 delete mode 100644 src/compositor-rpi.c
 delete mode 100644 src/rpi-bcm-stubs.h
 delete mode 100644 src/rpi-renderer.c
 delete mode 100644 src/rpi-renderer.h

diff --git a/Makefile.am b/Makefile.am
index 00b74e5..8ee9c8d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -328,40 +328,6 @@ nodist_wayland_backend_la_SOURCES =
\
protocol/fullscreen-shell-unstable-v1-client-protocol.h
 endif
 
-if ENABLE_RPI_COMPOSITOR
-if INSTALL_RPI_COMPOSITOR
-module_LTLIBRARIES += rpi-backend.la
-else
-noinst_LTLIBRARIES += rpi-backend.la
-endif
-
-rpi_backend_la_LDFLAGS = -module -avoid-version
-rpi_backend_la_LIBADD = $(COMPOSITOR_LIBS) \
-   $(RPI_COMPOSITOR_LIBS)  \
-   $(RPI_BCM_HOST_LIBS)\
-   $(INPUT_BACKEND_LIBS)   \
-   libsession-helper.la\
-   libshared.la
-rpi_backend_la_CFLAGS =\
-   $(AM_CFLAGS)\
-   $(COMPOSITOR_CFLAGS)\
-   $(RPI_COMPOSITOR_CFLAGS)\
-   $(RPI_BCM_HOST_CFLAGS)
-rpi_backend_la_SOURCES =   \
-   src/compositor-rpi.c\
-   src/rpi-renderer.c  \
-   src/rpi-renderer.h  \
-   src/rpi-bcm-stubs.h \
-   shared/helpers.h\
-   $(INPUT_BACKEND_SOURCES)
-
-if ENABLE_EGL
-rpi_backend_la_LIBADD += $(EGL_LIBS)
-rpi_backend_la_CFLAGS += $(EGL_CFLAGS)
-endif
-
-endif
-
 if ENABLE_HEADLESS_COMPOSITOR
 module_LTLIBRARIES += headless-backend.la
 headless_backend_la_LDFLAGS = -module -avoid-version
diff --git a/README b/README
index 3fdfb37..110a14b 100644
--- a/README
+++ b/README
@@ -138,8 +138,6 @@ would be roughly like this:
 
 - xwayland (depends on X11/xcb libs)
 
-- rpi-backend (depends on DispmanX, libudev, ...)
-
 - fbdev-backend (depends on libudev...)
 
 - rdp-backend (depends on freerdp)
diff --git a/configure.ac b/configure.ac
index 87e67fe..525810f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -208,23 +208,6 @@ if test x$enable_headless_compositor = xyes; then
 fi
 
 
-AC_ARG_ENABLE(rpi-compositor,
- AS_HELP_STRING([--disable-rpi-compositor],
-[do not build the Raspberry Pi backend]),,
- enable_rpi_compositor=yes)
-AM_CONDITIONAL(ENABLE_RPI_COMPOSITOR, test "x$enable_rpi_compositor" = "xyes")
-have_bcm_host="no"
-if test "x$enable_rpi

[PATCH weston] Remove support for the proprietary Raspberry Pi drivers

[Pekka Paalanen]

From: Pekka Paalanen 

Hi,

please see the commit message on the patch for the story.

The patch has been generated with -D to avoid listing the contents of the
deleted files. You can find the proper, complete patch at:
https://git.collabora.com/cgit/user/pq/weston.git/log/?h=rpi-removal


Thanks,
pq

Pekka Paalanen (1):
  Remove Raspberry Pi backend and renderer

 Makefile.am  |   34 -
 README   |2 -
 configure.ac |   18 -
 man/weston.ini.man   |1 -
 src/compositor-rpi.c |  575 
 src/main.c   |   19 -
 src/rpi-bcm-stubs.h  |  327 -
 src/rpi-renderer.c   | 1830 --
 src/rpi-renderer.h   |   52 --
 9 files changed, 2858 deletions(-)
 delete mode 100644 src/compositor-rpi.c
 delete mode 100644 src/rpi-bcm-stubs.h
 delete mode 100644 src/rpi-renderer.c
 delete mode 100644 src/rpi-renderer.h

Pekka Paalanen (1):
  Remove the special Raspberry Pi guide

 building.html|   4 +-
 raspberrypi.html | 225 ---
 2 files changed, 3 insertions(+), 226 deletions(-)
 delete mode 100644 raspberrypi.html

-- 
2.7.3

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

[PATCH wayland-web] Remove the special Raspberry Pi guide

[Pekka Paalanen]

From: Pekka Paalanen 

The Raspberry Pi backend has been removed from Weston. You should try
the FOSS driver stack instead.

Signed-off-by: Pekka Paalanen 
---
 building.html|   4 +-
 raspberrypi.html | 225 ---
 2 files changed, 3 insertions(+), 226 deletions(-)
 delete mode 100644 raspberrypi.html

diff --git a/building.html b/building.html
index a669e31..1ff9ea2 100644
--- a/building.html
+++ b/building.html
@@ -55,7 +55,9 @@ Ubuntu 12.04. May be useful for any Debian-derived 
system.
 Linux Mint 17, which is derived from Ubuntu 14.04.
 
 For building Weston for http://www.raspberrypi.org/";>Raspberry
-Pi, see Raspberry Pi build guide.
+Pi, follow the normal build guide after checking out the
+https://dri.freedesktop.org/wiki/VC4/";>FOSS drivers, and use
+the DRM-backend.
 
 For building Wayland on Arch note that https://wiki.archlinux.org/index.php/Docbook#Setting_up_Docbook_in_Arch";>DocBook
 dependencies will be needed when building documentation.
 
diff --git a/raspberrypi.html b/raspberrypi.html
deleted file mode 100644
index 442a694..000
--- a/raspberrypi.html
+++ /dev/null
@@ -1,225 +0,0 @@
-http://www.w3.org/TR/html4/strict.dtd";> 
- 
-
- 
- 
-
-Weston on Raspberry Pi 
-
-
-
-
-
-Weston on Raspberry Pi
-
-This is a guide for installing Weston into
-http://www.raspberrypi.org/";>Raspberry Pi. All commands and
-compiling are done directly on the Pi. In Raspbian, it is recommended to
-run Weston as the user 'pi', as Raspbian seems to allow input device access
-mostly for this user while logged in locally (not via ssh).
-
-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.
-
-Recent versions of the Raspbian image
-http://www.raspberrypi.org/downloads";>downloaded from
-raspberrypi.org already have the raspberrypi.collabora.com repository
-enabled. At least version 2013-09-25 is confirmed to have it, and
-in fact that image comes with Weston 1.1.0 pre-installed.
-
-If you need to add the repository manually,
-add the following line to /etc/apt/sources.list file:
-deb http://raspberrypi.collabora.com wheezy rpi
-
-To install Weston, just issue:
-sudo apt-get update
-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
-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 libraspberrypi-dev \
-libxkbcommon-dev libxcb-composite0-dev libpam-dev
-
-
-On December 4th, 2013, libxkbcommon-dev is not yet found in Raspbian
-itself, but it is available from the raspberrypi.collabora.com repository,
-see above.
-
-Firmware
-
-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. 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:
-
-   gpu_mem=128
-   How much memory to reserve for the VideoCore, i.e. framebuffers,
-   GL textures, Dispmanx resources.
-   dispmanx_offline=1
-   This will enable the firmware to fall back to off-line
-   compositing of Dispmanx elements. Normally the compositing
-   is done on-line, during scanout, but cannot handle too many
-   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. Heavily recommended.
-
-
-Setting up the environment
-
-Here we will install to the home directory of the pi user.
-
-
-export WLD="$HOME/local"
-export PATH="$WLD/bin:$PATH"
-export LD_LIBRARY_PATH="$WLD/lib:/opt/vc/lib"
-export PKG_CONFIG_PATH="$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/"
-export ACLOCAL_PATH="$WLD/share/aclocal"
-export ACLOCAL="aclocal -I $ACLOCAL_PATH"
-
-export XDG_RUNTIME_DIR="/run/shm/wayland"
-export XDG_CONFIG_HOME="$WLD/etc"
-export XORGCONFIG="$WLD/etc/xorg.conf"
-
-mkdir -p "$WLD/share/aclocal"
-mkdir -p "$XDG_RUNTIME_DIR"
-chmod 0700 "$XDG_RUNTIME_DIR"
-
-
-
-You may put the above in a script and source it 

[PATCH RFC] Add tiled states per edge

[Olivier Fourdan]

Hi all,

I send this as an RFC for now, to gauge the water and get the ball
rolling.

I don't think tiling overlaps with the "draw states" proposed by Mike
in the other thread currently on wayland-devel, I reckon tiling is more
than just drawing, applications must obey the configure event when
tiled, just like when maximized or fullscreen. They may also change
their decorations, of course, but not only.

This takes ideas from Jonas and Matthias, as discussed in GNOME 
bug #766860.

Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=766860

Olivier Fourdan (1):
  xdg-shell: Add tiled states

 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 27 +++
 1 file changed, 27 insertions(+)

-- 
2.7.4

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

[PATCH RFC] xdg-shell: Add tiled states

[Olivier Fourdan]

When tiled, clients must obey the window geometry specified in the
configure event and can choose to hide some of their decorations.

Signed-off-by: Olivier Fourdan 
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index ce57153..550a0e5 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -343,6 +343,33 @@
  active. Do not assume this means that the window actually has
  keyboard or pointer focus.

+  
+   
+ The top side of the surface is tiled, either to another surface
+ or a monitor edge. The window geometry specified in the configure
+ event must be obeyed by the client.
+   
+  
+  
+   
+ The bottom side of the surface is tiled, either to another surface
+ or a monitor edge. The window geometry specified in the configure
+ event must be obeyed by the client.
+   
+  
+  
+   
+ The left side of the surface is tiled, either to another surface
+ or a monitor edge. The window geometry specified in the configure
+ event must be obeyed by the client.
+   
+  
+  
+   
+ TThe right side of the surface is tiled, either to another surface
+ or a monitor edge. The window geometry specified in the configure
+ event must be obeyed by the client.
+   
   
 
 
-- 
2.7.4

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

Re: [PATCH weston 0/3] misc ivi-shell patches

[Pekka Paalanen]

On Thu, 12 May 2016 11:56:35 +0300
Pekka Paalanen  wrote:

> On Thu, 12 May 2016 07:50:08 +
> "Ucan, Emre (ADITG/SW1)"  wrote:
> 
> > Hi Pekka,
> > 
> > All patches look good. 
> > 
> > Reviewed-by: Emre Ucan   
> 
> Hi,
> 
> cool, patches 1 and 2 pushed:
>5375384..edcb312  master -> master
> 
> Since patch 3 adds new ABI, it's probably best to wait with it until
> after 1.11 release, even though it is a backward-compatible change
> unlike the previous we landed.
> 
> But if you would actually have use for it already, I could push it
> before the beta release.

Hi,

patch 3 pushed:
   2d825ed..eaa43fc  master -> master


Thanks,
pq

> > -Original Message-
> > From: Pekka Paalanen [mailto:ppaala...@gmail.com] 
> > Sent: Dienstag, 10. Mai 2016 16:21
> > To: wayland-devel@lists.freedesktop.org
> > Cc: wataru_nats...@xddp.denso.co.jp; Ucan, Emre (ADITG/SW1); Pekka Paalanen
> > Subject: [PATCH weston 0/3] misc ivi-shell patches
> > 
> > From: Pekka Paalanen 
> > 
> > Hi,
> > 
> > these patches are a by-product from working on the IVI-surface
> > remoting project.
> > 
> > Patch 3 is adding new API, and we are past alpha release in the 1.11
> > release cycle, so we might want to postpone that one to 1.12. The
> > others should be fine before beta, though.
> > 
> > Thanks,
> > pq
> > 
> > 
> > Pekka Paalanen (3):
> >   ivi-shell-user-interface: ignore all but first seat
> >   ivi-layout: clarify get_layers_under_surface doc
> >   ivi-shell: add API for weston_surface -> ivi_layout_surface
> > 
> >  clients/ivi-shell-user-interface.c |  4 
> >  ivi-shell/ivi-layout-export.h  | 14 +-
> >  ivi-shell/ivi-layout.c |  1 +
> >  ivi-shell/ivi-shell.c  | 12 
> >  ivi-shell/ivi-shell.h  |  5 +
> >  5 files changed, 35 insertions(+), 1 deletion(-)
> > 
> > --
> > 2.7.3
> >   
> 



pgpvpm6x02F_F.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Protocol for window previews/thumbnails

[Pekka Paalanen]

On Tue, 31 May 2016 14:49:38 +0100
adlo  wrote:

> > On 20 May 2016, at 08:50, Pekka Paalanen  wrote:
> > 
> > You would design a new protocol extension private to Weston, with which
> > you deliver to your client the handles for top-level windows as they
> > come and go.
> >   
> 
> This should probably be a separate protocol from the preview
> protocol. Is it possible to integrate the handle and preview protocol
> with another protocol, such as xdg-shell, so that the handles are
> delivered as xdg_surfaces and the preview protocol accepts
> xdg_surfaces as input?

No. Not for what you would like to use it. That simply is not what
xdg_surface is for, and none of the xdg_surface API or any other API
using xdg_surface would apply. So it is totally inappropriate to try to
shoehorn xdg_surface in there.

The handles would usually represent surfaces that have a xdg_surface
associated in the originating client, but it makes no sense to try to
call the handle a xdg_surface. The handles are used completely
differently than xdg_surfaces.

There is also a practical issue: to create an xdg_surface with
xdg_shell, you first need a wl_surface. However, you cannot refer to a
wl_surface of another client. That is the whole reason you need to
create handles in the first place, to be able to refer to surfaces that
are not your own.

> Is xdg-shell designed to be used by third-party clients for
> controlling windows in a similar way to libwnck? Does xdg-shell
> expose the inner workings of the compositor thus making it unsuitable?

As Jonas said, no.


Thanks,
pq


pgpL2MnbxzdWC.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] touchpad: warn if we have invalid touchpad ranges

[Hans de Goede]

Hi,

On 01-06-16 02:42, Peter Hutterer wrote:

Quite a few bugs are caused by touchpad ranges being out of whack. If we get
input events significantly outside the expected range (5% width/height as
error margin) print a warning to the log.

And add a new doc page to explain what is happening and how to fix it.

Signed-off-by: Peter Hutterer 


Looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
 doc/Makefile.am|   1 +
 doc/absolute-coordinate-ranges.dox | 120 +
 doc/page-hierarchy.dox |   1 +
 src/evdev-mt-touchpad.c|  59 ++
 src/evdev-mt-touchpad.h|   5 ++
 5 files changed, 186 insertions(+)
 create mode 100644 doc/absolute-coordinate-ranges.dox

diff --git a/doc/Makefile.am b/doc/Makefile.am
index f2a47cb..1e501a8 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -11,6 +11,7 @@ header_files = \
$(top_srcdir)/src/libinput.h \
$(top_srcdir)/README.txt \
$(srcdir)/absolute-axes.dox \
+   $(srcdir)/absolute-coordinate-ranges.dox \
$(srcdir)/clickpad-softbuttons.dox \
$(srcdir)/device-configuration-via-udev.dox \
$(srcdir)/faqs.dox \
diff --git a/doc/absolute-coordinate-ranges.dox 
b/doc/absolute-coordinate-ranges.dox
new file mode 100644
index 000..f9d9e98
--- /dev/null
+++ b/doc/absolute-coordinate-ranges.dox
@@ -0,0 +1,120 @@
+/**
+@page absolute_coordinate_ranges Coordinate ranges for absolute axes
+
+libinput requires that all touchpads provide a correct axis range and
+resolution. These are used to enable or disable certain features or adapt
+the interaction with the touchpad. For example, the software button area is
+narrower on small touchpads to avoid reducing the interactive surface too
+much. Likewise, palm detection works differently on small touchpads as palm
+interference is less likely to happen.
+
+Touchpads with incorrect axis ranges generate error messages
+in the form:
+
+Axis 0x35 value 4000 is outside expected range [0, 3000]
+
+
+This error message indicates that the ABS_MT_POSITION_X axis (i.e. the x
+axis) generated an event outside the expected range of 0-3000. In this case
+the value was 4000.
+This discrepancy between the coordinate range the kernels advertises vs.
+what the touchpad sends can be the source of a number of perceived
+bugs in libinput.
+
+@section absolute_coordinate_ranges_fix Measuring and fixing touchpad ranges
+
+To fix the touchpad you need to:
+-# measure the physical size of your touchpad in mm
+-# run touchpad-edge-detector
+-# trim the udev match rule to something sensible
+-# replace the resolution with the calculated resolution based on physical
+  settings
+-# test locally
+-# send a patch to the systemd project
+
+Detailed explanations are below.
+
+[libevdev](http://freedesktop.org/wiki/Software/libevdev/) provides a tool
+called **touchpad-edge-detector** that allows measuring the touchpad's input
+ranges. Run the tool as root against the device node of your touchpad device
+and repeatedly move a finger around the whole outside area of the
+touchpad. Then control+c the process and note the output.
+An example output is below:
+
+@code
+$> sudo touchpad-edge-detector /dev/input/event4
+Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event4
+Move one finger around the touchpad to detect the actual edges
+Kernel says:   x [1024..3112], y [2024..4832]
+Touchpad sends:x [2445..4252], y [3464..4071]
+
+Touchpad size as listed by the kernel: 49x66mm
+Calculate resolution as:
+   x axis: 2088/
+   y axis: 2808/
+
+Suggested udev rule:
+# 
+evdev:name:SynPS/2 Synaptics 
TouchPad:dmi:bvnLENOVO:bvrGJET72WW(2.22):bd02/21/2014:svnLENOVO:pn20ARS25701:pvrThinkPadT440s:rvnLENOVO:rn20ARS25701:rvrSDK0E50512STD:cvnLENOVO:ct10:cvrNotAvailable:*
+ EVDEV_ABS_00=2445:4252:
+ EVDEV_ABS_01=3464:4071:
+ EVDEV_ABS_35=2445:4252:
+ EVDEV_ABS_36=3464:4071:
+
+@endcode
+
+Note the discrepancy between the coordinate range the kernels advertises vs.
+what the touchpad sends.
+To fix the advertised ranges, the udev rule should be taken and trimmed
+before being sent to the [systemd project](https://github.com/systemd/systemd).
+An example commit can be found
+[here](https://github.com/systemd/systemd/commit/26f667eac1c5e89b689aa0a1daef6a80f473e045).
+
+In most cases the match can and should be trimmed to the system vendor (svn)
+and the product version (pvr), with everything else replaced by a wildcard
+(*). In this case, a Lenovo T440s, a suitable match string would be: @code
+evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO:*pvrThinkPadT440s*
+@endcode
+
+@note hwdb match strings only allow for alphanumeric ascii characters. Use a
+whildcard (* or ?, whichever appropriate) for special characters.
+
+The actual axis overrides are in the form:
+@code
+# axis number=min:max:resolution
+ EVDEV_ABS_00=2445:4252:42
+@endcode
+or, if the range is correct but the resolution is wrong
+@co