Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes

On Wed, Nov 16, 2016 at 04:00:23PM +, Daniel Stone wrote: > Hi, > > On 15 November 2016 at 09:42, Jonas Ådahl wrote: > > On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote: > >> But this I'd prefer to drop. We need to describe the button codes, but > >> the key

Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes

On Wed, Nov 16, 2016 at 04:00:23PM +, Daniel Stone wrote: > Hi, > > On 15 November 2016 at 09:42, Jonas Ådahl wrote: > > On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote: > >> But this I'd prefer to drop. We need to describe the button codes, but > >> the key

Re: [PATCH weston] xwayland: Remove pointless newline in X11 lock

On Wednesday, 2016-11-16 16:37:59 +, Daniel Stone wrote: > The newline was always chopped off by snprintf: pid is only 11 Don't you mean 10? Reviewed-by: Eric Engestrom > characters long, and we were asking to print 11 characters plus the > terminating NULL. Hence

Re: [PATCH] weston-launch: Protect KDGKBMODE K_OFF ioctl by KERNEL_VERSION check

Hi Krzysztof, On 27 September 2016 at 22:44, Dima Ryazanov wrote: > The kernel version used to build Weston isn't necessarily the same as the > version that will be used to run it. Weston should already work fine on > older versions: the second ioctl will return an error - but

Re: [PATCH weston v2] xwayland: Fix crash when run with no input device

Hi Tom, On 1 November 2016 at 19:14, Tom Hochstein wrote: > Starting an xterm with no input device led to a crash > because weston_wm_pick_seat() was returning garbage and > weston_wm_selection_init() was trying to use the garbage. > > Signed-off-by: Tom Hochstein

Re: [PATCH v6] protocol: Extend wl_touch with touchpoint shape and orientation

Hi, On 14 November 2016 at 18:12, Dennis Kempin wrote: > Thanks for the reviews guys! > > The patch for Exosphere is not fully done yet, but I'll post it here once I > got it polished up. > > What are the next steps to merge this patch now that has been reviewed? No

Re: [PATCH wayland] util: Document wl_fixed_t

On 11 November 2016 at 15:55, Yong Bakos wrote: > From: Yong Bakos > > Add doxygen comments for wl_fixed_t and its methods. > > Although wl_fixed_t can be thought of as an opaque struct, it is a typedef. As > such, doxygen does not provide an

Re: [PATCH] doc: Fix a typo in the client documentation

Hi Moritz, On 6 November 2016 at 17:35, Moritz Kiefer wrote: > Signed-off-by: Moritz Kiefer Pushed, thanks for the patch! To ssh://git.freedesktop.org/git/wayland/wayland 6a18a87..06b7c47 master -> master Cheers,

[PATCH weston] xwayland: Remove pointless newline in X11 lock

The newline was always chopped off by snprintf: pid is only 11 characters long, and we were asking to print 11 characters plus the terminating NULL. Hence snprintf would always chop the newline anyway. Signed-off-by: Daniel Stone Cc: Pekka Paalanen

Re: [PATCH wayland] util: Remove stray space from function signature

Hi Yong, On 8 November 2016 at 16:02, Yong Bakos wrote: > wl_fixed_to_double had a stray space before the parameter list. > Remove this space. > > Signed-off-by: Yong Bakos Pushed, thanks: To ssh://git.freedesktop.org/git/wayland/wayland

Re: [PATCH weston] Get rid of the window_create_menu function

Hi Dima, On 14 November 2016 at 07:44, Dima Ryazanov wrote: > It's currently unused, and there's actually no way to use it correctly. > > The caller cannot free the menu that was created: > - the function only returns the window, not the menu > - there's no public API to destroy

Re: [PATCH weston] xwayland: fix lock file parsing

Hi, On 14 November 2016 at 13:05, Pekka Paalanen wrote: > Patch 139fcabe7cdb1f2296bf02ef917aaab84e00cd4e "xwayland: Improve error > checking for strtol call" caused a regression in the X11 unix socket > lock file parsing. Before that patch, only the first 10 characters were

