C++ binding prototype for wayland

Hi guys, I got a prototype C++ binding for the wayland. It is based on the waylandpp project, but I modified lots and added the server side implementation. Is there anyone has needs for this? This is the github link, https://github.com/shawn-peng/waylandpp Thanks, Yisu(Shawn)

[PATCH wayland 9/9] client: Consume file descriptors destined for zombie proxies

We need to close file descriptors sent to zombie proxies to avoid leaking them, and perhaps more importantly, to prevent them from being dispatched in events on other objects (since they would previously be left in the buffer and potentially fed to following events destined for live proxies)

[PATCH wayland 8/9] client: Replace the singleton zombie with bespoke zombies

Using the singleton zombie object doesn't allow us to posthumously retain object interface information, which makes it difficult to properly inter future events destined for the recently deceased proxy. Notably, this makes it impossible for zombie proxy destined file descriptors to be properly

[PATCH wayland 7/9] client: Simplify some logic in queue_event

Both the blocks in this if/else clause do the same thing, so combine the comparisons into one. No functional change. Signed-off-by: Derek Foreman --- src/wayland-client.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/src/wayland-client.c

[PATCH wayland 6/9] connection: Make wl_closure_destroy() close fds of undispatched closures

When we have a closure that can't be dispatched for some reason, and it contains file descriptors, we must close those descriptors to prevent leaking them. Signed-off-by: Derek Foreman --- src/connection.c | 35 ---

[PATCH wayland 5/9] connection: Close fds from half demarshalled closures

If we fail to demarshal a closure we need to close any fds we've already removed from the buffer. The rest will be cleaned up when client_destroy results in a connection_flush. Signed-off-by: Derek Foreman --- src/connection.c | 5 + 1 file changed, 5 insertions(+)

[PATCH wayland 3/9] tests: Check for wrong fd delivery with zombie objects

If an event attempting to deliver an fd to a zombie object is demarshalled after the object is made into a zombie, we currently leak the fd and leave it in the buffer. If another event attempting to deliver an fd to a live object is in that same buffer, the zombie's fd will be delivered instead.

[PATCH wayland 2/9] tests: Add a test for fd leaks on zombie objects

If a client destroying a resource races with the server generating an event on that resource that delivers a file descriptor, we leak the fd. This test catches the leaked fd. Signed-off-by: Derek Foreman --- Makefile.am | 7 +++- protocol/tests.xml | 43

[PATCH wayland 4/9] connection: Close fds from half marshalled closures

If we fail to completely marshal a closure then we need to close the fds we created with dupfd. Signed-off-by: Derek Foreman --- src/connection.c | 4 1 file changed, 4 insertions(+) diff --git a/src/connection.c b/src/connection.c index 7fe35b5..22bf836 100644 ---

[PATCH wayland 0/9] Stop leaking file descriptors

Turns out there are several different ways to leak file descriptors in libwayland, this is an attempt to show a couple of those via tests, and close them off. patch 1 is, I think, a bug fix for a long standing error where close_fds only works sensible when told to close all the available fds. If

[PATCH wayland 1/9] connection: close_fds() should only remove fds it closed from the buffer

All current callers close all fds, so this has gone unnoticed, but if we close less than all fds with close_fds() we leak all the unclosed ones and ruin further event demarshalling. A future patch will close less than the full buffer's worth of fds, so this is now noticed. Signed-off-by: Derek

Re: [PATCH weston 04/15] libweston: let add/remove_output handle the lists

On 04.04.2017 12:58, Pekka Paalanen wrote: > From: Pekka Paalanen > > A weston_output available to the compositor should always be either in > the pending or the live outputs list. Let weston_compositor_add_output() > and weston_compositor_remove_output() handle

Re: [PATCH wayland] docs: Reference Contributor Covenant

And pushed, thanks for the acks all (including Yong, who forgot the list): To ssh://git.freedesktop.org/git/wayland/wayland 3f2c1946..0eefe99f push -> master Cheers, Daniel On 7 April 2017 at 15:58, Jonas Ådahl wrote: > On Fri, Apr 07, 2017 at 05:48:59PM +0300, Pekka

Re: [PATCH wayland] docs: Reference Contributor Covenant

On Fri, Apr 07, 2017 at 05:48:59PM +0300, Pekka Paalanen wrote: > On Fri, 7 Apr 2017 15:07:56 +0100 > Daniel Stone wrote: > > > All fd.o projects are now covered by the Contributor Covenant. Include a > > reference to this in the Contributing doc, making it clear that we

