Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 08:11:03 -0400 Drew DeVault said: > > what is allowed. eg - a whitelist of binary paths. i see this as a lesser > > chance of a hole. > > I see what you're getting at now. We can get the pid of a wayland > client, though, and from that we can look at

Re: [PATCH] protocol: Add summaries to event parameters

On Tue, Mar 29, 2016 at 05:17:06PM -0700, Bryce Harrington wrote: > On Tue, Mar 29, 2016 at 06:17:38PM -0500, Yong Bakos wrote: > > > > > > From: Yong Bakos > > > > > > All event arg elements now have an appropriate summary attribute. > > > This was conducted mostly in

Re: [PATCH] protocol: Add summaries to event parameters

On Tue, Mar 29, 2016 at 06:17:38PM -0500, Yong Bakos wrote: > > > > From: Yong Bakos > > > > All event arg elements now have an appropriate summary attribute. > > This was conducted mostly in response to the undocumented parameter > > warnings generated during 'make

Re: [PATCH wayland 0/5] add api to inspect the compositor state

On Mon, Mar 07, 2016 at 06:31:30PM +0100, Giulio Camuffo wrote: > This patches add several new functions to: > - get the list of current clients for a wl_display > - get notified of new clients > - get the list of resources for a wl_client > - get notified of new resources for a client > - get the

Re: [PATCH wayland 1/5] server: add listener API for new clients

On Mon, Mar 07, 2016 at 06:31:31PM +0100, Giulio Camuffo wrote: > From: Sungjae Park > > Using display object, Emit a signal if a new client is created. > > In the server-side, we can get the destroy event of a client, > But there is no way to get the created event of it. >

Re: [PATCH] protocol: Add summaries to event parameters

> > From: Yong Bakos > > All event arg elements now have an appropriate summary attribute. > This was conducted mostly in response to the undocumented parameter > warnings generated during 'make check'. > > Signed-off-by: Yong Bakos > ---

[PATCH] protocol: Add summaries to event parameters

From: Yong Bakos All event arg elements now have an appropriate summary attribute. This was conducted mostly in response to the undocumented parameter warnings generated during 'make check'. Signed-off-by: Yong Bakos --- protocol/wayland.xml

Re: [PATCH wayland] Add API to install protocol loggers on the server wl_display

On Wed, Mar 23, 2016 at 04:31:16PM +0200, Giulio Camuffo wrote: > The new wl_display_add_protocol_logger allows to set a function as > a logger, which will get called when a new request is received or an > event is sent. > This is akin to setting WAYLAND_DEBUG=1, but more powerful because it > can

Re: Introduction and updates from NVIDIA

Hi Andy, On 23 March 2016 at 00:12, Andy Ritger wrote: > Thanks for the thorough responses, Daniel. No problem; as I said, I'm actually really happy to see an implementation out there. > On Tue, Mar 22, 2016 at 01:49:59PM +, Daniel Stone wrote: >> On 21 March 2016 at

Re: Introduction and updates from NVIDIA

Hi, On 28 March 2016 at 19:12, Daniel Vetter wrote: > On Thu, Mar 24, 2016 at 10:06:04AM -0700, Andy Ritger wrote: >> eglstreams or gbm or any other implementation aside, is it always _only_ >> the KMS driver that knows what the optimal configuration would be? >> It seems like

Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 08:11:03 -0400 Drew DeVault wrote: > On 2016-03-29 3:10 PM, Carsten Haitzler wrote: > > > I don't really understand why forking from the compositor and bringing > > > along the fds really gives you much of a gain in terms of security. Can > > > > why? > >

Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 07:41:10 -0400 Drew DeVault wrote: > Thus begins my long morning of writing emails: > > On 2016-03-29 12:01 PM, Jonas Ådahl wrote: > Not everyone has dbus on their system and it's not among my goals to > force it on people. I'm not taking a political stance

Re: Collaboration on standard Wayland protocol extensions

Hi, On 29 March 2016 at 13:24, Drew DeVault wrote: > On 2016-03-29 11:45 AM, Daniel Stone wrote: >> Firstly, >> https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html >> is a cliché, but the spirit of free software is empowering people to >> make the change

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 11:45 AM, Daniel Stone wrote: > Firstly, > https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html > is a cliché, but the spirit of free software is empowering people to > make the change they want to see, rather than requiring the entire > world be perfectly

Re: Collaboration on standard Wayland protocol extensions

On Tue, Mar 29, 2016 at 07:41:10AM -0400, Drew DeVault wrote: > Thus begins my long morning of writing emails: > > On 2016-03-29 12:01 PM, Jonas Ådahl wrote: > > > I prefer to think of it as "who has logical ownership over this resource > > > that they're providing". The compositor has ownership

Re: Collaboration on standard Wayland protocol extensions

Hi, On 29 March 2016 at 13:11, Drew DeVault wrote: >> or just have the compositor "work" without needing scripts and users to have >> to >> learn how to write them. :) > > Never gonna happen, man. There's no way you can foresee and code for > everyone's needs. I'm catching on to