Re: [PATCH wayland] Makefile: build also test programs during a normal build

Hi Jan, On 16 November 2016 at 16:19, Jan Engelhardt wrote: > On Wednesday 2016-11-16 17:16, Daniel Stone wrote: >>> noinst_PROGRAMS = \ >>> + $(built_test_programs) \ >>> + exec-fd-leak-checker\ >>>

Re: [PATCH wayland] Makefile: build also test programs during a normal build

On Wednesday 2016-11-16 17:16, Daniel Stone wrote: >> noinst_PROGRAMS = \ >> + $(built_test_programs) \ >> + exec-fd-leak-checker\ >> fixed-benchmark >> >> check_LTLIBRARIES = libtest-runner.la > >Doesn't this

Re: [PATCH wayland] Makefile: build also test programs during a normal build

Hi Pekka, On 16 November 2016 at 11:46, Pekka Paalanen wrote: > Put also test programs into noinst_PROGRAMS so that they get always > built. In check_PROGRAMS they are built for 'make check' but not for > 'make'. > > This makes it harder to accidentally break the test

Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes

Hi, On 15 November 2016 at 09:42, Jonas Ådahl wrote: > On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote: >> But this I'd prefer to drop. We need to describe the button codes, but >> the key codes are _already_ perfectly described in the keymap. Leaving >> this

Re: [PATCH weston v2 8/8] terminal: Silence maybe-uninitialized warning

Hi, On 16 July 2016 at 08:42, Quentin Glidic wrote: > On 11/07/2016 23:28, Emil Velikov wrote: >> ::unicode will never be read (get_unicode) when it's invalid, since >> ::state will equal to utf8state_reject (as set in utf8_next_char). >> Seems like the

Re: [PATCH weston 5/8] clients/window: use weston_platform_destroy_egl_surface wrapper

Hi, On 14 November 2016 at 17:08, Emil Velikov wrote: > diff --git a/clients/window.c b/clients/window.c > index 84d585e..dabd0b0 100644 > --- a/clients/window.c > +++ b/clients/window.c > @@ -645,7 +645,7 @@ egl_window_surface_destroy(struct toysurface *base) >

Re: [PATCH weston v4 5/5] Switch to use safe_strtoint instead of strtol

Hi, On 10 August 2016 at 09:31, Pekka Paalanen wrote: > On Tue, 9 Aug 2016 11:12:33 -0700 > Bryce Harrington wrote: >> On Mon, Aug 08, 2016 at 02:55:14PM +0300, Pekka Paalanen wrote: >> > there's a new warning: >> > >> >

Re: [PATCH weston] editor: Fix g_type_init() call

Hi Quentin, On 23 June 2016 at 20:06, Quentin Glidic wrote: > From: Quentin Glidic > > HAVE_PANGO is not in any AC_DEFINE(), so the check is just wrong. > g_type_init() was never called, which is fine since GLib 2.36 anyway. > It is

Re: [PATCH weston] xwayland: Create the drag-and-drop window in weston_wm_dnd_init

Hi, On 24 May 2016 at 19:34, Derek Foreman wrote: > On 22/02/16 12:42 PM, Carlos Garnacho wrote: >> Just to keep it hidden so far... A lot of the plumbing necessary to >> handle x11->wayland drag and drop is missing, and the current >> partial handling gets in the middle

Re: [PATCH] xdg-shell: clarify popup constrain's slide mechanism

Some background: I was implementing v6 over the past few days and noticed, while handling constraints, that this was a hugely problematic scenario. If a popup was constrained in a particular way, the compositor could conceivably place it on the opposite side of the screen over unrelated

[PATCH] xdg-shell: clarify popup constrain's slide mechanism

some restrictions must be placed on this or else it becomes legal for the compositor to place popups in unexpected locations when sliding is allowed Signed-off-by: Mike Blumenkrantz --- unstable/xdg-shell/xdg-shell-unstable-v6.xml | 6 -- 1 file changed, 4

Re: [PATCH weston] clients: Fix weston-scaler source-only mode to use integer width and height