Re: [PATCH wayland] docs: Reference Contributor Covenant

On Fri, 7 Apr 2017 15:07:56 +0100 Daniel Stone wrote: > All fd.o projects are now covered by the Contributor Covenant. Include a > reference to this in the Contributing doc, making it clear that we are > all expected to behave like human beings. > > Signed-off-by: Daniel

Re: [PATCH weston v10 17/61] compositor-drm: Refactor sprite create/destroy into helpers

On Tue, 4 Apr 2017 17:54:35 +0100 Daniel Stone wrote: > 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

Re: [PATCH weston v10 16/61] compositor-drm: Rename drm_sprite to drm_plane

On Tue, 4 Apr 2017 17:54:34 +0100 Daniel Stone wrote: > 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.

[PATCH wayland] docs: Reference Contributor Covenant

All fd.o projects are now covered by the Contributor Covenant. Include a reference to this in the Contributing doc, making it clear that we are all expected to behave like human beings. Signed-off-by: Daniel Stone --- doc/Contributing | 13 + 1 file changed,

Re: [PATCH weston v10 15/61] compositor-drm: Clean up page_flip_pending path

Hi Pekka, On 7 April 2017 at 14:55, Pekka Paalanen wrote: > Reviewed-by: Pekka Paalanen > > Btw. I'll get rid of the phab tags and dual-SoB when I push. Unless > someone else pushes first. :-) Thanks! I left them there for later patches

Re: [PATCH weston v10 15/61] compositor-drm: Clean up page_flip_pending path

On Tue, 4 Apr 2017 17:54:33 +0100 Daniel Stone wrote: > page_flip_pending is only be set when do a pageflip to a newly-rendered > buffer; if the flag is not set, we have landed in the start_repaint_loop > path where the vblank query fails, and thus we must pageflip to the

Re: [PATCH weston v10 14/61] compositor-drm: Turn vblank_pending from bool to refcount

On Tue, 4 Apr 2017 17:54:32 +0100 Daniel Stone wrote: > 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 >

Wayland Virtual Keyboard

Hello, I'm working on an embedded device where we are writing our own custom Wayland compositor, and we have need of a virtual keyboard (something implementing one of the text-input protocols). Does anyone know of such a project? My searches turned up maliit (https://github.com/maliit), but I was

Re: [PATCH weston] compositor-drm: correctly set the version of the drmEventContext

Hi Emil, On 4 April 2017 at 18:07, Emil Velikov wrote: > We implement v2 so use that instead of the DRM_EVENT_CONTEXT_VERSION > macro. > > The latter defines the version of the drmEventContext struct declared in > the header [used in the current build] and can be 2, 3

Re: [PATCH weston v10 13/61] compositor-drm: Introduce fb_last member

Hi, Thanks for the review, and earlier merges too! On 7 April 2017 at 13:57, Pekka Paalanen wrote: > On Tue, 4 Apr 2017 17:54:31 +0100 > Daniel Stone wrote: >> @@ -1593,10 +1619,16 @@ drm_output_switch_mode(struct weston_output >> *output_base,

Re: [PATCH weston v10 13/61] compositor-drm: Introduce fb_last member

On Tue, 4 Apr 2017 17:54:31 +0100 Daniel Stone wrote: > Previously, framebuffers were stored as fb_current and fb_pending. > In this scheme, current was the last buffer that the kernel/hardware had > acknowledged displaying: a framebuffer would be created, set as >

Re: [PATCH weston v10 12/61] compositor-drm: Return FB directly from render

On Tue, 4 Apr 2017 17:54:30 +0100 Daniel Stone wrote: > 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. > > This brings damage handling in

Re: [PATCH weston v10 02/61] libweston: Add pixel-format helpers

On Wed, 5 Apr 2017 16:42:07 +0300 Pekka Paalanen wrote: > On Tue, 4 Apr 2017 17:54:20 +0100 > Daniel Stone wrote: > > > Rather than duplicating knowledge of pixel formats across several > > components, create a custom central repository. > > > >

Re: [PATCH weston 3/3] build: make libdrm a hard build-time dependency

On Thu, 6 Apr 2017 15:22:39 +0200 Quentin Glidic wrote: > On 4/6/17 2:09 PM, Pekka Paalanen wrote: > > From: Pekka Paalanen > > > > Libdrm provides headers that are useful even without libdrm.so itself, > > particularly