[weston][PATCH] compositor-fbdev: Add support grayscale PIXMAn_g4 format.

Signed-off-by: Enric Balletbo i Serra Reviewed-by: Sjoerd Simons --- src/compositor-fbdev.c | 51 +- 1 file changed, 42 insertions(+), 9 deletions(-) diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c index a6fd823..9d8a1f1 100644 --- a/

Re: [PATCH] build: always build wayland-scanner

On 3 July 2015 at 17:16, Derek Foreman wrote: > What's the benefit in forcing everyone to build wayland-scanner? Right > now it's not required. Is there actually a reason this ability must be > broken to add the functionality you want? > Just realised you might be talking about cross environme

Re: [PATCH] build: always build wayland-scanner

On 3 July 2015 at 17:16, Derek Foreman wrote: > What's the benefit in forcing everyone to build wayland-scanner? Right > now it's not required. Is there actually a reason this ability must be > broken to add the functionality you want? > Considering a scanner is needed to build all of wayland,

Re: [PATCH] build: always build wayland-scanner

On 03/07/15 10:06 AM, Burton, Ross wrote: > On 3 July 2015 at 15:50, Derek Foreman > wrote: > > On 01/07/15 04:51 PM, Ross Burton wrote: > > The previous idiom for building a cross-compiled Wayland is to build > once for > > the build host (with --enabl

Re: [PATCH] build: always build wayland-scanner

On 3 July 2015 at 15:50, Derek Foreman wrote: > On 01/07/15 04:51 PM, Ross Burton wrote: > > The previous idiom for building a cross-compiled Wayland is to build > once for > > the build host (with --enable-scanner --disable-libraries) to get a > > wayland-scanner binary that can then be used in

Re: [PATCH] build: always build wayland-scanner

On 01/07/15 04:51 PM, Ross Burton wrote: > The previous idiom for building a cross-compiled Wayland is to build once for > the build host (with --enable-scanner --disable-libraries) to get a > wayland-scanner binary that can then be used in a cross-compile (with > --disable-scanner). The problem w

Re: [PATCH libinput v3 5/5] libinput: add orientation and size of touch point and pressure to the API

Hi, On Thu, Jun 25, 2015 at 8:03 AM, Peter Hutterer wrote: > [...] > > - break; > > - case ABS_MT_TRACKING_ID: > > + } else if(e->code == ABS_MT_TRACKING_ID) { > > if (device->pending_event != EVDEV_NONE && > > device->pending_event != EVDEV_AB

Re: [PATCH 07/10] compositor-drm: Allow instant start of repaint loop. (v2)

On Sun, 21 Jun 2015 21:25:14 +0200 Mario Kleiner wrote: > drm_output_start_repaint_loop() incurred a delay of > one refresh cycle by using a no-op page-flip to get > an accurate vblank timestamp as reference. This causes > unwanted lag whenever Weston exited its repaint loop, e.g., > whenever an

Re: cross-client surface references

On Fri, Jul 03, 2015 at 11:52:53AM +0200, Alexander Larsson wrote: > On fre, 2015-07-03 at 17:24 +0800, Jonas Ådahl wrote: > > > > As an option prior to ending up with taking the nested compositing > > path, > > I had a proposal that sounds similar to what you are talking about: > > > > http://l

Re: [PATCH 09/10] presentation-shm: Allow setting of delay before surface.commit

On Sun, 21 Jun 2015 21:25:16 +0200 Mario Kleiner wrote: > A new optional parameter "-d msecs" allows to specify a > delay before the surface attach/damage/commit to shift > the point in time when a surface update is committed. > > This allows to test how different client timings interact > with

Re: cross-client surface references

On fre, 2015-07-03 at 17:24 +0800, Jonas Ådahl wrote: > > As an option prior to ending up with taking the nested compositing > path, > I had a proposal that sounds similar to what you are talking about: > > http://lists.freedesktop.org/archives/wayland-devel/2013 > -March/008093.html > > What i

Re: cross-client surface references

On Fri, Jul 03, 2015 at 10:37:01AM +0200, Alexander Larsson wrote: > I understand the ideas behind not allowing one client to access a > surface from another client. However, there are cases where we really > want one client to refer to a surface (typically a xdg_surface) from > another client. >

cross-client surface references

I understand the ideas behind not allowing one client to access a surface from another client. However, there are cases where we really want one client to refer to a surface (typically a xdg_surface) from another client. In particular, I have a need for this in my sandboxing work. Consider a setup

[PATCH] fixed-benchmark: remove unused arguments in main

Fixed benchmark uses main(int argc, char *argv[]) but does not use the arguments, so we can replace them with void Signed-off-by: Marek Chalupa --- tests/fixed-benchmark.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fixed-benchmark.c b/tests/fixed-benchmark.c index