Re: Why do I require a `wl_event_loop_add_idle` in creating a fork-exec wayland client

On 2018/7月/11 09:42, Sichem Zhou wrote: > Hi All, > > I have a question related to the wl_client creation in the compositor. I > followed these step like weston did: > > 1. create socketpair. > 2. fork a process and close `socket[0]` in child, close `socket[1]` in in > parent process. > 3. set

Re: [PATCH] server: add wl_signal_emit_safe

On 2018/July/13 05:40, Simon Ser wrote: > This new function allows listeners to remove themselves or any > other listener when called. This version only works if listeners > are properly cleaned up when the wl_signal is free'd. This is about free()ing the wl_listener in the actual handler, not the

Re: [RFC wayland-protocols] unstable: add protocol to give focus to a foreign surface

On 2018/7月/05 04:26, David Edmundson wrote: > This protocol is to address the following use case. > > A user clicks on a URL link in an IRC chat and a web browser opens. We want > an existing browser window to raise or if it's a newly spawned application > to claim focus on startup. > >

Re: [PATCH] libwayland: Add WAYLAND_DEBUG_INTERFACES

the supplied whitelist approach is the best way to go, or this should be a blacklist in practice. On 2018/6月/29 10:43, w...@ongy.net wrote: > From: Markus Ongyerth > > Add environment variable WAYLAND_DEBUG_INTERFACES for filtering the > output of WAYLAND_DEBUG logs. > Whil

Re: client: remove definition of wl_global

Hi, I once again seem to be missing the original message for some reason, so if I failed to properly fix up my headers again, I'm refering to [1] Reviewed-By: Markus Ongyerth [1] https://patchwork.freedesktop.org/patch/204915/ Cheers, ongy signature.asc Description: PGP signature