On 16/11/16 08:49 AM, Daniel Stone wrote: Hi, On 30 September 2016 at 17:13, Derek Foreman wrote: If only the source of a viewport is set, the width and height must be integer or the protocol mandates that the compositor generate an error. This is because using only

When to apply pointer constraints?

Hi Wayland devs, I'm currently implementing the pointer-constraints protocol and run into a small uncertainty with the documentation. For zwp_locked_pointer_v1::set_region we have: "The new lock region is double- buffered. The new lock region will only take effect when the associated

Re: [PATCH weston] clients: Fix weston-scaler source-only mode to use integer width and height

Hi, On 30 September 2016 at 17:13, Derek Foreman wrote: > If only the source of a viewport is set, the width and height must > be integer or the protocol mandates that the compositor generate an > error. This is because using only the source is a crop, and the > width

Re: [PATCH weston 1/2] input: Update keyboard serial on press and release

Hi, On 2 September 2016 at 09:30, Giulio Camuffo wrote: > 2016-09-02 10:27 GMT+02:00 Olivier Fourdan : >>> 2016-09-01 11:52 GMT+02:00 Olivier Fourdan : >>> >> I’m ok with that, but why not updating all three "grab_*" members? >>>

Re: [PATCH weston] gl-renderer: Use EGL_KHR_no_config_context

Hi, On 30 September 2016 at 13:27, Armin Krezović wrote: > This patch makes use of recently implemented > EGL_KHR_no_config_context extension in Mesa, > which superseeds EGL_MESA_configless_context. > > See also (and the follow-up patch): > >

Re: [PATCH weston v5 38/42] compositor-drm: Discover atomic properties

On 16 November 2016 at 14:25, Daniel Stone wrote: > Set the atomic client cap, where it exists, and use this to discover the > plane/CRTC/connector properties we require for atomic modesetting. Somehow I dropped attribution here; this is Pekka's patch originally. Cheers,

Re: [PATCH weston v5 00/42] Atomic modesetting

On 16 November 2016 at 14:24, Daniel Stone wrote: > Hopefully it's relatively easy to review these as separate bodies of > work: the first few misc cleanup patches, the drm_fb series, > the state management series, moving to output_state/plane_state, and > atomic support.

[PATCH weston v5 06/42] compositor-drm: Extract EGL destroy to helper

No functional change. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1484 --- libweston/compositor-drm.c | 26 +++--- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/libweston/compositor-drm.c

[PATCH weston v5 00/42] Atomic modesetting

Hi, Well, that got quite out of hand. When working on earlier rounds of atomic, I found it very difficult to keep it stable and handle all the corner cases, especially with TEST_ONLY. Coming back to it this time, I've tried to do a few things differently. Firstly, rather than using various parts

[PATCH weston v5 09/42] compositor-drm: Calculate more cursor state up front

Make drm_output_set_cursor more deterministic, by calculating more state and performing more plane manipulation, inside drm_output_prepare_cursor_view. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1485 ---

[PATCH weston v5 29/42] compositor-drm: Track all plane types

Retain drm_plane tracking objects for all actual DRM planes when using universal planes, not just overlay planes. Rename uses of 'sprite' to 'plane' to make it clear that it can now be any kind of plane, not just an overlay/sprite. These are currently unused. Signed-off-by: Daniel Stone

[PATCH weston v5 34/42] compositor-drm: Don't repaint if no damage

If we don't have any damage for the primary plane, then don't force a repaint; simply reuse the old buffer we already have. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1499 --- libweston/compositor-drm.c | 9 - 1 file

[PATCH weston v5 26/42] compositor-drm: Refactor sprite create/destroy into helpers

From: Pekka Paalanen This moves the single sprite creation code from create_sprites() into a new function. The readability clean-up is small, but my intention is to write an alternate version of create_sprites(), and sharing the single sprite creation code is

[PATCH weston v5 11/42] compositor-drm: Use signed int for width/height

This makes it sign-compatible with weston_output->{width,height}. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1486 --- libweston/compositor-drm.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git