Re: fullscreen shell is irrelevant to this (Re: Collaboration on standard Wayland protocol extensions)

This a mistake on my part. I mixed up the two protocols, I don't intend to make any changes to fullscreen-shell. Sorry for the confusion. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 10:25 AM, Martin Graesslin wrote: > > - More detailed surface roles (should it be floating, is it a modal, > > does it want to draw its own decorations, etc) > > Concerning own decoration we have implemented https://quickgit.kde.org/? >

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 10:20 AM, Martin Graesslin wrote: > > - Output configuration > > we have our kwin-kscreen specific protocol for this. You can find it at: > https://quickgit.kde.org/? > p=kwayland.git=blob=9ebe342f7939b6dec45e2ebf3ad69e772ec66543=818e320bd99867ea9c831edfb68c9671ef7dfc47=src >

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 3:10 PM, Carsten Haitzler wrote: > > I don't really understand why forking from the compositor and bringing > > along the fds really gives you much of a gain in terms of security. Can > > why? > > there is no way a process can access the socket with privs (even know the > extra

Re: Collaboration on standard Wayland protocol extensions

On 2016-03-29 8:25 AM, Giulio Camuffo wrote: > If the client just binds the interface the compositor needs to > immediately create the resource and send the protocol error, if the > client is not authorized. It doesn't have the time to ask the user for > input on the matter, while my proposal

Re: Collaboration on standard Wayland protocol extensions

Thus begins my long morning of writing emails: On 2016-03-29 12:01 PM, Jonas Ådahl wrote: > > I prefer to think of it as "who has logical ownership over this resource > > that they're providing". The compositor has ownership of your output and > > input devices and so on, and it should be

fullscreen shell is irrelevant to this (Re: Collaboration on standard Wayland protocol extensions)

On Tue, 29 Mar 2016 00:01:00 -0400 Drew DeVault wrote: > On 2016-03-29 11:31 AM, Carsten Haitzler wrote: > > my take on it is that it's premature and not needed at this point. in fact i > > wouldn't implement a protocol at all. *IF* i were to allow special access, > > i'd > >

Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 12:01:52 +0800 Jonas Ådahl wrote: > On Mon, Mar 28, 2016 at 11:33:15PM -0400, Drew DeVault wrote: > > On 2016-03-29 10:30 AM, Jonas Ådahl wrote: > > > I'm just going to put down my own personal thoughts on these. I mostly > > > agree with Carsten on all of

Re: Collaboration on standard Wayland protocol extensions

Hi, On 29 March 2016 at 05:01, Drew DeVault wrote: > You don't provide any justification for this, you just say it like it's > gospel, and it's not. I will again remind you that not everyone wants to > buy into a desktop environment wholesale. They may want to piece it > together

Re: Collaboration on standard Wayland protocol extensions

On Mon, 28 Mar 2016 09:08:55 +0300 Giulio Camuffo wrote: > 2016-03-27 23:34 GMT+03:00 Drew DeVault : > > Greetings! I am the maintainer of the Sway Wayland compositor. > > > > http://swaywm.org > > > > It's almost the Year of Wayland on the Desktop(tm),

Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 08:25:19 +0300 Giulio Camuffo wrote: > 2016-03-29 6:23 GMT+03:00 Drew DeVault : > > On 2016-03-29 2:15 AM, Martin Peres wrote: > >> I was proposing for applications to just bind the interface and see if it > >> works or not. But

Re: Collaboration on standard Wayland protocol extensions

On Sunday, March 27, 2016 4:34:37 PM CEST Drew DeVault wrote: > Greetings! I am the maintainer of the Sway Wayland compositor. > > http://swaywm.org > > It's almost the Year of Wayland on the Desktop(tm), and I have > reached out to each of the projects this message is addressed to (GNOME, >

Re: Collaboration on standard Wayland protocol extensions

On Sunday, March 27, 2016 4:34:37 PM CEST Drew DeVault wrote: > Greetings! I am the maintainer of the Sway Wayland compositor. > > http://swaywm.org > > It's almost the Year of Wayland on the Desktop(tm), and I have > reached out to each of the projects this message is addressed to (GNOME, >

Re: Collaboration on standard Wayland protocol extensions

On Tuesday, March 29, 2016 9:23:13 AM CEST Peter Hutterer wrote: > On Sun, Mar 27, 2016 at 04:34:37PM -0400, Drew DeVault wrote: > > Greetings! I am the maintainer of the Sway Wayland compositor. > > > > http://swaywm.org > > > > It's almost the Year of Wayland on the Desktop(tm), and I have > >

Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 00:01:00 -0400 Drew DeVault said: > On 2016-03-29 11:31 AM, Carsten Haitzler wrote: > > my take on it is that it's premature and not needed at this point. in fact i > > wouldn't implement a protocol at all. *IF* i were to allow special access, > > i'd simply