Re: [PATCH v3 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

On 2018/6月/22 08:00, Dorota Czaplejewicz wrote: > On Fri, 22 Jun 2018 12:36:16 -0400 > Simon Ser wrote: > > > On June 22, 2018 4:20 PM, Dorota Czaplejewicz > > wrote: > > > Provides the ability to emulate keyboards by applications. Complementary > > > to input-method protocol. > > > > > > The

Re: Session suspension and restoration protocol

On 2018/6月/19 01:39, Simon McVittie wrote: > On Tue, 19 Jun 2018 at 13:56:22 +0200, Markus Ongyerth wrote: > > P.S. I just thought about this ab it more, and something else came to my > > mind: > > How is env passed with dbus activation? afaik the session bus does not r

Re: Session suspension and restoration protocol

On 2018/6月/19 01:22, Simon McVittie wrote: > On Tue, 19 Jun 2018 at 11:18:17 +0200, Markus Ongyerth wrote: > > On 2018/6月/18 05:05, Roman Gilg wrote: > > > * using D-Bus interface only to secure against sandboxed clients > > What? Why exactly? When I first read this, I

Re: Session suspension and restoration protocol

On 2018/6月/19 11:18, Markus Ongyerth wrote: > Hey Roman, > > first a general remark: > I don't see any mention of which state is supposed to be restored. The > workspace (virtual desktops), geometry (session-restore), just client-side > window (the embedded usecas

Re: Session suspension and restoration protocol

Hey Roman, first a general remark: I don't see any mention of which state is supposed to be restored. The workspace (virtual desktops), geometry (session-restore), just client-side window (the embedded usecase)? Is this left implementation-defined intentionally? If so, I think it would be nice

Re: [PATCH] virtual-keyboard: Add new virtual keyboard protocol

On 2018/5月/18 07:23, roderick.colenbran...@sony.com wrote: > Hi Dorota, > > Thanks for sharing your proposal. Ourselves we have interest in this > kind of capability as well. Looking at our own use cases, I wonder if > this proposal goes far enough. > > We are basically interested in the

Re: libinput varlink implementation?

A quick glance at varlink makes me like it more than dbus, but I'm not sure it's the best choice to provide debug information about libinput configuration in compositors. All compositors I'm aware of, provide an IPC method for some (more or less) internals. GNOME (and afaik KDE) have dbus,

Re: [PATCH] Add layer-shell-unstable-v1.xml

Hi, butting in On 2018/May/08 04:17, Daniel Stone wrote: > > > [... details snipped ...] > > > > These ideas are still somewhat nebulous but I'm confident enough that > > it'll work that I think we can proceed with the discussion on protocols > > like layer-shell. Compositors which are

Re: [PATCH v2 1/2] weston-info: Add support for tablet-unstable-v2

Hi, thanks for the feedback, I'll provide a v3 shortly. I just have a few follow up questions, before I do so. On 2018/April/27 04:55, Peter Hutterer wrote: > On Thu, Apr 26, 2018 at 05:01:23PM +0200, w...@ongy.net wrote: > > From: Markus Ongyerth <w...@ongy.net> &g

Re: [PATCH v2 0/3] Deal with destroy signal use after free issues

ows. But I don't think that's a deal breaker. For Patch 1/2: Reviewed-by: Markus Ongyerth <w...@ongy.net> I'm fine with moving/resubmit of my code and am happy I could provide the testcase that shows an issue. Since it's originally authored by me, I guess my R-B would be weird there

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

l. Saying 'but the clients > never asked _not_ to be decorated' wouldn't really help you get out of > it either. Which is in a specialised environment that usually wants no deco (probably fullscreen shell by default etc.) but may run xdg-shell for reasons. On 2018/3月/18 03:40, Markus Ongyerth wrote: >

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

On 2018/3月/18 01:45, Daniel Stone wrote: > Hi Drew, > > On 15 March 2018 at 16:53, Drew DeVault wrote: > >> > In fact, I have done so. Before we started working on this protocol, > >> > Sway did exactly this. We have provided users the means of overriding > >> > the approach to

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

On 2018/3月/18 10:50, Eike Hein wrote: > > > On 03/16/2018 12:43 AM, Daniel Stone wrote:> No, it really has. GTK+ has > always - well, until you got the patches > > for this protocol merged a month or two ago - decorated its own > > windows under Wayland. Same with Qt. Same with EFL. These are

Re: [PATCH] unstable: add xdg-session-management protocol

On 2018/2月/26 08:58, Mike Blumenkrantz wrote: > for a variety of cases it's desirable to have a method for negotiating > the restoration of previously-used states for a client's windows. this > helps for e.g., a compositor/client crashing (definitely not due to > bugs) or a backgrounded client

Re: [PATCH 1/1] tests: Add free-without-remove test

On 2018/2月/23 08:53, Derek Foreman wrote: > On 2018-02-23 07:44 AM, Markus Ongyerth wrote: > > On 2018/2月/23 07:31, Derek Foreman wrote: > > > On 2018-02-23 03:52 AM, w...@ongy.net wrote: > > > > From: Markus Ongyerth <w...@ongy.net> > > > > &

Re: [PATCH 1/1] tests: Add free-without-remove test

On 2018/2月/23 07:31, Derek Foreman wrote: > On 2018-02-23 03:52 AM, w...@ongy.net wrote: > > From: Markus Ongyerth <w...@ongy.net> > > > > This is related to the discussion earlier on the mailing list and > > demonstrates a problem with current wl_priv_signal_e

Re: [RFC wayland] server: Add special case destroy signal emitter

Hi, I have a v2 RFC _emit_final based on your idea. It passes `make check` of libwayland and weston. It also passes the remove-without-free test I sent in another mail. --- (This patch isn't quite intended to be merged, but to get feedback on the approach) This adds a wl_priv_signal_emit_final

Re: [PATH] core: implement a safe wl_signal_emit

On 2018/2月/22 12:31, Derek Foreman wrote: > On 2018-02-22 10:48 AM, Markus Ongyerth wrote: > > On 2018/2月/22 09:34, Derek Foreman wrote: > > > On 2018-02-22 08:58 AM, Daniel Stone wrote: > > > > Hi, > > > > > > > > On 22 Februar

Re: [PATH] core: implement a safe wl_signal_emit

On 2018/2月/22 04:53, Daniel Stone wrote: > Hi ongy, > > On 22 February 2018 at 16:03, Markus Ongyerth <w...@ongy.net> wrote: > > On 2018/2月/22 02:58, Daniel Stone wrote: > >> On 22 February 2018 at 14:14, Markus Ongyerth <w...@ongy.net> wrote: > >&

Re: [PATH] core: implement a safe wl_signal_emit

On 2018/2月/22 09:34, Derek Foreman wrote: > On 2018-02-22 08:58 AM, Daniel Stone wrote: > > Hi, > > > > On 22 February 2018 at 14:14, Markus Ongyerth <w...@ongy.net> wrote: > > > > It seems that this patch makes that assumption invalid, and we would > &

Re: [PATH] core: implement a safe wl_signal_emit

On 2018/2月/22 02:58, Daniel Stone wrote: > Hi, > > On 22 February 2018 at 14:14, Markus Ongyerth <w...@ongy.net> wrote: > >> It seems that this patch makes that assumption invalid, and we would > >> need patches to weston, enlightenment, and mutter to pre

[PATH] core: implement a safe wl_signal_emit

> Since a destroy signal inidicates the object is utterly dead, I don't think > it's unreasonable for users to have assumed that they don't have to clean up > their listener link. It's *never* going to fire again, so why should > anything need to be removed? This only implies that the signal