[PATCH weston v5 42/42] compositor-drm: Atomic modesetting support

Add support for using the atomic-modesetting API to apply output state. Unlike previous series, this commit does not unflip sprites_are_broken, until further work has been done with assign_planes to make it reliable. Signed-off-by: Daniel Stone Co-authored-by: Pekka

[PATCH weston v5 18/42] compositor-drm: Use drm_fb for cursor buffers

Now that we have better types in drm_fb, use it for cursor buffers as well. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1493 --- libweston/compositor-drm.c | 73 +- 1 file changed, 53

[PATCH weston v5 32/42] compositor-drm: Track cursor_plane with a drm_plane

Change the type of cursor_plane from a weston_plane (base tracking structure) to a drm_plane (wrapper containing additional DRM-specific details), and make it a dynamically-allocated pointer. Using the standard drm_plane allows us to reuse code which already deals with drm_planes, e.g. a common

[PATCH weston v5 16/42] compositor-drm: Refcount drm_fb

Sometimes we need to duplicate an existing drm_fb, e.g. when pageflipping to the same buffer to kickstart the repaint loop. To handle situations like these, and simplify resource management for dumb and cursor buffers, refcount drm_fb. Signed-off-by: Daniel Stone

[PATCH weston v5 20/42] compositor-drm: Reshuffle drm_output_render

Call drm_output_render unconditionally, doing an early exit if we're already rendering a client buffer on the primary plane, and asserting for damage on the way out. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1494 ---

[PATCH weston v5 35/42] compositor-drm: Split repaint into helper

We can separate repainting into two phases: one performing the actual repaint (essentially drm_output_render) and populating the plane state that wasn't already populated by drm_output_assign_planes, and another applying this state to the device. Signed-off-by: Daniel Stone

[PATCH weston v5 36/42] compositor-drm: Move DPMS into output state

Extend drm_output_state to also cover DPMS, so we can use it to enable and disable outputs, and always keep a coherent state. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1501 --- libweston/compositor-drm.c | 142

[PATCH weston v5 41/42] compositor-drm: Don't open-code to_drm_output

Use this rather than container_of. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1506 --- libweston/compositor-drm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libweston/compositor-drm.c

[PATCH weston v5 30/42] compositor-drm: Introduce drm_output_state structure

Currently this doesn't actually really do anything, but will be used in the future to track the state for both modeset and repaint requests. Completion of the request gives us a single request-completion path for both pageflip and vblank events. Signed-off-by: Daniel Stone

[PATCH weston v5 22/42] compositor-drm: Introduce fb_last member

Clean up some ambiguity around current/next: current could previously have referred to a buffer which was being displayed, or the last buffer being displayed whilst we waited for a configuration we'd requested to take effect. Introduce a new variable, fb_last, which exclusively holds the latter

[PATCH weston v5 38/42] compositor-drm: Discover atomic properties

Set the atomic client cap, where it exists, and use this to discover the plane/CRTC/connector properties we require for atomic modesetting. Signed-off-by: Daniel Stone Co-authored-by: Pekka Paalanen Differential Revision:

[PATCH weston v5 31/42] compositor-drm: Introduce drm_plane_state structure

Track dynamic plane state (CRTC, FB, position) in separate structures, rather than as part of the plane. This will make it easier to handle state management later, and much more closely tracks what the kernel does with atomic modesets. The fb_last pointer previously used in drm_plane now becomes

[PATCH weston v5 27/42] compositor-drm: Rename fb_plane to scanout_plane

All planes being displayed have a framebuffer. What makes 'fb_plane' special is that it's being displayed as the primary plane by KMS. Previous patchsets renamed this to 'primary_plane' to match the KMS terminology, namely the CRTC's base plane, which is controlled by drmModeSetCrtc in the legacy

[PATCH weston v5 24/42] compositor-drm: Clean up page_flip_pending path

page_flip_pending is set when we do a no-effect pageflip, and thus don't need to release the buffer as we don't have a new one pending. Now we have last/cur/pending properly broken out, we can just use these consistently, and test if last != current (the effect), rather than the specific path

