Re: [PATCH weston 1/7] timespec: Add timespec_add_nsec helper

On Tue, 14 Feb 2017 14:21:17 + Daniel Stone wrote: > Hi, > > On 14 February 2017 at 14:09, Pekka Paalanen wrote: > > On Tue, 14 Feb 2017 13:18:01 + > > Daniel Stone wrote: > >> Add a (timespec) = (timespec) + (nsec)

Re: [PATCH weston 1/7] timespec: Add timespec_add_nsec helper

Hi, On 14 February 2017 at 15:02, Pekka Paalanen wrote: > On Tue, 14 Feb 2017 14:21:17 + > Daniel Stone wrote: >> On 14 February 2017 at 14:09, Pekka Paalanen wrote: >> > On Tue, 14 Feb 2017 13:18:01 + >> > Daniel Stone

Re: [PATCH weston] compositor-drm: Try to preserve existing output routing

On Mon, 16 Jan 2017 14:40:44 + Daniel Stone wrote: > Previously in picking CRTC -> encoder -> connecting routing, we went for > the first triplet we found which claimed to work. > > Preserving the existing routing means that startup will be faster: on a > multi-head

Re: [PATCH wayland] protocol: Clarify the meaning of NULL buffer attachment

On Mon, 13 Feb 2017 12:06:24 -0600 Derek Foreman wrote: > This documents what has apparently been the case for ages - attaching a NULL > buffer does *not* always remove the surface content, rather it has behaviour > determined by the surface role (which may be documented

Re: [PATCH weston 01/68] libweston: Add pixel-format helpers

On Mon, 13 Feb 2017 18:24:58 + Daniel Stone wrote: > Hi, > > On 14 December 2016 at 15:59, Pekka Paalanen wrote: > > On Fri, 9 Dec 2016 19:57:16 + > > Daniel Stone wrote: > >> + { > >> + .format =

Re: [PATCH weston v4] compositor-drm: Ignore non-KMS devices

Hi Emil, On 13 February 2017 at 23:42, Emil Velikov wrote: > On 13 February 2017 at 18:57, Daniel Stone wrote: >> /* >> * Find primary GPU >> * Some systems may have multiple DRM devices attached to a single seat. >> This > Completely

Re: [PATCH v2 libinput] tools: print errors as red, info as highlighted

Hi, On 14-02-17 02:58, Peter Hutterer wrote: makes it easier to filter out debugging messages Signed-off-by: Peter Hutterer --- Sorry, used the wrong patch, v1 was an earlier version. v2 looks good to me: Reviewed-by: Hans de Goede Regards,

[PATCH weston 3/7] timespec: Add timespec_to_msec helper

Paralleling timespec_to_nsec, converts to milliseconds. Signed-off-by: Daniel Stone --- libweston/compositor.c | 2 +- shared/timespec-util.h | 11 +++ tests/timespec-test.c | 9 + 3 files changed, 21 insertions(+), 1 deletion(-) diff --git

[PATCH weston 5/7] Don't delay initial output paint

On startup, we cannot lock on to the repaint timer because it is unknown to us. We deal with this by claiming that the moment of entry into the repaint loop is the moment a frame returned, causing finish_frame to delay our initial repaint to (refresh_time - repaint_delay), typically around 9ms of

[PATCH weston 1/7] timespec: Add timespec_add_nsec helper

Add a (timespec) = (timespec) + (nsec) helper, to save intermediate conversions to nanoseconds in its users. Signed-off-by: Daniel Stone --- Makefile.am| 10 shared/timespec-util.h | 21 + tests/timespec-test.c | 126

[PATCH weston 0/7] Grouped output repaint

Hi, One of the nice features of atomic modesetting is, well, atomicity of modesetting. Specifically that you can perform one call across every output to set every mode in one go. The previous atomic series implemented the nuclear pageflip side of atomic modesetting (for one output, every plane

[PATCH weston v5] compositor-drm: Ignore non-KMS devices

Given that we can have render-only devices, or vgem in a class of its own, ignore any non-KMS devices in compositor-drm's device selection. For x86 platforms, this is mostly a non-issue since we look at the udev boot_vga issue, but other architectures which lack this, and have multiple KMS devices

[PATCH weston 7/7] Allow backends to group repaint flushes

Implement new repaint_begin and repaint_flush hooks inside weston_backend, allowing backends to gang together repaints which trigger at the same time. Signed-off-by: Daniel Stone --- libweston/compositor-drm.c | 5 +++-- libweston/compositor-fbdev.c| 3 ++-

[PATCH weston 4/7] Calculate next-frame target time in absolute space

Rather than determining the time until next-frame repaint in relative space (time until repaint), determine it first in absolute space, and then later convert this to relative. This will later allow us to store these per-output, so we can have a single idle timer which will allow us to aggregate

[PATCH weston 2/7] timespec: Add timespec_add_msec helper

Add a (timespec) = (timespec) + (msec) helper, to save intermediate conversions in its users. Signed-off-by: Daniel Stone --- shared/timespec-util.h | 21 + tests/timespec-test.c | 11 +++ 2 files changed, 32 insertions(+) diff --git

[PATCH weston 6/7] Switch to global output repaint hook

In preparation for grouping output repaint together where possible, switch the per-output repaint timer to a global timer which iterates across all outputs. This is implemented by storing the absolute time for the next repaint for each output locally, and maintaining a global timer hook which

Re: [PATCH weston v4] compositor-drm: Ignore non-KMS devices

Hi Emil, On 14 February 2017 at 09:48, Daniel Stone wrote: > On 13 February 2017 at 23:42, Emil Velikov wrote: >> Thinking about this a bit more this won't fly either, I'm afraid. In >> the previous version we'll keep potentially old/unwanted

Re: wayland/weston 1.9.0 and glimagesingk gstreamer wayland sink query with i.MX6

Le mercredi 08 février 2017 à 19:28 +0530, Vikas Patil a écrit : > When I run simple video application (which pause and play gstreamer > pipeline continuously) based on following pipeline [1] with  weston > 1.9.0  and glimagesink (part of gstreamer1.0-plugins-bad 1.6.0 > package) on i.MX6 based

Re: [PATCH weston 1/3] tests: add a create_test_surface function

BTW note this series depends on this other one: https://patchwork.freedesktop.org/series/18695/ https://lists.freedesktop.org/archives/wayland-devel/2017-January/032890.html Cheers, Emilio On 03/02/17 16:10, Emilio Pozuelo Monfort wrote: > This doesn't attach a buffer to the surface. This is

[PATCH weston v6] compositor-drm: Ignore non-KMS devices

Given that we can have render-only devices, or vgem in a class of its own, ignore any non-KMS devices in compositor-drm's device selection. For x86 platforms, this is mostly a non-issue since we look at the udev boot_vga issue, but other architectures which lack this, and have multiple KMS devices

Re: [PATCH wayland] protocol: Clarify the meaning of NULL buffer attachment

On 14/02/17 06:05 AM, Pekka Paalanen wrote: On Mon, 13 Feb 2017 12:06:24 -0600 Derek Foreman wrote: This documents what has apparently been the case for ages - attaching a NULL buffer does *not* always remove the surface content, rather it has behaviour determined by

[PATCH wayland v2] protocol: Clarify the behaviour of wl_surface.attach

Attaching a NULL wl_buffer to a surface is not always valid, but the previous text indicated it was. Instead, let's define what NULL attachment does for all the surface roles defined in wayland.xml, stop giving a blanket definition of its behavior in wl_surface.attach, and warn developers that

[ANNOUNCE] wayland 1.12.93

This is the release candidate for wayland 1.13. There have been no changes since the beta. In addition to a range of bug fixes, changes since wayland 1.12 have added some API for controlling the visibility of globals and numerous documentation and other improvements. We're still on schedule for

[ANNOUNCE] weston 1.99.93

This is the release candidate for weston 2.0. A few cleanups have landed since the beta including several refinements for the drm compositor backend. Changes since weston 1.12 include EGL_KHR_swap_buffers_with_damage support, porting backends to new API for output setup, support for

Re: [PATCH wayland v2] protocol: Clarify the behaviour of wl_surface.attach

On Tue, Feb 14, 2017 at 10:20:06AM -0600, Derek Foreman wrote: > Attaching a NULL wl_buffer to a surface is not always valid, but > the previous text indicated it was. > > Instead, let's define what NULL attachment does for all the surface > roles defined in wayland.xml, stop giving a blanket

Re: [PATCH weston 1/7] timespec: Add timespec_add_nsec helper

On Tue, 14 Feb 2017 13:18:01 + Daniel Stone wrote: > Add a (timespec) = (timespec) + (nsec) helper, to save intermediate > conversions to nanoseconds in its users. > > Signed-off-by: Daniel Stone Hi, I recall some comments about using

Re: [PATCH weston 1/7] timespec: Add timespec_add_nsec helper

Hi, On 14 February 2017 at 14:09, Pekka Paalanen wrote: > On Tue, 14 Feb 2017 13:18:01 + > Daniel Stone wrote: >> Add a (timespec) = (timespec) + (nsec) helper, to save intermediate >> conversions to nanoseconds in its users. > > I recall some

Re: [PATCH weston 2/7] timespec: Add timespec_add_msec helper

On Tue, 14 Feb 2017 13:18:02 + Daniel Stone wrote: > Add a (timespec) = (timespec) + (msec) helper, to save intermediate > conversions in its users. > > Signed-off-by: Daniel Stone > --- > shared/timespec-util.h | 21 + >

Re: [PATCH weston 2/7] timespec: Add timespec_add_msec helper

Hi, On 14 February 2017 at 14:24, Pekka Paalanen wrote: > On Tue, 14 Feb 2017 13:18:02 + > Daniel Stone wrote: >> +/* Add a millisecond value to a timespec >> + * >> + * \param r[out] result: a + b >> + * \param a[in] base operand as timespec >> +

Re: [PATCH weston v5] compositor-drm: Ignore non-KMS devices

On 14 February 2017 at 13:49, Daniel Stone wrote: > Given that we can have render-only devices, or vgem in a class of its > own, ignore any non-KMS devices in compositor-drm's device selection. > For x86 platforms, this is mostly a non-issue since we look at the udev >