On Wed, Jun 17, 2015 at 03:13:51PM -0500, Derek Foreman wrote:
> The scanner doesn't need anything but wayland-util.c/.h so we can
> shrink wayland-util when not building the main libraries.
>
> Signed-off-by: Derek Foreman
> ---
> Makefile.am | 15 +--
> 1 file changed, 9 insertions
AM_CFLAGS are the defaults passed to anything that doesn't specify its own
_CFLAGS, so instead of putting FFI_CFLAGS there, let's just add that to
anything that actually needs it.
The only thing that needs it but didn't have it specifically was
libwayland_util (for connection.c)
Signed-off-by: De
The scanner doesn't need anything but wayland-util.c/.h so we can
shrink wayland-util when not building the main libraries.
Signed-off-by: Derek Foreman
---
Makefile.am | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 31adc97..84
AM_CFLAGS and AM_CPPFLAGS aren't positional, so putting them at a
random place in Makefile.am can be misleading.
Signed-off-by: Derek Foreman
---
Makefile.am | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 0ea300a..96ad0be 100644
When cross-compiling it may be useful to build only the wayland-scanner
natively. This patch makes it possible to disable build of the libraries.
Signed-off-by: Derek Foreman
---
Makefile.am | 47 +--
configure.ac | 30 --
Some generic clean ups of the build with the goal being building
the scanner without any libs or doc.
This is useful because when cross compiling wayland you only
need the scanner built natively. It also lets us remove some
dependencies for the build host (libffi, signalfd, timerfd,
CLOCK_MONOTONI
When building just the scanner or docs it's not required.
This can reduce requirements for a host cross compiling wayland,
since only the scanner needs to be built natively.
Signed-off-by: Derek Foreman
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configu
On Wed, Jun 17, 2015 at 9:35 AM, Bill Spitzak wrote:
> The problem is that the way it works is *not* a tree, but some kind of
> list.
>
> As described the following code:
>
> wl_subsurface_place_below(RED->subsurface, GREEN->surface);
> wl_subsurface_place_below(GREEN->subsurface, BLUE->surface);
The problem is that the way it works is *not* a tree, but some kind of list.
As described the following code:
wl_subsurface_place_below(RED->subsurface, GREEN->surface);
wl_subsurface_place_below(GREEN->subsurface, BLUE->surface);
Produces the order GREEN, RED, BLUE instead.
However if you desc
On Tue, 16 Jun 2015 23:47:03 +0800
Jonas Ådahl wrote:
> On Tue, Jun 16, 2015 at 04:46:55PM +0200, Arnaud Vrac wrote:
> > Hi,
> >
> > I'm wondering if a behaviour of weston related to subsurfaces is either a
> > bug or intended. The protocol description is not clear on what happens in
> > the fol
On Tue, 16 Jun 2015 23:42:43 +0800
Jonas Ådahl wrote:
> On Tue, Jun 16, 2015 at 08:02:52AM -0700, Jasper St. Pierre wrote:
> > I was not aware you could stack subsurfaces under a parent surface at
> > all. Is this intended protocol behavior? The fact that you might be
> > able to do that at all i
On Tue, 16 Jun 2015 08:02:52 -0700
"Jasper St. Pierre" wrote:
> I was not aware you could stack subsurfaces under a parent surface at
> all. Is this intended protocol behavior? The fact that you might be
> able to do that at all in Weston might be a bug.
Yes, stacking behind the parent is intend
On Tue, 16 Jun 2015 19:48:56 +0100
vishnu wrote:
> Hi,
> Trying to launch Weston with drm backend and weston-launch fails, below is
> the error message
>
> [18:00:38.278] input device 'AT Raw Set 2 keyboard', /dev/input/event0 is a
> keyboard
> [18:00:38.278] libwayland: wl_global_create: imple
Hi
> I am unhappy with all Desktop Environments / Window Managers out there.
That's a lot of unhappiness :)
> Then I watched some online records of some talks about X / Wayland.
> I am now totally convinced that X is horrible.
Beauty is always in the eyes of the beholder so I won't comment on t
14 matches
Mail list logo