[PATCH weston v5 21/42] compositor-drm: Return FB directly from render

Instead of setting state members directly in the drm_output_render functions (to paint using Pixman or GL), just return a drm_fb, and let the core function place it in state. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1419 ---

[PATCH weston v5 33/42] compositor-drm: Use drm_plane for scanout plane

Use a real drm_plane to back the scanout plane, displacing output->fb_{last,cur,pending} to their plane-tracked equivalents. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1416 --- libweston/compositor-drm.c | 131

[PATCH weston v5 19/42] compositor-drm: Rename current/next FB members

'next' is used as a framebuffer which has either been rendered but not had a configuration request (pageflip or CRTC set) applied to it, or when for a framebuffer that has had configuration requested but not applied (delayed pageflip where the event has not been applied). 'current' is used as the

[PATCH weston v5 40/42] compositor-drm: Add to_drm_mode helper

Much like we already have to_drm_output and to_drm_backend. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1505 --- libweston/compositor-drm.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git

[PATCH weston v5 10/42] compositor-drm: Use fb->fd consistently

Everyone else uses fb->fd rather than pulling the FD back out of GBM. Use that in the destroy callback too. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1406 --- libweston/compositor-drm.c | 3 +-- 1 file changed, 1

[PATCH weston v5 23/42] compositor-drm: Turn vblank_pending from bool to refcount

vblank_pending is currently a bool, which is reset on every vblank requests (i.e. sprite pageflip). This can occur more than once per frame, so turn it into a callback, so we only fire frame-done when we've collected all the events. Signed-off-by: Daniel Stone

[PATCH weston v5 25/42] compositor-drm: Rename drm_sprite to drm_plane

We make the differentiation where planes are an abstract framebuffer with a position within a CRTC/output, and sprites are special cases of planes that are neither the primary (base/framebuffer) nor cursor plane. drm_sprite, OTOH, contains nothing that's actually specific to sprites, and we end

[PATCH weston v5 37/42] [XXX] compositor-drm: Don't restore original CRTC mode

When leaving Weston, don't attempt to restore the previous CRTC settings. The framebuffer may well have disappeared, and in every likelihood, whoever gets the KMS device afterwards will be repainting anyway. XXX: This breaks gamma. Need to work around that. Signed-off-by: Daniel Stone

[PATCH weston v5 03/42] compositor-drm: Remove open-coded weston_compositor_wake

This always changes the state to ACTIVE when we enter the session, whereas the previous implementation preserved the state (i.e. if state was SLEEPING on exit, it would be restored to SLEEPING, but also with a repaint). This seems more helpful behaviour, however: if you enter a session, it's

[PATCH weston v5 39/42] compositor-drm: Add blob_id member to drm_mode

For atomic modesetting support, the mode is identified by a blob property ID, rather than being passed inline. Add a blob_id member to drm_mode to handle this, including refactoring mode destruction into a helper function. Signed-off-by: Daniel Stone Differential

[PATCH weston v5 28/42] compositor-drm: Add universal plane awareness

From: Pekka Paalanen Add awareness of, rather than support for, universal planes. Activate the client cap when we start if possible, and if this is activated, studiously ignore non-overlay planes. For now. [daniels: Rebased, split up, otherwise modified.]

[PATCH weston v5 08/42] compositor-drm: Make scanout view preparation more stringent

Don't import buffers which span multiple outputs, short-cut any attempt to import SHM buffers, and ignore buffers with a global alpha set. I'm not convinced all of these conditions entirely make sense, but this at least makes them equally nonsensical. Signed-off-by: Daniel Stone

[PATCH weston v5 13/42] compositor-drm: Add explicit type member to drm_fb

Rather than magically trying to infer what the buffer is and what we should do with it when we go to destroy it, add an explicit type instead. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1488 --- libweston/compositor-drm.c | 39

[PATCH weston v5 15/42] compositor-drm: Drop output from release_fb

We only need it for the GBM surface the FB was originally created against; a mismatch here is very bad indeed, so no reason to pass it in explictly every time rather than store it. Signed-off-by: Daniel Stone Differential Revision:

[PATCH weston v5 14/42] compositor-drm: Refactor destroy drm_fb function

From: Tomohito Esaki The drm_fb destroy callback to mostly the same thing regardless of whether the buffer is a dumb buffer or gbm buffer. This patch refactors the common parts into a new function that can be called for both cases. [daniels: Rebased on top of fb->fd changes,

[PATCH weston v5 17/42] compositor-drm: Use refcounted FBs for Pixman

When using the Pixman renderer, use drm_fb refcounting explicitly. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1492 --- libweston/compositor-drm.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH weston v5 12/42] compositor-drm: Store width and height inside drm_fb

This will be used so we can later determine the compatibility of drm_fbs without needing to introspect external state. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1487 --- libweston/compositor-drm.c | 24

[PATCH weston v5 07/42] compositor-drm: Reshuffle and comment plane conditions

Try to harmonise the various plane-import paths a little bit, starting with reshuffling and commenting the conditions to do so. Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1413 --- libweston/compositor-drm.c | 79

[PATCH weston v5 02/42] compositor-drm: Delete drm_backend_set_modes

Even if we do have a framebuffer matching the mode, we immediately schedule a repaint, meaning we either do work for no reason, or show stale content before we bring up the new content. Delete this and just let repaint deal with it. Signed-off-by: Daniel Stone

[PATCH weston v5 04/42] Remove DPMS-on when going offscreen

Forcing DPMS on when we lose our session may force an expensive modeset operation, which is pointless if the next consumer (another compositor, or the console) is going to do a modeset. These should force DPMS on regardless. This actively causes problems for the DRM backend, in that it may

[PATCH weston v5 01/42] compositor-drm: Comment struct members

Clarify the difference between crtc_id (DRM object) and pipe (index into drmModeRes->crtcs array, possible_crtcs bitmask). Signed-off-by: Daniel Stone Differential Revision: https://phabricator.freedesktop.org/D1405 --- libweston/compositor-drm.c | 4 ++-- 1 file

[PATCH weston v5 05/42] compositor-drm: Simplify drm_sprite_crtc_supported

No need to walk the CRTC list every time looking for CRTC indices, when we already have the CRTC index stashed away. Taking the plane as an argument also simplifies things a little for callers, and future-proofs for a potential future KMS API which passes a list of supported CRTC IDs rather than a

Re: [PATCH wayland v2 3/3] tests: add scanner tests

On Wed, 16 Nov 2016 13:38:17 +0200 Pekka Paalanen wrote: > From: Pekka Paalanen > > Add tests that ensure that wayland-scanner output for a given input does > not change unexpectedly. This makes it very easy to review > wayland-scanner

[PATCH wayland] Makefile: build also test programs during a normal build

From: Pekka Paalanen Put also test programs into noinst_PROGRAMS so that they get always built. In check_PROGRAMS they are built for 'make check' but not for 'make'. This makes it harder to accidentally break the test programs. Signed-off-by: Pekka Paalanen

[PATCH wayland v2 3/3] tests: add scanner tests

From: Pekka Paalanen Add tests that ensure that wayland-scanner output for a given input does not change unexpectedly. This makes it very easy to review wayland-scanner patches. Before, when patches were proposed for wayland-scanner, I had to build wayland

Re: [PATCH wayland 2/3] Makefile: do not put TESTS into check_PROGRAMS

On Wed, 16 Nov 2016 09:02:00 +1000 Peter Hutterer wrote: > On Thu, Nov 10, 2016 at 11:57:44AM +0200, Pekka Paalanen wrote: > > From: Pekka Paalanen > > > > If you assign TESTS into check_PROGRAMS, you cannot add a test that is > > not

Re: [PATCH 1/3 v4] wayland-server: Add API to control globals visibility

Hi Pekka, > > > [...] > > > Therefore I think this would be a beneficial addition: > > > Acked-by: Pekka Paalanen > > > > So, if I amend the commit message as above and rebase against current > > code, I can add your acked-by? > > Yes! > > As the Ack is for the